Initial whitefox support #987
Conversation
| #define KINETIS_MCG_MODE KINETIS_MCG_MODE_PEE | ||
| #define KINETIS_PLLCLK_FREQUENCY 96000000UL | ||
| #define KINETIS_SYSCLK_FREQUENCY 48000000UL | ||
| #define KINETIS_XTAL_FREQUENCY 16000000UL |
There was a problem hiding this comment.
This should not be here... I added the value from lib/chibios-contrib/os/hal/boards/PJRC_TEENSY_3_1/board.h to fix a compliation error.
|
Nice! What all is needed for this to be merge-ready? |
|
It would be nice to have someone other than me test it... I'm also having a weird issue (with both TMK and this, on only one of my two boards) where the escape key and `~ are reversed... which doesn't happen when using the official firmware. Considering this is pretty much just a straight port of the tmk whitefox code with the LED control removed, I'd feel alright with this being merged as-is... someone already did the hard work of adding support for ChibiOS, so there's actually not a ton of work here. I'll add a link to the whitefox folder with the other community maintained keyboards and as long as you don't have anything that's obvious, I'd be comfortable merging this... |
|
After a few hours of debugging, I finally figured out that swap_grave_esc was stuck on, so I held space and backspace when starting up to clear the EEPROM... and that part is all good. Boot magic is just that, magic. The LED controller can come later. |
|
I think the Whitefox should share much of the LED stuff with the Infinity Ergodox, as both uses the same controller. The Infinity Ergodox already have a driver in the Things have gone slowly since, I had a bit too big ambitions for the effect system and I kept iterating my design back and forth, and not that much time available either. But I now have something much more simple (not described in the proposal), almost working. Almost only the final integration and the communication protocol, which is discussed here is missing. However since I have constantly missed the deadlines I have promised, I won't say anything now. |
|
That's another reason I'll leave the LED controller for later. I noticed that the code was shared in other projects and figured I'd try to integrate with that and do it right... however this really isn't my expertise, so I couldn't get it working - I guess this sort of explains why. :P The controller which ships with tmk (for the WhiteFox) is a bit of a hack, and I'd rather attempt a better solution before giving up and porting that over. EDIT: I've also got an ergodox infinity coming from massdrop but I don't think that's due until March... It'll be nice to compare the two. |
|
I've been using this since I opened this PR and it seems to be working well. I'd be comfortable having this merged if you are. |
|
One thing that you might want to do is to apply this type of patch. Without this the wait_us(1), that you have in the matrix scan doesn't really wait for one microsecond, it waits for one millisecond. And that is for each row, so a full scan with 9 rows takes 9 milliseconds. This together with the debouncing could make it take up to 50ms for the keyboard to respond to keypresses. All the Infinity based keyboards originates from the same source, so they all have that bug. You could also increase the clock speed to 72Mhz instead of 48Mhz, which could come in handy when doing complicated LED effects. For this you need to change the mcuconf.h, see the Infinity Ergodox for an example of that. But it's probably not important yet. |
Based off of PR qmk#866 which did the same thing for the infinity60
Let me know if there's anything else which needs to be done. I've got a friend of mine testing this too, so I can be a little more confident that it works well. EDIT: Not sure if you want anything squashed, so just let me know |
| @@ -69,7 +69,7 @@ uint8_t matrix_scan(void) | |||
| case 8: palSetPad(GPIOC, 11); break; | |||
| } | |||
|
|
|||
| wait_us(1); // need wait to settle pin state | |||
| wait_us(10); // need wait to settle pin state | |||
There was a problem hiding this comment.
I suggest that you change this to 20 us, like it's on the Ergodox. It probably works with 10us right now, but if you spawn other threads, it might stop working. 20us is still very fast, as you can do a full scan in 9 * 20us = 180us. For a comparison, the Ergodox Ez takets 3.15 ms, so it's still 7.5 times faster than that.
I don't know the exact reason why the delay has to be at minimum two ticks, but I suspsect it's due to how the context switching is implemented internally in ChibiOS.
There was a problem hiding this comment.
Ah, good catch. I missed that change.
|
As another data point, I've patched this and have been running it for the past day with no issues. |
|
Awesome - thanks all! |
|
I'm having some trouble with this keymap. Compilation succeeds, but when I try to flash it with dfu-util (using version 0.9), the keyboard is rendered unusable until I flash another firmware that works for me, like TMK. I've tried building it both in my local environment on OS X 10.12, and using Docker with the instructions provided ( This outputs the following files: I was unsure of which one to flash, so I tried all 3 (whitefox_default.hex, .elf, and .map). All 3 leave my keyboard in DFU mode even if I unplug it and plug it back in. Any more info that I can provide to help with this? @belak's work to get QMK running on the Whitefox are very much appreciated, and I'd really like to get it running on my own Whitefox if possible. :) |
|
I need to look into the tooling behind this but what I did when I was testing this was run make with the dfu option because you need it to generate a .bin file then flash that manually because using the Makefile never worked 100% for me. Also, if I remember correctly, when you press the button on the back, it expects either a valid firmware to be uploaded or the power cycled... So you may not need to flash tmk when it fails. |
|
Ok, I just messed with it and make whitefox-matt3o-dfu-util worked. If you're still having issues and want to try debugging it, I usually idle in #input.club on freenode and I'd be happy to help there. |
|
Thanks for the fast reply! Unfortunately I'm having another issue (potentially unrelated to this, because I see it on TMK as well) where my modifiers are all wonky, and whatever key I set as my GUI key isn't working. Maybe I can hop into the #input.club channel tonight to try to debug it. Thanks again! |
|
@kevinmost I think the most likely thing there is that something is stuck on in the Boot Magic (see https://github.com/tmk/tmk_keyboard#keymap). I ran into the issue with ` and ESC being swapped (#987 (comment)). The issue you describe sounds similar to some of the other Boot Magic options. So you may want to try booting it up and clearing the EEPROM (I think that's hold Space and Backspace on startup). |
|
I don't think I ever would have guessed that that was the issue. Thanks so much for the help, @belak. |
I realize this isn't really ready, but I figured I'd throw it up as a proof of concept. This was based on the infinity60 support, grabbing settings from https://github.com/tmk/whitefox
I'd like to get the LED controller working, but as far as I can tell the support in the other repo is hacky at best.
I'd be interested in ideas for improvements as well, as I'm sort of new to this.