I'm completely symapathetic with this approach -- when I worked as one
of the architects
of the HP/ST LX/ST210 VLIW processor, I wrote multiple simulators
(including a gdb
based one) which we used for testing the compiler, porting libraries,
and even testing
the verilog (by linking with the PLI). It always surprises me that the
various gdb based
simulators rarely include some basic I/O -- a timer tick and
putchar/getchar are all that
is needed to port threads and a wide variety of other stuff; we included
a basic O/S
call table for the main unix functions which let us port significant
Unix apps as client processes.
This doesn't really answer the basic question, what is broken with the
msp gdb port, for
something clearly is. It appears that commands after breakpoints don't
work either in
the simulator or the real target. It doesn't surprise me that they
work the same way since
the simulator has no real gdb specific knowledge.
Geoffrey
To: <mspgcc-users@lists.sourceforge.net>
Subject: Re: [Mspgcc-users] gdb simulator "commands"
Date: Tue, 23 Nov 2004 11:41:15 +0900
Reply-To: mspgcc-users@lists.sourceforge.net
Hi Geoffrey,
Perhaps another line of thought for you to follow.
I've created an environment that allows MSP code to be compiled with
Microsoft Visual C and run on windows. There is additional C code that is
simulating the behaviour of the MSP down to the hardware level (interrupts,
GPIO, LCD controller, timers etc), and this only exists on the windows
build. I then use a very small TCL/TK script to show the LCD, LEDs and for
button presses.
The simulator has been so good, that the code that runs on it will always
run on the target - yes, including interrupt routines. So I spend more time
coding and less time downloading and wrestling with GDB and the 2 breakpoint
limit of the MSP debug core. I can use all the nice MSVC debugging features
to find my silly mistakes. Without a doubt, the time it took to write the
simulator is less than the time it would have taken to do all dev on the
target.
This environment is closer to what your students will encounter in the real
world. All the tools I have used from the mobile phone manufacturers use a
windows simulator. The target code is compiled to run on the 80x86 with
support code to make the simulator look like actual hardware. The best
simulators do lots of hardware simulation - the poor ones fudge it. But any
simulator is better than none. Exposing your students to a simulation
environment then moving on to the hardware is exactly what's done in
industry.
For my MSP project, the software was up and running long before hardware
became available. This is another benefit of this approach and shows yet
another reason for it's use in industry. It was very satisfying to see that
first download actually run. You can even test hardware changes in
software, before making the actual physical change.
The best simulator I've ever seen is for the Palm - it even runs the
Dragonball instruction set, but a simulator with this level of detail is
uncommon.
Cheers,
Rich :-)
