 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : USB Keyboard - slow response/dropped keypresses
Page 1 of 3   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10209 |
There are reports of slow response/dropped key-presses for the USB versions with a USB keyboard. I would like to get to the bottom of this so if you are seeing this please post on this thread. Please include details of exactly which version of the firmware you are using and complete option list. Also include precise information as to how the keyboard is wired and how the board is powered. Explain in exactly what circumstances you are seeing this issue. I can't see the problem which makes it difficult to track down. My test protocol is to run my finger along the keys as fast as possible from Q to P qwertyuiop and across the other rows as well. I don't see an issue doing this either at the command prompt or in the editor. If you can suggest a different test that doesn't involve a manual dexterity I may not possess then please suggest it. General info: At the moment there are three parameters related to the keyboard. 1: keyboard polling loop time - currently set to 20mSec - this would need to be changed in firmware 2: Repeat time for first keypress hold - defaults to 600mSec 3: Repeat time for subsequent hold - defaults to 150mSec The latter two can be adjusted with OPTION KEYBOARD or OPTION KEYBOARD REPEAT USB keyboards report a maximum of 6 simultaneous keypresses. MMBasic always takes the key at the top of the stack as the input which is the last key pressed. If two keys are pressed within 20mSec it is possible the first may be lost. The current code on the PicoMite is a direct copy from the CMM2. The issue of key-rollover also needs to be considered. USB keys are organised such that although up to 6 keys can be registered as pressed at the same time the scan built into the keyboard is not completely flexible so if two keys are in the same scan column or row then only one of them will be registered. The keyboard is typically organised so that physically adjacent keys are NOT in the same scan. Is there an issue with some keyboards (German layout?) that means that letters that are often following each other are in the same scan group? As previously stated, I'm happy to try and solve this issue but I need more than "it's slow, it's dropping keypresses" to help me do this. In particular, as I can't replicate, I will need someone who sees the issue to try out firmware versions with blind hacks until we get to an answer. |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 480 |
As I posted in the other thread, 600ms is too long for me especially while editing and positioning the cursor to some place. Then I need to press too much twice on a direction to find the correct position. And that's why I found for me, that about OPTION KEYBOARD REPEAT 180,80 is just right. The subsequent speed is then just fine too. |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 480 |
IIRC this is also valid for the serial console no matter which connection type on the local Screen console. I setup a PS/2 system and left the default speed. I realized that it was not enough for my needs and I had to change the PS/2 default to 0,2 to have it sufficient fast |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1573 |
Hi Peter, This answer is only indirectly related to the topic. I haven't noticed any problems with lost characters on my PicoMites yet. Maybe I'm just old and slow. However, I fear that there are still unknown causes for the problems others are experiencing. It's good that you're researching this! But I have one request: If I change the "repeat time for first keypress hold" and "repeat time for subsequent hold" for optimal input speed, it should be possible to restore the original settings. For example, after a program has ended. Two mm.info() functions would be nice: mm.info(first keypress) and mm.info(KEYBOARD REPEAT). Regards MIchael causality ≠ correlation ≠ coincidence |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 602 |
Only from the logic side of views - and please correct me if I am wrong - some of you suggested it might have something to do with pullups, OTG (usb On The Go) compatibility, or the source of the problem might be the keyboard(s) (five different!) itself. I think I can prove that it must be (as initially stated by me) the USB-variant firmware. Why is that so? Let's think of the most simple scenario I've tested: Problem occurs with all five keyboards (not required to use 5 or 6 keys in a row, four keys are enough, as you can see in my video here and here . Now the interesting part: I am using the firmware and circuit of this USB to PS/2 converter by the user "NoOne": Link . I am following the suggested schematic for it and I am using the SAME (!) five keyboards which are is connected via the SAME (!) USB OTG-adaptor-cable (micro-usb to usb-a-female). No problems at all. Now one can think, ok ok but the converter uses a Raspberry Pico RP2040, and above I am talking about the Pico 2. So I tested this above scenario with the RP2040 VGA usb firmware. Same problems with keyboards. So to sum up: we have the same OTG cable, the same Microcontrolerboard (Raspberry Pi Pico), the same keyboards.... what is different? The firmware. And now to be perfectly clear: I really don't want to say: "Ha! I knew it! I am right!" because there might be something I oversee here, I am a bit more cautious this time. But can anybode undersand what I am trying to say, I mean logically? It can not be the OTG cable or pullupresistors, at least as far as I can THINK of. In short: when it is a problem with OTG or pullups or any host mode stuff, why does everything work fine with the same setup but different firmware (NoOne Converter)? And even If I am right about this observation (logically) - sadly it doesn't really help to solve the root cause of it. I am aware of this... Hm.. but if I am really correct with this, maybe one could better track down - since we know it is not a pullup or OTG thing? Possible idea, but I think you (Peter) already thought about that: comparing the usb implementation of your MMBASIC firmware with the usb implementaion of "NoOne". Maybe this is easier said than done, since MMBASIC is way more complex. I have no idea about all this...  Greetings Daniel Edited 2025-07-05 00:18 by Amnesie |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10209 |
Are you prepared to do some testing? Version? Options? |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5036 |
@Peter, Is there a possibility that GPIO29 or GPIO24 are playing a role in this ? Is there any code in PicoMite that actually does something with these pins (maybe in TinyUSB to detect presence)..? In case No-One ignores these pins, and MMBasic is smarter, that could have impact. And it may be different when a hub is used. Another thing: is there a relation possible with CPU speed. Both firmwares use the same hardware platform, but may have a completely different clock structure. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 602 |
Of course!  The easiest platform to test would be the Pico2 or Pico1 controller in the VGA (usb) variant. At this moment I have no HDMI board... So HDMI I can't test right now. Since NoOne uses the RP2040, maybe this would be the right point to start with? I used no special options in my tests, I tried to keep everything as "stock" as possible. Only thing is: "OPTION KEYBOARD GR" @ Harm Maybe this is a good idea to look at! This is so complex... Greetings Daniel Edited 2025-07-05 00:41 by Amnesie |
||||
| mozzie Senior Member  Joined: 15/06/2020 Location: AustraliaPosts: 132 |
G'day Peter, First and foremost, many thanks to you and all those involved in the development of PicoMite 6.00.02, recently been away with work but took a Pico to play with and have only scratched the surface so far.  As for the USB Keyboard issue, I have also noticed problems with the keyboard on the USB firmware, the following will hopefully help with diagnosis. Keyboard: Dell SK-8115 (also others but will need to confirm make / type) Platform: Pico Computer option list PicoMiteHDMI MMBasic USB RP2350A Edition V6.00.02 OPTION SERIAL CONSOLE COM2,GP8,GP9 OPTION SYSTEM I2C GP20,GP21 OPTION FLASH SIZE 4194304 OPTION COLOURCODE ON OPTION KEYBOARD US OPTION RESOLUTION 848x480 @ 336000KHz OPTION DISPLAY 40, 106 OPTION KEYBOARD REPEAT 200,50 OPTION AUDIO GP10,GP11', ON PWM CHANNEL 5 OPTION RTC AUTO ENABLE OPTION MODBUFF ENABLE 192 OPTION PLATFORM PICO COMPUTER > Symptoms: Missing keypresses. Observations: Key Rollover Pressing (holding) the following keys will block nearly all other keys: A,I,J,K,L,P,Q,Z And the following will block most other keys: M,N,O,R,T,U,V,Y IE: hold down the "A" key and try most other keys and they wont work. So it may be a combination of keyboard and typing style that is the problem, in my case I cannot touch type but can do "option list" fairly quick, and most times lost the T in option, this is blocked by the P key possibly not being fully released in time. This keyboard works without a hitch direct to the PC and via terminal (No key blocking possible) Have several of these keyboards and have tried 2 with same result. Have noticed this on several versions of firmware and also direct to Pico USB port (no HUB) with same result on PicoMite USB and PicoMiteHDMI USB. Also remember similar symptoms on other keyboards but will need to confirm, unsure if the problem has varied in severity during the Beta/RC cycle or not. Also noticed this keyboard will not work on the "PicoVideoTerminal" USB-PS2 adaptor firmware, this is similar to PS2x2 Hope this helps and happy to do further testing as time allows. Regards, Lyle. P.S. 4.85V @ USB Port |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7833 |
First, ignore the NoOne converter. We aren't testing that. It's firmware isn't MMBasic and handles USB in its own way. Yes, a keyboard may work on that but not in MMBasic, but you could also say that about a Raspberry Pi or a PC. The fact that the NoOne converter uses a Pico is irrelevant. All it proves is that a particular keyboard will work with it. The bit about the USB port resistors *is* important if you want to rule out the hardware as a cause of the error. There is no reason why they shouldn't be needed with MMBasic but not with the NoOne converter. It may be a timing issue, speeding up falling edges that depends on the firmware. Try them *then* say that they make no difference. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10209 |
Here is a RP2040 VGA USB version. In this I have reduced the scan rate from 20mSec to 10 mSec - please report PicoMite.zip Please also try changing the repeat rates OPTION KEYBOARD REPEAT first, subsequent defaults top 600, 150 mSec |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 602 |
I think I discovered something important... Like Lyle, I tested the same key patterns on all my keyboards and guess what? every keyboard has different "problem-spots" Keyboard ONE: w e r t (fast typed in one movement - even as fast as I can!) No problem! Keyboard ONE: d a s (fast and moderat typed "a" is missing in 100% of the cases, slow without rollover it works) Resulting in: d s ------------------------------------------------------------------------------ Keyboard TWO: w e r t (fast typed in one movement) Problems! Resulting in: w e r (t is missing in 100% of the cases) Keyboard TWO: d a s (fast typed in one movement) No problem! ------------------------------------------------------------------------------- This would explain, why this is so hard to track and most have no problems at all: 1. Peter you are right in some way, because it definitly varies between keyboards and I can imagine if one is typing really slow, it is likly that he has never a problem 2. even if it is different on my tested (five) keyboards, every keyboard has specific problem spots, which are not there in the "NoOne" converter firmware. 3. I tested 4 keyboards which support PS/2 AND USB protocol, sadly I have only ONE real pure USB keyboard. But all of them have problems (even the pure USB one). EDIT: Ah! You've posted at the same time a new firmware, I test it in a half hour and report. Greetings Daniel Edited 2025-07-05 02:58 by Amnesie |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 602 |
I've tested your new firmware and made one good video with very systematic keypresses. First of all. Sadly not one single option cured the problem, I tried altering both values (first, subsequent) in a systematic way starting with the lowest possible. So I typed "OPTION RESET" and made this video with my wife as camera director; there is no difference to the official release, just in case you wondering if this version is a bit better (sadly it is the same - at least the result is) So what are you seeing in the video? Off camera, I already tested both keyboards and this pattern came out. UPPER CASE: what I actually typed lower case: what the result is Now I am typing live on camera to show that this pattern is perfectly repeatable. Only in one case it differs (I am only human, sure it was me). I tried to always keep the same speed. In case you wondering if I do this a little bit slower, it is also behaving like this. I am in the editor, but in the console it is the same. I am moving forwards on the keyboard in a systematic way: QWERT WERT ERTZ RTZU etc... Video uploaded to my Dropbox : As you can see both keyboards acting a little bit different, but I think there is a pattern... I really hope that this somehow helps. But it clearly shows that there is something wrong... If you have ideas, I will do more testing. Greetings Daniel |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10209 |
Please post the file you are editing so I can replicate |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10209 |
Also, please could you do a very quick test on this simple yes/no is all that is needed One more thing: can you see the issue if you run your finger across the groups of 4 keys? PicoMite.zip Edited 2025-07-05 05:00 by matherp |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 602 |
Flashed again with new firmware you provided: Problem persists. To understand you correctly what do you mean with: Do you mean what happens if I slowly "slide" over the keys? Probably to make sure that only one key at a time is pressed? This works only on one keyboard (nr. 1 in the file) without a fault. The other one gives missing keys. I reorganized the file and added numbers too, it is really strange but definitly some kind of pattern. All keyboards have different problem spots. See for yourself, I've attached the file: keybordTest.zip What I find so interesting is, that all keyboards have the EXACT same error pattern which is perfectly reproducible, but every keyboard has a different problem area... So somehow you are right, at least the keyboard is part of it. But not the only factor. With the converter firmware I have an error-rate of zero on all keyboards, I also flashed it on the very same Pico I created the file... But what I don't understand is, that it seems that you can not re-create this problem... I am sure you have different keyboards. Sadly I haven't a US-keyboard, but at least we know of now (two?) persons who use a US-keyboard with this problem. So it isn't a language thing. (I have only two keyboards in the file, if you want I add even more) Edited 2025-07-05 07:11 by Amnesie |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2593 |
I think this was meant to be posted here. |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 480 |
If I would have a problem with an USB keyboard I would test and compare first, how input behavior is through an USB/UART converter. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10209 |
UPDATE I've finally manage to re-create the? (a?) problem by slowing the polling rate to 200mSec. At this speed I am seeing dropped characters but more importantly I know where they are. To fix this needs some fairly complex code as it is all tied in with the key repeat logic. If I polled continuously then the problem would not manifest itself although in the limit it could still occur (and of course MMBasic wouldn't run). The problem occurs if two or more new key-presses happen within the polling interval in which case both the first, second and possibly subsequent values in the USB report will represent those new key-presses. This is non-trivial to interpret because a key held down will appear in the new report so the code has to distinguish between a held down key and a new key. At the moment it only does this for the top position in the report. I still don't understand why Amnesie is seeing the issue to such an extent. I'm testing on one of my PicoMiteVGA USB edition boards (RP2040) which has the USB port properly configured as a host and even slowing the polling rate from the original 20mSec to 50mSec I can't replicate the problem (Lenovo KU-0225 keyboard). Could it be that the internal scan in some keyboards is very slow and they are stacking up the key-presses into a single report - who knows? Anyway, I'll spend some time re-coding to accept new data in other than the first report slot and see if that solves it. Watch this space. |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 602 |
Peter, I'm glad you were able to replicate the problem, even if it doesn't occur as frequently. But I hope with my video you can at least understand, why the USB version for me is not usable. The problem occurance is extreme with all my keyboards. Since english isn't my native language, I hope to understand it correct, because I was asking me the question, why there isn't a problem with the converter firmware (NoOne). I interpret your UPDATE this way: The converter firmware is polling all the time and this makes the problem I am seeing at least way less likely. With the MMBASIC firmware, on the other hand, it isn't possible to poll all the time, because MMBASIC wouldn't run anymore. Do I understand it correct? I am really curious about your ideas for solving this. Greetings Daniel |
||||
| Page 1 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
