-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Raspberry Pi Pico support #47270
-
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?
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 5 -
👀 1
.NET nanoFramework now has support for Pico.
They announced it on LinkedIn: https://www.linkedin.com/posts/dotnet-nanoframework_github-nanoframeworknanofirmwareflasher-activity-7465036048427974656-Pw-i
Replies: 10 comments 15 replies
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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
Beta Was this translation helpful? Give feedback.
All reactions
-
Cc @krwq
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
❤️ 1
-
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.)
Beta Was this translation helpful? Give feedback.
All reactions
-
❤️ 2
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
FYI: .NET nanoFramework has a WIP to add a port for Pico. Running on top of Azure RTOS, btw.
Beta Was this translation helpful? Give feedback.
All reactions
-
@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
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 2
-
@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.
Beta Was this translation helpful? Give feedback.
All reactions
-
Hey @danmoseley! 😃
- GPIO is fully supported for a long time now.
- More than 50% of the binding have already been ported. See here.
- Linq is not available, but it's planned. Reduced version of course.
- Generics: almost done, "just" lacking the support from the VS debugger. Work is planned but still on the queue.
Beta Was this translation helpful? Give feedback.
All reactions
-
@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?
Beta Was this translation helpful? Give feedback.
All reactions
-
@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].
Beta Was this translation helpful? Give feedback.
All reactions
-
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)
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 5
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 2
-
Any updates with this? I would really love C# support on the PICO. A lot has changed since this post was written.
https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md
Beta Was this translation helpful? Give feedback.
All reactions
-
see:#119856
Beta Was this translation helpful? Give feedback.
All reactions
-
Beta Was this translation helpful? Give feedback.
All reactions
-
🎉 1
-
I had no issues running on a Pico 2
Beta Was this translation helpful? Give feedback.
All reactions
-
❤️ 1
-
.NET nanoFramework now has support for Pico.
They announced it on LinkedIn: https://www.linkedin.com/posts/dotnet-nanoframework_github-nanoframeworknanofirmwareflasher-activity-7465036048427974656-Pw-i
Beta Was this translation helpful? Give feedback.
All reactions
-
🎉 3 -
🚀 4