This new one is using a different method for scanning the keys and permits the detection of multiple simultaneous key pressed, like * + #.
Right now, there’s only one event raised, which tells the current (combination of) keys pressed and the precedent combination.
Keys are dealt with an enum so that it’s simple to use. See example.
One other difference between this driver and the other is that I’ve used Port.ResistorMode.Disabled. This way, the code is compatible with Hydra or Cerbuino (the 2 boards I’ve tested).
But this implies the use of real pulldown resistors, as you can see on the picture.
@ Bec a Fuel - This is very cool and thank you for posting this. I have limited hardware experience and just seeing the things you guys are doing is teaching me a lot.
I have a questions on the H/W side:
What is the difference between Hydra and Cerbuino that causes the incompatibility if not using ResistorMode.Disabled? I do not have either board, so this is a theoretical question for me, I cannot test anything. I am still getting my head around the sockets and when they support different things, the programmatic control of pull up/down resistors is still a little hit/miss for me as to when it applies and when it can be used.
If I may make some observations on the code
I would suggest that you fire the events on the Dispatcher thread, that way users of your driver will not run into issues because their event handlers are unexpectedly running on the driver thread. This seems to be the recommended approach for Gadgeteer.
I believe it is better to use a control variable to terminate your driver thread rather than using Thread.Abort. Thread.Abort, is a little like throwing an exception at some random point in your code. You never know what the thread is doing when the Thread.Abort is called. With the control variable you know at exactly which point the code will exit.
Caveat : My spiel regarding Thread.Abort is true for Windows in general, I would be happy to be corrected if this is an acceptable practice in .NET Micro Framework. I am still building my understanding of the best practices as they relate to .NETMF.
This is also how I’ve learned a lot : by others’ experience, when they spread it. I think it’s a good pratice, for both parts.
Hydra chip does not support pulldown but pullup If you try to set Pulldown you get an exception in your code. The common point in the two board is ResistorMode.Disabled, that’s why I finally put it in code.
This implies putting real pulldown resistors, though. I think the driver should/could be tweaked by the user, depending on the hardware he’s using.
This one needs some more thinking on my side… I think you may be right, but I’m not quite sure yet I will come back later about this.
Sure it’s best practice on Windows and that’s what I am doing in my commercial software
Here, in this particular example, I have to admit that I didn’t think at it more than that… I will correct the code in this regards, as I also think it is a good practice, even in .NetMF. Though it doesn’t mean that Abort() is bad practice in .NetMF, but I don’t know much about it either.
(just posted it)
If you try to set Pulldown you get an exception in your code. The common point in the two board is ResistorMode.Disabled, that’s why I finally put it in code.