Keypad with pyRTOS

[jwise-acton]

How well does the core module 'keypad' coexist with pyRTOS? Will 'keypad' interfere with pyRTOS execution; will it steal significant processing bandwidth; introduce significant timing jitter in the execution of pyRTOS tasks; etc.?

I can't find a listing of the keyboard module code, so I have no way to figure out the interactions of keypad and pyRTOS if I use keypad to monitor the pressing of push buttons in pyRTOS tasks.

Thanks,
Jeffrey Wise

[Rybec]

Ok, so first, sorry I haven't responded on the other issue. Things got really busy for me suddenly. I do intend on getting to it.

Now, I have no experience with the keypad module, so I can't give a solid answer. Here's what I can tell you: If the keypad module uses any sort of callback system where you give it callbacks and then let it handle the event loop, it won't play well. If instead it has some form of update function that you merely call regularly, it's probably fine. The timing side of things is complicated. If it uses a lot of CPU time, then you might have to make it a lower priority task that mostly runs in free time, and then avoid spending a lot of time in high priority tasks (this is generally how an RTOS should operate anyway). I don't have any experience with it though, so I don't actually know if this is the case.

Honestly, my suggestion is to just try it and see if it works. I suspect it won't consume a lot of CPU time. I don't know exactly what it's doing, but I suspect it's mostly just reading pins, working out which keys are pressed, and setting some variable to keep track of what is pressed and what isn't. It might have some timing math to keep track of current state, so it can respond to key press and key release events. On most microcontrollers though, even that shouldn't use a ton of CPU time. (Oh right, it will depend on the hardware. It might work for a fast microcontroller but not a slower one.)

This is just the general issue with microcontroller programming. Figuring out if the microcontroller can keep up with everything you need to do typically just requires experimentation. Obviously the RTOS also uses some CPU time, but I've tried to minimize that with PyRTOS. If it was me, I would just write up something fairly simple using it and see how it does. Maybe have a top priority task that blinks an LED with a 1 second yield delay between toggles, and then put the keyboard stuff in a lower priority task that yields frequenty but never sleeps, and watch the LED to see if it is consisitent, laggy, or whatever. Maybe also include a counter to keep track of how many iterations the keyboard code is going through, and calculate iterations per second. Use that to calculate how much time passes between iterations and decide if that is an acceptable amount of input lag. I think 10ms to 20ms is probably fine for anything that isn't a high end gaming keyboard. More than 100ms, and input lag might start to become noticable. Depending on application though, 50ms input lag can sometimes be noticable.

I guess there are just a lot of variables, honestly. You'll probably just have to test it yourself and see it if it can handle your application at an exceptable speed. I wish I could give you a better answer, but like I said, there are a ton of variables, and performance requirements are application specific.