Several questions regarding the pico environment

[HamzaHajeir]

Hi there,

As having a strong background in ESP8266 and ESP32, and yet new to the raspberry pico world, I'm having several inquiries/questions:

• On exception/abort, both ESPs dumps a stack, is there any comparable concept in pico?
• On exception, what method could be used to make the MCU reboot instead of hanging?
• The Serial terminal (in PlatformIO) does not respond when the MCU is hanging. It seems to me that the terminal on Ctrl+C triggers an action and waits a response from the pico which is already hung. Is it something that can be fixed? Any recommendation/suggestion regarding that? or we should just cope with :)?
• In both ESPs, there's an API to get the maximum heap block, which is extremely useful when it comes in estimating the max possible buffers, the H4 stack rely over to calculate the maximum packet size in various sources. Since RP2040 does not provide such an API, is there a method to cauculate? and if so, is there a plan to introduce?
• Is there a plan to enhance the WiFi class to manage events and perform auto reconnects asynchronously?
• The toolchain of both ESPs enables to erase the flash, does the RP toolchain permits that?

With thanks,
Hamza

[earlephilhower]

• On exception/abort, both ESPs dumps a stack, is there any comparable concept in pico?

It will panic() and you can use any SWD debugger (another Pico, even) to examine state. The ESPs dump stack over a physical UART/serial port, and there's a chip onboard that speaks USB on 1 end and UART on the other. Here, the Pico controls the port so a crash means no USB comms are possible, it's crashed.

• On exception, what method could be used to make the MCU reboot instead of hanging?

You can override panic() or use a watchdog timer to have the HW do it if your code doesn't tickle it every XXX milliseconds

• The Serial terminal (in PlatformIO) does not respond when the MCU is hanging. It seems to me that the terminal on Ctrl+C triggers an action and waits a response from the pico which is already hung. Is it something that can be fixed? Any recommendation/suggestion regarding that? or we should just cope with :)?

See the 1st note. USB is in SW on the Pico., You crash the Pico, you have immediate USB freeze.

• In both ESPs, there's an API to get the maximum heap block, which is extremely useful when it comes in estimating the max possible buffers, the H4 stack rely over to calculate the maximum packet size in various sources. Since RP2040 does not provide such an API, is there a method to cauculate? and if so, is there a plan to introduce?

No. On the 8266 we used UMM which handled this behind the scenes. It was important since we had only ~40KB total usable heap. The Pico uses Newlib's malloc which is scalable to the larger memory size.

• The toolchain of both ESPs enables to erase the flash, does the RP toolchain permits that?

No, and there's no real need for this. On the ESPs they stored some RF connection info in user flash and if it got corrupted you could end up with their BLOB hanging during chip boot or no WiFi. Here, any WiFi state lives in RAM on the CYW chip, not in the flash or the Pico chip.

The RPI folks do have a UF2 which you can manually/script upload to erase everything, check the SDK docs.

[HamzaHajeir]

Thank you for the elaborated answers.

You can override panic() or use a watchdog timer to have the HW do it if your code doesn't tickle it every XXX milliseconds

I think it's the already wrapping functions in RP2040 class of wdt_begin() and wdt_reset().

• In both ESPs, there's an API to get the maximum heap block, which is extremely useful when it comes in estimating the max possible buffers, the H4 stack rely over to calculate the maximum packet size in various sources. Since RP2040 does not provide such an API, is there a method to cauculate? and if so, is there a plan to introduce?

No. On the 8266 we used UMM which handled this behind the scenes. It was important since we had only ~40KB total usable heap. The Pico uses Newlib's malloc which is scalable to the larger memory size.

I see, I've just ported a simple estimated formula: (max block = free heap / 2). As the networking stack can deal easily with tens of KB of data (while memory is available).

• The toolchain of both ESPs enables to erase the flash, does the RP toolchain permits that?

No, and there's no real need for this. On the ESPs they stored some RF connection info in user flash and if it got corrupted you could end up with their BLOB hanging during chip boot or no WiFi. Here, any WiFi state lives in RAM on the CYW chip, not in the flash or the Pico chip.

The RPI folks do have a UF2 which you can manually/script upload to erase everything, check the SDK docs.

Nice, and for reference, here's a link for it.