 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 : Picomite/PicoMiteVGA V5.07.05 release candidates
  Page 5 of 9   |
|||||
| Author | Message | ||||
| Volhout Guru  Joined: 05/03/2018 Location: NetherlandsPosts: 3569 |
@Peter, I have finally experienced the remark that Frank(N Further) made on the keyboard support. Not with his solar clock, but with the chess program. I test this by pressing the NUM-LOCK key and check whether the LED turns ON and OFF. I have not found a guaranteed way to reproduce it, it simply happens when the program is running. Could be working fine for few minutes, then simply no response anymore to the NUM-LOCK key. At that moment the keyboard is locked up for X time. Pressing <CTRL-C> can't stop the program anymore. I started looking because I noticed that at a certain moment it looked like a different key was pressed (as if a glitch caused the bits to be shifted). I tried hardware: - waveforms are not different between working and non working keyboard. There are minor glitches, but these do not even come close to thresholds. - I added 100pF and later 470pF capacitors to make sure the glitches where gone (but yes, that influences timing). To no effect. - I changed the 4x10k to 4x3.3k for faster edges, no effect. Is there anything I can do to help analyze ? Attached is a scope picture of the original 1.4 board (with 10k pullups) on the 5V side. The PS2 clock is something like 16kHz.  PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
Response to numlock is completely different to normal chars. After receiving the numlock keypress the code has to send commands to the keyboard to light the LED. This is done with interrupts off. The firmware holds the clock low for 1/4 sec and than releases it to tell the keyboard to initiate command reception. The firmware then waits for the keyboard to generate clocks which the firmware uses to clock out data on the data pin. There is a timeout for all this so it won't stall MMBasic but it is possible the keyboard itself gets itself into a mess. As per a previous discussion all this is compromised by the lack of a true OC mode on the RP2040. Given that the issues seen only happen rarely and only for some users/keyboards and is not reproducible it is not something I intend to pursue even if I knew how |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5758 |
Could it be something to do with the MOSFETs? Perhaps reducing the 10k resistors on the 5V side to allow a little more current might help. Vgs(th) is usually quoted at 1mA, but you don't get that until the 5V resistors are about 6k8 (10k on the 3V3 side is fine - it doesn't affect the drain current). 10k may be fine if the keyboard already has internal pullups, but not if it hasn't. I'm clutching at straws here. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3569 |
@Peter, @Mick, First of all, I noticed it before I even started debugging using the NUM-LOCK key. It was not even with INPUT or INKEY$. I agree it is possible that the keyboard itself gets confused by these NUM-LOCK events. Although this is not obvious from looking at the communication from the keyboard. It continues to send the same command (looking at the O-scope). Peter, do you think it would make sense to change the pico pin into a real open drain ? (phil99 proposed something with a diode and 2 resistors). I am willing to try that if you think it makes any sense... I already tried changing the PS2 5V from 4.2V to 5.5V and the issue did not disappear. (pico cannot handle more than 5.5V). Edited 2022-10-07 23:33 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3569 |
The 1/4 second low does not happen. Not with a working keyboard, not when the keyboard is not working. Maybe that is compromised by the OC... In below pictures, the trace "envelope" is shows. My scope cannot show the detail in this timebase setting. Each peak is basically a set of clock pulses/data. You can see that the working keyboard (numlock working) has a set of 5 communication packets. But no CLOCK low 1/4 sec.  When the keyboard stops working, there are only 2 packets. In case the keyboard should generate the clocks..well..it does not...  Again, this is num lock behaviour, which is not the actual complaint, but a method to show it stops working. Edited 2022-10-08 00:00 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3569 |
Maybe a strange question: " can it simply be a buffer full situation ?" When I run a program, like the chess program, that occupies the CPU in long calculations and does NOT use INPUT or INKEY$ (my chess program version skips INPUT to make it play itself), I seem to be able to make the PS2 misbehave by making the keyboard autorepeat (i.e. press the "s" key for a several seconds). After that the num-lock does not respond anymore. After some time (1 minute or more) there is response again and I can press keys again. My situation: So my CPU is busy in the chess program, doing MMBasic. The basic program does not read (INPUT) keyboard. I enter keyboard keys. PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5758 |
Possibly.... Doesn't pressing a key generate an interrupt to add the key to the buffer? In that case, unless the keyboard buffer is circular, it probably will fill up. If the CPU is busy and can't check the buffer frequently it will take time for the buffer level to drop - I assume there's some hysteresis involved so keyboard input isn't re-enabled immediately one key is read from the buffer. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
Why is it nobody ever looks at the freely available code rather than speculating?  256 circular buffer, overwrites oldest if overflow, can't stall As before, someone needs to produce a simple program that demonstrates the problem if it is to be solved. That we we can isolate if there is a specific basic statement causing the problem |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5758 |
If I understood C I would, Peter. It's just weirdness to me. :) I withdraw my ludicrous idea then. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| ville56 Regular Member  Joined: 08/06/2022 Location: AustriaPosts: 68 |
Peter, ad: Fixed bug in LOAD IMAGE for mono displays (e.g. SSD1306I2C32) It works now as expected, thank you Peter. Intergestingly, now also a .jpg file can be loaded onto the SSD1306I2C32 vis LOAD JPG. But there is a problem with displaying the content. The file contains:  and the display looks like this (saved image):  Remark: the display is physically 128x32, the image loaded is 256x32. The saved image is thus 128x32. So i expected to see the left half of the .jpg file. It makes no difference if the loaded image fits the display size or is bigger. Tried both. Also tried some variations in generating the .jpg file to no avail. Was it intentionally that LOAD JPG now works for b/w displays? Regards, Gerald 73 de OE1HGA, Gerald |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
Works for me with a 256x32 jpg test1.zip May be the type of jpeg |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3569 |
Are all entries in the keyboard buffer single char? Could an overwrite cause a combination that cannot be decoded bij the sw? I wll spend time to find a simple way to demonstrate..... PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3569 |
Are all entries in the keyboard buffer single char? Could an overwrite cause a combination that cannot be decoded bij the sw? Something like 2 key down without key up? I wll spend time to find a simple way to demonstrate..... PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
V5.07.05RC7 https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip Changes to PS2 keyboard handler, may or may not improve things WARNING: this release will erase all options and programs saved in flash |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3569 |
Peter, Have not tried above RC7 yet. Will do soonest. Spend yesterday evening hours to duplicate using Keyboard 1 and GAMEpicoVGA 1.4 board from Mick. I Could not, it was simply rock steady. My other system (Your design board 1.4) using keyboard 2 is at my work that has shown the problem, I can check that system on monday. I will try your new code, but also plan to disable SD CARD and AUDIO. These signals (GP7 (PWM audio) and GP10 (SD card clock)) run parallel to GP8 and GP9 (PS2) and may cause problems when active (glitches from cross coupling). That is the only thing I can think of that distinguishes between Micks board and your board. Or it is the keyboard itself. Volhout Edited 2022-10-09 20:59 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
The other thing you could try is changing the 10k PS2 pullups to 4K7 or even lower |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 1807 |
If crosstalk is the problem Peter's idea should fix it. On the Pico side of the level shifters you could go down to 680R and 2k2 on the 5V side. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
Note RC7 updated in the download at 17:23UTC 9-Oct-22. Please re-download if accessed before then |
||||
| Frank N. Furter Guru Joined: 28/05/2012 Location: GermanyPosts: 815 |
I now have no problems with the keyboard and my program SolarSysVGA. The keyboard now no longer crashes!  ...can it be that something has been changed in the "OPTIONS"??? > OPTION DISPLAY 60, 106 Error : Invalid Option > OPTION DEFAULT FONT 7, 1 Error : Invalid Option Frank |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
No: doesn't exist Set the default font with OPTION LCDPANEL CONSOLE [fnt] [,foregroundcolour] [,bacgroundcolour] |
||||
| Page 5 of 9 |
|||||
 Print this page |
