Why is nobody implementing ARM Cortex MCU's in their projects?

[that_guy]

Generally yes it's the cost of producing a PCB that can support the fine pitch BGA package that the high end Cortex A series usually comes in. I say 'usually' because if you're feeling adventurous you can buy the Allwinner A13 (Cortex A8 core) on AliExpress for $6 or so. It comes in an impressively large TQFP package. I wonder how well matched the bond wire lengths are inside that thing? But for hobby use buying a PI or similar on a proven PCB has to be the way to go.

[tszaboo]

Beside, you need an adult PCB design package and perhaps a fair knowledge of high-speed design.

Not really. In one of the projects I was involved I guided someone through the PCB design and he used Geda and PCB for a 6 layer board with an iMX5x SoC.
Still count on 100 to 200 hours for a board (depending on space constraints) and another 200 hours to get Linux up & running reliably.

Getting the linux ready its more like infinite time and then some. If you have a linux computer in a product, you can preatty much assign someone for that board soldering the code and the kernel full time.

[XynxNet]

Speaking for myself. Learning curve vs. benefit is to high.
I'am a hobbyist, not a professional circuit designer.

The more i have to outsource manufacturing etc, because i can't do it myself or it's to expensiv,  the more changes my focus from electronics to application.
If application is the focus it is easier to use existing dev-boards.

Same goes for my professional activities. If science is the focus, why should i custom build electronics as long as there are reasonable affordable existing solutions and specific measurement equipment is not integral to my research goal.

[AlfBaz]

Beside, you need an adult PCB design package and perhaps a fair knowledge of high-speed design.

Not really. In one of the projects I was involved I guided someone through the PCB design and he used Geda and PCB for a 6 layer board with an iMX5x SoC.
Still count on 100 to 200 hours for a board (depending on space constraints) and another 200 hours to get Linux up & running reliably.

I'm sure you could do it with MSPaint.
With the project I mentioned I hit altiums limitations with regards to high speed design. I explored most of its offerings at the time even the ones touted as "useless" and hit birck walls everywhere.
Even matched length routing was difficult because termination resistors split the net into 2 different lengths and there was no accounting for bond wire lengths within the package. Allegro's cadence had the works plus some really good routing aids
Even exporting to hyperlinx format for signal integrity analysis was problematic. Planes and polygon pours wouldn't export unless you ran 3rd party scripts and you could forget about layer stack info in altium making it through to hyperlinx

[nctnico]

What kind of SoC did you use in your project? That must be some very exotic part because the SoCs I have used so far (Freescale and TI) didn't need all that fancy stuff to get a PCB designed for it.

[Spikee]

I have done a 4 and 6 layer quad core ARM A64 core with DDR3 and MIPI / LVDS before.

Find out what busses you need (LVDS , DDR3 , USB ...) and find the relevant design rules / guides for that -> follow the design rules.
For decoupling just follow whatever the manufacturer recommends and you will be safe.

As for high speed "interactive length tuning" features are nice to have but not necessary. For DDR2/3 the altium length tuning feature-set is not sufficient and you will have to write your own program to check or excel (manual work is necessary). Generally the IC MFG has some guidelines for DDR(3) routing -> follow that.

It is not rocket science. First try took about 2 months with no prior DDR3/BGA design experience. Second design took a month. I could re-do it now in less than a week for a new board (depending on how many footprints need to be made, if from scratch ~2-3 weeks).

Generally a big IC like that has much more features than you actually need. So that simplified routing a lot (you might just have 150 disconnected balls on your 400 ball bga).
Also most big arm's are optimized to work on 4 layer designs due to cost.

Also the major reason why you might go >4 layers is because of power routing. Could fit it in four but that's not ideal.

[senso]

There was a router/switch that was designed in Eagle, some Buffalo or maybe some MIPS based thingy, and it was a comercial effort..
I might be painfull, but it can work, also, those nice clusters used in BMW's, VAG group and what not where designed in Eagle, and they used the auto-router....

Also, why is using Atmel bad?
I'm using an Atmega256RFA2 in a big project, I'm a noob because its atmel and thus it must have some Arduino connection?...

[nctnico]

Atmel is on my blacklist for lying in their datasheets. It is just too tedious to read between the lines in order to get the REAL limits of a device (or worse: find out when it is too late).

[AlfBaz]

What kind of SoC did you use in your project? That must be some very exotic part because the SoCs I have used so far (Freescale and TI) didn't need all that fancy stuff to get a PCB designed for it.

Nothing exotic at all, just an arm using ddr1 which doesn't have the nice little extras to ease routing/impedance matching pains that ddr2 and 3 have. That and I wanted to study signal integrity, high speed pcb design and the tools used for it in depth

[Scrts]

Well DDR1 does not have ODT like DDR2 has... So for me DDR1 routing was more painful.

[jnz]

Atmel is on my blacklist for lying in their datasheets. It is just too tedious to read between the lines in order to get the REAL limits of a device (or worse: find out when it is too late).

That's a bummer to hear. I'm interested in their SAM CortexM0+ for a project.

Any details about what to watch for? My application will be digital buss only.

[nctnico]

Just walk away and choose a microcontroller from NXP or maybe the newer ones from TI if you value your sanity.

[james_s]

I haven't used them simply because I haven't needed to. For the microcontroller based projects I've built, the 8 bit AVR series has met all my needs, I know how to use them, they're familiar and I haven't had any reason to look elsewhere.

[Kjelt]

From a friend I found out that porting an existing "Linux" variant for their HW platform that was supported by the variant, including hardening such as killing all unneeded services, updating and employing security and making it stable (production ready), took them almost a year with four experienced software engineers and an architect. So his best guess for a mature development cycle would be around 3 man years at least. My question why it took so long: many many hidden time consuming issues if you want it to get right and stable. This is for devices that stay on 24/7 and are internet connected. After one month they had it up and running. The rest of the time was getting it lean, secure, and stable and the remote firmware update also took them quite a while.

[Howardlong]

From a friend I found out that porting an existing "Linux" variant for their HW platform that was supported by the variant, including hardening such as killing all unneeded services, updating and employing security and making it stable (production ready), took them almost a year with four experienced software engineers and an architect. So his best guess for a mature development cycle would be around 3 man years at least. My question why it took so long: many many hidden time consuming issues if you want it to get right and stable. This is for devices that stay on 24/7 and are internet connected. After one month they had it up and running. The rest of the time was getting it lean, secure, and stable and the remote firmware update also took them quite a while.

Interesting, because this reflects my own experiences about three or four years ago, it seemed like a great idea to use something where everything was already implemented, including integrated WiFi with reasonable speed, and both Ethernet and USB stacks. What wasn't so great was finding bugs for various bits and pieces, particularly in the USB stack, slow boot times and being terribly power hungry. Getting fixes re-integrated into the build proved difficult because I wasn't in the clique. It was a case of the grass apparently being greener, but in the end it wasn't. Getting a PoC up and running was reasonably easy, but making it into something that would be reliable, lean and ready for production use proved to be just too demanding in terms of time and effort.

[jnz]

From a friend I found out that porting an existing "Linux" variant for their HW platform that was supported by the variant, including hardening such as killing all unneeded services, updating and employing security and making it stable (production ready), took them almost a year with four experienced software engineers and an architect. So his best guess for a mature development cycle would be around 3 man years at least. My question why it took so long: many many hidden time consuming issues if you want it to get right and stable. This is for devices that stay on 24/7 and are internet connected. After one month they had it up and running. The rest of the time was getting it lean, secure, and stable and the remote firmware update also took them quite a while.

Interesting, because this reflects my own experiences about three or four years ago, it seemed like a great idea to use something where everything was already implemented, including integrated WiFi with reasonable speed, and both Ethernet and USB stacks. What wasn't so great was finding bugs for various bits and pieces, particularly in the USB stack, slow boot times and being terribly power hungry. Getting fixes re-integrated into the build proved difficult because I wasn't in the clique. It was a case of the grass apparently being greener, but in the end it wasn't. Getting a PoC up and running was reasonably easy, but making it into something that would be reliable, lean and ready for production use proved to be just too demanding in terms of time and effort.

Makes me really glad I walked away from this idea. It almost seemed to easy to "just have" wifi, file system, usb, high level programs like http server, etc.

[tszaboo]

From a friend I found out that porting an existing "Linux" variant for their HW platform that was supported by the variant, including hardening such as killing all unneeded services, updating and employing security and making it stable (production ready), took them almost a year with four experienced software engineers and an architect. So his best guess for a mature development cycle would be around 3 man years at least. My question why it took so long: many many hidden time consuming issues if you want it to get right and stable. This is for devices that stay on 24/7 and are internet connected. After one month they had it up and running. The rest of the time was getting it lean, secure, and stable and the remote firmware update also took them quite a while.

Interesting, because this reflects my own experiences about three or four years ago, it seemed like a great idea to use something where everything was already implemented, including integrated WiFi with reasonable speed, and both Ethernet and USB stacks. What wasn't so great was finding bugs for various bits and pieces, particularly in the USB stack, slow boot times and being terribly power hungry. Getting fixes re-integrated into the build proved difficult because I wasn't in the clique. It was a case of the grass apparently being greener, but in the end it wasn't. Getting a PoC up and running was reasonably easy, but making it into something that would be reliable, lean and ready for production use proved to be just too demanding in terms of time and effort.

Yes, reliability and production readyness is my biggest issue. I am working with a custom linux SBC, without real network, and it is a pain. I had to implement a support for an extra USB feature, you know, the type you plug in in windows and it works.
OK, plug in, nothing happens. OK, is it supported in the kernel? Recompile the thing and the linux a dozen times to work (that is a few hours every time). Ok lets find a program that uses it. Ah, there is two dozen, but only one in the distro. Ok, lets try to add it. Few weeks later I realised two different version of the program is on the distro, and the files are strangely mixed. Ok, so unmix them, apply a bunch of patches from random internet forums. Compile the linux another dozen times.
The information about any Linux related stuff seems to be randomy organised. Forums and blogs and mailing lists going crazy. "ah your software is not working, just get another one with apt-get..." I have no network (by design), and I dont want to do it on every machine we make from now on, and I'm using a different distro.
And this was one issue. And I'm a hardware engineer.
This is the definition of not having fun at work.

[nctnico]

From a friend I found out that porting an existing "Linux" variant for their HW platform that was supported by the variant, including hardening such as killing all unneeded services, updating and employing security and making it stable (production ready), took them almost a year with four experienced software engineers and an architect. So his best guess for a mature development cycle would be around 3 man years at least. My question why it took so long: many many hidden time consuming issues if you want it to get right and stable. This is for devices that stay on 24/7 and are internet connected. After one month they had it up and running. The rest of the time was getting it lean, secure, and stable and the remote firmware update also took them quite a while.

I guess they started with a desktop/server Linux distribution and not an embedded device distribution like Buildroot or Openembedded. I'm not saying there isn't a learning curve using Buildroot and Openembedded but at least you have better control over what runs on your device and what does not. Also having a read-only root filesystem is much easier with Buildroot (and I assume Openembedded) so a sudden power failure can't affect the filesystem.

[Dijital]

From a friend I found out that porting an existing "Linux" variant for their HW platform that was supported by the variant, including hardening such as killing all unneeded services, updating and employing security and making it stable (production ready), took them almost a year with four experienced software engineers and an architect. So his best guess for a mature development cycle would be around 3 man years at least. My question why it took so long: many many hidden time consuming issues if you want it to get right and stable. This is for devices that stay on 24/7 and are internet connected. After one month they had it up and running. The rest of the time was getting it lean, secure, and stable and the remote firmware update also took them quite a while.

Interesting, because this reflects my own experiences about three or four years ago, it seemed like a great idea to use something where everything was already implemented, including integrated WiFi with reasonable speed, and both Ethernet and USB stacks. What wasn't so great was finding bugs for various bits and pieces, particularly in the USB stack, slow boot times and being terribly power hungry. Getting fixes re-integrated into the build proved difficult because I wasn't in the clique. It was a case of the grass apparently being greener, but in the end it wasn't. Getting a PoC up and running was reasonably easy, but making it into something that would be reliable, lean and ready for production use proved to be just too demanding in terms of time and effort.

Yes, reliability and production readyness is my biggest issue. I am working with a custom linux SBC, without real network, and it is a pain. I had to implement a support for an extra USB feature, you know, the type you plug in in windows and it works.
OK, plug in, nothing happens. OK, is it supported in the kernel? Recompile the thing and the linux a dozen times to work (that is a few hours every time). Ok lets find a program that uses it. Ah, there is two dozen, but only one in the distro. Ok, lets try to add it. Few weeks later I realised two different version of the program is on the distro, and the files are strangely mixed. Ok, so unmix them, apply a bunch of patches from random internet forums. Compile the linux another dozen times.
The information about any Linux related stuff seems to be randomy organised. Forums and blogs and mailing lists going crazy. "ah your software is not working, just get another one with apt-get..." I have no network (by design), and I dont want to do it on every machine we make from now on, and I'm using a different distro.
And this was one issue. And I'm a hardware engineer.
This is the definition of not having fun at work.

Mini rant just because it feels nice to get it off my chest. Not quite at the same level as you guys, but same general experience.

I have made 3 forays into linux in my life. First was about 10 years ago and lasted a month. Quit because every single little thing would need research and tweaking to work. Second was a year or so ago. Lasted a good 4 months. Really tried to stick with it, and the UX had imporved. But quit because again, I got so fucking sick of having to deal with broken stuff constantly, and deal with them in the seemingly foreign language of terminal. Now my third foray has been the beaglebone black wireless I got 2 weeks ago. At 20 hours in, and and extra $15 spent on a display adapter (which shouldn't be need, but HDMI is broken on the BB), I finally got it connected to my wifi and displaying the desktop. 20 hours to get where I thought I would be in 20 minutes. (this should be linux's slogan) I have probably reflashed it 30 times now, because every other command you find online to fix an issue was a crapshoot of soft-bricking. Even when i got users to help me on the IRC channel, many left me with "hmm, never seen that before, well i dunno then". To get things working I had to cobble together commands and .configs from a variety of random posts scattered over the last few years, and use an image compiled by a contributor, not the official one. Most things, especially for the newer BBBW, have no documentation at all. The whole thing has been a nightmarish exercise in frustration and head banging.

I love the idea behind linux. And I'll keep supporting it. But jesus fucking christ is it a fragmented confusing mess, filled with people who would rather tell you why writing your own config file, after fishing with obscure commands in terminal for network information in order to connect to wifi is better than having a program where you double click on your network and then enter the password to connect. Or even just a terminal command where you enter the network name and then the password.

Ok I feel a bit better now.

[Monkeh]

jesus fucking christ is it a fragmented confusing mess, filled with people who would rather tell you why writing your own config file, after fishing with obscure commands in terminal for network information in order to connect to wifi is better than having a program where you double click on your network and then enter the password to connect. Or even just a terminal command where you enter the network name and then the password.

And yet, Linux has both of those (and several options of both), and they work.

[filssavi]

My experience with Linux is exactly opposit with the ones here, ok granted that i have been using Linux ad my main Workstation OS for 3/4 years so I have done experience...

I user Linux in a zynq processor/FPGA to do hardware Image filtering (coursework at uni), i have a flask web frontend (non hardened) that takes the Image and with the help of a c++ shim and a custom DMA driver (in kernel) sennds it to the FPGA, and then does all of this in reverse and serves the output

To get up and running i used yocto/openembedded to get a custom Linux environement with the packages i needed, while there is a little bit of learning curve it's not that base (the thing i gate the most is that yocto is python2 only and so i must use venv's ti get it going)

The most difficult part was editing the driver since the documentation is quite poor and scattered around (the LDD3 book that is regarded ad the bible of diverse is outdated in this case, that was the hardware thing), but i can say that it is a little bit like FPGA developement, once you wrapped your head around the logic of how the kernel is written it's quite easy to navigate

[AlfBaz]

Somebody on another thread recommended this book on linux in embedded systems, which I duly purchased and not read
Apparently quite good

[Dijital]

And yet, Linux has both of those (and several options of both), and they work.

True, but when your image doesn't come with them and you are trying to get online, the task becomes a bit more daunting. Especially when no one else has documented the process.

[filssavi]

And yet, Linux has both of those (and several options of both), and they work.

True, but when your image doesn't come with them and you are trying to get online, the task becomes a bit more daunting. Especially when no one else has documented the process.

I font know where you were starting from but it seems it was not the best starting point ever.

Ad I said there are system (i am familiari with yocto, but i know at Leasys of another One: bitbake) that can generare a fully functional (bother cli and GUI) Linux system from sources, by changing config files you can specifico which packets di you want, it installs also a package manager of your choice (APT yum etc) ant it is quite well documented(ti be anche FOSS project anyway)

[brucehoult]

My understanding is that there is a team of 60 people, who are working full time on the Raspberry PI project. Under the employ of the Raspberry PI foundation.

The Raspberry Pi 3 has been out for a year now, with a 64 bit cpu. There is still not a supported 64 bit OS for it! You're limited to treating it as a slightly faster Pi 2 with regular old ARM 32 software (and actually I found that both Mono and CoreCLR run faster on the Pi2 than on the Pi3).