I think you're confusing 'embedded industry' with 'embedded hobbyists', because we (the industry) don't focus on hobbyists.
The RPi really does suck from a professional use-case: no volume, no 10 year guarantee, no proper industrial certifications and until a few years ago, extremely bad integration with tools like Yocto.
The two segments do overlap sometimes, but it's definitely not the same beast. A lot of SBC vendors have provided great boards over the years (looking at Variscite, PHYTEC, Toradex, SECO et al), but the incentives, and thus the final product, are not what hobbyists expect.
Exactly as you see in this comment chain, engineers at startups get fed up of the embedded industry being stuck in the 1980s (long sales process with many meetings and salespeople, custom blobs galore, custom distros, long lead times, high prices etc).
You cannot iterate quickly based on the glacial embedded industry. I am amazed by the way we are quoted 3 month wait for a shipment (even pre-covid) without anyone batting an eyelid.
You're a bit like the satellite industry looking at Starlink and saying "well it's not true satellite, doesn't have X, Y and Z" and pointing to a few specialist applications where legacy satellite is highly suited and ignoring the masses of business applications that have moved to Starlink.
I mean, I won't even try to rebate you, I agree with you, mostly. lol.
My only fear is that, it's really, really hard to get a safe, performant product without really knowing what you're doing. And although RPi and others do a good job at the prototyping level, it becomes messy very quick.
We're trying to be better, though, there are some nice solutions popping up here and there.
> extremely bad integration with tools like Yocto.
Is that really a feature? Having to use a mess of vendor kernels and overlays that patch anything from ffmpeg to GTK to chromium just to build a 5 year old, EOL kernel version that still doesn't do what the board was advertised as supporting.
E.g does a SBC really support accelerated video decoding if it's only via patched libraries that are also 3 years old?
IMO the embedded Linux ecosystem seems to really hate Linux since it rarely follows standards (especially in user space) or upstream drivers, etc.
I can see where your generalisation is coming from, but again, it's a generalisation. There are a bunch of nice layers that build cleanly with Linus's tree against OE master no problems. That takes work, naturally.
In one of the Yocto Summits I've been to there was literally a talk about "stop venturing the kernel". Everyone hates it. We really do fight against the major SoC vendors to stop not upstreaming stuff and it has been getting better :-)
You might be amused that my company literally uses raspberry pi's in production as they are cheap and let us encourage our customers to hack on the robot themselves - https://openshelf.com/
This is targeting hobbyist and not the typical kind of production usage for embedded systems. I rarely heard of embedded people encouraging customers to hack their production system...
Showing as "not reachable" for me. Luckily it's not used for controlling an elevator or a car, or even worse a plane or a bomb, which usually is what "industry" is being referred to.
> which usually is what "industry" is being referred to.
Bingo. It's always a bit hard for me to properly communicate to people that the 'industry' is not an air monitoring/grafana-prometheus/PiHole/whatever low-volume, no risk application.
I know of a few robotics and industrial control companies that integrate RPis into their stacks. They definitely are a real industry tool. I think companies like these are where the limited supply goes.
I have a bunch of experience on this but won't go into much detail because it may be a touchy topic: most companies that do $THING and use SBCs like the RPi are extremely talented at $THING, and not at embedded development. That's why, most of the time, they go into this ecosystem.
And I mean, it works! But it's an unsafe mess which generates a bunch of regulatory issues and it keeps me up at night :-)
I don't think it's that touchy of a subject. I feel most firms understand the a Pi should not be directly controlling machinery that can cause real harm. They shouldn't be replacing PLCs. But imagine use-cases like analytics and reporting or remote access. Or small scale devices like automated lab equipment (where the company's main $THING is biotech).
Exactly, just pretending to ignore the 80% of the market that isn't critical or safety of life and saying it's not true "embedded industry" (or True Scotsman) is just ignoring the reality.
> Rpi actually suck if you compare it to industrial automation PLCs eco-system
Wait, what? PLC’s and Raspberry PI’s have nothing in common surely? PLC as in thousands of dollars, Ladder logic, built like a tank and about the same size? When has a PI ever been compared to a PLC?
These PLC enclosures for PI look to cost as much or more than an actual PLC. Then you have a PI inside that is not designed to handle the vibration, temperature, etc, requirements of an industrial setting right? Why would anyone want this? It just looks expensive and unreliable.
I don't remember the name of the company, but it was a service you bought where you would get network monitoring by placing these small PoE powered boxes all over your offices.
It would allow you to do network reliability testing, as well as get data back on Wifi AP's and some environmental data.
Company I worked for had them spread out across all of their offices in various different locations, all of them reporting back to a central location.
When we took apart the device we found a Raspberry Pi inside, with a PoE hat. It made sense for the use case, cheap devices, custom case, and MAC address that was set to the vendors MAC address range upon boot up.
At the time I was helping with a security assessment, and being able to run our own software/tools on a device that would blend in was kinda nice ;-)
"Embedded industry" is a VERY large segment.
Here's a fun one for you. This was told to me by the person who helped build this project. Parallax makes a device they call the BASIC Stamp 2 (https://www.parallax.com/product/basic-stamp-2-microcontroll...). It is a very easy to use and develop for microcontroller yet it is incredibly capable. You program it in BASIC.
The BASIC Stamp 2 was for the longest time used in a production sold to consumer timer clocks for turning solenoids on and off for sprinkler systems. At one point in time you could buy it off the shelf at Home Depot not knowing that the device contained a very simple BASIC Stamp 2 to do its functions.
These devices end up in the weirdest places. You'd think a manufacturer would switch from a BASIC Stamp based product to spinning their own board + using a small embedded CPU instead, but the cost savings just weren't there.
The RaspberryPi is likely used in far more places than you or I could imagine in ways that are considered "professional". That stuff gets hidden in little metal/plastic moulded boxes and for all intents and purposes disappears.
I said "until a few years ago", and AFAIK this was not done by the RPi folks themselves, but by the community. And that's perfectly okay, it's not their market, which is my whole point.
It takes a serious effort and money to maintain a layer. It's not easy to integrate and test everything.
How does Beaglebone look to you (aka: TI's AM335x Sitara line?).
I've played with it some but I'm no professional here. I personally do consider it a major contender thanks to OSD335x SiP modules (although I haven't built an OSD335x, the deadbug demo intrigues me: https://octavosystems.com/2019/04/12/osd335x-c-sip-dead-bug/).
Beaglebones have been the proving ground of numerous successful consumer electronics. The beaglebone itself isn't a platform but a vehicle for components that are bundled together on a custom board. It's a prototype and evaluation board for their OMAP line.
That being said I wouldn't recommend shipping an OMAP product in this day and age. Something with a MediaTek SOC is probably more palatable if you plan to spin up production at volume.
> It's a prototype and evaluation board for their OMAP line.
Oh, I see the confusion now. I didn't realize that Beagleboard was OMAP old.
I was talking about Beaglebone Black/Green, which is a 10-year-old design yes, but the AM335x line of Ti chips (while a decade old) seems well supported and working with mainline Linux.
Beaglebone Black/Green seems to be comparable to Rasp. Pi 1 or Rasp. Pi 2, though with far less power consumption, better documentation. I'm impressed by it, though I haven't made the leap into a custom design yet.
-----------
But yeah, I guess I only became aware of Beaglebone around Beaglebone Black era / Sitara line. I always saw them as the "Industrial Rasp. Pi" if I wanted to reach for a more serious project, though I haven't really done any good electronics work back then. I'm doing a bit more of an electronics push these days again though.
I'm more interested in Beaglebone Black / Green because AM335x has 0.80mm pin pitch BGAs, which looks doable on OSHPark 6-layer 5mil trace/space.
More recent Beaglebone Play / AM625 has far superior specs (quadcore + CortexM4 onboard / etc. etc.), but 0.5mm trace is literally impossible at 5mil trace/space.
Any Cortex A8 would probably suffice. I've been out of the game for a while but there was definitely a vendor push to 64-bit SoCs for even mundane tasks, not to mention all samples being Android based...
If you can get away with something low spec then you'll be fine, generally. Board bringup for any Cortex A8 or similar is comically easier than for lines ending in double digits.
I found Rockchip much easier to work with than TI, fwiw.
Pretty much what the other comment said about the BB being proven etc.
Because of better support from TI, BB always had a more professional feel than the Raspberry Pi, specially for documentation etc. It's a fine chip, if you can source it (haven't messed with anything from Octavo, but it seems solid to me). All the software issues are pretty much solved and upstreamed at this point.
Yeah, building on a literally 10+-year-old chip feels weird coming in from the computer industry. But if its _still_ reasonably popular after this long, I think its clearly got some long-term legs to stand on.
I think the main advantage, for my hobbyist self at least, is the 0.80mm pitch BGA which is doable on OSHPark.
TI's more recent AM625 is 0.50mm pitch, which is too small for OSHPark 5mil trace/space, lol. Perhaps a bad reason to a professional but... I'm filtering out for chips that I can actually affordably make a PCB for on a hobbyist scale.
AM3352BZCZ100 is literally #6 on Digikey's list of MPUs right now with 6058 in stock (ignoring "marketplace products"). That's a singular SKU as well, multiple chips in the series means that in practice, the Sitara has more than enough supply.
Mouser also has 3000, 4000, 5000 in stock depending on SKU ( AM3357BZCZA80 vs AM3352BZCZA80). Easily 15,000+ at Mouser if you're not picky about the particular part in the series.
You may struggle getting 400-500k units in a single bin in Shenzhen, if that is your goal. If it's not, sure, go nuts. I'm from a world where we were spot buying 40k units multiple times a week to avoid being ransomed by manufacturing. I have no idea what the yield is like on those parts but TI's reputation proceeds itself in terms of truly off the charts "go fuck yourself" yields.
The RPi really does suck from a professional use-case: no volume, no 10 year guarantee, no proper industrial certifications and until a few years ago, extremely bad integration with tools like Yocto.
The two segments do overlap sometimes, but it's definitely not the same beast. A lot of SBC vendors have provided great boards over the years (looking at Variscite, PHYTEC, Toradex, SECO et al), but the incentives, and thus the final product, are not what hobbyists expect.