• Locked Locked
  • Replies 4 replies
  • Subscribers 119 subscribers
  • Views 3785 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex-M3 vs ARM7TDMI

Jayanth Acharya
Note: This was originally posted on 21st April 2011 at http://forums.arm.com

Trying to turn what was a simple hobby project based on Cortex-M3 with some serious enhancements/additions, into a semi-commercial product (might sell it at cost, or even opensource design/software), however I am at a crossroad of sorts, and need to decide whether I could stick to Cortex-M3 or move to ARM7TDMI, since those seem to be comparably priced, although from max DMIPS standpoint, are much lower than those on latest Cortex-M3s. My query is, how much of a factor is DMIPS in my circumstance.

Given some very rough (& not very scientific) estimates, I'd require around 120DMIPS of performance which I might be able to squeeze into say 80DMIPS if I go with commercial libraries & invest significantly (time/effort) in optimizing, which given the nature of the project (desire to sell at-cost or opensource) will be difficult, if not impossible. The point where I do hit the limits of Cortex-M3 is the onboard SRAM. This is where I am in some confusion, as to whether I should try a switch to ARM7TDMI ? Will the Cortex-M3's with External-Memory support, help address my issue ?

~Jay
Parents
  • Note: This was originally posted on 22nd April 2011 at http://forums.arm.com

    Thank you Joseph and Miro. Excellent points there.

    Joseph, the software based nested interrupt management is something I am familiar with from 8-bit MCU programming, but getting it right can be a lot of work. I am guessing that using an RTOS that is already ported on ARM7TDMI (probably like FreeRTOS / eCOS), might take care of that for me. As for the extra code size, due to many instructions being 32-bit ARM instructions, is definitely something worrying. After some quick envelope-back calculation of the BOM with external SRAM (my requirement was for mostly larger stack/heap, and to a lesser extent also for instructions), looks like I begin to approach the ARM9 range. Since I don't really need the PWM, much of A/D conversion, the benefits of sticking to an MCU fade away (well, the charm was always the cost -- of the processor and the dev-board).

    Miro, excellent point there about using HAL. Since my aim is to quickly get along with the application development, I was banking on an RTOS keep the job of abstracting the core architecture anyhow, and was banking more towards FreeROTS for this reason, although the lure of shifting to a POSIX compliant OS, and availability of libs is quite hard to resist -- though a paradigm shift.

    Once again, thank you very much.
Reply
  • Note: This was originally posted on 22nd April 2011 at http://forums.arm.com

    Thank you Joseph and Miro. Excellent points there.

    Joseph, the software based nested interrupt management is something I am familiar with from 8-bit MCU programming, but getting it right can be a lot of work. I am guessing that using an RTOS that is already ported on ARM7TDMI (probably like FreeRTOS / eCOS), might take care of that for me. As for the extra code size, due to many instructions being 32-bit ARM instructions, is definitely something worrying. After some quick envelope-back calculation of the BOM with external SRAM (my requirement was for mostly larger stack/heap, and to a lesser extent also for instructions), looks like I begin to approach the ARM9 range. Since I don't really need the PWM, much of A/D conversion, the benefits of sticking to an MCU fade away (well, the charm was always the cost -- of the processor and the dev-board).

    Miro, excellent point there about using HAL. Since my aim is to quickly get along with the application development, I was banking on an RTOS keep the job of abstracting the core architecture anyhow, and was banking more towards FreeROTS for this reason, although the lure of shifting to a POSIX compliant OS, and availability of libs is quite hard to resist -- though a paradigm shift.

    Once again, thank you very much.
Children
No data