.NET Microframework
-
Give me some hints - what do you use?
Regards, Rob Philpott.
Z80's (in the Z180 variant, and yes I know it's old, so is the hardware designer... :laugh:) and occasional ARM based jobs. But the embedded work is very thin on the ground these days, except for maintenance work...no one is designing new products. :sigh:
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
Has anyone used this and if so had any joy with it? It seems like a somewhat half-arsed amateur attempt to me. Maybe because it is open-source MS don't see any profitability in it. I bought a Netduino Plus 2 (32bit ARM Cortex) which is a little prototyping board which hardware wise is a complete beast in comparison to its competitor - the Arduino which is a weedy 8 bit thing. 168Mhz vs. 16Mhz with a lot more flash and RAM memory. Unfortunately though, this thing is super slow, principally because it interprets the CIL rather than Jitting it. There is a jitter in the framework source but apparently it doesn't compile and they never bothered to fix it. Also, jitting isn't ideal on flash memory as you can't replace the CIL with native instructions. This would require RAM. Add in the fact the the framework will likely consume most of your flash memory, interrupt latency of up to 20ms discounting any realtime operation (who'd want that in an embedded device) and appalling documentation on MSDN and you end up with one big turkey. To get the I2C bus working on it, you have to twiddle some private members using reflection every time you want to read/write data. So, I've given up and bought an Arduino for £10 which is likely to be quicker and £40 less expensive, and hopefully won't give me a four day headache like its counterpart. *moan over*
Regards, Rob Philpott.
I looked at the uFramework some time ago and it looked very amateurish then, I guess your right they don't see the profit so they don't pursue it. Personally I think they're making a big mistake. They'll wait for someone else to develop the technology then buy it to catch up.
Along with Antimatter and Dark Matter they've discovered the existence of Doesn't Matter which appears to have no effect on the universe whatsoever! Rich Tennant 5th Wave
-
Z80's (in the Z180 variant, and yes I know it's old, so is the hardware designer... :laugh:) and occasional ARM based jobs. But the embedded work is very thin on the ground these days, except for maintenance work...no one is designing new products. :sigh:
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
Ah the nostalgia. I was on the 6502 side of the fence. I'm almost tempted to write an ARM assembler myself (in .NET obviously) but then you need a C/C++ compiler as well really and that's a bit more of a challenge. And a linker I guess.
Regards, Rob Philpott.
-
I looked at the uFramework some time ago and it looked very amateurish then, I guess your right they don't see the profit so they don't pursue it. Personally I think they're making a big mistake. They'll wait for someone else to develop the technology then buy it to catch up.
Along with Antimatter and Dark Matter they've discovered the existence of Doesn't Matter which appears to have no effect on the universe whatsoever! Rich Tennant 5th Wave
I think the big mistake might be to try and run a managed environment on an embedded device in the first place. Managed heap, garbage collection, threadpools etc. - does this really belong on tiny devices? One way might be to use some sort of NGEN, effectively statically linking only the bits required.
Regards, Rob Philpott.
-
I don't know what NetBeans is but I don't like the sound of it. Suppose I should find out for knowledge sake..
Regards, Rob Philpott.
-
Has anyone used this and if so had any joy with it? It seems like a somewhat half-arsed amateur attempt to me. Maybe because it is open-source MS don't see any profitability in it. I bought a Netduino Plus 2 (32bit ARM Cortex) which is a little prototyping board which hardware wise is a complete beast in comparison to its competitor - the Arduino which is a weedy 8 bit thing. 168Mhz vs. 16Mhz with a lot more flash and RAM memory. Unfortunately though, this thing is super slow, principally because it interprets the CIL rather than Jitting it. There is a jitter in the framework source but apparently it doesn't compile and they never bothered to fix it. Also, jitting isn't ideal on flash memory as you can't replace the CIL with native instructions. This would require RAM. Add in the fact the the framework will likely consume most of your flash memory, interrupt latency of up to 20ms discounting any realtime operation (who'd want that in an embedded device) and appalling documentation on MSDN and you end up with one big turkey. To get the I2C bus working on it, you have to twiddle some private members using reflection every time you want to read/write data. So, I've given up and bought an Arduino for £10 which is likely to be quicker and £40 less expensive, and hopefully won't give me a four day headache like its counterpart. *moan over*
Regards, Rob Philpott.
A VM is fundamentally the wrong approach for an embedded device, even if it did have a JIT compiler that worked (running the JIT compiler on the board would also take a lot of resources). You can't blame MS for trying to take advantage of the popularity of .Net to get into that market, and try to provide something for softcore programmers who want to play with embedded systems, but really it's as dumb as a Java embedded device.
-
I think the big mistake might be to try and run a managed environment on an embedded device in the first place. Managed heap, garbage collection, threadpools etc. - does this really belong on tiny devices? One way might be to use some sort of NGEN, effectively statically linking only the bits required.
Regards, Rob Philpott.
Embedded devices seem to be heading in at least 2 directions; small 8 bit devices and the System on a chip devices that have tons of memory and run some form of OS. I believe the SoC devices will become more popular as our appliances and homes become smarter.
Along with Antimatter and Dark Matter they've discovered the existence of Doesn't Matter which appears to have no effect on the universe whatsoever! Rich Tennant 5th Wave
-
A VM is fundamentally the wrong approach for an embedded device, even if it did have a JIT compiler that worked (running the JIT compiler on the board would also take a lot of resources). You can't blame MS for trying to take advantage of the popularity of .Net to get into that market, and try to provide something for softcore programmers who want to play with embedded systems, but really it's as dumb as a Java embedded device.
I agree - I think you've hit the nail on the head there. This may sound odd, but the reason I try to avoid C++ is header files. It drives me mad having to put stuff in two places for every method you create. But that said, it'd be nice to look at a hex display of some memory at a memory address again rather than a kindergarten .NET byte array!
Regards, Rob Philpott.
-
I agree - I think you've hit the nail on the head there. This may sound odd, but the reason I try to avoid C++ is header files. It drives me mad having to put stuff in two places for every method you create. But that said, it'd be nice to look at a hex display of some memory at a memory address again rather than a kindergarten .NET byte array!
Regards, Rob Philpott.
The declaration/definition divide seems to be a common feature of that generation of languages. In C++ it's header/body, in C it's the same, in Delphi/Pascal it's declaration of classes/functions/procedures at the top and the content below (essentially a header and body in the same file). I suppose it's to make the compiler's life easier, but it does seem silly to define the same thing in two places when the information must be available from the content to auto-generate most of the header.
-
A VM is fundamentally the wrong approach for an embedded device, even if it did have a JIT compiler that worked (running the JIT compiler on the board would also take a lot of resources). You can't blame MS for trying to take advantage of the popularity of .Net to get into that market, and try to provide something for softcore programmers who want to play with embedded systems, but really it's as dumb as a Java embedded device.
-
The Raspberry Pi has an application CPU, not one designed for actual embedded work. "Embedded" depends on who you ask. Embedded to someone means Windows running in an ATM, embedded to someone else might mean 8 bit assembly on a 4MHz CPU.
.-. |o,o| ,| \_\\=/\_ .-""-. ||/\_/\_\\\_\\ /\[\] \_ \_\\ |\_/|(\_)|\\\\ \_|\_o\_LII|\_ \\.\_./// / | ==== | \\ |\\\_/|"\` |\_| ==== |\_| |\_|\_| ||" || || |-|-| ||LI o || |\_|\_| ||'----'|| /\_/ \\\_\\ /\_\_| |\_\_\\ -
Has anyone used this and if so had any joy with it? It seems like a somewhat half-arsed amateur attempt to me. Maybe because it is open-source MS don't see any profitability in it. I bought a Netduino Plus 2 (32bit ARM Cortex) which is a little prototyping board which hardware wise is a complete beast in comparison to its competitor - the Arduino which is a weedy 8 bit thing. 168Mhz vs. 16Mhz with a lot more flash and RAM memory. Unfortunately though, this thing is super slow, principally because it interprets the CIL rather than Jitting it. There is a jitter in the framework source but apparently it doesn't compile and they never bothered to fix it. Also, jitting isn't ideal on flash memory as you can't replace the CIL with native instructions. This would require RAM. Add in the fact the the framework will likely consume most of your flash memory, interrupt latency of up to 20ms discounting any realtime operation (who'd want that in an embedded device) and appalling documentation on MSDN and you end up with one big turkey. To get the I2C bus working on it, you have to twiddle some private members using reflection every time you want to read/write data. So, I've given up and bought an Arduino for £10 which is likely to be quicker and £40 less expensive, and hopefully won't give me a four day headache like its counterpart. *moan over*
Regards, Rob Philpott.
The need "to twiddle some private members using reflection" implies that the framework is a bit overweight. :-\
Wrong is evil and must be defeated. - Jeff Ello[^]
-
Has anyone used this and if so had any joy with it? It seems like a somewhat half-arsed amateur attempt to me. Maybe because it is open-source MS don't see any profitability in it. I bought a Netduino Plus 2 (32bit ARM Cortex) which is a little prototyping board which hardware wise is a complete beast in comparison to its competitor - the Arduino which is a weedy 8 bit thing. 168Mhz vs. 16Mhz with a lot more flash and RAM memory. Unfortunately though, this thing is super slow, principally because it interprets the CIL rather than Jitting it. There is a jitter in the framework source but apparently it doesn't compile and they never bothered to fix it. Also, jitting isn't ideal on flash memory as you can't replace the CIL with native instructions. This would require RAM. Add in the fact the the framework will likely consume most of your flash memory, interrupt latency of up to 20ms discounting any realtime operation (who'd want that in an embedded device) and appalling documentation on MSDN and you end up with one big turkey. To get the I2C bus working on it, you have to twiddle some private members using reflection every time you want to read/write data. So, I've given up and bought an Arduino for £10 which is likely to be quicker and £40 less expensive, and hopefully won't give me a four day headache like its counterpart. *moan over*
Regards, Rob Philpott.
I programmed a bit on a Netduino as well but came across the same problem. Too slow. I just did away with the .net microframework and ran native on bare metal. It ran sooooo much faster running on bare metal and was still quite usable.
-
Has anyone used this and if so had any joy with it? It seems like a somewhat half-arsed amateur attempt to me. Maybe because it is open-source MS don't see any profitability in it. I bought a Netduino Plus 2 (32bit ARM Cortex) which is a little prototyping board which hardware wise is a complete beast in comparison to its competitor - the Arduino which is a weedy 8 bit thing. 168Mhz vs. 16Mhz with a lot more flash and RAM memory. Unfortunately though, this thing is super slow, principally because it interprets the CIL rather than Jitting it. There is a jitter in the framework source but apparently it doesn't compile and they never bothered to fix it. Also, jitting isn't ideal on flash memory as you can't replace the CIL with native instructions. This would require RAM. Add in the fact the the framework will likely consume most of your flash memory, interrupt latency of up to 20ms discounting any realtime operation (who'd want that in an embedded device) and appalling documentation on MSDN and you end up with one big turkey. To get the I2C bus working on it, you have to twiddle some private members using reflection every time you want to read/write data. So, I've given up and bought an Arduino for £10 which is likely to be quicker and £40 less expensive, and hopefully won't give me a four day headache like its counterpart. *moan over*
Regards, Rob Philpott.
The .NET MF is here for like 8 years, came from commercial product and was close-sourced for couple of years, so I wouldn't exactly say half-arsed amateur attempt. Jitter was considered and tested in the past, that's why it is in the source. However as you noted yourself, it turned out not to be ideal (and resulted in overall worse performance), so it wasn't kept up to date with new memory model and other changes on the way. The framework was designed from the very beginning not to be realtime and any expectations in this regard must ultimately fail, indeed. There are lots of embedded applications that do not need realtime operation. The MSDN documentation is absolutely outdated though, I am with you on this. As for your I2C experience, the only private members of I2C stuff is the I2CDevice.Initialize method which is called by constructor and m_xAction with [FieldNoReflection] attribute so I am not really sure what do you mean by this as there is quite nothing you gain using reflection. Arduino is cheaper and quicker at running, for sure. But it does not have the framework - web services, user interface, SSL, reflection, XML, Unicode and more. That stuff costs space and speed.
-
I programmed a bit on a Netduino as well but came across the same problem. Too slow. I just did away with the .net microframework and ran native on bare metal. It ran sooooo much faster running on bare metal and was still quite usable.
Nice! May I ask how you did that? i.e. what tools/platform you used. I'm toying with this idea as well. My concern is how to get the code on it. Wiping the flash with the 3.3v lead each time you want to deploy doesn't sound great so I guess some sort of bootloader on device might be a good idea.
Regards, Rob Philpott.
-
The .NET MF is here for like 8 years, came from commercial product and was close-sourced for couple of years, so I wouldn't exactly say half-arsed amateur attempt. Jitter was considered and tested in the past, that's why it is in the source. However as you noted yourself, it turned out not to be ideal (and resulted in overall worse performance), so it wasn't kept up to date with new memory model and other changes on the way. The framework was designed from the very beginning not to be realtime and any expectations in this regard must ultimately fail, indeed. There are lots of embedded applications that do not need realtime operation. The MSDN documentation is absolutely outdated though, I am with you on this. As for your I2C experience, the only private members of I2C stuff is the I2CDevice.Initialize method which is called by constructor and m_xAction with [FieldNoReflection] attribute so I am not really sure what do you mean by this as there is quite nothing you gain using reflection. Arduino is cheaper and quicker at running, for sure. But it does not have the framework - web services, user interface, SSL, reflection, XML, Unicode and more. That stuff costs space and speed.
I absolutely love the .NET Framework, it's a thing of beauty. I am also a fan of ARM microprocessors and started using them pretty much the moment they arrived in the 80s. It should be a marriage made in heaven. But here's the thing. I read somewhere that a simple Int32.ToString() wasn't fast in netmf, so I tested it. A for loop 0 to 999, in the loop a line to convert the iterator to a string. LED on, then the same thing again, LED off. When running this, the LED blinks at a rate of about twice a second, implying that the code can execute about 4000 iterations a second. 4000 Int32.ToString()s a second on a 168MHz processor. That IMO can only be described as catastrophic performance. As far as the I2C bus goes, I just couldn't get it to work no matter what I tried. See here: http://forums.netduino.com/index.php?/topic/944-i2c-internaladdress-repeated-start-bit-support/[^] When I tried this reflection it couldn't find the private members, and I've checked the source and they don't seem to be there in any version, so I am currently at a complete loss. I might be being thick but I've just lost patience with the thing. Even if I can get it to work it's not going to be quick enough.
Regards, Rob Philpott.
-
Has anyone used this and if so had any joy with it? It seems like a somewhat half-arsed amateur attempt to me. Maybe because it is open-source MS don't see any profitability in it. I bought a Netduino Plus 2 (32bit ARM Cortex) which is a little prototyping board which hardware wise is a complete beast in comparison to its competitor - the Arduino which is a weedy 8 bit thing. 168Mhz vs. 16Mhz with a lot more flash and RAM memory. Unfortunately though, this thing is super slow, principally because it interprets the CIL rather than Jitting it. There is a jitter in the framework source but apparently it doesn't compile and they never bothered to fix it. Also, jitting isn't ideal on flash memory as you can't replace the CIL with native instructions. This would require RAM. Add in the fact the the framework will likely consume most of your flash memory, interrupt latency of up to 20ms discounting any realtime operation (who'd want that in an embedded device) and appalling documentation on MSDN and you end up with one big turkey. To get the I2C bus working on it, you have to twiddle some private members using reflection every time you want to read/write data. So, I've given up and bought an Arduino for £10 which is likely to be quicker and £40 less expensive, and hopefully won't give me a four day headache like its counterpart. *moan over*
Regards, Rob Philpott.
I did use the net duino plus (v1) with the .net micro framework, it made it very easy to program it. It was a simple project with a ultrasonic distance sensor and a 3 line LCD to display information. Didn't have any performance issues, but I guess it maybe because I never built any complex, performance dependent algorithms to use with it.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Has anyone used this and if so had any joy with it? It seems like a somewhat half-arsed amateur attempt to me. Maybe because it is open-source MS don't see any profitability in it. I bought a Netduino Plus 2 (32bit ARM Cortex) which is a little prototyping board which hardware wise is a complete beast in comparison to its competitor - the Arduino which is a weedy 8 bit thing. 168Mhz vs. 16Mhz with a lot more flash and RAM memory. Unfortunately though, this thing is super slow, principally because it interprets the CIL rather than Jitting it. There is a jitter in the framework source but apparently it doesn't compile and they never bothered to fix it. Also, jitting isn't ideal on flash memory as you can't replace the CIL with native instructions. This would require RAM. Add in the fact the the framework will likely consume most of your flash memory, interrupt latency of up to 20ms discounting any realtime operation (who'd want that in an embedded device) and appalling documentation on MSDN and you end up with one big turkey. To get the I2C bus working on it, you have to twiddle some private members using reflection every time you want to read/write data. So, I've given up and bought an Arduino for £10 which is likely to be quicker and £40 less expensive, and hopefully won't give me a four day headache like its counterpart. *moan over*
Regards, Rob Philpott.
-
Has anyone used this and if so had any joy with it? It seems like a somewhat half-arsed amateur attempt to me. Maybe because it is open-source MS don't see any profitability in it. I bought a Netduino Plus 2 (32bit ARM Cortex) which is a little prototyping board which hardware wise is a complete beast in comparison to its competitor - the Arduino which is a weedy 8 bit thing. 168Mhz vs. 16Mhz with a lot more flash and RAM memory. Unfortunately though, this thing is super slow, principally because it interprets the CIL rather than Jitting it. There is a jitter in the framework source but apparently it doesn't compile and they never bothered to fix it. Also, jitting isn't ideal on flash memory as you can't replace the CIL with native instructions. This would require RAM. Add in the fact the the framework will likely consume most of your flash memory, interrupt latency of up to 20ms discounting any realtime operation (who'd want that in an embedded device) and appalling documentation on MSDN and you end up with one big turkey. To get the I2C bus working on it, you have to twiddle some private members using reflection every time you want to read/write data. So, I've given up and bought an Arduino for £10 which is likely to be quicker and £40 less expensive, and hopefully won't give me a four day headache like its counterpart. *moan over*
Regards, Rob Philpott.
Hello Rob, You might want to try out Atmels "AtmelStudio" IDE. It is based on MS Visual Studio, has a sensible debugger, and is a free (free means: you trade in some personal data) download. It covers most, if not all Atmel ARM products as well as the 8/32 bit Atmel cores, and the Arduino too. Use it to code in C/C++. Compiling native code, it comes without all the .NET runtime overhead. See "http://www.atmel.com/technologies/cpu\_core/arm.aspx".
-
Nice! May I ask how you did that? i.e. what tools/platform you used. I'm toying with this idea as well. My concern is how to get the code on it. Wiping the flash with the 3.3v lead each time you want to deploy doesn't sound great so I guess some sort of bootloader on device might be a good idea.
Regards, Rob Philpott.
Rob, I used the Yagarto toolchain with Eclipse IDE. I did have to wipe the flash everytime before doing an upload and because there was no built in JTAG interface is was difficult to debug programs but I did manage to control a Ninco slot car race track with it which couldn't be done using the .NET microframework. There is a good SDK you can download from ATMEL that will help with controlling the GPIO ports. Check out this page to download http://www.atmel.com/devices/SAM7X512.aspx?tab=overview[^]
