|
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".
|
|
|
|
|
Stupid King Cnut1 doesn't know they aren't meant to be switched on at the slightest hint of rain.
And did you know that LED brake lamps were originally used as anti-collision beacons on DC-10s? They weren't? Who'd have thunk!
With thanks to MM
|
|
|
|
|
I am soooooooooooo with you on this one ! That post made my day. I wish I could just force-blind these people with a 30kW lamp for an hour.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
Yes and if using them please switch them off when in traffic where their use is completely pointless.
Also what is it with drivers these days where they insist on sitting at traffic lights on dark nights with the brakes on (why doesn't anybody use the handbrake at lights anymore?) and possibly even fog lights, if behind one of those idiots the light show is so bright I have to keep putting my sunglasses on. 
|
|
|
|
|
For automatic cars a foot on the brake while waiting at the lights is how it appears to be taught in US driving schools.
I learned to drive in England where most cars are, or at least used to be, manual ("stick shift" for the USians) and I was taught to go into neutral and put the handbrake on while waiting at the lights.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
For automatics the foot brake when waiting at lights is OK, they can't all be automatics though. Also with all the technology available today why not have a bit of technology to switch of the brake lights once the car is stopped for a little while.
For manuals I can't see a reason for such behaviour except for laziness maybe. Perhaps its the way they learn them these days.
|
|
|
|
|
UsernameNotDefined wrote: For automatics the foot brake when waiting at lights is OK, they can't all be automatics though.
The vast majority are. Only ~ 1 car in 15 sold in the US had a manual transmission a year ago[^]; and IIRC fro other coverage at the time, the reason it was considered newsworthy then was that there was a sudden large jump from previous level of 1 in 25. I don't recall reading anything to say if the jump to 6.5% then was sustained or was just a brief anomaly.
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'm not sure what the % of manuals to autos is in the UK is but its quite a bit more in favour of manuals. Probably something more like 1 to 15 the other way.
|
|
|
|
|
This is probably because it is considered that manual transmissions are more fuel efficient than automatics and when you have petrol ("gasolene" for the USians) at $10+ a gallon this is very important.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I don't think it is, it's always been that way even when petrol costs were a very small factor. It's more that our roads require good usage of the gears, and until recently (2005? 2000 at best) automatics were really very bad at selecting the right gear at the right time. In contrast, in the Americas (and Australia) you have wide straight flat roads where you need to be in the same gear for 300 miles, and then towns, where you need to trundle between traffic lights and having to manage a clutch and gears is inconvenient.
In Britain in particular we've also got a cultural tradition of driving for fun (see all the sports cars that we used to be famous for making for concrete evidence of that). That's probably a result of the same thing, our curved and varying roads. It's impossible to have fun in an automatic.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
