Suka: Your project is awesome. Jim66, thanks for the original post. If I ever do a keyboard completely by myself, I'm gunna be digging out your link
. Also (in response to some comments on the deskauthority thread), for using a connector between the two halves, have you considered I2C or SPI I/O expanders? It looks like we'll stick with I2C for this project, but if you're willing to accept the extra wire (5 total instead of 4) SPI would be much faster (from experiment, a simple usage of I2C seems to limit the scan rate to ~167Hz IIRC). We have a firmware
(that's not quite done, but should be stable enough) that'll handle I2C, if you didn't want to just add the capability to your own. And if the Teensy has similar hardware support for SPI I doubt it'd be overly hard to add. Anyway, thanks for the write up
Rburrows, tjweir, OrangeJewce: I've been considering dorkvader kind of the official greeter all this time, but I wanted to welcome you too. I'm glad to see people still posting to register interest!
And Dox, I know I'm way late, but I never said how excited I was (am) that we're getting close to first prototype.
About the connector:
Did we loose a few posts? But anyway, the discussion made me think about it even more, and here's a few things I realized (I'll call the MCP23018 side the LH side, and the Teensy side the RH side, for the sake of brevity):
- The LH side isn't connected to anything till we plug it in; so no matter how the contacts are arranged, only one side has power, and we're safe from direct Vcc/GND shorts.
- This makes me think it'd be better to put GND on the sleeve (and probably Vcc on the tip), like dorkvader was talking about. He had better reasons - I just think it'd be more standard, and just as good.
- I found one other project that was using TRRS for I2C. He had it wired (tip to sleeve) SCL, SDA, Vcc, GND, with a resistor on Vcc it looks like (and I don't know if anything else).
- The user will have a choice of which side to plug in first; so no matter how the contacts are arranged:
- Either the LH Vcc pin will be brought low or the LH GND pin will be brought high; or both.
- Would regular diodes on Vcc and GND be able to help us with this? Or is the MCP23018 okay with that? I wasn't able to find it in the datasheet.
- Any RH pin will have a chance of touching any LH pin on each insert; so we need to make sure all the pins will be fine with that.
- We also have to keep in mind that SCL and SDA will be oscillating between logic low and hi-Z with a 2.2kΩ pull-up during insert (unless the RH side isn't plugged in to USB yet).
- I still think we should at least put a current limiting diode (like this one) on the RH Vcc. If you want, it might be extra safe to put a 2mA one on the LH Vcc. Or, since it looks like the MCP23018 can operate at full speed down to at least 2.7V, a current limiting resistor should also work.
- Would it be good to have TVS diodes on all the pins, to protect from ESD? I hadn't thought of that before, but it seems like a good idea to me, if there's room.
About the firmware:
I was wondering if anyone would care to design a QWERTY (and maybe Dvorak?) layout? The current QWERTY layout is rather pathetic, but I just don't feel like putting that much time into it because I'm likely going to neglect both and give Arensito
a serious shot. What I'm thinking, if I can get decent QWERTY and/or Dvorak layouts, is that I'll compile the firmware with all three layouts separately, and post 3 different .hex files for everyone's convenience. If you'd like to take a look, please see the layout documentation file
on github (make sure you're on the 'dev' branch), and let me know if you have any questions.
Partly implied in the above, I'm not currently planning to implement on-keyboard remapping. I'm almost certain it wouldn't be technically hard (it might be almost trivial) with the current design, but I can't think of a good way to do it. The thing is, if you're willing to learn the *smallest* bit about Make and C (or if you already know both; and I'll try to write a little howto before I consider the project done) you'll be able to remap to your heart's content *and* store keymaps much more easily than you could with on-keyboard remapping, and with no extra effort in the firmware. If you're willing to learn a lot (or just a little extra, if you already know C), you'll be able to write new keypress/release functions (all keypresses and releases are function calls) and do most anything you want, which wouldn't be possible at all with other methods. If anyone has some good ideas about how on-keyboard remapping could work though, I'd be interested to hear them; if only because it's a problem I couldn't think of an elegant solution to.
Also, I'm currently working on NKRO. I'd really like to make it work, but I'm not completely sure if I'll have the patience. Is this very important to people?
And if anyone has any other thoughts on the firmware I'd be interested to hear them, since the design is starting to finalize in my head. Not sure what else I'll have the patience/time to implement, but suggestions are always good.
Thanks :) . Sorry this post is so long.