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
: Edited by User
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.
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)
To follow your first suggestion and optimize my code, where do I start? From what I found, I should use an avrdude/avr-gcc instead. Where is the difference and why is this more efficient? Please try to be precise.. Thank you! Have a look into my code! https://pastebin.com/vGe16nkH
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?
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.