daveMy keyboard matrix is completed.
What happens if I press multiple buttons at once? - It registers only the one that was pressed first
What happens if I hold a button down for an hour? - Nothing, until you release it. It could be easily customised to act as a normal keyboard would, but It's not neccessery, so I will probably not implement that.
What about ghosting? - 33 diodes prevent that from happening. One for each button and 3 for every row selector pin.
In the video I explain a sad story about my SRAM and then later in the video I demonstrate how my keyboard matrix works.
The quality of the video is pretty bad. Sorry about that.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Hah! I dig your sense of humor... Preventing the self-aware chip from taking over the world.
Are you sure? yes | no
Humor is a spice of life, I've heard. Yes, it was a big conspiracy :). Thanks for the comment.
Are you sure? yes | no
eric, I started to experience the same problem with my keyboard matrix, that I had with my sram. It freezes everything up after a while of use.. It uses the same kind of mcu. PIC16f723a for a controller. Not all unused pins are grounded. Do you think that could be it? I don't know what else to think.
Thanks in advance.
Are you sure? yes | no
Tried it, it's not it.
Are you sure? yes | no
Beat me to it! Actually, I'm not very familiar with PICs. For AVRs most of the pins can be controlled via software to use internal pull-up resistors. I imagine it's similar with PICs...
Your crashing-problem is definitely a curiosity to me, but I honestly don't understand the details of your project enough to be much help.
One similarity, however: Your SRAM venture and your Keyboard venture both have data sent to the main controller, whereas the LCD display only has data sent out from the main controller. Is it possible your TDP has a bug in the Slave->Master direction? I just noticed you have the code available, I'm curious how it works and I'll try to take a look at it over the next day or so.
Are you sure? yes | no
Actually, I started looking over it a little bit. I recognize your methodology, using while-loops to wait for expected responses, in order to keep everything synchronized. But, this methodology has often led me down the path you're running into: What happens if the two devices are somehow offset by just a single transaction?
E.G. Maybe the two devices take a different amount of time to boot and one starts transmitting before the other is even booted. Or maybe a little bit of noise gets into the system and suddenly one device thinks the other is transmitting when it's really not... now that device is stuck waiting in while loops for something that will never come.
What if you used time-outs...? A simple start might be to use for-loops instead of while-loops, with large counts, and if that count is reached then time-out from the receive/transmit functions...
Again, I haven't looked it over *completely*, it may be you've accounted for these possibilities.
Are you sure? yes | no
Hmm.. I know what you mean. Maybe I could keep while loops as they are and in the body of while loop, I'd count up to .. hmm, I don't know what would be a number big enough, for it to take 1 second (you know how to calculate that??) and then unconditionally exit the statement.
Are you sure? yes | no
you were correct my dear friend. That was almost 100% it. I have another problem now. I must figure out if the data transmission has been terminated or completed and let both communicating chips know that. hmm. Back to the drawing board :)
Are you sure? yes | no
I have another question. It seems that I will have to rewrit my protocol. Do you have any suggestions how it should work... the problem is, that both pins must know if communication is terminated or going ok.
Are you sure? yes | no