ARM board evaluation

[zoneblue]

The ARM microcomputer board is the heart of the blackbox project. Whether or what form an additional microcontroller is added in, is another matter. But ARM boards have the right combination of resources and power consumption to handle primary storage and communication.

It would be good if we could accumulate what we know about each board in one place. The TBB wiki is the obvious place, but here will also do. Anyone what wants edit rights to the wiki let me know.

I will start by moving my Cubieboard1 install writeup to the wiki. I guess ordering a black and cubie2, will be the next step, and one or two of these cheap hackable android set top boxes. They have the advantage of having a case and wifi built in.

While atom silvermont has now been released i expect it will be a while before we see Bay trail miniitx or smaller boards. Maybe next year, but they should be awsome too.

[Gregy]

Below link has a very comprehensive matrix of ARM boards
No sense in replicating the data collection ...
We just need to determine the characteristics that are important for BB core platform
Albeit No details on GPIO (except a yes or no) .... So if we want to capture
Greater detail on GPIO we will need to look further...

http://socialcompare.com/en/comparison/arm-boards

[Gregy]

Comparison of RPi vs cubieboard

http://blog.bulte.net/01-09-2013/cubie-board-quick-look-raspberry-pi-comparison.html

When you look at the benchmark graphs - easy to see where RPi has performance deficiencies
In areas that are important for BBP
(Not detracting of course from RPi  capabilities on graphics for multimedia etc ... But these are not relevant for BBP)

Summary : IMHO  cubieboard much better suited than RPi for the BBP core

[Gregy]

Comparison of rpi vs beaglebone (not black) vs arduino

http://makezine.com/2013/04/15/arduino-uno-vs-beaglebone-vs-raspberry-pi/

In particular the summaries near bottom of article help put into perspective the relevant
Benefits and likely positioning of arduino vs beaglebone for different tasks

Note the beaglebone is not the black version, however we can generalize the beaglebone
Comments as relevant for most of the ARM type platforms (cubieboard, beaglebone black etc)
As compared to arduino

Summary:  IMHO continues to support my thinking on the role of ardunio as a sensor module for BBP,
Particulary for a low cost "remote" and "distributed sensor" module
(See my separate thread on core vs sensing modules)

[dgd]

The ARM microcomputer board is the heart of the blackbox project. Whether or what form an additional microcontroller is added in, is another matter. But ARM boards have the right combination of resources and power consumption to handle primary storage and communication.

Yes I see thats the way the BBP is going as far as hardware platform is concerned
I'm not sure the current ARM systems such as rPi, Beagle, cubie etc should really be the 'heart' of the BBP system. APart from the ultra low power aspect I think the resources, or lack of them, is a major restriction on doing any decent data processing.

I would be happy to use something more 'normal', eg a PC running Linux, the 24hour power needed can be significanty minimised so that power consumption becomes a non issue. Then web server, web pages, libs, C compilers, rtc, serial and ethernet comms all become so much easier to apply and manage. Working memory and storage restrictions dont apply.

Anyway, I speak only from experience of using the rPi and I wouldn't seriously give it any significant data processing to do

Or what about the BBP functionality being defined, core and desirable, then the processor options looked at to see what can be implemented on each?  Is that where Gregy is heading?

dgd

[Gregy]

Beaglebone black. ("Black") IO

http://circuitco.com/support/index.php?title=Cape_Expansion_Headers

65 digital GPIO. (3.3V)  each can generate an interrupt
8 PWM and 4 timers
7 ADC. (1.8V)
4 serial UARTs (official site say "4.5" )
2 SPI ports
2 I2C ports

Accessible via 2x46 Pin expansion headers
Black has "capes" (analogous to "shields") that plug into the headers to provide expansion support

Summary : very impressive IO capability on board ...
IMHO More than enough for "local" sensing for BBP
black has the greatest "onboard" IO support (as compared to cubieboard and RPi)

[Gregy]

DGD
Agree with your thoughts

My assumption ( but I have zero Linux knowledge) was that it can largely operate independant
Of the underlying platform (probably a gross over simplification)
And hence BPP could "scale" onto different platforms - albeit at present ARM based ?

It's clear that as each new iteration of ARM boards emerges .. The capability and performance goes up.
But certainly RPi will be under powered c/w black and cubie
but will they be enough? As number sensors increases, and as we go beyond ..
capture/log/graph ..  I leave this to you Linux and programming experts (I have no clue)

I already have a HA PC (win os) that will need to run (in discretionary mode)
..  already looking at DC Power supply options To run a ruggedized  lower power motherboard version
So your point has merit ...

Q; is how easy (or hard) is it to "port" it to a different Linux platform?

As to your question about where am I heading
My thinking was to define a structure that segregated functionality - that could be matched against
The respective h/w demands
Eg use arduino for the  distributed sensor nodes (where low cost and low PWR are amongst critical factors)
Vs the "core" platform h/w... That has different requirements (non volatile storeage, memory, network connectivity
Processing power etc)

[zoneblue]

Im no big arm fan. For one its such a cowboy environment that debian installer isnt able to support most of these devices out of the box.

But as far as efficency goes the power consumption to cpu speed is currently unbeatable. BB pages render as quick on a 1.25W cubieboard as they do on a 20W atom.

20W, 24/7, is about as much as a fridge, so unless that thing has other core uses, NAS, backup whatever, then its not the right tool for the job. As i said i do have high hopes for the next generation of atoms, intel has finally  figured out that the world has gone mobile and so i fully expect better x86 options to  emerge first quarter 2014. Intel claims 3-5 times more efficient.

But i agree, the point is to make the thing portable, able to be run on ARM A8 'or better'. 

However there'd be a few catchs to that if we start relying on i2c or gpio, which arent standard gear on traditional motherboards.

Meantime in terms of software development, i am currently playing a bit of a cat and mouse game, optimising, developing, optimising to make best use of finite cpu cycles. Theres plenty left to optimise so im not too worryed about it.

Power consumption is key.

[Gregy]

I was planning a dissertation on "interfaces for BBP"  in my other thread
I was working up to it ... By demonstrating the large number different interfaces across
The various sensors categories (and I just posted another!)

So i can see that zoneblue has recognized the "dilemma"
And quite correctly that some ARM. Boards have much greater GPIO than others and
Certainly mainstream intel type boards usually don't have these as native.

More and more this is pushing my thinking about separating the BBP core functions from sensors,
And limit the use of onboard GPIO on the BBP core platform
So BBP can more easily transport across different ARM and intel platforms

[zoneblue]

Which takes you to a daughter board of some kind that talks to the sensor satelite units, either near or far. Right?

Arduino plus ethernet, plus zbee, plus rtc plus ? Or a custom board containing same?
Webcontrol wont work for that as its bus challenged, right?

[Gregy]

Yep exactly

if you see my post on AC power energy sensing (reply #10)
http://midniteforum.com/index.php?topic=1439.msg11911#msg11911

At least one of those "daughter boards" would be the emonBASE for the Openenergymonitor
Device - with its using RFM12 wireless to get data from emonTX module,
Which effectively makes it a wireless gateway that can listen for other nodes,
In this case it's a Ethernet gateway - so no requirement of using any GPIO on the BBP core .. The ultimate daughter board .. Eg it's all interfaced thru sw over Ethernet

And as the emonBASE is based on nanodeRF - which in turn can also communicate with other sensing
Nodes wirelessly .. Then this should be able to be a generic wireless gateway  for when wireless sense modules are required ... I'm still getting my head around this ... Hence why as yet I haven't posted the wireless modules and BBP interfaces dissertations in my BBP senses modules thread
... But like most of the other posts ... It's probably going to be large..ish
Sorry about all the reading ... But it's a collection of info that I'm using at least for nothing else to collect my own thoughts

[Gregy]

Webcontrol uses Ethernet interface
So it works great as part of an Ethernet connected sensor node, but if you need more than 3ADC,
Then it's "IO challenged ". (But It does have good digital IO)

I assume thats what you meant by "bus challenged"?

[RossW]

Webcontrol uses Ethernet interface
So it works great as part of an Ethernet connected sensor node, but if you need more than 3ADC,
Then it's "IO challenged ". (But It does have good digital IO)

You're being a bit harsh on the WC.

1. It has 3 x 0-10V ADC
2. It ALSO has a 0-5V ADC (normally used for a humidity sensor)
3. It ALSO supports up to 8 DS18B20 sensors
4. It ALSO supports up to 8 TTL digital inputs
4a. (One of those can be used as a counter or a frequency input up to about 2MHz)
5. With the addition of a single chip add another 4 channels http://tinyurl.com/lgfu9zn

Or, wait for the WC32 which support 16 TTL in, 8 ADC and 16 DS18B20.

[Gregy]

No harshness intended
It was "only" the 3ADC case I was referring.. (And I did mention "Good digital IO")

But you raise great points
Q can the 0-5ADC be generally accessed? I may have incorrectly interpreted as "reserved for humidity"
Q: the tiny chip adds what type of additional 4ch?

What is your experience with the DS18B20 sensors on CAI?
If I understand correct, they have to be run in non parasitic mode ?
I had read that there may be other constraints introduced when running a larger number? 
Slows down the sensing ? Or something along those lines?

[RossW]

But you raise great points
Q can the 0-5ADC be generally accessed? I may have incorrectly interpreted as "reserved for humidity"
Q: the tiny chip adds what type of additional 4ch?

The link provided was to the 20mA input device. They also make an identical unit (just doesn't have the shunt resistors) that measures 0-5V on each channel. I have a couple of those myself and it works quite well.

What is your experience with the DS18B20 sensors on CAI?

Extensive.  I ship (temperature) dataloggers all over the place that use them. http://logging.net.au
I also make them into a fully remote/mobile setting:


These generally include a 3G cellular modem:

If I understand correct, they have to be run in non parasitic mode ?
I had read that there may be other constraints introduced when running a larger number? 
Slows down the sensing ? Or something along those lines?

There is a maximum bus length, which depends on topology, cable characteristics and number of sensors. I have heaps of these things running 8 x 3m sensors in "star" topology (which is admittedly not optimum).

I believe they bitbash the onewire protocol on the WC8 boards, but use a dedicated onewire controller on the new WC32.

The longest lead I ran so far was 7 x 3m + 1 x 20m (ie, 41 metres of cable), and it was perfectly reliable. I did add a 4K7 pullup on the far end of the 20m cable though, which helped.