Arduino for STM32

i took a closer look at the hardware timers, apparently what is called hardware timers on stm32s are called pwm on pico
https://datasheets.raspberrypi.org/rp20 ... asheet.pdf
so that 'pwm' can be used for to drive dma quite similar to how it is done on stm32

then what is called timers are probably more like a high accuracy rtc or some such

AndrewBCN wrote: Sat May 22, 2021 2:47 pm I am still trying to think of a single use case where the RP2040 would be a better choice than any member of the STM32 family, whether for a maker or for an engineer designing a product for industrial use.
Also in terms of development tools and ease of use, the STM32 family is light years ahead.
Btw I am an RPi 4 fan. Fantastic, extremely powerful SBC for as little as $35 (but I suggest going for the 4Gb version for as little as $55, and a USB M.2 drive for $40 more).
The RP2040, meh...

well i'm quite a fan of stm32s as well, but more because i'm *lazy* to learn other mcus, it is easier and use one set of tools for the programming.
the registers and headers are familiar etc. ST designed the stm32 families pretty well. e.g. i found that stm32f4xx pretty much use the same / similar registers across the stm32f4xx line, with the 'higher end' chips having more features / registers that 'entry level' ones don't.
this makes it possible to make .h includes files that could be used without 'if defs', at least not within the .h itself.
it is occasionally even possible to check registers on the 'lower end' ones to see that a particular feature isn't there and the firmware can 'skip' processing dynamically. this makes it possible to write a same firmware that can work on both 'low end' and 'high end' stm32f4 chips.

for what is worth rp2040 has lots of sram (they moved flash out to external to make room for it), while sram and flash are abundant on the 'higher end' stm32 chips. so if considering a board, rp2040 is more 'flexible' as you can combine different amount of flash with the same limited amount of sram.
that sram and abundant flash (since it is external after all) makes it possible to run things like micropython which would otherwise not fit in there.
and having more sram and flash means bigger and fatter arduino sketches can be written and run on RPi pico.

i tried making a web server interacting with esp8266 on a stm32f103c8, the main thing about that 'web' stuff is that even a simple http header can blow the 20k sram budget on a stm32f103c8, and you still need sram for the normal ops (e.g. stack), global variables etc. sram is precious on the small devices.
making a web server with a 'duino' is easy on RPi pico due to the large cache of sram. that would make possible 'simple' stuff like controlling a led from a web page. and it isn't just limited to 'leds', you could probably put a whole motor control web (say a 3d printer) on the RPi pico making use of the sram and flash, and you can probably stream your 3d printing (or cnc machine) gcodes across wifi via a web or mqtt interface.
i'd think mqtt is already possible with stm32 even the small stm32f103c8 20k sram. but for a full 'web' experience, it'd take a more abundant sram/flash mcu e.g. the 'higher' end stm32 say stm32f407ve 512k sram & 512k flash or stm32f405rg 512k sram 1m flash etc

ag123 wrote: Sat May 22, 2021 4:14 pm
... but for a full 'web' experience, it'd take a more abundant sram/flash mcu e.g. the 'higher' end stm32 say stm32f407ve 512k sram & 512k flash or stm32f405rg 512k sram 1m flash etc

... but the RP2040 everyday price of $4 USD is a powerful price point. I ran several sketches under Arduino and had success; even dual-core, but there is no RTOS currently integrated into the core so the programmer needs to handle incorporating some "rtos" or manage hardware conflicts by code: that is suspending one core while another uses a shared hardware device. Of course, the default Arduino configuration is just to pretend it is single-core.

Considering the above, Espressif ESP32 has a mature Arduino core and an integrated FreeRTOS pre-configured in every Arduino image ... and at under $6 each (qty=3 Amazon Prime)

And if you are doing web-stuff, the ESP32 already has the 2.4G RF section ... so, the extra $2 for the ESP32 sounds like a bargain.

@ray
for a SMP RTOS, i think currently a best one is Nuttx, it isn't Arduino though
https://www.hackster.io/news/the-raspbe ... b07a04060c
https://nuttx.apache.org/
but i'd think SMP requires a rethink of how to wire up the io layers, *duino style codes are normally not thread safe, nor are they designed to run multi-processing

i'd guess FreeRTOS can be integrated with Arduino but it'd take some effort / time to get it done correctly, but at least that provides some form of multi-thread, smp support. But with that a lot of things has to be manually patched up when accessing the 'core' (kernel) layers. e.g. one may need a mutex for some things and that there is a danger of deadlocks if not careful.

i've read things like if thread 1 locks mutex A then mutex B, while thread 2 locks mutex B then mutex A, you simply gets a dead lock as the 2 threads will be waiting for each other to release a mutex.

and as we are talking about FreeRTOS, there are already efforts in the community
https://forums.freertos.org/t/freertos- ... 2040/12135
https://www.seeedstudio.com/blog/2021/0 ... y-pi-pico/

mrburnette wrote: Sun May 23, 2021 2:26 am ...
And if you are doing web-stuff, the ESP32 already has the 2.4G RF section ... so, the extra $2 for the ESP32 sounds like a bargain.

Yes, for the usual MCU projects where every $0.01 counts, the RP2040 is trying to squeeze into a market that is already abundantly covered by various tried and proven MCUs (STM32 family, AVR family, etc) with tried and proven developments tools, and for what you call "web-stuff" (here I thought the buzzword was IoT or Internet of Things), the growing ESP32 family provides much better/cheaper solutions.

So again, I am left wondering what exactly was the Raspberry Pi Foundation thinking when they thought it was a good idea to spend a vast amount of money, time and resources on developing a proprietary low/mid-range ARM MCU from scratch? Personally I believe those same resources would have been better employed expanding their extremely successful Raspberry Pi SBC family.

In any case, as an embedded software/hardware development engineer and a maker, I have exactly zero motivation to try the RP2040. And it seems I am not the only one: https://hackaday.com/2021/05/19/raspber ... rspective/

my guess is that RP2040 is an IP belonging to RPi foundation, hence they can sell it for more margins than they'd get designing open sourced boards as it is unlikely they get much margins for using commonly found components. RPi boards are apparently being manufactured by various oem manufacturers e.g. element14 farnell etc possibly under license agreements. but with RP2040, RPi foundation simply need to sell the chip others can make the board for possibly 'free' as long as they stick to the specs e.g. RPi pico. so for the 'others' e.g. Adafruit they would feel 'free' to design their own boards after all and just get the chip, so do this tiny 2040. oem's has incentive to design their own boards for a simple way to distinguish their products from 'others'. But it'd make the boards available in market more fragmented, just like the chinese 'pill' boards and other stm32 boards. i.e. it'd be harder to make a 'shield' that fits them all.

for me as i'm just playing with these RPi pico is just another toy as like the common stm32 blue pills, black pills etc boards.
i'm only liking it just for the less stingy sram and flash outlay. apart from that stm32 has a lot of merits, e.g. stm32's hardware timers is possibly more advanced compared to pico's pwm's it'd seemed for some use cases it is possible to do so on stm32's timers (e.g. input capture) but may not be possible on pico. and stm32 timers seemed to be capable of more elaborate waveform generation compared to pico's pwm. however, it is casual and i've not really studied it to really say it is indeed the case.

ag123 wrote: Sun May 23, 2021 9:24 am my guess is that RP2040 is ...

Since we are all guessing, I doubt if "profit" from chip sales was a business driver. I suspect it was because the rPi boards are woefully deficient for I/O + sensor integration... many (most!) of my rPi projects eventually use an Arduino to do real interfacing. In the worse-case, I do all sensors on an Arduino and serial-BT the Arduino output as faux JSON which is easily consumed by NodeRED running on the rPi. (Pix below of a test.)

I would not be surprised if uPython was chosen as the default language because rPi is already heavily invested in Python, including Thorny with each Raspbian image. That said, the toolchain for C/C++ was required for porting microPython. Once that was complete, Adafruit just hacks uPython to generate a flavor of CircuitPython. I actually think this is rather clever. For hardcore types and HAT developers, C++ is already there. If implemented correctly, Pico could become the preferred uC bridge for all those sensors that Adafruit sells as Ladyada publishes working libraries for the vast majority of her products.

I have written real native C to run on the rPi (just once) and it was a P.I.T.A. ... I'd rather learn uPython.

nothing against upython and the similar alternatives (embedded lua?). the main difference between upython vs c/c++ is that in c/c++ the codes are linked and any unused functions are removed by the compiler, this significantly reduce binary foot print and also significantly reduce sram usage.
for upython and the alternatives, although dynamic loading is still used, normally the full modules need to be loaded, even if some of the binary codes wouldn't be used. and i'd guess additional ram would be needed for various marshaling and dynamic linking as well. this would make the apps memory and storage hungry though with dynamic loading very significant apps can be written with modest amount of memory. just that if the mcu is too 'small', it would be too squeezed for resources to run upython.

My (limited) experience with uPython is that it is extremely efficient.

I could envision a rPi "feeding" over a serial port the Python code to the REPL as fast as the RP2040 can digest it. As such, the SD feeding the script from the SD card (or SSD) is essentially unlimited in storage capacity (relative to the script size.) Research Raspberrypi.org/forums for "autologin serial port"

(The same serial concept can be applied in reverse; that is the RP2040 can control the rPi over the serial port. Example: RP2040 can manipulate such things as MPD/MPC on the rPi for internet radio. The serial console is bi-directional, so the RP2040 can react to errors or even parse the station/song names. Code proven on Arduino programmed BluePill.)

Implementation to play internet radio on rPi with control from BluePill using a joystick! Almost any state machine can be implemented in a similar way. I included the entire sketch for anyone wanting to play around (and improve the POC) with the concept. For example, were I wishing to monitor 8 analog signals with the rPi, I would only require a RP2040 running uPython and an analog mux such as the CD74HC4051. The rPi would send serial to the REPL, 3 RD2040 lines would address the 4051, the Pico would perform the analog readings, apply any statistics required, and send the answer back to the rPi if warranted for displaying or processing in something like NodeRED: also the immediate benefit for a web-based experience at no cost (as in free.) The same thought process applies for any peripheral internal/external to the Pico uC. Allowing Adafruit and others to devote energy to the uPython libraries is brilliant (as in 'no-brainer')
https://circuitpython.org/libraries

As real world readings are often needed in non-real-time, small processing delays are often permissible and leads to an inexpensive and sophisticated, flexible solution.

Opinion: From my year working in research at Uni, I can say that too many solutions are over-engineered.

Updated Libraries
Adafruit_CircuitPython_AMG88xx
Adafruit_CircuitPython_BME280
Adafruit_CircuitPython_CharLCD
Adafruit_CircuitPython_DotStar
Adafruit_CircuitPython_FakeRequests
Adafruit_CircuitPython_FunHouse
Adafruit_CircuitPython_HTU21D
Adafruit_CircuitPython_HTU31D
Adafruit_CircuitPython_IL0373
Adafruit_CircuitPython_IL0398
Adafruit_CircuitPython_IL91874
Adafruit_CircuitPython_MCP230xx
Adafruit_CircuitPython_MCP9808
Adafruit_CircuitPython_MONSTERM4SK
Adafruit_CircuitPython_NeoPixel
Adafruit_CircuitPython_ProgressBar
Adafruit_CircuitPython_Pypixelbuf
Adafruit_CircuitPython_seesaw
Adafruit_CircuitPython_SHT4x
Adafruit_CircuitPython_SSD1306
Adafruit_CircuitPython_SSD1608
Adafruit_CircuitPython_SSD1675
Adafruit_CircuitPython_SSD1680
Adafruit_CircuitPython_SSD1681
Adafruit_CircuitPython_TinyLoRa
CircuitPython_Community_Bundle

mrburnette wrote: Mon May 24, 2021 2:33 pm ...
For example, were I wishing to monitor 8 analog signals with the rPi, I would only require a RP2040 running uPython and an analog mux such as the CD74HC4051.
...

Or you could use a $5 WeAct STM32F411CEU6 "Black Pill" and use any 8 of its 10 available 12-bit ADC channels, and avoid the cost and hassle of the analog mux chip + its printed circuit board + assembling/soldering. And as for programming the WeAct STM32F411CEU6 "Black Pill":
1. CircuitPython: https://circuitpython.org/board/stm32f411ce_blackpill/
2. MicroPython: https://github.com/micropython/micropyt ... 32-version
3. Arduino IDE and good old C/C++ code: here...

Again: I can't think of a single example where the RP2040 has a clear advantage over the existing MCU families.