USB features

[benblazak]

Wished for features include:

• NKRO
• mouse keys
• media keys
• wake on keypress

I might attempt this by merging / porting hasu's version the the PJRC USB stack, or possibly by rewriting the whole thing (or most of it) myself. Neither option (for me, right now) would be trivial, and depending on interest, etc., there's a chance it won't get done... but it'd be really nice if it did. We'll see how it works out.

[judascleric]

I really want to get media keys working so I can take a look at this. Where does this code live?

[benblazak]

Hasu's firmware is here. I'd probably start by looking at common/keyboard.* common/mousekey.* and maybe protocol/pjrc/, but I haven't had time to look thoroughly enough to understand what's going on, so that's just a slightly less than random suggestion.

On a related note, I thought about this a lot yesterday, and I'm starting to think there might be diverging interests regarding a firmware for the ergodox - but I'm not quite sure what to make of things. I'll try to explain:

My rev. 1 firmware I'm more or less finished with in favor of rev. 2 (on the 'partial-rewrite' branch). It does have several advantages however, namely that it's the firmware the Massdrop configurator is currently using, and that you're already familiar with it. There's a chance, depending mostly on Massdrop and you, that it would be better to continue development on this branch and maintain at least layout compatibility for the time being. If this turns out to be the better option, and you were willing, I'd be inclined to recommend that you maintain your own fork, which I'd gladly and prominently link to. Or I could continue to accept your patches, of course, and I'd be glad to, but I'm not really getting any from anyone else, so I'd hate to deny you credit for effectively maintaining it.

Then there's rev. 2 of my firmware, which I'm working on, and which is getting close to being in a usable state. The original goal was to have everyone (in their own time) switch over to this. The layouts are not compatible between the two (though they're pretty close in some respects), but the second version is much better organized IMHO, more flexible, better documented, and a lot easier to work with. Cons are that my main goal is to have it that way (features are definitely secondary to me there), so for the average user, or the programmer concerned with features like media keys, etc. :) , it may not be the best thing to put effort into - I'm really not sure which way to call it. Of course, any effort put into library-like functionality for rev. 1 (such as porting Hasu's USB stack) should be fairly easily portable between the two, so that might be a consideration as well.

Then, there's Hasu's firmware. The only reason my firmware exists, really, is because when I started I didn't know enough to be able to figure out how to port Hasu's to the ergodox, lol. There's already an issue open on his github to add I2C support, which shouldn't be extremely hard for anyone familiar with a similar keyboard firmware (though I'm not planning to do it, because it doesn't sound fun to me.. lol - but if anyone else did, I'd consider it a positive development). I tend to think (though of course I'm biased here) that my firmware is more flexible, easier to understand and work with, and also much better documented (or at least will be in rev. 2) - but Hasu's is probably technically superior, already has more features than mine is likely to ever have, and he's been developing it since ~2010 it looks like - which gives me the impression he's not likely to completely stop, whereas once I'm happy with my rev. 2, I'll probably start considering it finished (as with rev. 1) and move on to other things.

So, I just wanted you to be aware of these things before you put much more effort into any one option. I'll definitely do what I can for you, whichever direction you choose :) .

[judascleric]

Momentum and motivation make or break most projects and since you're focused on rev-2, I suspect that would be the best place to help contribute. I've been directing my energy at rev-1 because it's the only codebase that I'm aware of at the moment to drive the ErgoDox hardware I just put together. While evaluating media keys, I will have a good opportunity to look at Hasu's code and the PJRC code. If I get it working on rev-1, I can fork rev-2 and try porting it over and get familiarized with the code. It should be a good evaluation to get a feel for whether to maintain rev-1 a while longer or jump into rev-2.

[judascleric]

I've taken a look at Hasu's code. The USB side of it is an abstraction layer wrapping the PJRC code, iWRAP, LUFA, and V-USB. The PJRC code was refactored to fit the interface of the abstraction layer but it's nothing too dramatic. It looks like I'd have to update the USB descriptor to enumerate the additional capabilities and generate and send new report descriptors for media keys and mouse keys.

As a learning experience, I will take usb_extra.c/.h from Hasu's code and try to get it to work on my fork. That will help inform next steps. I don't know whether the PJRC code or the Hasu code is more actively maintained but it seems like Hasu's project is fairly healthy and more in line with the cusomizability and feature set desired for ErgoDox. I think it would be worth taking Hasu's USB stack. I don't think it will be a big change to adapt the top-level code to use his stack instead of the PJRC stack. It should just be a matter of passing a key report struct to the USB stack instead of just setting the keyboard_keys[] and keyboard_modifier_keys globals currently being used.

I think the top-level code for implementing key functions should remain ErgoDox-specific. It seems like ErgoDox doesn't have exactly the same audience as tmk-keyboard firmware. It might be worth trying to merge them at some point but it would be nice to have some freedom to experiment with user-facing functionality for a while.

[judascleric]

I got media keys working on my fork in 513b82d585. I'll put a pull request for review and start to familiarize myself with the partial-rewrite branch.

[benblazak]

Sounds good. If you develop any opinions about it, especially as someone who's dealt with both Hasu's code and my rev. 1, I'd be glad to hear them :) . Even if they're negative (... lol, espeically if they're negative. those are the best kind to learn from).

[benblazak]

Update (for lack of a better place to put it): Rev. 2 is working! :) using it on my keyboard right now. Still bunches to do before I'll consider moving the branch to 'master' though.

[amj]

for lack of a better place to put it -- what are the "bunches to do" -- anything i can help with? I'm currently adapting all the stuff in the v2 branch to my divergent, not-quite-an-ergodox design; to echo judascleric, momentum & motivation are pretty important -- any way i can help out on v2?

[benblazak]

Off the top of my head, the things I really want done before I merge are:

• Write examples of how to create one's own key-functions (including methods for sticky keys, macros, chorded keys, ... probably how to change the meaning of the LEDs, ... and anything else I become aware of in the mean time)
• Write a layout for chordmak - to demonstrate a different way of implementing chorded keys
• Write scripts to read most of the comments from the C code and generate pretty documentation, including a graphical representation of the layout

Things I'd like done, but could probably wait:

• Implement a global get_milliseconds() function, so that key-functions and such can do things based on time (quick double tap of shift for capslock?) (and then I'll probably have to write an example of how to do this too)

Other things I'm thinking about:

• How to implement on-keyboard macro recording + playback (using the EEPROM)
• Whether the USB code needs to be rewritten (half for fun, half to try and figure out what it's doing, ... and half to get the stuff listed in this issue taken care of :) )
• Whether it'd be a good idea to have a vector somewhere of functions that need to be called at certain times - on the next scan cycle, for instance, or maybe in n milliseconds
• Whether it'd even be worth thinking about fixing the TWI code to use interrupts (like a real TWI library, lol)

I forget if there's anything else. My references.md file probably needs to be split up into more searchable sections. I dunno.

Lol, so ya, lots of stuff :) . I really appreciate the offer to help, but seeing as I have a fairly definite idea of how I'd like most things to work, and I will have very definite opinions on the design of the things I haven't completely figured out yet, I'm not sure there's much for anyone else to do. Largely a fault of my personality, I suppose... lol, but for this relatively small project, I'm hoping it'll lead to a more consistent design.

That said, I'd love to link to your project, if you have a link to give out. I'd also really appreciate any feedback you have, especially if there was anything unintuitive that I could do better. No promises :) but it'd be helpful, since I've been working on this for quite a while now, and some things have been in my head so long that I really can't tell whether anyone else would find them obvious or not.

[judascleric]

I've got a routine for timing using TIMER0 overflow interrupt. It lives here https://github.com/judascleric/mousetest/blob/master/controller/teensy-2-0.c. I'm just using an 8 bit static for counting milliseconds that I reset periodically, but it could easily use a 16 or 32 bit counter to reach into the seconds elapsed rate or so.

[judascleric]

As far as TWI library goes, I don't think interrupts make sense on ErgoDox. With the TRRS cable carrying voltage, ground, SDA, and SCL we don't have an extra wire to carry the interrupt signal! I believe the benefit to using interrupts is for power savings, which I don't think is a big concern on ErgoDox.

[benblazak]

Thanks :) . Timer 0 should be good - no sense tying up a higher resolution timer when all we need is millis. I started writing the files a little bit ago, just haven't got to finishing them yet...

As for TWI with interrupts, I meant using the interrupt vectors that the AVR has for various TWI events - but you're probably right about the only real benefit in this application being power reduction, which I don't think is a big concern either.