[sdiy] LCDs, encoders, and interrupts

[Carsten Toensmann]

Hi Tom,

perhaps it is better not to use an interrupt. In my scheduler routines I 
just process all peripherical devices in the MAIN loop, so no collisions can 
occur. In my uNet - keyboard controller for instance I scan the two encoders 
for key velocity and joystick sensitivity, process and store the values in 
EEPROM and then display it on the LCD. I use an Atmel AT90S8535 with 8 mhz 
clock and have no time problems at all, allthough all peripherical devices 
are scanned and processed in a sequence. No encoder moves get lost.

Here is my scheduler which handles the keyboard, a switch, two encoders and 
the joystick:

MAIN:
 rcall check_switch
;-- load switch position from memory
 ldi xl,low(switchpos)
 ldi xh,high(switchpos)
 ld r16,x
 tst r16; switch on?
 breq external_operation

;-- internal operation
 rcall check_joystick
 rcall check_encoder
 rcall clear_flags; clear 'key is still pressed' flag in note buffer
 rcall scan_kbd_block_0
 rcall scan_kbd_block_1
 rcall scan_kbd_block_2
 rcall scan_kbd_block_3
 rcall scan_kbd_block_4
 rcall scan_kbd_block_5
 rcall scan_kbd_block_6
 rcall scan_kbd_block_7
 rcall note_off; send 'note off' for all released keys
 rjmp MAIN

;-- external operation
external_operation:
 rcall midi_mon
 rjmp MAIN

See also http://www.analog-monster.de/un_kbd_en.html

Cheers

Carsten
http://www.analog-monster.de/index_en.html


----- Original Message ----- 
From: "Tom Wiltshire" <tom at electricdruid.net>
To: "synth-diy DIY" <synth-diy at dropmix.xs4all.nl>
Sent: Saturday, February 27, 2010 11:27 AM
Subject: [sdiy] LCDs, encoders, and interrupts


> Hi all,
>
> Two or three weeks ago there was a discussion about the best way to  read 
> encoders and update an LCD display with values. Or that was  *one* of the 
> things that got talked about, anyway.
>
> I'm actually playing with this on my breadboard now, and I've got a 
> question. It was suggested that it would be a good idea to read the 
> encoders using an interrupt at a reasonable speed (say 500Hz) and  then 
> update the LCD in main code loop periodically. That way, no  encoder 
> tweaks would get missed, and if the LCD skips a few values if  you turn 
> fast, so what?
> The problem I've got is that the encoders and the LCD share a  databus. 
> This means that the 'read encoder' interrupt can occur  whilst the LCD is 
> in the middle of trying to update the value -  indeed, because LCDs are so 
> slow, this is quite likely. I can save  and restore the state of the 
> databus and control lines to the LCD  along with other variables going 
> into the interrupt routine, but this  on its own isn't enough. If I'm 
> halfway through a LCD data transfer,  it will get screwed up.
>
> What to do? Has anyone else had to think about this? I don't want to 
> waste time reinventing the wheel if there's a good solution out there 
> already.
>
> Thanks,
> Tom
>
>
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy