Fastest uC @ 5[v]

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am looking for the fastest uC that operates @ 5[v], GPIO and ADC have to be able to operate @ 5[v]. Currently, I am using A Nuvoton M4@75mhz@5[v] which is already fast but I could make good use of more computational horsepower, any suggestions would be greatly appreciated.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I could only find this: https://www.nxp.com/products/pro...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TY for the nxp suggestion, 160Mhz is really fast.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The fact that it is an M4 is probably more important than the 75MHz in fact.

 

Of course there are various versions of M4 (some parts of the core are options) so are you using hardware floating point, DSP facilities or NEON-SIMD ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

The higher clock speeds get hampered to a degree by the flash speed - faster clocks - more wait states. More MHz doesn't necessarily mean faster processing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

toalan wrote:
GPIO and ADC have to be able to operate @ 5[v]

Why is the "[v]" in brackets?

 

Could you cope with level translators if that meant you could use a much "faster" (sic) processor ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The $10 STM board with the 168MHz F4 (and built in debugger) is always a good option but you would need level transition for using that.

 

EDIT:  https://www.st.com/en/evaluation-tools/stm32f4discovery.html#sample-and-buy  but when did that go up from $10 to $20 ??

Last Edited: Wed. Sep 4, 2019 - 11:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Why would anyone want to use 5V GPIO ?
Surely 3.3V is more acceptable. And possibly use a chip with 5V tolerant GPIO on a few pins.
I can't think of (m)any external chips that require 5V

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Sep 4, 2019 - 12:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

power dissipation (CMOS power is proportional to the square of the voltage)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Why would anyone want to use 5V GPIO ?
noise margin

david.prentice wrote:
Surely 3.3V is more acceptable.
concur and the drive impedance can still be excellent; more low threshold FETs are appearing so can easily increase the drive's current.

david.prentice wrote:
And possibly use a chip with 5V tolerant GPIO on a few pins.
Prevalent in PIC32

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

david.prentice wrote:

And possibly use a chip with 5V tolerant GPIO on a few pins.

Prevalent in PIC32 

also STM32 ... 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

The higher clock speeds get hampered to a degree by the flash speed - faster clocks - more wait states. More MHz doesn't necessarily mean faster processing.

 

That is something that I was going to look into. I have enough RAM that I can load most of my functions into RAM and execute from RAM. On the M4, is there a metric/parameter that I can look at that indicates how flash bottlenecked the uC is?                                                                                                                                                                                                                

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look up how many wait states need to be dialled up vs clock rate. There was some discussion regarding the SAMD20/21 clock and wait state performance many moons ago. Running from ram should supercharge the performance vs executing from flash as most chips have full speed ram access.

 

interestingly, I just looked at the spec for the NuMicro M485 and it says 'zero wait state flash'. Maybe they're running a wide flash width (64/128/256.. bits wide) to get the required performance. Flash usually bummed out around 40MHz - maybe there's some new high speed flash technology?

Last Edited: Thu. Sep 5, 2019 - 03:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The faster arms get actual cache memory, to complicate io and interfere with determinism.
It may affect ram as well, unless it is “tightly coupled ram”...
There are 5v arm families from Cypress (psoc4 and 5, plus some more), NXP (FREESCALE KE series), and I think toshiba.

A well written story on a successive

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

toalan wrote:
On the M4, is there a metric/parameter that I can look at that indicates how flash bottlenecked the uC is?  

It's not really to do with the M4 - it's how the particular chip has all the rest of its memories and busses and other stuff configured & connected.

 

Running from RAM is not necessarily faster than running from Flash: as westfw suggests, because running from Flash is the normal use case, chip designers put a lot of effort & resources into ensuring that path is highly optimised - with things like Flash accelerators, cacheing, bus optimisation, etc ...

 

You may find that all RAM accesses go over 1 bus - both code & data - so that becomes a bottleneck...

 

etc, etc, ...

 

As already noted, the raw MHz figure is not necessarily very useful.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a performance monitoring unit called DWT defined by ARM, but it's optional. If present, maybe it can be used to benchmark flash vs RAM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed. But that would only tell you about Flash vs RAM on that particular chip - the result would not (necessarily) be portable to any other chip

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TY for all the info on the flash. When I have time I will move the most used functions into RAM and see how much of an improvement it brings. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


awneil wrote:
Indeed. But that would only tell you about Flash vs RAM on that particular chip - the result would not (necessarily) be portable to any other chip

 

Indeed. The manufacturer is supposed to tell us somewhere in the datasheet the penalty cycles for flash access, but sometimes it's difficult to find.

This is an example of how to do it right from the SAMD11 datasheet, that has selectable wait states for flash. So, at low voltage and high frequency, you may need to set a 3 cycle penalty on flash for reliable operation on this device.