Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

why hercules ARM-R4 and not a ARM-M4? Please some clarification

Other Parts Discussed in Thread: TM4C123GH6PM, HALCOGEN

Hello everyone,

I would like some clarifications. i don't have enough experience to see the advantages of a TMS570LS0432 vs a TM4C123GH6PM. A ARM-R4 vs a ARM-M4.

A ARM-M4 is normally jam packed with peripherals. The price difference doesn't seem that big.

I am still a student and i am going to specialize in automation (and in my college there's allot of automate electric cars) and it seems the ARM-R4 is better for reacting to sensor data.

  • Main diffrerence between ARM-R4 and ARM-M4 is focus to safety in TMS570/Cortex-Rx.
    Cortex-R4 can be used together with "lock step" technology (two CPU kernels with compare unit).

    TMS570... MCUs also have some more safety features, like ECC control and some more.

    M4 is designed to low power, securyty is not main focus, but both have memory protection unit for ex.

  • You need to consider in the discussion if the question is really M4 vs. R4 or whether you are looking at a discussion of Hercules device features vs. Tiva device features.  Some of the points you note are related to CPU and some are related to the platform implementation.  I'll address the CPU differences.

    Both processor cores are good choices and there is some overlap in the applications which can be built with each.  M4 is best for control of a single low latency control function; the R4 trades off some control latency for higher compute performance and typically controls multiple medium latency control functions .  M4 has a lower peak frequency capability and lower compute performance potential than the R4 and has fewer configuration options (no cache, no lockstep, reduced MPU, reduced debug/trace, ...).  It is also smaller and typically results in a lower power design.

    The R4 core is more flexible than the M4 in that it supports both the ARM and Thumb-2 instruction sets.  This is a critical point to many customers migrating from ARM7/9/10/11, but is becoming less of an issue as ARM's Cortex M platform matures and gains customers.  However, if you are also developing with Cortex A cores in your system, you will find the R profile more consistent to program than switching between the A and the M.

    The M4 is several years newer than the R4, and incorporates a number of microarchitecture improvements which were first debuted on the R4.  For example, the FPU is a direct derivative of the one introduced on the R4.

    Hope this helps.

    Regards,

    Karl

  • Thank you very much.

    But i have a bit of a doubt in this:

    KGreb said:
    he R4 trades off some control latency for higher compute performance and typically controls multiple medium latency control functions

    The ARM-R4 has higher latency in control? I don't quite understand what you mean by that.

    The higher compute performance i can understand since the ARM-R4 not only seems to have higher peak frequency, but also better pipelining for higher performance per Mhz.

  • Hi Luis,

    For embedded IC design we think of I/O latency in terms of the number of cycles needed to access a peripheral at a given level of interconnect hierarchy.  

    The M4 uses a simple 32b AHB interface to access peripherals.  A round-trip access is possible in three clock cycles best case (not considering pipelining or device level architecture impact).  

    The R4 uses a more complex 64b AXI interface to access peripherals.  A round-trip access is possible in around seven clock cycles best case.  This interface is more optimized for bursting access, parallel access by multiple bus masters, and for cache operations.  As a result, it can move quite a bit more data than the M4 on average, but it does so by sacrificing some latency in its design.

    Note that this is a common micro architectural trade off (latency vs. frequency vs. throughput) and does not indicate any kind of design defect. By comparison, that same basic peripheral access on an SMP cluster ARM device such as an ARM Cortex A9 could take 30+ clock cycles.  I/O latency for a typical x86 processor tends to  be in the 100s of clock cycles.

    Regards,

    Karl

  • Thank you very much KGreb.

    I am looking for a good MCU for motor control with the possibility of interfacing with sensors. I know there is the C2000 that seems really good at it but, I am considering learning about and using the hercules since it's a ARM which i am more comfortable in using.

  • Just 1 more question,

    If i want to start with the hercules launchpad for example, which software libraries are there available, or better yet, in which should i start?

    Are there something similar to TivaWare for Tiva (not asking for portability) 

  • I have started by installing HALCoGen, and checked out the examples that come with it.
    That helped me to understand most of the peripherals.

    Then I built the Hercules safety demo from source, and started stepping through it to understand the safety and memory validation features.

    At this moment I'm digging into the HET co-processor.  I used several examples from TI to dig into.  I found their projects to emulate communication protocols quite useful to get a better understanding of how HET works.

    I learned a lot by porting TivaWare and other examples to the Hercules family.