Hacker News Reader

Comment by gte525u | Hacker News Reader

The page linked seems to indicate a cortex-M3 on there somewhere. I don't see it in the OSD3358 docs or on the BOM. Anyone know if that's a mistake?

View on HN

The main CPU is a Cortex-A8. In additions, there is a PRU-ICSS (Programmable Real-Time Unit Industrial Communication Subsystem), which has two 32-bit RISC cores. The latter can handle hard real-time intricacies without any latency from the A8. It is what sets this board apart from the simple-minded Raspberry Pi and other boards.

In practice, you can use the A8 as if the PRU is not there for 99% of what you want to do. You can also get into programming the PRU itself, but this is very much for the advanced user.

BTW, I don't see the PRU referred to anywhere else as "Cortex-M3".

https://www.element14.com/community/community/designcenter/s...

There are two lines in the spec summary. The PRU is one, a Cortex M3 is another. It's not unliklely that the SoC indeed has both, intending the ARM for use as a very low power, always-on sensor listener (e.g. the DSPs that handle audio and sensor input on phones so they can wake up the main CPUs for gesture or voice recognition).

Except the datasheet [0] does not list anywhere "Cortex-M3", nor reference any ARM cores other than the Cortex-A8. So if it is there, they are keeping it a deep secret.

[0] http://octavosystems.com/octavosystems.com/wp-content/upload...

It's used for power management, and it's listed in the full Technical Reference Manual, page 1172:

http://www.ti.com/lit/pdf/spruh73

What a surprising find! I would imagine Cortex-M3 (with 24 KiB RAM in total) a huge overkill for just power management. And it totally escapes me why the realtime co-processors are using a custom ISA solution rather than just using Cortex-M0/3/4. Would have been great to leverage the mature toolchain for Cortex-M!

Power management on modern SoCs is actually really complicated. There are dozens of power rails and clocks for different subsystems that all must be brought up and down with controlled order and timing if the device is going to work reliably. This kind of controller is routine on most "big" SoCs these days.

Then how about Cortex-M0, instead of M3? Surely enough that can save quite a bit of area, while still enjoying the good interrupt support of Cortex-M?

Presumably so they can share the workload with other tasks, like boot verification or low power sensor listening. The M3/M4 are still very small cores.

You pretty much need to use the PRU if you want to do any control algorithms, except the PRU /sucks/ to program.

I stay away from BBB because it's _so_ hard to use, at least from me/my team's experience.

The M3 is not well documented. The big thing to discover is the memory map to get at the IO. At least the firmware is open source to help provide a starting point and it includes some base addresses for peripherals in the system.

https://e2e.ti.com/support/arm/sitara_arm/f/791/t/284956

http://arago-project.org/git/projects/?p=am33x-cm3.git;a=sum...

http://www.ti.com/lit/ug/spruh73o/spruh73o.pdf page 1172

Reply on news.ycombinator.com