No Flash Configuration and CMake Modifications

[daveythacher]

How hard would it be to add a few configurations without flash? (Arduino may not play nice with this.)

I took a look at it and found the linker script (lib/memmap_default.ld) which has been edited for filesystem and EEPROM. I was able to rename the default linker to use the no flash linker script. Arduino still reports certain things, which is annoying. However, I found in boards.txt a few settings which made it use correct sizes. However, Arduino appears to be mostly built for Harvard systems.

Would also be nice to be able to change the CMAKE settings. Default CMake settings are used? So, I do not need to worry about heap overflows as the guards are not used? (I can technically exceed the heap allocation settings used.) I am guessing the main CMake file is in /tools/libpico/CMakeLists? Meaning that if I edit that file that would be the same thing as compiling on the command line?

[earlephilhower]

The cmake question is easiest to answer: you can change what you like, but it won’t be used unless you manually, outside of Arduino, rebuild it with the makelibpjco.sh script.

Not sure what you mean about heap overflow, did you mean stack overflow? The stacks are now on the private 4k scratchpad areas. GCC does have a stack smash checking option, but that’s just making sure a function doesn’t overwrite past the end of its frame, not that the stack is within some range.

There isn’t a good way now to specify a different link script, but there’s no reason you couldn’t put in the work to make it possible as one of the IDE menus.

[daveythacher]

I want to say the pico-sdk has default heap size and has optional guards to block over allocation. By default, the heap is fairly small, and the guards are disabled. I just wanted to confirm that I could make large allocations. Good to know about the script for changing the CMake settings.

Is changing the linker script all it would take to move over to all no-flash? I have an application which cannot use XIP due to time, so I need some of the routines to be in stripped RAM. I am too lazy to figure out how to use the pico-sdk ram function attribute in C++. However, since my program is small, I just plan to move it over to no-flash. I am trying using Arduino so I can use it on the desktop without too much hassle.

Arduino apparently does not like this too much. I think Arduino could be made to support this fairly easily, however how much complexity it wants to expose to the user is the question.

I am not sure how Arduino will like the idea of scratchpad areas come to the think of it. I know the RP2040 does this for performance reasons. It also offers a means of allocating the core1 stack on the stripped RAM. This could be better considering the undocumented core0/1 stack limit. That being said I think the approach you use with setup1/loop1 is correct and better.

[earlephilhower]

You'll have to test whether just swapping out the linker script will work. I think it should, but it's not something I've tested.

The problem with doing it that way is that the code will never be put into flash, so on a powercycle it will be lost. So, except for testing, it's not really useful for anything in the real world.

Decorating your functions with __not_in_flash_func() like this is a better way to run fast:

arduino-pico/cores/rp2040/SerialPIO.cpp

Line 78 in d43dcbc

static void __not_in_flash_func(_fifoIRQ)() {

What happens is you have a copy of the fcn in flash which is then copied to RAM during the startup phase and only accessed via that RAM location. It's used for IRQs and other things that need to be as fast as possible in the core and other examples in the SDK.

[daveythacher]

I am planning to have the Pi program the RP2040 during program load. The RP2040 is acting as a hardware interface. I care more about the determinism and power consumption of the RP2040. For my particular application I can afford to waste the RAM. In theory I could save 50 cents doing it all from RAM. It would be a little easier to use the flash, but if it is simpler, I may just drop it.

I observed a difference between this:

arduino-pico/cores/rp2040/SerialPIO.cpp

Line 78 in d43dcbc

static void __not_in_flash_func(_fifoIRQ)() {

and this:

arduino-pico/cores/rp2040/SerialPIO.cpp

Line 90 in d43dcbc

void __not_in_flash_func(SerialPIO::_handleIRQ)() {

The former appeared to work while the later did not. I explained this away with symbol mangling, but I really have no idea.

[daveythacher]

I just ran a test, it appears to work for both. My apologies. I had to look into the map and disassembly to verify it.