|
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. 
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: I don't know what NetBeans is
It's Boiled Beans that you can order over the Net.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
