Developing/Debugging ARM code
Posted 25 August 2011 - 10:44 PM
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?
Posted 26 August 2011 - 06:26 AM
For example, Segger J-Link EDU (check out review and comparison at microBuilder; J-Link is sold as OEM versions by Analog Devices, Atmel, Freescale, IAR etc.), various cheaper clones are also available. There are dozens of ARM JTAG programmers, you'd probably need to choose one that is supported by the IDE of your choice.
Any recommendations for a cheap JTAG->USB adapter?
I have only limited experience with ARM emulators, but sometimes their features are rather limited, usually only basic hardware modules such as GPIO, UART, timers etc. are emulated, so depending on the type of your application, you may hit the case when you need the actual hardware for further development.
... contains an emulator so I don't even need the eval board
Regarding the JTAG support on Netduino, if you have steady hand, you may be able to solder thin wires directly to microcontroller leads and the JTAG connector (don't forget pull-up resistors). I have also listed several other dev. boards with AT91SAM7X (or compatible/upgradeable) in the following post.
Posted 26 August 2011 - 07:04 AM
I will be creating the ARM assembly code with a .Net->ARM assembly crosscompiler.
Sounds like some magic is going to be required there! These exist?
Posted 26 August 2011 - 08:57 AM
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)
- Type casting and checking (like "as" and "is")
- Delegates, MulticastDelegates
- 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.
Posted 26 August 2011 - 03:42 PM
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.
Posted 26 August 2011 - 03:57 PM
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.
Posted 29 August 2011 - 07:56 AM
Most toolchains have a simulator that enables you to trace through the code, for example you should be able to set project target to "ARM Simulator" in Crossworks IDE.
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
JTAG is usually used to refer to the debugging mechanism, or the connector. J-Link is just a product name.
I'm a bit confused though between J-Link and JTAG
For historical reasons - recent embedded circuits provide such diagnostic features that there is no emulation involved in the hardware debuggers (see In-Circuit Emulator). An emulator is another hardware (usually specialized ASIC, FPGA or a bound-out processor) that behaves like ("emulates") the circuit being diagnosed, and has exposed debugging features.
And why is it called an "emulator"?
Posted 29 August 2011 - 06:33 PM
Posted 03 September 2011 - 08:10 PM
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...
...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.
Posted 04 April 2012 - 07:13 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users