This week I restructured the code for the usb keyboard, the aim is to modify as little as possible from the original demo code, so that there is a clear separation of my code from the one provided by microchip in its demo code and also reduces the amount of code that is caused by modifying the code. I created separate functions that work alongside the original code, but uses a global variable to provide a bridge between my code and the state machine.
When writing the code for the keyboard, one thing that I didn’t realise was the need for a delay, so that there is enough time for a connection between the pic32 and the computer to be established, as Dr Shawn pointed out. For the initial delay the time required depends on the computer the pic is connected to, my laptop required around 1 to 2 seconds whereas the computer here required around 10 seconds (the pic32mx ethernet starter kit runs at a clock speed of 80MHz). The delay between keys however required only 1ms.
When attempting to transfer the code to the pic32mz, a strange thing that happened was that a keyboard would still be detected after connection, but it would then render my laptop keyboard unusable afterwards. Each board behaves differently in terms of how it affects my laptop, with the board marked 2 actually outputs some keys although not the intended ones.
I then proceeded to test the board using the cdc_com_port_single project provided by harmony and connecting it with my laptop running tera term. After making sure that it ri=uns on the pic32 ethernet starter kit, I proceeded to test it on the actual board. As usual, some slight modification to the bsp_sys_init.c code in terms of the which ports and pins the led of the board is connected to has to be made as it is defined differently in their starter kit board. Initial testing of the board determined that the state machine goes into an error state and continues looping forever using the actual board, so I added a line which reinitialises the board whenever it goes into the error state. The part of the code which governs sending keys worked and was able to send a string whereas the reading part didn’t behave as expected. The original code tells the pic to read from an input, then add 1 to it then outputs it back. But using the actual board it outputs a character repeatedly even though there was no input, and changing the working frequency of the board doesn’t change anything.
This leads me to suspect that somehow for the keyboard code, the actual board is sending too many keys into the computer at once, effectively “jamming” it. This behaviour was similar to when I first started experimenting with the keyboard code and trying to send multiple characters at once to the computer.
0 Comments