My folks have gone on to see some other family in Perth, hence it's back to the mechatronic land of sleepless experimentation that we all love...
I've only done a little bit of work on the robot side of things in the last fortnight, but I have had some success. Firstly, I've figured out the (first) issue I've been having with my interrupt code - it turns out that it was that the compiler wasn't coding the isr as an isr but as a standard function.
From the M16C docs: By declaring the function as an interrupt handler, the compiled output ends in an "reit" (return from interrupt) instruction rather than the standard "rts" (return from subroutine). For hardware interrupts, use the declaration:
#pragma INTERRUPT function name.
When I was debugging the compiled code, I noticed that there was not REIT at the end of my srf_isr(). What actually needs to happen is that #pragma INTERRUPT directive needs to go in the same C file as the function it is referring to - I previously had it in main.c. Therefore, the ISR vector table quite happily invoked srf_isr() on the first timer interrupt, but then the thing crashed when trying to leave the isr for the first time.
I've also got rid of lots of debug code (LCD outputs), and now, for some reason, I can do sprintf(...) which previously didn't work. I really don't know why on that one.
Now my current problem lies with the fact that I dony appear to be getting any echo transitions back from the SRF04 - I seem to be getting a constant '1' back. I'm a bit concerned that the LCD output and control code actually interferes with my srf code. According to the SKP board schematic, the LCD only uses port 9_0 to 9_3 (4 lines) for data and port 6_0 and 6_1 for control. I use port 9_4 for ECHO_INPUT and 9_7 for TRIGGER_OUTPUT. So there shouldn't be a problem, but when I use the debugger on the supplied LCD code, it seems to change p9_5 occasionally - so I'm going to concentrate on that for a little while.
I've also been working on a new robot site.