How Do You Compare the STM32F4 (180MHz) with the K66?

Status
Not open for further replies.
D

davidbitton

Member
I was wondering how the 180MHz versions of the STM32F4 compare with the K66 in the 3.6. If they are both ARM Cortex-M4 chips, what sets them apart? What features and/or specs does one look at to determine which chip is better suited for a particular application? Thanks.
 
Often the most important question is: how quickly can you produce working code. The libraries that run on the Teensies are pretty amazing. The support here is astonishingly great.

If it comes down to some silicon performance spec, you'll probably need to read the reference manuals for both chips and write some benchmarks. If you go this route, share your benchmark code here and on some STM32F4 forum so you don't miss any obvious optimizations.
 
The ARM core performance should be about the same. The peripheral architectures will differ in types/counts of peripherals and IO register definitions. I have some simple comparative numbers of MBED F446RE (STM32F446xx@180mhz) against various Teensy/NXP MCU's. Performance may differ from compiler (GCC and mbed ARM CC) and its settings. The MBED API differs from Arduino/Teensy. Your application needs might determine which MCU is best.

https://github.com/manitou48/DUEZoo/blob/master/perf.txt

your mileage may vary
 
Software is indeed the main difference. Some people care quite a lot about software. Others seem to like to focus only on the silicon.

The chips are pretty similar. Sure, you can find differences in peripherals. ST gives you a camera & LCD interface and 5V tolerance. NXP gives you an on-chip PHY for the fast USB port. One extra cycle wait state for most of the RAM probably makes little or no difference if you can put the stack into the fast memory.

This is the same chip that Arduino.org was going to use for Star Otto, right?
 
In terms of real-world performance, software optimization on algorithms and non-blocking I/O usually makes far more difference than minor hardware differences. For example, look at the recent thread optimizing trig function phase input range in a LED animation project.

I know many people like to talk about which hardware would be faster in a theoretical scenario where the software could be as optimal as possible. But the reality of many modern peripherals and protocols, like USB & Ethernet, is far more complexity than most people will ever manage to deal with for a single project. The supporting software matters greatly.
 
Status
Not open for further replies.
Back
Top