The incredible part is the RPi sucks less than all the other commercial embedded SBCs such that it's had huge industry uptake purely by being the least worst.
The state of the embedded industry continues to amaze me.
The state of the embedded industry continues to amaze me.
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.
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/).
https://www.digikey.com/en/products/detail/texas-instruments...
The AM335x is clearly still a common chip today.
-------
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.
I think this is why the am335x and imx6 are still available, despite the am335x being older than the Raspberry Pi 1.
Of course, such chips are generally slower than flagship phone/tablet processors even at launch, and after 10-15 years even moreso.
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.
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.
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.
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.
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.
Old does not mean worse.
All of the extra gorp on newer chips takes a LOT more power.
For example, that 10-year-old chip runs Linux quite reliably in a 5V-500mA power envelope--something the RPI series never did.
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 :-)
Spot on. Rpi actually suck if you compare it to industrial automation PLCs eco-system, heck, even compared to other SBC like nvidia jetson.
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?
> 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'm not affiliated with this, just poked around. Looks neat by the way.
https://github.com/agherzan/meta-raspberrypi
For what it's worth, the entire Pi lineup is also well supported by Buildroot. In-tree, no less.
It takes a serious effort and money to maintain a layer. It's not easy to integrate and test everything.
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.
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.
Korg makes a line of popular synthesizers that are based on RPi, so I believe the volume issue has been solved?
https://www.raspberrypi.com/success-stories/korg-synthesizer...
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.
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.
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 :-)
> and until a few years ago, extremely bad integration with tools like Yocto.