skeezix
Internal Development
<damn, my keyboard 'n' key is unreliable; partdon mistyping more than usual below 
>
The below is useless, but if it amuses you, read on; thats why you're here, right?
Fuuuuuuu', okay, got my ps2 keyboard code ported to the zikzak eZ80 side. goddamn .. that was one of those weeks, where you stare at the same code and piece of hardware for a long, long time, and .. theres just enough clues in your testing and trials, to make you think its one of a dozen things.. but its not. (And with some bizarre behaviour, it started making me think.. bad solder joint? bad docs? buggy compiler optimizer munching my code? etc..).
But finally, finally got it.
Its really hard to debug interrupt handling code imho; I mean -- its _fast_ (the clock here is 10khz signal coming in), and you can't do much .. you can't use serial to print out anything (its too fast), and even logging to a circular buffer in RAM (think print statements, but into RAM, and into a buffer of say the last 100 messages or something) .. but that gets annoying fast; you want to break in and see the messages, but again.. you can't touch the system mid-stream to inmspect what happened, and adding a rediculous amoutn of logging is just annoying and disruptive. So in the end, the debug technique I came up with was to just add a bunch of output signals .. I've got a 4 channel scope after all, so watch the PS/2 keyboard CLK and DATA signals coming in, and watch my signals going out. ie: In my interupt handler .. put a output toggle as first thing, so that every time my interupt handler got hit, my output signal woudl toggle.. high/low/high/low; throw that on the scope and fid out all sorts of weirdness.. it toggling super fast, all the time; or after a reset, but not after keyboard was struck, etc. Using various kinds of interupts.. are they beig reset right? is the cpu just fooked? is my code fooked?
Took me way longer than it shoudl have, but once I got good debugging output signals into my head and onto the scope, it all came together pretty well. The other debug techniques just were't cutting it, or were themselves interfering.
In the end .. with some interupt types (such as rising or falling edge) you have to reset them (so the cpu knows it can interupt you again, pretty much.) For others, you don't need to reset them. Anyway, I was changing typesd willy nilly, so had to generalize my code.. pick which gpio's to use, whifh interupt type, what reset modes, all that.. since it was driving me nuts, make it easy to change, rule out solder joints etc by moving things around. Man. Anyway, with the eZ80 and falling edge interupt, you have to reset it by writing to the data port, and specify the edge type (falling or rising) with the data port. (Stupid, no?) .. i their C wrappers for setting up interupts (you can just tweak registers, but they offer convenience functions, that I shall now call INconvenience functions.) .. So you call the inconvenience function to set a falling edge interupt - and I need to dig out the code it does, cause it sucks - so that things are right. You have to reset the register to 1 (either before or after).. so its best to do this:
- set to 1 (reset the port)
- set to falling edge <- doesn't actually do anything? sets up most of the registers, but not actually the falling/rising edge one
- set to 0 (to signal you want falling edge)
Then in your interupt handler, you have to..
- set to 1 (reset)
- set back to 0 (to signal falling edge)
This isn't spelt out in the specs, and it varies by which chip you are using I'm using the F93 variation; the F91 is different, for instance.)
One would think settig to falling edge, would in fact, set it to falling edge. But it doesn't.
Note that this is the data register, which is the one that you can read to find out what incoming signals are at, etc. Note that if your ps/2 keyboard changes the signal, and causes a falling edge interupt, you _must_ set it to falling edge again,since the keyboard is pulling it up and down; when keyboard pulls it up, fine; but in your interupt handler, on its way out if you don't reset it to 1 and then 0, then the cpu is now using the value supplied by keyboard as the rising or falling edge indicator, say. ie: so an outside object is now setting your iterupt handler type? I dunno. Seems to be the case anyway.. or it is at least flaky.
This all leads me to.. I didn't quite grok that se tto 1, then set to 0, .. I didn't relize I had to set it to 0 every stinking time, because stupid-Zilog. Also, I had a bug.. I had a 'return' in just the wrong place, in a really devious locatio that seemed fully right, but in fact was causing it to jump back before forcig the falling edge interupt to 0 .. so in some odd cases, it was leaving it at whatever it was coming in (sometimes risig edge, a 1 value).
Therein was my madness.. the docs were not clear, and it varies by chip and interupt mode and cpu mode, and I also had a code bug.
Anyway, so now I have a working interupt based ps2 keyboard handler test code for zikzak.
I suppose I should make another lame little video, so you can see me typing on a keyboard and having it show up on the screen in glorious 8bit; maybe I should make a dmeo that emits a soud tone based on the key hit, and changes screen colour, or something; that'd be very Commodore 64 of me
jeff
>The below is useless, but if it amuses you, read on; thats why you're here, right?
Fuuuuuuu', okay, got my ps2 keyboard code ported to the zikzak eZ80 side. goddamn .. that was one of those weeks, where you stare at the same code and piece of hardware for a long, long time, and .. theres just enough clues in your testing and trials, to make you think its one of a dozen things.. but its not. (And with some bizarre behaviour, it started making me think.. bad solder joint? bad docs? buggy compiler optimizer munching my code? etc..).
But finally, finally got it.
Its really hard to debug interrupt handling code imho; I mean -- its _fast_ (the clock here is 10khz signal coming in), and you can't do much .. you can't use serial to print out anything (its too fast), and even logging to a circular buffer in RAM (think print statements, but into RAM, and into a buffer of say the last 100 messages or something) .. but that gets annoying fast; you want to break in and see the messages, but again.. you can't touch the system mid-stream to inmspect what happened, and adding a rediculous amoutn of logging is just annoying and disruptive. So in the end, the debug technique I came up with was to just add a bunch of output signals .. I've got a 4 channel scope after all, so watch the PS/2 keyboard CLK and DATA signals coming in, and watch my signals going out. ie: In my interupt handler .. put a output toggle as first thing, so that every time my interupt handler got hit, my output signal woudl toggle.. high/low/high/low; throw that on the scope and fid out all sorts of weirdness.. it toggling super fast, all the time; or after a reset, but not after keyboard was struck, etc. Using various kinds of interupts.. are they beig reset right? is the cpu just fooked? is my code fooked?
Took me way longer than it shoudl have, but once I got good debugging output signals into my head and onto the scope, it all came together pretty well. The other debug techniques just were't cutting it, or were themselves interfering.
In the end .. with some interupt types (such as rising or falling edge) you have to reset them (so the cpu knows it can interupt you again, pretty much.) For others, you don't need to reset them. Anyway, I was changing typesd willy nilly, so had to generalize my code.. pick which gpio's to use, whifh interupt type, what reset modes, all that.. since it was driving me nuts, make it easy to change, rule out solder joints etc by moving things around. Man. Anyway, with the eZ80 and falling edge interupt, you have to reset it by writing to the data port, and specify the edge type (falling or rising) with the data port. (Stupid, no?) .. i their C wrappers for setting up interupts (you can just tweak registers, but they offer convenience functions, that I shall now call INconvenience functions.) .. So you call the inconvenience function to set a falling edge interupt - and I need to dig out the code it does, cause it sucks - so that things are right. You have to reset the register to 1 (either before or after).. so its best to do this:
- set to 1 (reset the port)
- set to falling edge <- doesn't actually do anything? sets up most of the registers, but not actually the falling/rising edge one
- set to 0 (to signal you want falling edge)
Then in your interupt handler, you have to..
- set to 1 (reset)
- set back to 0 (to signal falling edge)
This isn't spelt out in the specs, and it varies by which chip you are using I'm using the F93 variation; the F91 is different, for instance.)
One would think settig to falling edge, would in fact, set it to falling edge. But it doesn't.
Note that this is the data register, which is the one that you can read to find out what incoming signals are at, etc. Note that if your ps/2 keyboard changes the signal, and causes a falling edge interupt, you _must_ set it to falling edge again,since the keyboard is pulling it up and down; when keyboard pulls it up, fine; but in your interupt handler, on its way out if you don't reset it to 1 and then 0, then the cpu is now using the value supplied by keyboard as the rising or falling edge indicator, say. ie: so an outside object is now setting your iterupt handler type? I dunno. Seems to be the case anyway.. or it is at least flaky.
This all leads me to.. I didn't quite grok that se tto 1, then set to 0, .. I didn't relize I had to set it to 0 every stinking time, because stupid-Zilog. Also, I had a bug.. I had a 'return' in just the wrong place, in a really devious locatio that seemed fully right, but in fact was causing it to jump back before forcig the falling edge interupt to 0 .. so in some odd cases, it was leaving it at whatever it was coming in (sometimes risig edge, a 1 value).
Therein was my madness.. the docs were not clear, and it varies by chip and interupt mode and cpu mode, and I also had a code bug.
Anyway, so now I have a working interupt based ps2 keyboard handler test code for zikzak.
I suppose I should make another lame little video, so you can see me typing on a keyboard and having it show up on the screen in glorious 8bit; maybe I should make a dmeo that emits a soud tone based on the key hit, and changes screen colour, or something; that'd be very Commodore 64 of me
jeff
