|
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! 
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.
|
|
|
|
|
Z80's (in the Z180 variant, and yes I know it's old, so is the hardware designer... ) 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. 
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 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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
I think that requiring the declaration in the header was once upon a time required so that the compiler could work with only a small amount of working memory. And more easily and quickly, from punch cards, or paper / magnetic tape.
|
|
|
|
|
BobJanova wrote: A VM is fundamentally the wrong approach for an embedded device
I think it is too expensive to write everything in assembler.
Mono works just fine on the Raspberry.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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 ||
|_|_| ||'----'||
/_/ \_\ /__| |__\
|
|
|
|
|
As Lloyd says, a Pi is a small computer, not an embedded device. Check its specs versus that of an Arduino, for example. A Pi does have memory and CPU constraints but no worse than the devices the early .Net Framework and certainly the Compact Framework were originally designed for.
|
|
|
|
|
The need "to twiddle some private members using reflection" implies that the framework is a bit overweight. 
|
|
|
|
|
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.
|
|
|
|
|
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[^]
|
|
|
|
|
Nice one Mathew, thank you. After much distress I've got eclipse and Yagarto working now. I had to remind myself how makefiles work having not used one in 20 years. Strange how I never missed them.....
It'd be good to get C++ working and I have in a sense, but without any standard library. So there is no heap, no malloc and no new operators so its a bit useless at the moment. Still thinking about what to do there.
Will check the link too. Cheers.
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.
|
|
|
|
|
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
|
|
|
|
|
|
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".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
