Sun Jul 13 13:50:09 EDT 2014
Seems that serial input needs a buffer. It doesn't look like there
are any comm errors from dumping straight to ram and from examining
the line with pyla. This makes the next assumption to be timing
Let's run uart in through low-pri interrupt.
It misses note off sometimes. This is the pyla output from one of
those misses. Manually annotated with new note state.
80 60 38
90 5E 1A # 5E
80 5E 10 #
90 5C 5A # 5C
80 5C 16 #
90 60 3E # 60
90 5C 6A # 60 5C
90 59 3E 5B 5C # 60 5C 59 5B
80 60 24 # 5C 5B 59
80 59 46 5B 0A 5C 2A #
90 60 42 # 60
90 5E 4E # 60 5E
80 60 3E # 5E
90 5A 62 5C 4E # 5E 5A 5C
80 5E 48 # 5A 5C
Hmm. that actually doesn't have note off for 5A and 5C. Keyboard or
BCR2000 not doing the right thing there..
Let's see: 31250 baud, 3125 bytes / sec.
This gives 12MHz / 3125kHz = 3840 cycles to get a byte out of the
buffer before the next one arrives.
This should really be enough in the current approach..
Anyway it's still possible I guess.
How to find out?
Check overflow / frame errors?
RCSTA is #x90 so no overruns or framing errors.
Switch back to USB to see if that changes anything
USB works without a glitch.
So things I've seen:
- missing note off when keyboard -> BCR2000 -> synth
- stuck note but no missing note off keyboard -> synth
Well.. Let's try to make this work with buffered input. Probably need
that anyway at some point.
Actually, the serial.rkt resets these bits, so let's define a new
See serial-debug.rkt (records OR and FE)
Indeed when it misses there is an overrun recorded.