Faster microcontroller

OP #6190604
Hello all, I'm currently using an Mega 2560 PRO (RobotDyn) to read the 
UART communication between my ebikes display and controller. It's 
purpose is to read specific commands and manipulate them (ex. limit 
current draw) or to trigger actions (ex. braking > brake light on).

The momentary speed is transferred using UART as well. Since it's 
processing a lot of commands, there's a noticeable delay with speed 
updates in the display.

Is there a faster microcontroller than the ATmega2560 to solve this? I'm 
embedding it into a 3D printed case. I thought about the STM32H7 
(https://www.aliexpress.com/item/4000065515487.html). I'm not into 
PCB-designing, so it should be an development board, similar to the 
RobotDyn.

I attached an image of my box.

More about this project (in case you're interested):
https://endless-sphere.com/forums/viewtopic.php?t=94850
Attached files:
Guest
Kim N. wrote:
> Is there a faster microcontroller than the ATmega2560 to solve this?

Up to Teensy 4.0 with 400MHz.

But probably your ATmega256 is fast enough if programmed efficiently.
Guest
Let me just guess:

You are using several slow uarts with the arduino framework in blocking 
mode and now you need a faster microcontroller?

For your task everything with enough hardware uarts should be suitable, 
the problem is that some programming skills are required as it was 
already mentioned above.

You have two options:

1. Learn to use a microcontroller without a kid-friendly but clumsy 
framework (or at least google for a better implementation of the uart, 
that would already fix your problem)

2. Ask how to use a raspberry pi for your application, because of your 
demand on huge processing power (to keep up with modern arduino makers)
Guest
Kim N. wrote:
> Since it's
> processing a lot of commands, there's a noticeable delay with speed
> updates in the display.

Maybe, on over 1000 different commands the parsing speed may have 
influence.
But I think, there are other time gulping tasks on your program, e.g. 
slow display speed, which can not be solved by a faster CPU.
A typical programmers fault was, that the display was written dozen 
times faster, than a human was able to read.

Which speed use the UART?
Guest
Kim N. wrote:
> Have a look into my code

Of course this is slow, because you have programmed it slowley.

All the serial.print slow down the program to the rate of the serial 
port, even a digitalRead does take 400 times as long as a 
PORTD|=(1<<BITPOS) .

Your program will not run faster if using a faster processor, it must be 
decoupled from slow I/O.

First remove ll the unneccessary serial. commands.

Then remove all the blocking while loops.

Simply told: Learn programming. Learn what's behind.

Reply

A question of your own? This thread is over 6 years old. Ask it in a thread of its own – more people read along there, and it gets answered more often and sooner.

Start a new thread

A fix, an addition or feedback on this thread? Then reply here.

Formatting
  • [c]C-Code[/c]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]
  • [[Title]] – link to an article
  • Link to another post: right-click its post ID (#8078628), copy the address, paste it into the text

More about formatting

Post long source code as an attachment, not in the text.

Already registered? Log in

Not shown to anyone. We send you a link; your post appears once you confirm it there.

By submitting you create a free account and accept the terms of use.