.NET Microframework
-
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.
Can't you just dump the microframework and write / find your own? The ARM core is a wonderful beast to work with, a heck of a lot more fun than any 8 bit micro I ever worked with!
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 – ∞)
-
Can't you just dump the microframework and write / find your own? The ARM core is a wonderful beast to work with, a heck of a lot more fun than any 8 bit micro I ever worked with!
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 – ∞)
Yes, I've been thinking about that. I know ARM, although my knowledge is about 22 years old from an old Archimedes. There seems to be two problems: 1. .NET does give you very nice debug support which I'm going to miss 2. Development tools. You need eclipse which needs Java and I have a rule about having that in my house. Then you need the GNU ARM toolchain etc. I just get so frustrated trying to set these things up. Microsoft have an ARM assembler somewhere in Visual studio but its output is going to be a PE file, whereas what I think I need is a binary file to load into the bottom of the address map. It's not a trivial thing to do I don't think.
Regards, Rob Philpott.
-
Can't you just dump the microframework and write / find your own? The ARM core is a wonderful beast to work with, a heck of a lot more fun than any 8 bit micro I ever worked with!
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 – ∞)
I should add that the board itself is a beautiful well-designed thing. It's just the software which stops it being brilliant.
Regards, Rob Philpott.
-
Yes, I've been thinking about that. I know ARM, although my knowledge is about 22 years old from an old Archimedes. There seems to be two problems: 1. .NET does give you very nice debug support which I'm going to miss 2. Development tools. You need eclipse which needs Java and I have a rule about having that in my house. Then you need the GNU ARM toolchain etc. I just get so frustrated trying to set these things up. Microsoft have an ARM assembler somewhere in Visual studio but its output is going to be a PE file, whereas what I think I need is a binary file to load into the bottom of the address map. It's not a trivial thing to do I don't think.
Regards, Rob Philpott.
Rob Philpott wrote:
2. Development tools. You need eclipse which needs Java and I have a rule about having that in my house.
Could be worse. For a recent PIC32 project, the vendors C IDE was based on NetBeans. :doh:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Yes, I've been thinking about that. I know ARM, although my knowledge is about 22 years old from an old Archimedes. There seems to be two problems: 1. .NET does give you very nice debug support which I'm going to miss 2. Development tools. You need eclipse which needs Java and I have a rule about having that in my house. Then you need the GNU ARM toolchain etc. I just get so frustrated trying to set these things up. Microsoft have an ARM assembler somewhere in Visual studio but its output is going to be a PE file, whereas what I think I need is a binary file to load into the bottom of the address map. It's not a trivial thing to do I don't think.
Regards, Rob Philpott.
Rob Philpott wrote:
NET does give you very nice debug support which I'm going to miss
I know what you mean - I miss it every time I do embedded...mind you, there is a lot of fun to be had adding your own debugging facilities to an embedded board! :laugh:
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 – ∞)
-
Rob Philpott wrote:
2. Development tools. You need eclipse which needs Java and I have a rule about having that in my house.
Could be worse. For a recent PIC32 project, the vendors C IDE was based on NetBeans. :doh:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
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.
-
Rob Philpott wrote:
NET does give you very nice debug support which I'm going to miss
I know what you mean - I miss it every time I do embedded...mind you, there is a lot of fun to be had adding your own debugging facilities to an embedded board! :laugh:
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 – ∞)
Give me some hints - what do you use?
Regards, Rob Philpott.
-
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.
