Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

BitFlipper's Content

There have been 16 items by BitFlipper (Search limited from 30-March 23)


By content type

See this member's

Sort by                Order  

#32300 This looks like a bug in InterruptPort

Posted by BitFlipper on 19 July 2012 - 04:03 PM in General Discussion

Hi BitFlipper - thanks for replying, that's useful information anyway.

My issue sounds possibly related to yours. I've a sensor sending 43 bits of information, and the Netduino only picks up around 30-40 - I've found that it "loses" interrupts in the middle of the signal.

I'll keep looking for a solution :)

Thanks again,
Jeremy


Jeremy, it sounds like your issue is a bit different. In my case I simply needed to know about the last transition, whereas in your case, you need to know about every transition. I'm sure if the issue was fixed, it simply did something like check at the end of each notification that was sent whether the last value that was notified matched the actual pin state. If not it would send a new notification to get everything back in sync (and keep doing it until the actual pin state matches the last sent value). Such a fix won't handle your case properly where a series of fast intermediate transitions will still get lost.



#32261 Netduino speed vs native 48Mhz Atmel code

Posted by BitFlipper on 19 July 2012 - 07:00 AM in General Discussion

Your results sounds reasonable and pretty much what I expected, just wanted to make sure we were talking about the same thing here.

Btw, what toolchain etc. did you use for native C programming on the Netduino? I've been meaning to do a little native stuff for some time now but never actually got around to do so.


Well, that whole project ended up going into a completely different direction. Now remember that most of this was done as a pet project just to see whether it could be done or not, so it might not make sense why I did it this way...

The first idea was to have a .Net decompiler that recompiles the .Net IL into C++. First it would do a static code path analysis so it only decompiles the code that is actually used by your application, then create the equivalent C++ headers and source files based on that IL. It includes a garbage collector and everything else you need that makes it "managed". The only thing it didn't do was reflection. This actually worked quite well and I was getting very encouraging performance results. But this was always on my desktop computer, not on a microcontroller. The idea was that once reliable C++ code could be created, that a standard ARM C++ compiler could then be used to compile that code to native ARM code.

But after looking into C++ ARM compilers, I realized that was a bad idea. Most were really expensive and the cheap/free ones were not worth the setup/maintenance headaches. I then started looking into compiling the .Net IL code into native ARM code. This project also progressed well and I ended up making a .Net decompiler, ARM compiler and ARM emulator. So basically I could take any .Net assembly (it didn't even needed to be a MF assembly, it could be the a full .Net assembly, as long as it didn't use things like WCF, WPF, etc), and this would then be decompiled to IL, re-compiled into ARM assembly and then executed by the ARM emulator. This also worked quite well but I got stuck on a particularly difficult to track down bug, and like most pet projects, before I could complete it, another shiny object attracted my attention. I still plan to get back to it at some point and turn it into something really useful.

What made this complex as well is that while it could cross-compile a lot of the full .Net classes into native ARM code, as soon as any of those methods make a native call, all bets are off. For instance, combining two strings in the .Net framework is not done in C# code by the String class, but it does a PInvoke to native code. So I had to add special checks for any IL code that makes native calls, and throw an error. Since many of these classes are critical to most applications, I had a system where there would be specially created substitution classes that do implement the full functionality in either C# or in "inline" ARM code. So if the decompiler came across a String.Concat(string, string) method, it would know to substitute it for the explicitly implemented one.

That was probably more info than you wanted to know, so to answer your actual question... I never ended up using any ARM C++ compilers.

EDIT: I just realized you were talking about the native vs C# performance results. Well, I never did that testing myself, but someone else posted performance results of toggling the pin with C/C++ code and then with C# code. So I base the "100 to 1000 times" values on results I have seen from other people's tests.



#32257 This looks like a bug in InterruptPort

Posted by BitFlipper on 19 July 2012 - 06:30 AM in General Discussion

Hi BitFlipper

Could you confirm if the fix in .NET MF4.2 for issue 1073 (http://netmf.codeple...m/workitem/1073) actually solved the problem for you?

I'm coming across a similar InterruptPort issue myself and just wanted to check if your issue was resolved by the change.

Thanks!
Jeremy


Jeremy, to be honest, I don't believe I ever tried the version where this bug was marked as fixed. The polling loop ended up working well enough for my purposes so I never tried the later version.



#32236 Netduino speed vs native 48Mhz Atmel code

Posted by BitFlipper on 18 July 2012 - 10:16 PM in General Discussion

Were these tests made on equivalent hardware and regardless of that, which hardware(s)?


I don't remember the details but yes, it was the same hardware. I think it was on a Netduino. IIRC the test was to see how fast a pin could be toggled in C vs C#.



#32083 Netduino speed vs native 48Mhz Atmel code

Posted by BitFlipper on 17 July 2012 - 01:02 AM in General Discussion

In my own tests a while ago, I determined that the C# code runs roughly 100 to 1000 TIMES slower than the equivalent C++ code. The bottom line is that it is very slow but you get an excellent development environment and a managed language that makes coding up complex tasks much easier and faster, as long as you don't need super fast execution. Not sure whether that helps or not.



#32082 Pre-made complete units

Posted by BitFlipper on 17 July 2012 - 12:51 AM in General Discussion

OK it's been a while since I've posted here or even visited these forums so I'm a bit out of the loop so excuse my ignorance...

I bought a house and it came with a pool that has a solar water heater. The solar water heater controller is ancient (see here), and frankly isn't working properly. There is some interactions between currently available sunlight, current water temperature, and how long the main pump has already been on. The controller basically opens/closes a valve that allows water to either flow through the panels or bypass the panels. The reason it isn't working properly right now is a bit involved to go into but basically has to do with startup conditions where the pump has to initially push the water up two stories and this sometimes prevents the pump from priming properly. There needs to be some delay introduced before the panel valve opens.

Anyway, I'm thinking of creating my own controller that can manage the solar panel valve more accurately. I'm also considering making this new controller take over ALL management, including the main pump and booster pump operations (which is really just turning each pump on/off at the right time and making sure the booster pump only runs when the main pump is running - simple stuff really). I recently replaced the ancient mechanical pump timers with this unit.

Well, that's not really the problem (and probably a bit more info than what is required but it is good to give some context I guess). What I really want to get at is that I'm looking for a pre-made complete Netduino unit that has the following features:

1. Contained in an all-weather enclosure that can be placed outside. This is not a deal-breaker as I can always put the unit inside another all-weather enclosure if needed.

2. Has a dot-matrix LCD display that can be programmed to display whatever I need (including the current time, soft-buttons, setup steps etc).

3. Has 4 or more soft-buttons (more would be better).

4. Has outputs that can drive at least 3 relays directly.

5. Has inputs for at least 2 temperature sensors.

6. Has a backup battery that can retain the current setup in case of power failures (also not a deal breaker but would be nice).

I have done a few Netduino projects in the past however this time I really don't want to spend too much time making a klugy box that is never going to look right. I need a professional pre-made box that has all the right hardware already wired in.

Any suggestions?

EDIT: Hmm, stumbled up this. Might be a bit overkill but it'll sure make a cool, professional looking control panel for any project. Anyone have experience with this particular product?



#17496 Developing/Debugging ARM code

Posted by BitFlipper on 03 September 2011 - 08:10 PM in Netduino 2 (and Netduino 1)

@CW2
Thanks for the info!

I've been reading your progress on the channel9 forum, its an exciting prospect to run C# code natively on an ARM. If you do go the assembler route please be aware there are different ARM instruction sets, ARM, THUMB, THUMB2. Some of the more recent ARM based chips (Cortex-M3) only support THUMB2, where as the ARM7TDMI chips support ARM & THUMB, but not THUMB2.


Yes I am currently working on my compiler to generate ARM instructions instead of the C++ code. While I've had really good results with the generated C++ code, once I started looking at the process required to compile this C++ source code down to ARM code, I came to the realization that such an additional step is just too much hassle. The "better" IDEs are ridiculously expensive (Keil quited me $2700 for their crippled 256K limited "Basic" edition). The cheap or free solutions are difficult to set up, and overall it just isn't worth it.

So I decided to create an ARM assembler/emulator/linker. So far I'm about 80% done with the assembler. There are a few ARM instructions that it currently doesn't assemble yet (PSR and the coprocessor instructions). I will get to those shortly. Once you create an assembler, you are 80% towards an emulator so I'm currently working on that.

Of course skipping C++ has advantages and disadvantages. Advantages include not having to deal with trying to satisfy the C++ compiler with all the intricate C++ syntaxes etc, not having to declare types, not having to worry about name collisions, etc. Disadvantages include losing features like virtual functions, not having the C++ compiler optimize the code, etc.

For virtual functions, you have to create a vtable for each type that has one or more virtual functions anywhere in its lineage, and each instance of such a type needs a pointer to its vtable. I just completed this part today, and should be able to test it shortly.

Also completed is the string lookup tables. I have not completed the linker yet so I can't actually test all of this.

The next major part of the work will be actually compiling the code. Since my assembler is working now, the compiler can simply emit standard ARM assembly instruction sequences, for instance...

Emit("STMFD R11,{R0,R3,R5,R7-R9,R11-R13}^");


...will compile down to the correct instruction.

You make a good point about the different instruction sets. I will initially just do ARM instructions and then later add support for THUMB and THUMB2.



#17116 Developing/Debugging ARM code

Posted by BitFlipper on 26 August 2011 - 03:57 PM in Netduino 2 (and Netduino 1)

Does anyone have experience with OVP? They claim OVP is open and free simulation software that supports ARM. Unfortunately their website seems to be a bit flaky right now.

What I need to do is test ARM executables that will be auto-generated by my compiler, so it is more important at this point to be able to see the generated code as assembly instructions (so there will be no C++), and step through that code than it is to actually run it on a physical processor. It is not even that important right now to be able to access the processor's ports, for now I just need to get the basic code generation up and running.

So would OVP be something I could use for this purposes? I guess I should try it out, but if someone has experience with it, I would like to know what you think about it, and whether there is something else that could work better for my purpose.

EDIT: Here is a J-Link "emulator" for $60 for non-commercial private use. I'm a bit confused though between J-Link and JTAG, and whether eval boards with "JTAG" ports can work with this.. And why is it called an "emulator"? Still, I'd like to completely bypass having to buy any additional hardware if I can get a satisfactory ARM emulator up and running.



#17115 Developing/Debugging ARM code

Posted by BitFlipper on 26 August 2011 - 03:42 PM in Netduino 2 (and Netduino 1)

Just out of curiosity, how is your approach related to Mono AOT?


Well in many ways it is similar except that I don't believe that with Mono AOT you can have the debugging scenario I mentioned above. This is where you have the code running on the PC as a full .Net application in the debugger but all hardware-specific calls are remoted into the microcontroller (e.g. InputPort.Read, OutputPort.Write).

I did look into Mono AOT initially but it would have required code changes to it in order to support what I needed (and MonoTouch is actually even closer to what I'm doing). However I would not have learned much about any of this stuff if I went down that road, so I just decided not to rely on any of that.



#17084 Developing/Debugging ARM code

Posted by BitFlipper on 26 August 2011 - 08:57 AM in Netduino 2 (and Netduino 1)

Sounds like some magic is going to be required there! These exist?


I'm currently working on a .Net->C++ compiler, with some very promising results so far. It takes a .Net assembly (the full .Net version, not .Net CF), and using reflection it extracts the IL, examines all code paths and then only includes the types and methods that your code actually calls into. This IL is then converted to C++.

Currently the C++ code is compiled for x86, and it creates a stand-alone native exe that does not require the .Net CLR, since it contains its own managed runtime.

The idea was to ultimately compile this C++ using a compiler that can target ARM processors. However it occurred to me that maybe a better idea could be to completely bypass the C++ stage and just go directly from IL to ARM assembly. The front-end compiler can stay exactly the same, but what I need to do is swap out the part that generates C++ for one that generates ARM assembly.

This project was started as an educational exercise to see if one can generate C++ from managed IL, but I think there could be real practical use for this. For someone developing an application, the workflow would be:

  • Use VS to develop and debug your application as if it is a full .Net application (with some limitations on which classes you can use - it just isn't going to work if you include WPF, WCF. XNA, etc).
  • Add a reference to a special .Net library that, amongst other things, communicates with the microcontroller using the USB port. This library also contains classes to interface with the microcontroller, like IO pins, etc.
  • During debugging, your code will run on the PC as if it is a typical full .Net application, but any calls you make into the hardware classes will be remoted into the microcontroller (like setting/clearing pins, reading analog ports, etc). So this will actually read/write to the ports as if the code was running on the microcontroller.
  • Switch to the release build configuration, and a post-build step will compile your application to native ARM code and download it to the hardware. It then runs as a native application on the microcontroller.

So far I have the following .Net features working in the generated C++ code:

  • All basic CLR types (ints, floats, bool, strings, etc)
  • Arrays
  • Generics
  • Type casting and checking (like "as" and "is")
  • Boxing/Unboxing
  • Delegates, MulticastDelegates
  • Multithreading
  • GC - Mark/Sweep (in other words, objects are properly collected)
  • Internal calls (call native functions from your .Net code)

The two main advantages of this approach would be that you will be able to write substantially larger applications because the current .Net MF does not need to be resident on the microcontroller, and the code will run substantially faster than current .Net MF code.



#17073 Developing/Debugging ARM code

Posted by BitFlipper on 25 August 2011 - 10:44 PM in Netduino 2 (and Netduino 1)

I want to be able to develop and debug ARM assembly. I don't necessarily want to write the code in C/C++. More specifically, I will be creating the ARM assembly code with a .Net->ARM assembly crosscompiler.

Ultimately, I want to run the code on the Netduino without the .Net MF firmware. However, since the Netduino doesn't expose the JTAG port, I can't debug it on the Netduino.

In order to debug the assembly code, I just ordered this dev board. I know it only has 256K flash and 64K RAM, but since I don't need the .Net MF, this should not be a problem I believe.

In addition, I was thinking of getting CrossWorks for $150.

Ideally CrossWorks contains an emulator so I don't even need the eval board, but since it isn't mentioned on their website I'm assuming it does not contain an emulator. Correct?

Is there anything else I would need to get this up and running other than the dev board and CrossWorks?

EDIT: OK, it looks like I would also need a JTAG adapter. I have since been looking at the Fez Panda II which has an exposed JTAG interface (missing the header though), but even if I get that, I would still need a JTAG adapter. Any recommendations for a cheap JTAG->USB adapter?



#16933 Suggestions for a good ARM assembly programming book?

Posted by BitFlipper on 22 August 2011 - 03:34 AM in General Discussion

I ended up ordering this one.



#16922 Suggestions for a good ARM assembly programming book?

Posted by BitFlipper on 21 August 2011 - 03:40 PM in General Discussion

I'd like to learn how to program assembly for the Netduino. There are quite a few books on Amazon.

Any suggestions for a good one?



#16888 Need help compiling C++ on Netduino

Posted by BitFlipper on 20 August 2011 - 10:19 PM in General Discussion

I would be interested in contributing to this project... please contact me at james@loveelectronics.co.uk


I sent you an email.



#16793 Need help compiling C++ on Netduino

Posted by BitFlipper on 17 August 2011 - 03:28 PM in General Discussion

Excellent, thanks for the link. I should find what I need there. BTW the reason I need this is because I'm working on a project that will allow you to take a full .Net exe (not .Net MF) and recompile it to C++. Then you can use a C++ compiler as a post-build step to convert it to a native executable. This project is moving along very well and I'm getting close to the point where I need to start testing this on a microcontroller. This project will allow you to create C++ code from your .Net app that is very compact since it doesn't need the .Net runtime at all as it has its own CLR-like kernel. It does a static code analysis pass in order to only include the code that actually gets executed. It is fast since it is not interpreted but C++ (with added support for GC, full type checking, exception handling, delegates, threading etc). It will also allow P/Invoke just like you can right now with the full .Net, using the exact same P/Invoke syntax. Once this project is at a good point, I will make it available on CodePlex. I will also post a thread here to describe the project in detail. It is a big project but as I said I have made very good progress.



#16778 Need help compiling C++ on Netduino

Posted by BitFlipper on 16 August 2011 - 11:30 PM in General Discussion

Let's say I want to temporarily remove the .Net MF firmware from my Netduino and play around with a purely C++ project. Can someone please let me know where I can get good information related to setting this up? I know that other people have done this but I have not seen good resources with clear steps on how to accomplish this. Specifically, I want to do the following: - Compile a C++ project to be deployed and run on the Netduino. - The C++ compiler should support standard C++, including templates. - I want to connect and communicate from PC to Netduino using the USB->Serial cable. - Obviously I need to do some debugging, how would this be set up? I assume I'll be using GCC since I can't afford to pay $6000 for something like RVDS.




home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.