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 :-)
----- Original Message -----
From: "geobrown" <geobr...@cs.indiana.edu>
To: <mspgcc-users@lists.sourceforge.net>
Sent: Tuesday, November 23, 2004 10:55 AM
Subject: [Mspgcc-users] gdb simulator "commands"
I'm trying to design a lab to ease my students into working on a
target. I thought I'd
have them use the simulator for a few programs. The problem is getting
output.
For the following program
char *msg = "hello world\n";
int putchar(int i){}
write(const char *msg)
{
while (msg[0])
{
putchar(msg[0]);
msg++;
}
}
main()
{
int i;
for (i = 0; i < 10; i++)
{
write(msg);
}
}
I've tried the following gdbinit file to cause breakpoint commands to do
my work:
target sim
load
break putchar
commands
silent
printf "%c", i
continue
end
run
Unfortunately, msp430-gdb doesn't seem to do the right thing with
breakpoints. Where
it should silently handle the breakpoint and print to the screen, I get:
Program received signal SIGTRAP, Trace/breakpoint trap.
putchar (i=101) at test2.c:6
6 }
continue doesn't print the output either. This program and gdbinit file
(minus the target
sim) does what it's supposed to under linux.
Any ideas ?
Geoffrey
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
