> If things hasn't changed, the compiler only saves "a basic context"
> (see section 3.4 of the compiler's manual for a complete list), but
> for some weird reason it does not consider some registers as PROD,
> TBLPTR,...,  part of the "basic ones", although it uses them at its
> wild as temporally variables. So you end catched by corrupting them
> inadvertely.
> 
> If my memory doesn't leak, the < save = section ("MATH_DATA") > option
> will instruct the compiler to save all them.

Aha! I knew there must be something like this. I'll give it a shot.

>>a matrix keyboard/LED scanning routine on a timer so that the LEDs are
>>multiplexed properly. The keyboard data is read in the interrupt and
>>processed (for debouncing, etc.) in the mainline. But this sometimes
>>causes erroneous behaviour.

I use a keyboard matrix using transistor pulldowns on the rows (12 rows) 
and columns pulled up with resistors to read the key inputs (6 columns) 
processed through some comparators to make the signals look TTL again 
due to voltage drop over the row drivers. At the same time the row 
drivers double as LED drivers. I have also 6 LED columns using push-pull 
drivers to pulse the LEDs at high current.

During the interrupt the LED rows are scanned and the keyboard inputs 
are stored into an array. (one element per row) In the mainline the 
keyboard inputs are processed for change and debounce, etc. and key 
up/down changes are sent to the host over the USART. Meanwhile my 
program is also taking care of a number of other peripherals which are 
less timing sensitive.


Andrew
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist