Hacker News Reader

Comment by boojums | Hacker News Reader

One proposal I saw was to treat the RV32 core like a microcontroller or as a dedicated co-processor. https://www.robertlipe.com/bl808-not-symmetric/

View on HN

Let me see if I have this straight ... it's a device that can run a general OS like Linux, but say, have a core that could be run real-time, with all the goodies like timers and stuff that we expect from microcontrollers?

If so, then that would be pretty awesome. I think that people have been trying to get real-time working on Raspberry Pis. It seems that they get kinda close, but never manage to get all the way.

This is actually a common pattern you get from multiple vendors.

The TI AM335x is a good example of that. An ARM core with 2 "PRU" microcontrollers, and they share access to the memory. The BeagleBone Black uses the AM335x, and there's various projects that make use of the PRUs. A list of some of them: https://beagleboard.org/static/prucookbook/

Also the TI AM6442. Its an awesome chip but the sdk and tooling for the evaluation board is a little rough around the edges.

Just as a semi-random example, NXP has the i.MX series[1] with one or more application-level cores alongside a microprocessor-level core. You can get something like the i.MX 8M Nano[2] with 4x Cortex-A53 and a single Cortex-M7.

Another "big-player" option is ST which has the STM32MP1[3], which features a single Cortex-A7 alongside a Cortex-M4.

[1]: https://www.nxp.com/products/processors-and-microcontrollers...

[2]: https://www.nxp.com/products/processors-and-microcontrollers...

[3]: https://www.st.com/en/microcontrollers-microprocessors/stm32...

NXP's software support for the heterogenous ARM cores is abysmal. I had to abandon an architecture on the iMX7 because their RPMSG drivers were simply broken. Documentation and examples were multiple-years old and their FAE support came down to "well, the examples work." Except they didn't.

Perhaps it's better with the newer BSPs on the 8, but I wouldn't be too quick to jump back into it.

I haven't worked with 'bigger' (application processors running Linux) yet, but with the small MCUs I always stick to an Open Source toolchain/RTOS. Sometimes you have to write a driver yourself, but if you can integrate it upstream it's not in vain.

But I imagine that the larger SoCs are a more complex beast where getting everything to play nice with upstream Linux would be a greater challenge.

Yikes that doesn't sound very promising. I've seen the i.MX 8 used in several different products, so clearly someone has made them work, or at least kinda work... but I can imagine that might be despite the "support".

The iMX line is totally solid for ARM/Linux application work. I've been shipping with them for over a decade. The automotive sector uses it heavily because of the onboard hardware codecs for video and camera.

It's just the coprocessor stuff they're weak on. It's easier to just link up to a Cortex-M3 offboard, but then again NXP has completely screwed up their supply chain and these parts are somewhat hard to get.

Most modern ARM SoCs capable of running Linux have one or more cortex M cores, down from M1s to M4s (I have yet to see M7s). It is precisely for what you describe.

M0. I’ve never seen an SoC with an M1, which is a core specifically designed to be implemented on an FPGA.

Cortex-R is also pretty common (R5 on Zynq-7000 and R7 on UltraScale MPSoC, for example)

Indeed, brainfart, thinking too much about the Apple M1. Thanks!

Reply on news.ycombinator.com