Comparison of arduino-pico to MBED-OS core (app size, RAM, features, etc.)

[urish]

First of all, thanks again Earle for working on this project!

I'm working on integrating rp2040js into the Wokwi online simulator. Right now, the integration uses the official Mbed OS-based core which recently added support for the RP2040 / Pi Pico board.

I'd love to support both cores, and let the users choose which core to use when compiling their project. But naming things is hard, and I'd appreciate your input about how to call this core in a way that will differentiate it from the official, Mbed OS one.

We could go with "official" vs "unofficial" or "ArduinoCore-mbed" vs "earlephilhower", but there are probably some better ideas.

p.s. here's an early preview of the Pi Pico and a 2 LEDs in simulation.

[earlephilhower]

There are two hard problems in computer science: naming things, cache coherency, and off-by-one errors. :)

For names, why not use "ArduinoCore" and "Community"? Others in web coverage already used that term, and it seems appropriate and more meaningful than my own name.

That's a very neat tool, BTW. I can see it being handy for elementary school STEM teaching!

[urish]

Thank you!

There are two hard problems in computer science: naming things, cache coherency, and off-by-one errors. :)

Two hard problems? I believe I counted four!

For names, why not use "ArduinoCore" and "Community"? Others in web coverage already used that term, and it seems appropriate and more meaningful than my own name.

I went with arduino-core vs arduino-community. You can see your Arduino core in action in this traffic light example.

I hope to merge this preview version into the main site next week.

I also plan to work on GPIO input in the next live stream. This should open some more hardware options (pushbutton, switch, keypad, lcd-1602, etc.). PIO is also coming sometime next month. As I promised before, I will let you know as soon as we begin working on PIO.

By the way, is there any list of the key differences between the community core and the Mbed OS core?

I looked through the docs (great job, BTW), but couldn't find such list.

[earlephilhower]

Unfortunately I don't have a list of comparisons between MBED and this version.

My belief from looking at the MBED code is that the major differences are:

• MBED is Arduino.cc managed so by definition it's "true Arduino" :)
• GCC version (10.2 here, 7.x?? MBED), Newlib (4.0 vs 3.x?)
• PIO use...I don't think they're used at all in MBED, here we do it for Tone, Servo, and I2S (not present on MBED yet)
• Peripherals (both sets of I2C, SPI, UART and pin configs available here, only 1 set on MBED with fixed pinout)
• EEPROM (emulated here, I think not present on MBED)
• Multicore (setup1/loop1 vs. calling raw SDK...I assume that is possible in MBED, but not 100% sure)
• MBED version probably has better compatibility and testing than this repo, that's the joy of code reuse!
• Board support (not yet in MBED...but probably will be added by the vendors given time)

Overall, both probably support the same features and 3rd party libraries just fine with minor differences (i.e. LittleFS here vs. the VFS implementation in mbedOS).

It might be interesting to find a non-trivial example and see what kind of differences in code/RAM there are. I don't know how much overhead the MBED OS bit adds (ARM is very good at optimizing things!) vs. the direct SDK use here.

[urish]

Actually, this is a great answer. I'm in the process of writing the documentation for the pi pico simulator, mind if I link to this list?

[earlephilhower]

Sure, link away. If someone has any corrections, they can leave something here and I can update the post. I'm not claiming my 1st impressions above are correct and I'm sure both versions are moving targets!

[jmnc2]

Well building the Examples basic blink sketch with Arduino IDE 2 And MBed gives:

Sketch uses 80072 bytes (0%) of program storage space. Maximum is 16777216 bytes.
Global variables use 52920 bytes (19%) of dynamic memory, leaving 217416 bytes for local variables. Maximum is 270336 bytes.

1/5th of ram to blink the LED seems a lot.

[earlephilhower]

Good data point!

In the core here using the Arduino blink.ino example I get

/home/earle/Arduino/hardware/pico/rp2040/system/arm-none-eabi/bin/arm-none-eabi-size -A /tmp/arduino_build_646370/Blink.ino.elf
Sketch uses 212756 bytes (10%) of program storage space. Maximum is 2093056 bytes.
Global variables use 16812 bytes (6%) of dynamic memory, leaving 245332 bytes for local variables. Maximum is 262144 bytes.

I seem to have a much larger base code footprint, but significantly lower RAM usage. I have a feeling that things like the FS/etc. are baked in to the build image for me even if they're not used. I'd need to look at the MAP/ELF files from both builds to determine things with more precision.

[urish]

Sure, link away. If someone has any corrections, they can leave something here and I can update the post. I'm not claiming my 1st impressions above are correct and I'm sure both versions are moving targets!

Thanks, linked!

Other than PIO, is there any way the emulator can be useful for you or the users of the core? Perhaps for some of the documentation code examples?

[earlephilhower]

Maybe opening a discussion or using the forums at raspberrypi.org would be the best way to answer.

With the really good SWD GDB support (and picoprobe meaning no special HW needed), most core issues are pretty straightforward to trace. I think a simulator would be most useful for debugging low level peripheral stuff....interrupts, internal FIFOS/registers/etc. But that's me, so may not be representative of most users so do take with a grain of salt!

[earlephilhower]

Also, it looks like I have some issue w/c++ exceptions which is why the code is so large. They're enabled, which eats a LOT of flash, but for general Arduino compatibility they should be disabled. Probably 100K of the 200K base image size is exception unwinding logic/etc. :(

[earlephilhower]

For posterity, #137 fixes the memory/ROM usage and massively shrinks both RAM and ROM footprint of sketches.

[urish]

For posterity, #137 fixes the memory/ROM usage and massively shrinks both RAM and ROM footprint of sketches.

Cool, waiting for the release and will update the online simulator with this version

[fabianoriccardi]

I would update this discussion. Compiling blink.ino sketch I get (v1.9.1):

Sketch uses 57808 bytes (2%) of program storage space. Maximum is 2093056 bytes.
Global variables use 11640 bytes (4%) of dynamic memory, leaving 250504 bytes for local variables. Maximum is 262144 bytes.

while using official arduino core (Mbed OS RP2040 v2.2.0):

Sketch uses 78496 bytes (0%) of program storage space. Maximum is 16777216 bytes.
Global variables use 52656 bytes (19%) of dynamic memory, leaving 217680 bytes for local variables. Maximum is 270336 bytes.

[earlephilhower]

Good info, thanks!

Note, though, that for some reason the MBED core only seems to report a 16MB flash, so while ~35% more program flash bytes are used in MBED, the "% of program storage space" is lower.

The MBED core also adds in both CORE0 and CORE1 stacks in free RAM (giving 270K) reports, which seems bogus (since you'd need stacks for at least 1 core, even if they don't support dual cores) but maybe I don't understand how they manage stacks...dynamic allocation, maybe? In any case, the 2 scratchpads are non-contiguous with heap so it seems like it'd be hard to do.

[fabianoriccardi]

Yes thank for adding the comment, In fact I was a bit confused about the maximum values provided by mbed core, since they exceed the specifications in the datasheet.

Maybe another difference is about the first boot and serial port: at the first boot, you can just flash the firmware even if the serial port is not available, while with the official core you have to paste the exported binary in UF2 partition.

[earlephilhower]

With #245 the RAM and Flash memory usage has gone down even more. Here's Blink.ino:

Sketch uses 52236 bytes (2%) of program storage space. Maximum is 2093056 bytes.
Global variables use 7864 bytes (2%) of dynamic memory, leaving 254280 bytes for local variables. Maximum is 262144 bytes.

Basically, the stdc++ library was built w/exceptions enabled, but not used since we run with -fno-exceptions. There was a 4K chunk of code in RAM supporting and a 6K chunk of code in flash supporting it, but never being used.

[earlephilhower]

(Moved to a discussion and opened since this is actually a handy thread to have...)

[chrisckc]

I tried to use the official Arduino MBED-OS core to read an ADC at around 12KHz. I setup an interrupt on the "data_ready" pin of the ADC and used this to then poll the data from the SPI bus.

I found that the delay between the data ready pulse on the pin and the interrupt firing was too long to allow anywhere near this speed. The average delay was around 200 to 300uS, the delay was varied greatly, being unpredictable.

I quickly abandoned it in favour of Arduino-Pico, using this I was seeing only around 5uS interrupt delay which also included the time taken to set an output pin low to measure the delay.

I would expect the MBED RTOS to add delays but not to that extent.

I recently encountered another issue with the official Arduino MBED-OS core, huge interrupt delays when receiving data in i2c slave mode and large random amounts of missing data. The missing data part of the issue is linked to an issue I logged here which I have found also exists using the Pico SDK directly.
#979