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
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
I've also been working on a new robot site.