Raspberry Pi Pico support

[marinasundstrom]

What does it takes to get .NET apps to run on a Raspberry Pi Pico microcontroller?

The chip has an Arm Cortex M0+ CPU and 2MB on-board flash memory.

Is there some effort in doing native compilation?

[PathogenDavid]

Ooh, those are seriously cool! Now for the bad news...

.NET Core sadly does not support ARMv6 (which if I'm not mistaken, is what those boards are gonna be using with those Cortex M0+ cores.) This is what blocks it from running on the Raspberry Pi Zero as well. (See #7764)

There was a work-in-progress PR to add support, but it ran into issues: #657

Mono does support ARMv6, although I'm not sure the extent or if it works with Mono AOT.

The final issue you're going to run into that those boards are meant to run code without the help of a conventional operating system. (At least that's the impression I got.) Overcoming that isn't an insurmountable task, but it's not exactly trivial. There are various projects out there for running .NET at that low of a level (Cosmos in particular comes to mind), but that's not the sort of thing that tends to be very portable.

Is there some effort in doing native compilation?

Yes, .NET Runtime Native AOT Lab. (Previously called CoreRT) However it uses the runtime JIT compiler as an AOT compiler, so it has the same lack of ARMv6 support.

There's also Mono AOT.

[ivanjf1978]

Hi guys,

I just want to know it is possible to make a wifi camera like ESP32 with the new Raspberry Pi pico and then can be work on MotionEyeOS?

About ESP32
https://randomnerdtutorials.com/esp32-cam-video-streaming-face-recognition-arduino-ide/

Thanks

Regards

Ivan

[PathogenDavid]

This probably isn't the right forum for this, although I'm also not 100% sure what you're asking.

If you're asking "Can the Raspberry Pi Pico be used to make something like ESP32-CAM?" The answer is no because the Raspberry Pi Pico does not have WiFi.

If you're asking "Can I combine the Raspberry Pi Pico with the ESP32-CAM and run MotionEyeOS on the Pico?" The answer today is no because .NET can't run on a Pico. Even if it could, I'm somewhat doubtful it is powerful enough to run MotionEyeOS. You should not think of the Raspberry Pi Pico as a tiny Raspberry Pi, think of it as a Pi-flavored Arduino.

[ivanjf1978]

Yes, I was trying to ask: Can the Raspberry Pi Pico be used to make something like ESP32-CAM?
It is possible to put a wifi adapter on Raspberry pi Pico and then connect it through wifi net?

I asked because I trying to add ESP32 camera on motioneyeOS but it is impossible. I think with the Raspberry Pi pico if it can be connect to wifi could be possible to add on motioneyeOS

What do you think?

Thanks for your comments

[danmoseley]

Cc @krwq

[PathogenDavid]

What do you think?

I don't see why using a Pico as the interface to the camera instead of an ESP32 would make it any easier for motionEyeOS to interface with it. The issue is whether or not the code on the server (whether it be a Pico or an ESP32) speaks the protocol needed by motionEyeOS, switching microcontrollers does not change that.

[marinasundstrom]

I’m thinking of a subset of the BCL API surface and supporting GPIO and devices through dotnet/iot.

I guess, it could be achieved with an optimized Mono runtime and native compiled app.

[PathogenDavid]

Yeah, you'd definitely want to start with a bare minimum BCL.

@MichalStrehovsky has some cool demos that use Native AOT to build .NET apps to run on Windows NT 3.51, DOS, and even as EFI modules. (Again though, RyuJIT doesn't even support the instruction set used by the Pico so you can't use the fundamental building blocks of his approach.)

[snikeguo]

Although coreclr supports thumb2 instruction , the code of coreclr is not friendly and cannot be tailored.

Ecma-335 has such a description:

IV.3.1 The Kernel Profile 
This Profile is the minimal possible conforming implementation of the CLI. It contains the types 
commonly found in a modern programming language class library, plus the types needed by 
compilers targeting the CLI. 
Contents: Base Class Library, Runtime Infrastructure Library

IV.4 Kernel Profile feature requirements 
All conforming implementations of the CLI support at least the Kernel Profile. Consequently, all 
CLI features required by the Kernel Profile shall be implemented by all conforming 
implementations. This clause defines that minimal feature set, by enumerating the set of features 
that are not required; i.e., a minimal conforming implementation shall implement all CLI features 
except those specified in the remainder of this clause. The feature requirements of individual 
Libraries as specified in §IV.5 are defined by reference to restricted items described in this 
clause. For ease of reference, each feature has a name indicated by the name of the clause or 
subclause heading. Where Libraries do not specify any additional feature requirement, it shall be 
assumed that only the features of the Kernel Profile as described in this clause are required.

Ironically, Microsoft didn't realize this function.

In fact, what we want is very simple: a very small CLR, which only includes:
JIT (required)
Thread (required),
Synchronization (required)
Debug (optional),
File / path operation (optional)
Network (optional)
AOT (optional)
As an IOT device, these functions are enough. Other specific functions can be completed through dllimport ( like this: mono_dl_register_library (const char *name, MonoDlMapping *mappings)

 * This is typically used like this:
 * MonoDlMapping sample_library_mappings [] = {
 *   { "CallMe", CallMe },
 *   { NULL, NULL }
 * };
 *
 * ...
 * main ()
 * {
 *    ...
 *    mono_dl_register_library ("sample", sample_library_mappings);
 *    ...
 * }
 *
 * Then the C# code can use this P/Invoke signature:
 *
 *     [DllImport ("sample")]
 *	extern static int CallMe (int f);

)

[snikeguo]

https://github.com/maekawatoshiki/yacht

[snikeguo]

An ECMA-335 implementation written in Rust

[jrmoserbaltimore]

You're not going to run .NET or .NET Core apps, but you could port .NET Micro to it and use C#.NET.

This eats about 60k of RAM and some 200k of program flash, which is significant, but the Pico isn't an Arduino Nano and has plenty of these resources by comparison.

[snikeguo]

the nanoframework has no jit and no native thread.

[jrmoserbaltimore]

Correct. NETMF comes with threads and a JIT, and can fit on the Pico easily; it would not work on the Nano, with its 2k of RAM and 30k of available flash.

[josesimoes]

FYI: .NET nanoFramework has a WIP to add a port for Pico. Running on top of Azure RTOS, btw.

[krwq]

@RobertSundstrom are you interested in any specific APIs? @Ellerbach has run .NET IoT on top of nano framework and it apparently works great for the most part, I'm not sure if Pico would work but might be worth checking with him if he has any pointers for you

[Ellerbach]

What does it takes to get .NET apps to run on a Raspberry Pi Pico microcontroller?

We are currently in an effort to add Raspberry Pico to support .NET nanoFramework. See: https://github.com/nanoframework/. .NET nanoFramework allows you to run .NET code written in C# on micro controllers. There is already a large support of MCU like ESP32, STM32, TI and NXP and some associated platforms, and it gets larger over time. .NET nanoFramework is community driven so the efforts goes as as fast as the community can go. If you have one of the supported MCU like a simple ESP32, give it a try!

There is a current work to add support for PiCo on the Azure RTOS branch: https://github.com/nanoframework/nf-interpreter/tree/develop-azurertos/targets/AzureRTOS

The main key elements are functional but nothing like GPIO, SPI or I2C is implemented yet. There is work to take. So if you are interested, you're welcome :-)

Now, on the .NET side, what you can run on a very little processor is of course limited. So the implementation of .NET in there is made small and efficient. Still, you can use Visual Studio 2019 to debug your code running on such devices with break points, getting the value data. And you use nugets as well and all the love you have in C# (9.0 supported) :-) Now, there is no generic (yet), no async or Linq.

[danmoseley]

@Ellerbach is it a goal that some or all of the device bindings maintained in this repo could be used on nanoFramework, once it supports GPIO etc? If so, and that's a goal we want to support, I wonder whether there's a surface area (ie a subset of .NET Standard) that we could compile against to ensure we don't use Linq? Generics would be a substantial limitation though -- do they have eg a modified compiler that flags them?

I'm sure this has been discussed I'm just curious.

[josesimoes]

Hey @danmoseley! 😃

1. GPIO is fully supported for a long time now.
2. More than 50% of the binding have already been ported. See here.
3. Linq is not available, but it's planned. Reduced version of course.
4. Generics: almost done, "just" lacking the support from the VS debugger. Work is planned but still on the queue.

[danmoseley]

@josesimoes thanks for the info! That's great. I see the doc there about porting. Do you anticipate creating a surface area that we would build against here to make porting easier, or is the focus on extending nanoFramework and spotting porting blockers in PR's?

[josesimoes]

@danmoseley the plan is to complete the bindings that are not yet ported (you can find the pending ones at that repo under src/devices_generated). Some won't be ported because of the complexity or because it doesn't make much sense to have them in nanoFramework due to platform specifics). The guides are there as you've found out.
Following this, the goal it port over here any changes that are made on the nano versions and vice-versa.

You can build locally as you are working on the port. Just need to install the .NET nanoFramework VS extension.

PR against the upstream repo will fire the Azure Pipeline and all required checks and tests are performed.

There will be porting blockers yes, but most of them can be tackled by just coding workarounds using the available API.
You're more than welcome helping with this effort. Ask any questions you have on our [Discord server](https://discord.gg/gCyBu8T].

[danmoseley]

Thanks @josesimoes . I don't have time to contribute, but I will watch with interest. (I'm in the same team as some of the maintainers here)

[marinasundstrom]

Thank you all for the answers!

I was talking about having an API surface that is compatible with dotnet/iot.

But since I have read that there is an effort to bring nanoFramework closer to .NET “proper” in terms of functionality and APIs, I will wait an see with excitement.

Being able to target the Pico without code changes would be cool.

[josesimoes]

I was talking about having an API surface that is compatible with dotnet/iot.

But since I have read that there is an effort to bring nanoFramework closer to .NET “proper” in terms of functionality and APIs, I will wait an see with excitement.

Except with some specific APIs, we've always been fully aligned with .NET. 😉
You can check the API documentation here and browse or samples repo here.