Using a SBC in a final product - Page 1
Forum section: electronics / general

author: darko31
author_rank: Regular Contributor
timestamp: May 10, 2017, 08:45:03 pm
content: Hi guys, what is your advice and experience for using SBC in a final product? Product constraints are:- low production run, less than 1000 units- BLE and/or WiFi enabled, but has to be able at least partially to work without internet connection- controlling several stepper motors and a brushless/brushed DC motor and few optical sensors- user controllable via mobile app, or web interface. no display on the product itself (user uploads a "script/program", then plays it)- product sends data back to mobile app or a server, so user can track his or her progress- security, some sort of encryption should be supported- price is not that much of concern as long is not something ridiculously expensiveI'm having a discussion with my colleague, he is biased towards SBCs (something like NanoPi Neo Air, Raspberry variations etc) or a custom board with SoC, I'm biased towards MCUs (stuff like nRF52840, STM32s with BLE or WiFi modules etc).He claims that software development is easier on SBCs, which I do fully agree, but I don't think that this project is complicated enough to require an OS. Also MCUs are easily accessible, while specific SoCs are not, outside of China, and SBC manufacturers are not that reliable and designing custom PCB for a SoC would take a good chunk of time.What is your take on something like this? Where is the line where you absolutely need fully fledged mini PC and OS, or to rephrase, the line where MCU isn't going to cut it?

author: suicidaleggroll
author_rank: Super Contributor
timestamp: May 10, 2017, 08:58:21 pm
content: That's a good question. The main issue with having MCUs drive the main user interface, in my experience, is configuration. Especially when it comes to Wifi. Are you planning on it hosting its own Wifi network that the user would have to connect to? If so, that causes problems with connecting to this device and others simultaneously. Are you planning on having this Wifi device join an existing network? How will the user tell it what SSID and key to use? How robust is the auto-reconnection, and how easily can it be reconfigured? Also sometimes devices like this need to be deployed in remote, unmanned locations. How will you handle any necessary port forwarding, firewalling, data logging, remote reconfiguration, etc?Meanwhile, SBCs with full OSs handle all of those questions with ease, but introduce problems of their own...namely obsolescence. OSs move fast, and many times kernel updates can inadvertently break seemingly unrelated things. Once you develop for a specific version of a specific OS, you oftentimes need to shut off updates and just live there until you can invest the time necessary to update to a new release, re-qualify all of your software and interfaces, etc. Also the hardware itself goes obsolete on a very regular basis. Most SBCs in my experience have a realistic lifetime of maybe 3-6 years. Go past that and it will be increasingly hard to find new SBCs, which means redesigning your adapter board to suit whatever replacement SBC you choose. This is where something like the 96Boards initiative helps, they specify a common form factor, including size, connector locations, voltages, and pinouts, and let manufacturers build to those specs. Theoretically any device you build for one 96Boards-compatible device will plug straight into another one. This helps to fight the hardware obsolescence issue, but you still have the software problem mentioned above.Personally, if I have a project that can be done on an MCU and doesn't have an interface any more complicated than USB or serial, I'll use an MCU. As soon as the processing requirements or interface requirements surpass that limitation, or it's a device that has a very real chance of being installed in a remote, unmanned location, I typically move to an SBC with a real OS.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2017, 11:30:39 pm
content: When going for a SoC you'll want guaranteed long term availability so that leaves device from TI and NXP (formerly Freescale) on the table. I have done several of these designs with both full custom boards and modules. Unfortunately modules seem to have availability and obsolence issues as well. The OS running on a SoC is likely Linux. Even with a software package provided by the manufacturer (called a BSP) this will need a work to debug and get it running stable.Back to your project: if you can contain BLE and/or Wifi in a module with guaranteed availability then I don't see why this couldn't work on a microcontroller. I wouldn't be too quick to jump on the RTOS bandwagon because real multi-tasking where tasks are interrupted at random will come with thread synchronisation issues which are a PITA to get right.

author: krho
author_rank: Regular Contributor
timestamp: May 11, 2017, 04:44:26 am
content: The other option is to add a small MCU to handle a realtime task e.gQuotein OPs case and handle file parsing and all the gruesome parts on a SBC.

author: mubes
author_rank: Regular Contributor
timestamp: May 11, 2017, 07:51:02 am
content: Quote from: darko31 on May 10, 2017, 08:45:03 pmOh, how many times have I heard this one? I'm gonna bite, and probably start a religious warIf you like it or not, your application is going to deal with issues like task synchronisation, priority, scheduling and timers. That's an OS. You can either implement that yourself, or you can get something off the shelf that already does it. The only thing that's really under debate is where the crossover is between implementing that functionality yourself because it's simple and straightforward, and learning an OS and dealing with the overhead of it. The fact is, based on a _lot_ of experience, I'm 100% convinced that crossover is at a much lower level of complexity than you think it is....this isn't an opinion based on conjecture, it's based on a fair bit of experience of doing it both ways....and getting it wrong both ways too. In the olden days I was _very_ anti-OS, but eventually you realise that all your embedded patterns for building these systems are an OS in disguise really anyway....look at this (https://github.com/mubes/leater/blob/master/src/main.c) for a perfect example of what I mean.Nowadays, our guys sometimes start off with the "I don't need no OS" position, and I almost always argue (bully?) them into it. On day one you certainly don't need an OS, but by the time your application reaches the level of complexity that does need it, you've got too much of a ball of wax to install one without quite some pain....so you continue without one, arguing that you really don't need it (while simulteneously trying to implement cludges to give you task priority, or whatever aspect of an OS it is that you're actually needing for this specific app).An OS does of course come with some cost/overhead; Execution (generally, for deeply embedded, about 1-5% or so in my experience) and Size (Depends on what we're talking about...anything from 2K to 200M!)...in a modern CPU environment I would consider those acceptable collateral damage unless I'm under huge (generally battery lifetime) constraints. However, the biggest single issue with a standard OS for an embedded application is the increase in attack surface that it creates...and a standardised attack surface, at that....and that one I don't have good defences against, except to say that security by obscurity is a mirage, and chances are that the off-the-shelf OS will have been considerably more hardened than my attempt.For your specific applciation where you will have real time control issues (the motors, for example) and external interfaces I would consider something like the iMX7 which will give you Linux (or BSD or whatever) for the high level stuff and a CORTEX-M4 (FreeRTOS, RTX, NuttX etc) for the low level stuff....and partitioned development between the 'user facing' and 'machine facing' sides. Varicite and Toradex have long lifetime modules that will meet your supply needs, and prices are surprisingly reasonable.Let the squabbling begin.RegardsDAVE

author: westfw
author_rank: Super Contributor
timestamp: May 11, 2017, 09:03:05 am
content: Quotethe level of networking you describe pretty much requires some sort of OS *somewhere*. It might be buried inside some sort of networking module, but it can be a lot more "comforting" to have it in source code somewhere where you can keep an eye on it. :-)You could always design it for either one (which is probably good for code modularity/etc, anyway), and see if one eliminates itself by complexity, or price. (at the "one" level, something like a RPi is as cheap or cheaper than designing a microcontroller, but I'm not sure how things scale up to that 1000 unit mark. RPi-zero essentially dribbles out as rationed loss-leaders...)

author: darko31
author_rank: Regular Contributor
timestamp: May 11, 2017, 10:39:01 am
content: Thank you everyone for replies, it's very helpful to hear opinions from people with far more experience.I'm not really against an OS, I'm against overly complicating the thing since we haven't yet fully defined features of the product.Ideas have been thrown around, with some cool extra features. I'm concerned that we'll too much focus on those extra features (hardware wise for start, then software development time later), and then miss out on the core of the product which simply has to be top notch. This is more of a organisational problem really.I do like those Variscite modules, they may be the way to go.

author: varghese
author_rank: Newbie
timestamp: May 11, 2017, 11:21:51 am
content: SBC1.LInux based application software development time is shorter2.Best if the product requires Display (QT GUI) + Network/Wifi Stack + BL stack +USB stack3.can Play around without bothering memory4. Most OS have 1ms latency/switching, that makes Special hardware IOs bit problematic5. PCB design is bit challenging , if u make it your ownMicro1. Space & IO flexibility2. easy use & low costbest designs would be choosing the right thing ..

author: mubes
author_rank: Regular Contributor
timestamp: May 11, 2017, 12:02:15 pm
content: Quote from: darko31 on May 11, 2017, 10:39:01 amWe do use the Variscite modules but I've just discovered Toradex and intend to get one of their iMX7 setups to have a play with it....probably Linux+FreeRTOS, although I _really_ like the idea of Rust and the work that's being done here (http://blog.japaric.io/fearless-concurrency/). One of the Toradex engineers is contributing to the Blackmagic Probe project and and anyone who does something like that gets bonus points from me.On my desk at the moment I have a LPC4367 board (204MHz M4 + 2xM0) and I'm just bringing up the M0s....it's not pleasant, simply because you're dealing with individual registers and shared memory/facilities. Something that gives you a bit more separation (==isolation) just 'feels' like it would be easy to develop with and to keep stable...I have FreeRTOS on those cores and have just spent the morning moving the SYSTICK over to RIT because they didn't implement SYSTICK on the M0s.I think the arguments for an OS only get stronger if you're going to end up in an 'Agile' (in a marketing sense of the word, not an engineering one) development because you can partition and protect more easily.Let is know how all this develops....its always interesting to hear from the experiences of others. What is the product to do BTW, are you able to say?RegardsDAVE

author: janoc
author_rank: Super Contributor
timestamp: May 11, 2017, 03:17:07 pm
content: Quote from: darko31 on May 11, 2017, 10:39:01 amWell, an SBC can always control something simple. On the other hand, if your simple controller has no flash space/CPU time/sw development skill left for that one extra feature requirement that always arrives once you have committed yourself to the hw design, you are screwed.If you don't have all the requirements clear yet, then an SBC is a safe bet. It is always easier to scale down than up.I also agree with the posts by others above - if the gadget requires Bluetooth and Wifi, you need an OS. Those things are hell to make work without, you will end up writing your own RTOS as a minimum. And then you still have the user interface on top of all that.

author: darko31
author_rank: Regular Contributor
timestamp: May 11, 2017, 03:39:48 pm
content: I'm sorry, I'm not at liberty to say what exactly the product is.QuoteI do agree with this, so we will probably use a SBC. Finding one that isn't too expensive and easy to buy, has reasonable market life, and comes with WiFi+BLE will be fun.Thanks!

author: krho
author_rank: Regular Contributor
timestamp: May 11, 2017, 05:20:40 pm
content: Look for something with imx6UL or imx6ULL. 512M ram 4G emmc and wifi + bt shouldn't be more than 50€ in 100+ QTYs

author: mac.6
author_rank: Regular Contributor
timestamp: May 19, 2017, 08:23:16 am
content: If going to the SBC route, be sure that:1- your board has a good board support package (BSP) from vendor, best if supported by SoC manufacturer out of the box2- Even if possible in early dev, forget about using a stock *ian distribution as embedded OS. Learn to build , package and maintain your own distro (ie, yocto/buildroot or custom *ian packages).3- be sure your SBC has eMMC and do not use uSD as running media. This is all about reliability.4- linuxRT can now run reliably on most SoC even when not officially supported, for example I have a good track of usage of linuxRT on i.MX6.

author: coromonadalix
author_rank: Super Contributor
timestamp: May 23, 2017, 01:21:43 am
content: Imx6 Imx7 with open hardware, or at least known pinouts for a baseboard, like EDM socket, mxm socket if i recallYou have Goembed, Variscite, Toradex as mentioned ... priced very goodWe use at my job closed source imx6 sbc based on windows CE6, 100$ a piece, a nightmare to update and compile, they use poprietary software, we are checking android / linux based versions to cut the costs and ease development.In my case, getting an windows CE sbc package is sometime very expensive, while linux / android ports are way cheaper.