New Target hardware? Raspberry Pi pico?

[RichMorin]

I recently posted a note to the Elixir Forum, asking about the possibility of porting Nerves to the Raspberry Pi pico. Frank Hunleth (fhunleth) replied as follows:

The Nerves core team is focused on microprocessor-based embedded devices, so supporting a Cortex-M0 device is not something that we’d take on. That’s not to say that what you propose wouldn’t be interesting.

The two routes I know that might support the Pico are:

• Porting AtomVM which is a small BEAM bytecode interpreter
• Using Lumen to compile Elixir to machine code.

I'd greatly prefer the first route, since it would (in theory) allow any BEAM-supported language to run on the pico. Please consider making the pico a first-class target, since it's certain to be a very popular platform.

-r

[tlack]

Hey Rich,

I was able to get AtomVM compiled cleanly into the Pico SDK via the "examples" system if I recall.

But at that point I was stuck because I couldn't find a way to transfer the .AVM bytecode (of your actual program) to the device.

So, where do I load the root module from?

On the ESP32 you can put it in a partition. On the K210 you can append the data to the firmware file when you write it. But on the Pico I couldn't find any good documentation about how to do this.

Other examples that use the Pico and involve data payloads (games etc) tend to involve soldering an SD card or similar to the board and using SPI. To me that raises the bar a bit too high for a new user experience with AtomVM, so I didn't care to go that route.

I was also very frustrated by the lack of wifi ;)

I can unearth my code if you'd like, but it's quite straight forward.. and not usable.

I'm very eager to get this working cuz I bought too many of these boards, so if you know a simple fix for this, let me know! :)

[bettio]

Porting AtomVM to Raspberry Pi pico should be feasible, however I don't have the hardware so I cannot help you. Any PR for it would be welcome.

The strong assumption in AtomVM is that all BEAM code is CPU addressable (memory mapped), so the .avm with all the modules should be flashed in some safe flash area.

ESP32 has partitions that are a handy feature, but on STM32 a different approach is used. I think that a well know address / flash offset would be good enough for most of the use cases.