Where does RIoT fit ?

Selsinork,

Would 'available development tools' or 'ease of programming' make a difference here? I'm more into the 'bare metal' microcontroller programming than into the Linux based stuff, but I know I really like Atmel & EnergyMicro because of their documentation and good tooling, whereas others provide very little info or badly documented stuff  or very meager peripherals (ST still has to learn a bit..). That's why cost/features is not the only option there.

Does this also apply to the SBC market, or is any box running Linux equally simple in development apart from the obvious difference in interfaces?

I don't intend to start a flamewar here on which one is better than which other, I'm just interested how my view from chip programming maps to SBC programming.

The difference for these SBC's is that you can essentially run exactly the same version of Debian on top of all of them, so the development tools are identical.  Also, most software you'd find on another linux machine (server/desktop/laptop/phone) will work on the SBC with a simple re-compile.  So from that perspective the playing field is mostly level.

Documentation can be an issue, yes.  It's why you'll frequently see me asking for schematics, gerbers etc. It's all very well knowing your code is talking to gpio12 but if you don't know how that maps to the 150+ pins that the manufacturer has named differently then you're not getting anywhere fast.

There are basically three major SoC vendors represented here, TI (am3359/omap), Freescale (i.MX6), Allwinner (A10/A20), four if you count Broadcom with the RPi.

Freescale and TI have mountains of docs, the am3359 TRM is 4100 pages, the iMX6 equivalent is 5700. In comparison, Allwinner is much worse, but uses much more in the way of standard blocks so it's not been a huge problem. Broadcom comes in last, but still with enough docs to make the RPi useful. 

All of them have their closed areas, you'll see most complaints around that for the RPi but that's mainly down to a design choice where the RPi SoC is really a GPU with an Arm afterthought. The others don't have the Arm subservient to the GPU, but the gpu's are still mostly an undocumented black box.

Generally most of the boards have a good range of peripherals, so the two questions become:

1. is there a driver for the peripheral on this SoC or not ?

2. did the board designer make the necessary pins available, multiplex another function on top of them, or leave them disconnected?

My experience says those two are fairly relevant for microcontrollers as well. For example, I've seen Microchip PIC stuff where you can have I2C channel 2 or UART2, but not both as they use the same pins.

Linux acts as a big abstraction layer.  For example if I want to talk to some I2C sensor then as long as I use the provided /dev/i2c<n> API my code should work on any board that has an I2C driver. I may need to change /dev/i2c0 to /dev/i2c1 but otherwise the code should just work.  So the advantage becomes that I don't need to change the code when I pick a different board. That benefit obviously also has costs, you don't get the real-time performance or guarantees you do with bare metal microcontroller work. 

There's nothing to stop you doing bare metal coding on an SBC though, but that's a trade-off too. Yes it can probably do a lot more, but that comes with a level of complexity that you need to deal with yourself.

When SBC's were $200 and upwards it simply wasn't cost effective and most of my stuff was with microcontrollers, SBC's at $20 with a standard OS compatible across the majority of them changes things. Both SBC's and microcontrollers still have their place.

Thanks a lot for your elaborate explanation! I -kind0of-had-that-in-my-mind, but very happy to hear it from the hands-on expert!

I'm a bit addicted to the power of 'bare metal' programming (making measurement devices most of the time I have to be sure about what happens when), and of course I'm very pedantic about garage door openers that use a RasPi where an AtTiny could have sufficed. But the power of easy software development does have its merits! Setting up a webserver in 6 lines of Node.js on the BBB dropped my jaw

Easy software development has it's downsides too, things become bloated or slow because the developer can abuse the ample resources. Which in turn leads to demand for more resources.  Many of todays programmers would do well to take a leaf out of your book and do some development on microcontrollers, the experience is invaluable in writing efficient code.

For the RPi garage door opener, I tend to agree. From the other side though, you could build one that lets you answer the door remotely with video and audio to your phone, talk to the delivery driver, open the garage door for him to leave the package... When the garage opens he'll see himself on the monitor in the wall being recorded, along with video of you watching him... So the SBC opens possibilities that are less easy to accomplish with an AtTiny    That's a big part of why I like SBC's, more possibilities that are often easier to accomplish.

I'm not at all bashing microcontrollers, I've done that too. Having 1K of program memory and 128 bytes of ram forces you to think differently. Using that experience probably means you can see far more possibilities for what you could do with an SBC.

It gets interesting when it works out that the SBC and microcontroller boards cost essentially the same. You can then start thinking that you can have that 6 lines of node.js done and your app running in five minutes..

Easy software development has it's downsides too, things become bloated or slow because the developer can abuse the ample resources. Which in turn leads to demand for more resources.  Many of todays programmers would do well to take a leaf out of your book and do some development on microcontrollers, the experience is invaluable in writing efficient code.

For the RPi garage door opener, I tend to agree. From the other side though, you could build one that lets you answer the door remotely with video and audio to your phone, talk to the delivery driver, open the garage door for him to leave the package... When the garage opens he'll see himself on the monitor in the wall being recorded, along with video of you watching him... So the SBC opens possibilities that are less easy to accomplish with an AtTiny    That's a big part of why I like SBC's, more possibilities that are often easier to accomplish.

I'm not at all bashing microcontrollers, I've done that too. Having 1K of program memory and 128 bytes of ram forces you to think differently. Using that experience probably means you can see far more possibilities for what you could do with an SBC.

It gets interesting when it works out that the SBC and microcontroller boards cost essentially the same. You can then start thinking that you can have that 6 lines of node.js done and your app running in five minutes..