Simulator Test

Having looked through the examples and the website, the creators of the RealView Microcontroller Development Kit seem to put great store in the integrated simulator. From what I can see, you are pretty much encouraged to develop and debug as much of your application on the simulator before committing it to real hardware. This is a little scary to me. I grew up in an embedded world, where simulators where untrustworthy; where Forth ruled because it ran on real hardware and that's where you started out -- porting Forth to the real hardware.

Leery though I have been of simulators, I thought I would give it a go and see if I could break it. A good way of doing this is to stick in a binary of a real application that you know runs on real hardware and see what happens. Sometimes the simulator makes assumptions about the world around it -- access to symbol tables, knowledge of the source code etc. Giving it a pure binary makes those kinds of "simulators" choke.

So, as you might expect, I gave the simulator in the RealView Microcontroller Development Kit a complete real-time, multi-tasking, interactive, target development environment binary to boot -- Forth! Something that I knew ran on Philips LPC Microcontrollers standalone, from my old friends at Microprocessor Engineering (MPE). (Cue shameless plug for my previous employers)
http://www.mpeforth.com/arena.htm

This initially was problematic. "Aha!," I thought. "Gotcha." I couldn't invoke the debugger without a project written using the IDE. I then created a null project with no code in it and this, too, didn't work. Things were looking black. Still, people don't always use project managers; some people use makefiles and some people just end up with code as binary, hex or the like -- there had to be a way...

I looked under help in the IDE and found "Internet Support Knowledgebase." This took me to the online knowledgebase on the web: Entering: "Loading Hex" did it! The fourth item, entitled uVISION DEBUGGER: DOWNLOADING HEX FILES," was what I wanted. As I suspected, creating a null project was the right idea. I just had to tell the debugger not to try and load the (non-existent) code at startup.

So that's what I did: once in the debugger, I used the command line (Hooray! Every debugger should have one) to load an Intel hex file of Forth built standalone for the LPC family of microcontrollers into the simulator and then pressed go. Hey Presto! Up came MPE Forth. What was more impressive was when I pressed the button in the IDE representing the LPC's reset pin, up came Forth again and again. I then tried to write a hello world word such as
: Hi ." Hello World" ;

This compiled "ok" but when I tried to execute Hi, the simulator complained telling me I was trying to execute code in a data space. Not surprising but pleasing since the simulator certainly knows where code and data should be on the LCP2148 if it's written in C. It was easy enough to get the debugger to set the RAM memory map of 0x40000000 ... to be executable as well as writable and readable; after that Forth just ran fine.

So I am now beginning to believe in the simulator, now on to some code which I can run on it...

Tune in shortly for some C code running on the simulator :-)