Thanks! We're in the middle of a big website refresh with more information.
Also, you can find the new developer site here: http://beta-developer.wildernesslabs.co/, which has the Meadow docs. We haven't pushed it to the main site yet because we're still missing a home page design. :)
Xamarin and Microsoft alum Bryan Costanich got some friends together to rescue Netduino and “reboot” it.
They wanted to maintain that same sense of delight for .NET devs, but also modernize the aging hardware platform and replace the restricted .NET Micro Framework with full .NET Standard support on the software side.
Several friends from the old Xamarin docs team worked their magic on the Wilderness docs site—which is why it’s so good.
.NET is a nice runtime... But I wonder if NodeJS might get more uptake since there is a larger community of javascript/typescript developers out there.
I know hardcore embedded people will hate this idea, but sometimes you have to take the massive performance and memory hit to tempt developers in who prefer to get stuff done with powerful libraries than learn a new language and start worrying about memory management...
True, but one mans 'realtime' is very different than another.
Most microcontrollers today don't even have cycle-accurate memory access guarantees, so it's impossible to do timing more accurate than tens of nanoseconds.
Things requiring low latency and accurate timing always end up hardware assisted (USB controllers, PWM hardware, UART serializers, and a million more examples).
That is why Java variants for embedded soft real time deployments have completely different kind of GC implementations like something as OpenJDK or IBM J9, and expose regions and access to unamaged memory.
Likewise .NET's support for value types and low level programming also means not everything needs to be GC-allocated.
That's all true. But at some point if you really need to avoid GC, you end up writing in a subset of C# that is so limited, it's really just C.
Most people don't have those kinds of performance considerations. I use C# for soft realtime all the time, but in the instances when I have done actual realtime embedded work, I just used C.
Any architecture with a CPU cache is generally not cycle accurate (since at the time you compile your code you can't fully predict if your data will be in the cache or not).
Many pipelined architectures do not define in datasheets exactly what can cause a pipeline stall - usually they provide rough guidance, but not information about corner cases. Branch prediction likewise is rarely fully defined in the datasheets.
Some architectures have some operations which are data dependant - for example, "division takes 6-8 cycles". The software developer can't be sure it will be 6, 7, or 8, and if they were to measure performance, they'd be relying on undefined performance behaviour, since a new revision of the same model of chip could change performance.
Also, most architectures with DMA aren't cycle accurate because the SRAM is single-ported, so you get a CPU stall if you happen to read memory in the same cycle as a hardware device needs more data.
Even when writing C or C++ for an MCU, you're going to avoid heap allocation as much as possible, so the same design is going to lead to a .NET app that has no GC collections as well.
I write VR apps in C# for a living. Avoiding the GC is not that hard.
I write games in C#, but I've worked in embedded systems.
The thing is most methods for avoiding GC are just round about ways of doing manual memory management. And games are soft realtime, so a dropped frame every now and then is generally acceptable.
Also look at the new Unity DOTS stuff. They are building their own high performance subset of C# where memory layout and data locality are first class concerns and adding in mechanisms for manual memory management.
In VR, dropped frames are quite noticeable. Even with Asynchronous Time Warp, while you won't get hitches in your view of the scene, you get hitches in anything that is animated. So, for example, waiving your controller around, it'll start to skip around. And you're always waiving the controller around. Nobody is a stone-still statue.
It's not really "round about ways of doing manual memory management". You can heap-allocate as much as you want, as long as you aren't doing it in a critical hot path. Object pooling is good practice, regardless of language and runtime, for real time anything. I do my major allocations and deallocactions during scene transitions, where the view is faded out already because making visible scene transitions in VR is nausea-inducing on its own.
And from a project management perspective, I've found it best to avoid using as much of Unity's built-in stuff as possible. Most of what they create are just garbage reimplementations of stuff that already exists in the .NET ecosystem.
I'm long-term going to get off of Unity. I'll eventually be building my own system on top of Xamarin, as I excise more and more of Unity out of my projects. I've already had to code my way around so many of their systems just to make quality apps that don't hiccup when things load that I don't really have a lot left to do.
All of the VR vendors provide C APIs for interfacing with their systems, which are the actual, first-class systems. Providing a P/Invoke layer on top of that won't be too hard. And Xamarin already provides wrappers around ARKit and ARCore.
Shader-wise, there's not enough processing budget to do anything but very basic shaders that I already know how to write, anyway. Any of the more advanced shaders that work well in VR are open-source.
Light baking can be done in Blender directly.
Unity's Audio pipeline is really bad. I have 50% of a reimplementation already. And again, spatialization is provided by the VR vendors, so there is very little of Unity's own code running in my audio systems anymore.
Sure, I wouldn't have learned how to do all of this stuff if I hadn't started with Unity, but once you get into trying to build scalable apps with pleasant user experiences, you have to ditch so much of Unity's built in stuff that it starts to look less and less like a good value proposition to continue to put up with the rest of their stuff, considering how buggy it can be.
If you really are doing hard realtime--absolutely no dropped frames, hard limit of 11ms per frame every time. Then you basically have to program in a way that completely avoids GC. Or use an incremental GC that you run when you have time.
So many things in C# use heap memory that you are programming in C# but without most of the advantages. Why use it over C++ or C?
Also if you take a look at DOTS, there's quite a lot that would be very hard to replicate yourself if you are using Unity.
And yes object pooling is a good best practice. But it negates a lot of the advantages of having a GC in the first place, and it's a lot easier for someone to accidentally allocate memory in C# without realizing it. Unity has a lot that I take advantage of, so I deal with avoiding GC. However if I was using my own engine, I wouldn't use C#. Despite the fact that I love C#.
Whoa. The only project I know of that allowed that is GRiSP. Is that what y'all are using? Or is this some even-more-exotic bare-metal Erlang implementation?
I'll have to check out RTEMS. Knew about Ling / Erlang-on-Xen, but figure that's a bit different from proper bare-metal deployment (though I guess so RTEMS would be), given that it expects Xen running underneath.
Plenty of people, myself included, write games in C#. But it's soft realtime so occasional frame drops aren't a huge deal. And we are constantly doing our own manual memory management with things like object pooling to avoid the GC whenever possible.
Exactly! The Rust people run around telling everyone that GC is evil, but I am quite productive in F# and Erlang with a GC language, and it's a breeze to program on these platforms.
There are many games in C# that even run on iPhones and are very performant.
I'm going to argue that, while the .NET environment may be unfamiliar, it's as good (if not better!) than the NodeJS environment for "getting stuff done." You may have fewer libraries (depending on what you're looking for), but with .NET Standard 2, you need fewer of them. The standard library has support for everything from Memory Mapped Files [0], to Parallel loops [1], every collection type under the sun [2], globalisation [3], and HTTP applications [4].
Memory management is just as automatic as well (they seem to just be using the mono runtime).
And bringing it back to small embedded systems, there are some really nice plugins for VS that let you stay in that familiar environment. I am so much more productive with Visual Studio and the VisualMicro and Visual GDB plugins than I would be in the respective "native" IDEs.
There already is JavaScript on microcontrollers - espruino.com
There is also MicroPython and CircuitPython.
Embedded people are very happy about any new languages coming to our hardware. Especially when it brings in new people, i.e. CircuitPython is a great tool for beginners.
But there is also severe limitations with these interpreted/bytecode-vm languages. MicroPython i.e. takes a 100x performance hit. And you need beefy big controllers.
There however a lot of situations where they are usable, and in in those cases, it's really great and fun to work with.
Depends on where you are- Node folks are not that common where I live. I mean I've done some nodeJS(amongst other things), and most other devs I work with have, but first and foremost its C# and .NET. .NET Core seems to be the way most of us in my locale are going(Houston, Texas area) Im sure though that everyone on HN could tell a different story though. I guess the point Im making is that NODE is more popular. If this is to be believed its about the same take rate...
It looks pretty nice and the .Net part seems to be pretty good. However the Omega 2+ runs Linux, has twice the Mhz and 4x RAM for much less money... https://onion.io/store/omega2p/ . Perhaps that is why it seems to be sold out at the moment.
This is probably running ucLinux to run Mono. I think the bigger issue with the Onion is you can't change the firmware (or at least I got the impression the last time I looked).
The Dotnet Micro Framework appears to be no longer developed by microsoft, with the official repository being archived [1]. However the Nanoframework[2] fork appears to be alive. Does anyone know which one this project is using? It's unclear from both the OP and the Kickstarter link as well.
"From the very inception, we had a vision to fix a lot of the issues with hardware, starting by getting Mono (the open-source runtime that powers Xamarin) running on a microcontroller in order to bring a modern runtime to the class of computing that powers real IoT."
We're running full .NET via Mono. NanoFramework is just a re-write of the .NET MicroFramework. That's basically .NET 1.1 from from almost 20 years ago. No generics or beyond.
Meadow is very different. Full .NET means Generics, LINQ, etc., and all the nugets. :)
I keep hearing from the Dev-Shops, that ".Net Core" will be replacing "Full .Net" w.r.t. long-term support from Microsoft, and that .Net Projects should be checked for availability of a migration path to .Net Core.
Is this a (future) concern for the F7M, and projects running on it?
Since it's IOT, these things can be expected to be found installed for much longer than 5 years, so continuing long-term (security) support seems important.
Mono, with .NET 4.7.2 actually gives you the .NET Standard 2.0 API surface area + other stuff. Eventually, the Mono and Core Runtimes will be merged and we'll switch over to that. It's all clear as mud; but the point is; we'll continue to be up to date.
This is great. I have a rather large .NET Standard 2.0 library that I've built for VR projects that would be a big boon in IoT devices. It has a large set of unit-of-measure conversions and formatters, some Geospatial features for doing math on LatLngs, audio format decoding, image format decoding, various compression algorithm interfaces, type-safe HTTP requests, and a number of statistical filtering systems such as Kalman filtering of kinematic vectors. It'll be great to be able to reuse all of that code.
And if System.IO.Ports can some day get added to .NET Standard, I've got serial port communication in there too.
The active .NET open source community has been very proactive about upgrading to .NET Standard 2.0. There are a lot of things Microsoft "got right" with 2.0 that are making conversion from .NET Framework a lot easier. For example, my own code (which numbers in the 50kloc range) only took a lite weekend to convert, and most of that was just learning about the new project file format (which is drastically simplified for the better, BTW).
Just wish Microsoft had made their Bluetooth stack a part of .NET Standard instead of jamming it into UWP.
EDIT: I'm having a hard time finding an official spec sheet. Has anyone seen it?
I thought I'd look at audio. Netduino.Foundation.Audio seems to have support for playing a tone on a piezo speaker. Compared to Teensy audio, Axoloti, or Bela, this seems pretty unsophisticated? But maybe I missed something?
58 comments
[ 4.3 ms ] story [ 145 ms ] threadAlso, you can find the new developer site here: http://beta-developer.wildernesslabs.co/, which has the Meadow docs. We haven't pushed it to the main site yet because we're still missing a home page design. :)
They wanted to maintain that same sense of delight for .NET devs, but also modernize the aging hardware platform and replace the restricted .NET Micro Framework with full .NET Standard support on the software side.
Several friends from the old Xamarin docs team worked their magic on the Wilderness docs site—which is why it’s so good.
I know hardcore embedded people will hate this idea, but sometimes you have to take the massive performance and memory hit to tempt developers in who prefer to get stuff done with powerful libraries than learn a new language and start worrying about memory management...
That being said, there are plenty hobby (and commercial) projects where .NET is perfect.
Most microcontrollers today don't even have cycle-accurate memory access guarantees, so it's impossible to do timing more accurate than tens of nanoseconds.
Things requiring low latency and accurate timing always end up hardware assisted (USB controllers, PWM hardware, UART serializers, and a million more examples).
Likewise .NET's support for value types and low level programming also means not everything needs to be GC-allocated.
Most people don't have those kinds of performance considerations. I use C# for soft realtime all the time, but in the instances when I have done actual realtime embedded work, I just used C.
Many pipelined architectures do not define in datasheets exactly what can cause a pipeline stall - usually they provide rough guidance, but not information about corner cases. Branch prediction likewise is rarely fully defined in the datasheets.
Some architectures have some operations which are data dependant - for example, "division takes 6-8 cycles". The software developer can't be sure it will be 6, 7, or 8, and if they were to measure performance, they'd be relying on undefined performance behaviour, since a new revision of the same model of chip could change performance.
Also, most architectures with DMA aren't cycle accurate because the SRAM is single-ported, so you get a CPU stall if you happen to read memory in the same cycle as a hardware device needs more data.
I write VR apps in C# for a living. Avoiding the GC is not that hard.
The thing is most methods for avoiding GC are just round about ways of doing manual memory management. And games are soft realtime, so a dropped frame every now and then is generally acceptable.
Also look at the new Unity DOTS stuff. They are building their own high performance subset of C# where memory layout and data locality are first class concerns and adding in mechanisms for manual memory management.
It's not really "round about ways of doing manual memory management". You can heap-allocate as much as you want, as long as you aren't doing it in a critical hot path. Object pooling is good practice, regardless of language and runtime, for real time anything. I do my major allocations and deallocactions during scene transitions, where the view is faded out already because making visible scene transitions in VR is nausea-inducing on its own.
And from a project management perspective, I've found it best to avoid using as much of Unity's built-in stuff as possible. Most of what they create are just garbage reimplementations of stuff that already exists in the .NET ecosystem.
I'm long-term going to get off of Unity. I'll eventually be building my own system on top of Xamarin, as I excise more and more of Unity out of my projects. I've already had to code my way around so many of their systems just to make quality apps that don't hiccup when things load that I don't really have a lot left to do.
All of the VR vendors provide C APIs for interfacing with their systems, which are the actual, first-class systems. Providing a P/Invoke layer on top of that won't be too hard. And Xamarin already provides wrappers around ARKit and ARCore.
Shader-wise, there's not enough processing budget to do anything but very basic shaders that I already know how to write, anyway. Any of the more advanced shaders that work well in VR are open-source.
Light baking can be done in Blender directly.
Unity's Audio pipeline is really bad. I have 50% of a reimplementation already. And again, spatialization is provided by the VR vendors, so there is very little of Unity's own code running in my audio systems anymore.
Sure, I wouldn't have learned how to do all of this stuff if I hadn't started with Unity, but once you get into trying to build scalable apps with pleasant user experiences, you have to ditch so much of Unity's built in stuff that it starts to look less and less like a good value proposition to continue to put up with the rest of their stuff, considering how buggy it can be.
So many things in C# use heap memory that you are programming in C# but without most of the advantages. Why use it over C++ or C?
Also if you take a look at DOTS, there's quite a lot that would be very hard to replicate yourself if you are using Unity.
And yes object pooling is a good best practice. But it negates a lot of the advantages of having a GC in the first place, and it's a lot easier for someone to accidentally allocate memory in C# without realizing it. Unity has a lot that I take advantage of, so I deal with avoiding GC. However if I was using my own engine, I wouldn't use C#. Despite the fact that I love C#.
There's also LING for Erlang on Xen which isn't supported much but some still use it.
There are many games in C# that even run on iPhones and are very performant.
Memory management is just as automatic as well (they seem to just be using the mono runtime).
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.io.memory...
[1]: https://docs.microsoft.com/en-us/dotnet/api/system.threading...
[2]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...
[3]: https://docs.microsoft.com/en-us/dotnet/api/system.globaliza...
[4]: https://docs.microsoft.com/en-us/dotnet/api/system.net.http?...
Except heaps / priority queues, which always irked me because it's in the Java standard library :-(
There is also MicroPython and CircuitPython.
Embedded people are very happy about any new languages coming to our hardware. Especially when it brings in new people, i.e. CircuitPython is a great tool for beginners.
But there is also severe limitations with these interpreted/bytecode-vm languages. MicroPython i.e. takes a 100x performance hit. And you need beefy big controllers.
There however a lot of situations where they are usable, and in in those cases, it's really great and fun to work with.
http://pypl.github.io/PYPL.html
https://developer.wildernesslabs.co/Hardware/Tutorials/Elect...
Which is where you can find the Meadow docs!
[1] https://github.com/NETMF/netmf-interpreter [2] https://nanoframework.net/
https://community.wildernesslabs.co/t/lay-of-the-land/362/2?...
"From the very inception, we had a vision to fix a lot of the issues with hardware, starting by getting Mono (the open-source runtime that powers Xamarin) running on a microcontroller in order to bring a modern runtime to the class of computing that powers real IoT."
Which would seem to indicate it runs Mono.
Meadow is very different. Full .NET means Generics, LINQ, etc., and all the nugets. :)
Is this a (future) concern for the F7M, and projects running on it?
Since it's IOT, these things can be expected to be found installed for much longer than 5 years, so continuing long-term (security) support seems important.
https://developer.wildernesslabs.co/Netduino/Application_Fun...
- the board is based on the STM32F7 chip
- https://elinux.org/STM32#STM32F7_based
https://www.microsoft.com/en-us/research/project/singularity... (no more active development from Microsoft, but the source is Shared Source available)
https://www.gocosmos.org/ (still actively developed)
https://github.com/mosa/MOSA-Project (still actively developed)
https://github.com/sharpos/SharpOS (seems defunct)
And if System.IO.Ports can some day get added to .NET Standard, I've got serial port communication in there too.
The active .NET open source community has been very proactive about upgrading to .NET Standard 2.0. There are a lot of things Microsoft "got right" with 2.0 that are making conversion from .NET Framework a lot easier. For example, my own code (which numbers in the 50kloc range) only took a lite weekend to convert, and most of that was just learning about the new project file format (which is drastically simplified for the better, BTW).
Just wish Microsoft had made their Bluetooth stack a part of .NET Standard instead of jamming it into UWP.
EDIT: I'm having a hard time finding an official spec sheet. Has anyone seen it?