pico rp2040
Hi,
i'm interested about adding rp2040 microcontroller.
before starting anything, i just try running an atmega328 with a 160 MHz clock.
i can't have real time, so it's a bit annoying as rp2040 run up to 133MHz.
Did you try using a QThread for each mcu ?
maybe eMcu::runEvent method could start eMcu::stepCpu in a Thread and get the result next time.
Don't know if it's clear :
is it possible that eMcu::runEvent :
-> save input states
-> get output states of last execution of stepCpu
-> run eMcu::stepCpu in a QThread and didn't wait the result, it would be read next time
I think I'll give it a try
Hi.
I don't think that threading is a solution in this case, but maybe there is a way that I don't know.
In any case running anything at 160 MHz and real time is not easy:
Executing 10 instructions will "consume" 1.6 GHz, so the maximum you can execute each cycle is a few 10's of instructions.
You can't do much with that.
If you do some experiments please let me know what do you get.
Hi,
i did some experiments and i agree with you.
when the task is too fast, threading didn't help
-> QThread with QMutex is way slower
-> QThread with signal/slot is not that bad but significantly slower
-> QThread with "volatile" members instead of QMutex is better but slow too
Thank you very much for the feedback.
I have been thinking about this, and maybe there is some chance for these high frequency MCUs at least in some cases:
Often the interaction with the Circuit is not that fast, maybe in the ms range.
So a MCU in the 100's MHz range could run 100's K clock cycles in another thread until it needs to interact the circuit.
In this case the overhead of using another thread could be worth as it will run 100's K clock cycles in each run instead of 1.
The challenge is to know how many cycles should the MCU run until it needs to synchronize with the circuit.
For outputs and input reads it's easy: the MCU will run code until it does an IO Pin operation.
But for inputs that must "react" to circuit changes seems almost impossible to predict.
So I don't see a viable solution, but maybe there is some chance I can't imagine yet...
interesting.
It could speed up a lot, notably with programs which uses delay function.
But for inputs that must "react" to circuit changes seems almost impossible to predict.
you mean interrupts ?
i think interrupts shouldn't be a problem most of the times :
-> they are not related/synchronised to "main" code so it won't change the behavior if they are executed at a "wrong" time
-> problems could be related to timer usage, i haven't look at this part of the code for the moment.
maybe we could try with a simulation option wich could be desactivated : fast simulation vs as realistic as possible
you mean interrupts ?
Yes, and things like timers driven by external clock, comparators, waking from sleep, etc.
And in some cases timing can matter.
In any case implementing something like this is still a challenge (devil is in the details), the MCU should run always "ahead" of the circuit or something like that.
Often the circuit could run way faster than the MCU, so we need some mechanism for the circuit to wait for the MCU, and this can become more complicated if there are more that 1 MCU.
Also Simulide 1 has no support for 32 bits CPUs/MCUs, I'm working on it for Simulide 2, but this is still very raw.
And something like this would require some refactoring on how MCUs work (creating an event loop inside the MCU).
Also Simulide 2 will be notably faster, that will help as well.
So I can see something like this implemented in Simulide 2.
For Simulide 1 I don't see any chance.
maybe we could try with a simulation option wich could be desactivated : fast simulation vs as realistic as possible
Yes, that could be a good option, in most cases synchronization from circuit to MCU is not needed.
EDIT:
Indeed many of those cases when the MCU should "react" to circuit changes could be detected, showing a warning or something.
For example: a timer is configured to use external clock.