Further experimentation. I’ve set it to use the pico8.lua in the keys.lua. Then I edited the first function so that only 3 keys were in green and the rest were all white. Fired it up and surprisingly the keyboard lit up as programmed. So now I’m wondering if the keypresses aren’t getting detected, or indeed occurring at all?.
I’ve now checked that all the switches are working using a continuity tester. When they are mounted in the frame and the key is pressed, using the detector on the reverse side of the HAT, it shows the switch connection is being passed to the HAT, so I used some text from one of the examples and managed to change the colour of the switch being pressed. Some progress at least. But I can’t get it to put any text into, say, Wordpad. For example
function handle_key_00(pressed) if pressed then keybow.text("The first key has been pressed") keybow.set_key("0", pressed) keybow.set_pixel(0, 0, 255, 255) else keybow.set_pixel(0, 255, 255, 0) end end
will execute the colour change but not output the text. I noticed the Boilerplate LUA uses [[xx]] instead of “xx” but that makes no difference.
One other thing is that at least the device is now showing in Device Manager as a Portable Device - Keybow. FAILED to start Load Kernel Modules still appears on a screen attached to the PiZero. :-)
I’m now leaning towards this being a hardware problem for the HAT.
Ok, here are my thoughts at this stage…
From what you’ve described in your last post, it’s almost certainly not an issue with the Keybow PCB itself. If i) the continuity on the switches is all good, and ii) you and get the lights to respond to a keypress, then that rules out an issue with the PCB. Each switch is wired straight to the GPIO on the Pi, so if the Pi is receiving a keypress and sending data back to the LEDs, then that suggests that everything is fine with the PCB.
You’ve tried multiple Zeroes, so it’s unlikely to be an issue with the Zero.
We know that the SD card works.
The fact that the lights are working suggests that the OS is being loaded correctly into the RAM-disk.
I get the same warning as you, but everything works as expected, so that seems unlikely to be the problem.
Which leaves… either an issue with the host machine or with the USB cable, so, could you try a different host machine, if you have one, and a different micro-USB cable too?
Well we finally got it working. A combination of two things. Both the host machine and the USB cable. I intended using this on a Mac with Logic Pro (and maybe to log in as well :-)) but the first USB cable returned nothing on that. I then tried on my Windows 10 Desktop and also got nothing. After trying a few USB cables I found one that worked with the Mac then tried it on my Surface Pro. Interestingly it was one that came with a Microsoft product and hadn’t been touched before. It worked on both machines. I’ve now identified two USB cables that work with it, but it still won’t work with the original machine. Although both my windows machines are running Win 10 my Desktop is on the Fall 2018 release but the SurfacePro is on preview build 18309, a much later version by several builds. At least now I can start setting it up to control Logic Pro rather than using my iPad :-)
Many thanks for your help here. I appreciate you spending the time with me.
Yay! I’m glad you got it working. :-)
Just received my replacement Raspberry Pi Zero and wanted to report that the Keybow is now working perfectly!
An afterthought !
I’ve got my keybow working to control the window configuration on my twin-monitor xubuntu sytem together with a nice led display. However two or three times recently the leds have lit up but the keys did not function. This is using the same working microsd card. Checking syslog the Keybow was not being seen.
After pushing in the usb cable on the Pi it suddenly burst into life.
It looks as if it is possible for the usb port to get power but be unable to transmit data to the host. Presumably one or more pins not making a good connection.
This may explain some of my previous problems.