@VIPQualityPost: some starters for multicore-programming (parallel functions, communication between cores, sharing MCU resources):
https://learnembeddedsystems.co.uk/basic-multicore-pico-example
https://arduino-pico.readthedocs.io/en/latest/multicore.html
https://community.element14.com/products/raspberry-pi/b/blog/posts/four-multicore-c-programs-for-raspberry-pi-pico-using-arduino-ide
https://www.hackster.io/news/multicore-arduino-the-easy-way-ec8b0c73c5ae
2 Likes
We tested again our 48V (ACT 86BLF04 500W) motor, this time without load/highest speed and the Pico crashed again. I measured the GND to GND voltage between different GND points and that was high. The reason is as already suggested above the back EMF (produced induction voltage) of the motor at high speed.
Then I added this code change to our driver ([FEATURE] Include motor inductance in voltage control. ¡ Issue #246 ¡ simplefoc/Arduino-FOC ¡ GitHub) and the GND glitches were almost gone. Only at highest speed the Pico crashed again (due to sporadic, very short voltage glitches). I finally added a 1000uF capacitor to the Pico 3.3v and the Pico crashes are now gone at no load/high speed - Lesson learned: Try to add computed EMF into your controller calculations and âfixâ the remaining glitches by hardware 
âŚ
1 Like
I am a RP2040 fanboi, because itâs pretty good (definitely I have a lot of ideas for the version 2.0, but itâs only like a year old at this point) and open source all the way down. I think learning and using it is has a good future because we know it will only get better, more supported, stick around etc. I have read it is more of a standard for microcontrollers rather than about this exact chip, which imo is a great idea.
The second core is super important for this kind of thing I think, this is what I was getting at with my waveform generator. You get a lot of complications fast when you try to weave waveform generation in with the other things that need to be done. Nobody liked my waveform idea because of communication issues (which I donât think are that bad but whatever). But with a second core you can just use global variables for instance. There is not in/out, no checking the interface, practically no delays.
The GPIO peripherals also help a lot and would have solved several of the problems I encountered before I even noticed them. They can do the I2C communication, for instance, so itâs not blocking any more. It blocks for at least 300 microseconds for an as5600 otherwise, for instance. SPI is faster but itâs still blocking.
I have had problems with the second core crashing too and I donât know why, there seems to be only preliminary support. You really have to keep the stuff on that second core to a minimum, which it sounds like you are doing.
Perhaps we could use an RP2040 on the Lepton 3.0. I floated that idea previously and Runger said the STM32 chips are better because of their various features, but I have to admit I havenât been that impressed. I will have to try running that test code on the G431 board though to see, I know it does the motor.move() loop at 37.5 khz, clock speed is 170Mhz, M4 core. The Lepton, which is an M0 core at 64Mhz, and has no floating point hardware, does it at 5kHz. If the Rp2040 could do it at say 10kHz then thatâs good for lots of stuff.
What I would really like to do is wrap a highly optimized waveform generator into a micropython module that could run on the second core :-). Then I can just use micropython for all the slow stuff on the primary core.
These chips btw have no supply issues, that is an important strength.
Actually I did not like the idea of a HAT before, but I am warming up to in now. Just a HAT with some current sensors and 6 pin PWM stuff could become a real workhorse. Ditch the G431 maybe. Might be a good idea. What else are the points in favor and against the two chips?
I will have to look a this computed EMF stuff, it sounds important.
I agree, but keep in mind STM MCUs track record is many years, RP2040 is a newbie by comparison. So if youâre looking for tried and proven tech, RP2040 isnât the one.
Certainly the communications can be a lot faster, but it is still two independent, concurrently executing cores. So sharing data between the threads running on them is not completely trivial - concurrent programming has many tricky pitfalls. Interrupts are a much simpler model.
This is a misconception. The I2C and SPI peripherals on RP2040 and STM32 arenât that different in their operation - in each case they are functionally independent âblocksâ which do their thing independently of the main CPU. They communicate via buffers/fifos and are asynchronous, generating interrupts or DMA requests when they are done with their work.
The part that is synchronous (blocking) is the Arduino frameworks API to these peripherals, and this is the same on RP2040 and on STM32, and on any MCU you use through Arduino.
I think @greymfm identified his problem rather nicely. Why the problem happens on the second core is still a somewhat open question, it may just be because it is doing more work and needing more powerâŚ
Perhaps. Perhaps itâs also a weakness though - e.g. no one was interested enough to use/buy them in serious quantities. 
Seriously though, the STM32 were not available because simply everyone uses them. RP2040 were, because theyâre more or less a maker product, not (yet) used in real products.
The many advantages of the RP2040 are well knownâŚ
Perhaps less well known are some of the differences that may play a role in motor control:
- RP2040 comes in one package, with one pinout. STM32s are available in 100s of packages and pinouts.
- STM32s are generally âready to goâ with only a few capacitors as required components. RP2040 needs external flash memory, which complicates board design.
- STM32 has excellent motor control features, supported for at least one motor on almost all of their chips (donât use the L0 series!), while RP2040 was clearly not designed with motor control in mind
- Compared to RP2040, this includes a complex event system between ADC, DMA and PWM enabling use cases like low side current sensing, which wonât work on the RP2040
- Speaking of ADC, the RP2040 one is buggy, and is slow compared to STM32s
- STM32 PWM features include break input support, dead-time insertion and a trigger/event system
- Some STM32 models include OpAmps and Comparators, enabling designs with built-in current sense amplification, BEMF zero crossing detection or hardware over-current protection
- many STM32s come with encoder support, while this can be done with the PIOs on RP2040
- But RP2040s have 2 cores, which is only available in the highest end STM32s, at many times the cost
Note that in terms of SimpleFOC hardly any of these advanced features are supported by the library
I think one of the principle advantages of RP2040 is the price, which is really more than fair for a mid-range 32 bit MCU like this. Or said another way, itâs cheap as f***.
Personally, Iâm quite a fan of the ESP32. Itâs also very inexpensive, far more powerful than any cortex M0, also available in dual core models, and comes with a huge amount of peripherals, including WiFi. Unfortunately its ADC is also not very good, but many models do have a MCPWM unit which is specifically designed for motor control.
To me, the ESP32 is still much better than this generation of the RP2040, but like you I am also eager to see the next generation of the Pico and how it progressesâŚ
I have read the reason they are available is because the die is very small, thus they use relatively little silicon an are easy to make. Not because they are crummy and they made too many and no one wants themâŚ
The small die size may be related to the no internal memory, so you have to pick one - available or internal memory. Using an actual pico board seems like it mostly solves that problem, because they are only $5.5 usd each and they have some other good stuff on them which youâd have to pay for if you made your own board anyway. In other words, a HAT may not be a bad idea after all. Suppose itâs $17 for both after everything.
However I did not have too bad an experience with the STM32s and I am generally agreeing and thinking that a G431 based board is still the most advisable path, as a single board for the community to adopt as the flagship.
You obviously know way more about the details of microcontrollers, but I guess where Iâm coming from is that features that are supposedly wonderful but somehow have never been harnessed are not that interesting to me. For example, Arduino has been around for a long time, and I did see some stuff about people throwing around the idea of making non-blocking I2C code, but no one has ever done it. So here we are.
One valid approach may be to make a list of libraries for arduino that need to be written at a low level to make simpleFOC more practical. However this would I assume end up being specific to hardware. If we flocked around say the lepton 3.0 this may be worth doing, as what gets done stays done and is multiplied by the quality of the board etc.
As often happens, we look for a way to squeak by and make do, and two cores or even two MCUs does appear to be helpful in making that happen. I do think it is a sound concept on this subject, as it eases complexity and debugging and timing issues.