I got it working! I just used the MD1 scan module, modified it a bit, made a new folder, and edited the pinout and default layer. I'm basically using the default settings on the CMakeLists, aside from removing the extra layers, and changing the mcu. Getting the key assignments setup to the wiring I did was a real pain in the ass :/ I also managed to do all of this on windows, mainly because I didn't want to boot a VM every time I wanted to modify something.
I also haven't figured out the key assignments for keypad stuff.
I'd agree with you that Teensy's are a bit of a rip off when the chip probably sells by itself for pennies, the next time I need another one, I might take a look at your boot loader stuff. What I do like about the Teensy is the affordability, and it lowered the barrier to entry for me, but I'm just lazy and don't want to work too hard.
This particular Teensy was my mistake, The first one I bought and, of course, it was the wrong one for the code I wanted it to work with, but just today I've been shown 2 possibilities. The 1st was CAN bus communication with ODBII systems on cars, and the 2nd was this! If I keep the correct pins available, I can have a keypad that I can tear up Osu with, and talk to cars! Or better yet, install osu on the computer in my car! Okay I'm just talking nonsense now.
Alternative controller experiments
-
baked_cake
- Main keyboard: rt101+
- Main mouse: corsair vengeance m90
- Favorite switch: momentary blue alps
- DT Pro Member: -
-
twiddle
- Main keyboard: Shine 3 TLK MX Brown
- Main mouse: Sensei
- Favorite switch: MX Blue
- DT Pro Member: -
There are more parts than usual because of the additional functionality I have on the board for development - I have both a reset and a bootloader button with associated pullups, the status LED and associated transistor as well as the SWD header. The actual circuit as things stand is otherwise just the reference designs indicated in the reference manual for the chip in question (lpc11u35). Aside from the aforementioned optional parts, I'm using an external crystal which also needs load caps so that I can get an accurate 48mhz clock needed for full speed USB. Schematics need a lot of tidying up but I'll post them when the design is settled and I've done the cleanup.
-
twiddle
- Main keyboard: Shine 3 TLK MX Brown
- Main mouse: Sensei
- Favorite switch: MX Blue
- DT Pro Member: -
The controller is currently running in full-speed mode, yes.
Not that it really needs it for a kb, no, but the capability is there on the MCU so I figured I might as well learn to use it - I have some broader plans than just keyboards for these controllers, and this design in and of itself is essentially a teensy without the software library in terms of its flexibility so it didn't seem to make sense to cripple it.
Not that it really needs it for a kb, no, but the capability is there on the MCU so I figured I might as well learn to use it - I have some broader plans than just keyboards for these controllers, and this design in and of itself is essentially a teensy without the software library in terms of its flexibility so it didn't seem to make sense to cripple it.
-
flabbergast
- Location: Southampton, UK
- DT Pro Member: 0120
- Contact:
What do you mean? Pretty much every controller with native USB these days (i.e. everything except the korean atmega32a based boards (face U/W, bface)) uses USB 2.0. Certainly teensy. Not that it makes much difference, except when the boards use a lot of current for LEDs (the koreans get away with 1.1 because computers do not actually enforce the 100mA limitMuirium wrote: ↑Full speed USB? Do you mean something beyond USB 1.1? That would be unusual, to say the least, for a keyboard controller!
-
Muirium
- µ
- Location: Edinburgh, Scotland
- Main keyboard: HHKB Type-S with Bluetooth by Hasu
- Main mouse: Apple Magic Mouse
- Favorite switch: Gotta Try 'Em All
- DT Pro Member: µ
Ah, slippery old USB. Here's what I'm on about:
Mac OS X includes a System Info utility that, among other things, can enumerate the USB devices on your system. Here's my USB 3 equipped laptop running with an iPhone 4S in one port and my HHKB in the other. The iPhone is connected at USB 2 speed (480 Mb/sec) while the HHKB is all the way down at 12 Mb/sec. It's far from the only keyboard I've seen down at USB 1.1 (or even 1.0?) speeds. Most do that. The system can supply a lot more bandwidth, but most keyboards negotiate for a slower connection just like this. Including the MacBook Pro's own integrated (but USB native) keyboard!
- USB Chart.png (102.96 KiB) Viewed 6167 times
-
twiddle
- Main keyboard: Shine 3 TLK MX Brown
- Main mouse: Sensei
- Favorite switch: MX Blue
- DT Pro Member: -
Ah... What you are talking about *is* Full Speed on that HHKB, Muirium.
The spec has the following speeds:
Low Speed (1.5 mbit/s) -> Full Speed (12 mbit/s) -> High Speed (480 mbit/s) -> Super Speed(5gbit/s)
It gets more confusing when you see that both Low and Full Speed were part of USB 1.0, but there are a lot of USB 2.0 devices out there that are actually only Full Speed - USB2 devices have to be marked as a 'USB 2.0 High Speed' controller in order to actually support the 480mbit data rate. If it doesn't explicitly state it, it's Full Speed despite being a USB2 device. As a result, 'Full Speed' sits in a funny spot where technically it is USB1.0 but in practical terms it really sits in both USB1.0 and USB2.0.
The spec has the following speeds:
Low Speed (1.5 mbit/s) -> Full Speed (12 mbit/s) -> High Speed (480 mbit/s) -> Super Speed(5gbit/s)
It gets more confusing when you see that both Low and Full Speed were part of USB 1.0, but there are a lot of USB 2.0 devices out there that are actually only Full Speed - USB2 devices have to be marked as a 'USB 2.0 High Speed' controller in order to actually support the 480mbit data rate. If it doesn't explicitly state it, it's Full Speed despite being a USB2 device. As a result, 'Full Speed' sits in a funny spot where technically it is USB1.0 but in practical terms it really sits in both USB1.0 and USB2.0.
-
flabbergast
- Location: Southampton, UK
- DT Pro Member: 0120
- Contact:
Sorry, apparently I had it wrong as well. I didn't realise that full speed (12) was allowed also within USB 1.1 specification. TIL that 500mA is also allowed in 1.1.
It looks like keyboards invariably use at most full-speed (12). [The korean boards can actually only do low-speed, i.e. 1.5Mb/s - still plenty enough for a keyboard though.]
This is largely irrelevant for the actual capabilities (so I'm just indulging in a pointless banter), but what I meant is whether the devices (claim to) conform to USB 1.1 spec or USB 2.0 spec (regardless of the speed they're using). This is not possible to see from OS X's utility (which is one of my gripes with it). The atmega32u4 and the new fancy ARM chips are certainly capable of conforming to USB 2.0, although they only support full-speed (12). For instance in TMK one can set whether it's supposed to pretend to be 1.1 or 2.0 (as I admitted - not that it makes any difference).
It looks like keyboards invariably use at most full-speed (12). [The korean boards can actually only do low-speed, i.e. 1.5Mb/s - still plenty enough for a keyboard though.]
This is largely irrelevant for the actual capabilities (so I'm just indulging in a pointless banter), but what I meant is whether the devices (claim to) conform to USB 1.1 spec or USB 2.0 spec (regardless of the speed they're using). This is not possible to see from OS X's utility (which is one of my gripes with it). The atmega32u4 and the new fancy ARM chips are certainly capable of conforming to USB 2.0, although they only support full-speed (12). For instance in TMK one can set whether it's supposed to pretend to be 1.1 or 2.0 (as I admitted - not that it makes any difference).
-
twiddle
- Main keyboard: Shine 3 TLK MX Brown
- Main mouse: Sensei
- Favorite switch: MX Blue
- DT Pro Member: -
To further elaborate, one reason (aside from the cost of chips with high-speed controller support) that most kbs don't go beyond USB-FS is that when you're talking 480mbit/s you're dealing with very high frequency signals. This means you need to match impedances and trace lengths etc to a much tinier tolerance than for Low/Full-speed. It also means that if you want to make a commercial product and sell it into the US you start to get to a point where the frequency of those signals makes you an 'unintentional emitter' and you have to pass FCC checks for EMF which are expensive.
It isn't an exact comparison, but on the tangent of the cost difference, here's a High-speed controller compared with a Full-speed one:
http://au.element14.com/freescale-semic ... dp/2133639
http://au.element14.com/freescale-semic ... dp/2133572
You get so much extra stuff with the High-speed controller it ends up being overkill - 100 i/o pins, 1MB flash, 3x the chip frequency, etc etc. While it would be fun to over-engineer a keyboard and add in additional functionality, from a commercial standpoint it doesnt make much sense.
It isn't an exact comparison, but on the tangent of the cost difference, here's a High-speed controller compared with a Full-speed one:
http://au.element14.com/freescale-semic ... dp/2133639
http://au.element14.com/freescale-semic ... dp/2133572
You get so much extra stuff with the High-speed controller it ends up being overkill - 100 i/o pins, 1MB flash, 3x the chip frequency, etc etc. While it would be fun to over-engineer a keyboard and add in additional functionality, from a commercial standpoint it doesnt make much sense.
-
vvp
- Main keyboard: Katy/K84CS
- Main mouse: symetric 5-buttons + wheel
- Favorite switch: Cherry MX
- DT Pro Member: -
Muirium, if you have some linux then:
- to get usb version:
Code: Select all
lsusb -v 2>/dev/null |grep -E '^(Bus| bcdUSB)' - to get the bus speed:
Code: Select all
lsusb -t
-
Muirium
- µ
- Location: Edinburgh, Scotland
- Main keyboard: HHKB Type-S with Bluetooth by Hasu
- Main mouse: Apple Magic Mouse
- Favorite switch: Gotta Try 'Em All
- DT Pro Member: µ
Linux? Nah. According to this, however, the built in ioreg function can list the USB goodies in greater depth than the System Profiler GUI, like so:
ioreg -p IOUSB -l -w 0
If that's not good enough for you, someone built a Mac port of lsusb I could be badgered to install if really necessary. Which it isn't, as we're all cool with the low speed USB shenanigans of keyboard controllers now…
ioreg -p IOUSB -l -w 0
Code: Select all
+-o XHCI Root Hub SS Simulation@14 <class IOUSBRootHubDevice, id 0x1000002bc, registered, matched, active, busy 0 (2 ms), retain 11>
| | {
| | "sessionID" = 1499188089
| | "Low Power Displayed" = No
| | "AAPL,current-extra-in-sleep" = 1600
| | "idProduct" = 32775
| | "bNumConfigurations" = 1
| | "iManufacturer" = 2
| | "bcdDevice" = 768
| | "Bus Power Available" = 450
| | "bMaxPacketSize0" = 9
| | "USB Product Name" = "XHCI Root Hub SS Simulation"
| | "iProduct" = 1
| | "iSerialNumber" = 0
| | "bDeviceClass" = 9
| | "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| | "bDeviceSubClass" = 0
| | "USB Address" = 128
| | "bcdUSB" = 768
| | "locationID" = 352321536
| | "AAPL,current-extra" = 2200
| | "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| | "AAPL,current-available" = 2100
| | "bDeviceProtocol" = 3
| | "AAPL,max-port-current-in-sleep" = 2100
| | "Ports" = 6
| | "USB Vendor Name" = "Apple Inc."
| | "Device Speed" = 3
| | "idVendor" = 1452
| | "PortNumberOffset" = 15
| | "Requested Power" = 0
| | "IOGeneralInterest" = "IOCommand is not serializable"
| | "AAPL,standard-port-current-in-sleep" = 900
| | }
| |
| +-o Card Reader@15400000 <class IOUSBDevice, id 0x1000002e7, registered, matched, active, busy 0 (133 ms), retain 9>
| {
| "sessionID" = 2403252974
| "idProduct" = 33798
| "bNumConfigurations" = 1
| "iManufacturer" = 3
| "bcdDevice" = 2080
| "Bus Power Available" = 450
| "bMaxPacketSize0" = 9
| "USB Product Name" = "Internal Memory Card Reader"
| "iProduct" = 4
| "iSerialNumber" = 5
| "bDeviceClass" = 0
| "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| "bDeviceSubClass" = 0
| "USB Address" = 5
| "bcdUSB" = 768
| "locationID" = 356515840
| "PortNum" = 4
| "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| "Built-In" = Yes
| "bDeviceProtocol" = 0
| "non-removable" = "yes"
| "uid" = "USB:05AC8406000000000820"
| "kHasMSCInterface" = Yes
| "USB Vendor Name" = "Apple"
| "Device Speed" = 3
| "idVendor" = 1452
| "PortNumberOffset" = 15
| "USB Serial Number" = "000000000820"
| "Requested Power" = 448
| "IOGeneralInterest" = "IOCommand is not serializable"
| "Low Power Displayed" = No
| }
|
+-o XHCI Root Hub USB 2.0 Simulation@14 <class IOUSBRootHubDevice, id 0x1000002c0, registered, matched, active, busy 0 (5 ms), retain 17>
| {
| "sessionID" = 1502114849
| "Low Power Displayed" = No
| "AAPL,current-extra-in-sleep" = 1600
| "idProduct" = 32775
| "bNumConfigurations" = 1
| "iManufacturer" = 2
| "bcdDevice" = 768
| "Bus Power Available" = 250
| "bMaxPacketSize0" = 9
| "USB Product Name" = "XHCI Root Hub USB 2.0 Simulation"
| "iProduct" = 1
| "iSerialNumber" = 0
| "bDeviceClass" = 9
| "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| "bDeviceSubClass" = 0
| "USB Address" = 129
| "bcdUSB" = 512
| "locationID" = 335544320
| "AAPL,current-extra" = 2200
| "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| "AAPL,current-available" = 2100
| "bDeviceProtocol" = 1
| "AAPL,max-port-current-in-sleep" = 2100
| "Ports" = 14
| "USB Vendor Name" = "Apple Inc."
| "Device Speed" = 2
| "idVendor" = 1452
| "PortNumberOffset" = 0
| "Requested Power" = 0
| "IOGeneralInterest" = "IOCommand is not serializable"
| "AAPL,standard-port-current-in-sleep" = 500
| }
|
+-o Apple Internal Keyboard / Trackpad@14c00000 <class IOUSBDevice, id 0x1000002fb, registered, matched, active, busy 0 (240 ms), retain 14>
| {
| "sessionID" = 2606426035
| "idProduct" = 610
| "bNumConfigurations" = 1
| "iManufacturer" = 1
| "bcdDevice" = 549
| "Bus Power Available" = 250
| "bMaxPacketSize0" = 8
| "USB Product Name" = "Apple Internal Keyboard / Trackpad"
| "iProduct" = 2
| "iSerialNumber" = 0
| "USB Address" = 3
| "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| "bDeviceSubClass" = 0
| "bDeviceClass" = 0
| "bcdUSB" = 512
| "locationID" = 348127232
| "PortNum" = 12
| "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| "Built-In" = Yes
| "bDeviceProtocol" = 0
| "non-removable" = "yes"
| "USB Vendor Name" = "Apple Inc."
| "Device Speed" = 1
| "idVendor" = 1452
| "PortNumberOffset" = 0
| "ExtendedData" = (50399521,50465057)
| "Requested Power" = 20
| "IOGeneralInterest" = "IOCommand is not serializable"
| "Low Power Displayed" = No
| }
|
+-o BRCM20702 Hub@14800000 <class IOUSBHubDevice, id 0x100000345, registered, matched, active, busy 0 (4 ms), retain 11>
| | {
| | "sessionID" = 2804714262
| | "AAPL,standard-port-current-in-sleep" = 500
| | "idProduct" = 17664
| | "bNumConfigurations" = 1
| | "iManufacturer" = 1
| | "bcdDevice" = 256
| | "Bus Power Available" = 250
| | "bMaxPacketSize0" = 8
| | "USB Product Name" = "BRCM20702 Hub"
| | "iProduct" = 2
| | "iSerialNumber" = 0
| | "USB Address" = 4
| | "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| | "bDeviceSubClass" = 0
| | "bDeviceClass" = 9
| | "bcdUSB" = 512
| | "locationID" = 343932928
| | "PortNum" = 8
| | "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| | "Built-In" = Yes
| | "bDeviceProtocol" = 0
| | "non-removable" = "yes"
| | "Ports" = 3
| | "USB Vendor Name" = "Apple Inc."
| | "Device Speed" = 1
| | "idVendor" = 2652
| | "PortNumberOffset" = 0
| | "Requested Power" = 47
| | "IOGeneralInterest" = "IOCommand is not serializable"
| | "Low Power Displayed" = No
| | }
| |
| +-o Bluetooth USB Host Controller@14830000 <class IOUSBDevice, id 0x100000398, registered, matched, active, busy 0 (4 ms), retain 12>
| {
| "sessionID" = 3183117365
| "idProduct" = 33417
| "bNumConfigurations" = 1
| "iManufacturer" = 1
| "bcdDevice" = 259
| "Bus Power Available" = 250
| "bMaxPacketSize0" = 64
| "USB Product Name" = "Bluetooth USB Host Controller"
| "iProduct" = 2
| "iSerialNumber" = 0
| "USB Address" = 6
| "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| "bDeviceSubClass" = 1
| "bDeviceClass" = 255
| "bcdUSB" = 512
| "locationID" = 344129536
| "PortNum" = 3
| "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| "Built-In" = Yes
| "bDeviceProtocol" = 1
| "non-removable" = "yes"
| "USB Vendor Name" = "Apple Inc."
| "Device Speed" = 1
| "idVendor" = 1452
| "Requested Power" = 0
| "IOGeneralInterest" = "IOCommand is not serializable"
| "Low Power Displayed" = No
| }
|
+-o iPhone@14500000 <class IOUSBDevice, id 0x100001263, registered, matched, active, busy 0 (146 ms), retain 13>
| {
| "sessionID" = 12517505748675
| "PortUsingExtraPowerForSleep" = 1000
| "idProduct" = 4768
| "bNumConfigurations" = 4
| "iManufacturer" = 1
| "bcdDevice" = 1040
| "Bus Power Available" = 250
| "bMaxPacketSize0" = 64
| "USB Product Name" = "iPhone"
| "iProduct" = 2
| "iSerialNumber" = 3
| "bDeviceClass" = 0
| "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| "bDeviceSubClass" = 0
| "USB Address" = 31
| "bcdUSB" = 512
| "locationID" = 340787200
| "PortNum" = 5
| "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| "SupportsIPhoneOS" = Yes
| "bDeviceProtocol" = 0
| "Preferred Configuration" = 3
| "PortUsingExtraPowerForWake" = 500
| "USB Vendor Name" = "Apple Inc."
| "Device Speed" = 2
| "idVendor" = 1452
| "PortNumberOffset" = 0
| "USB Serial Number" = "af3a46c60b555f85ffd4292b4d411f5fbbe9b82d"
| "IOGeneralInterest" = "IOCommand is not serializable"
| "Requested Power" = 250
| "kCallInterfaceOpenWithGate" = Yes
| "Low Power Displayed" = No
| }
|
+-o HubDevice@14100000 <class IOUSBHubDevice, id 0x1000012b2, registered, matched, active, busy 0 (6 ms), retain 11>
| {
| "sessionID" = 12720613171712
| "iManufacturer" = 0
| "bNumConfigurations" = 1
| "idProduct" = 90
| "bcdDevice" = 256
| "Bus Power Available" = 250
| "bMaxPacketSize0" = 64
| "iProduct" = 0
| "iSerialNumber" = 0
| "USB Address" = 2
| "bDeviceClass" = 9
| "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| "bDeviceSubClass" = 0
| "locationID" = 336592896
| "bcdUSB" = 512
| "ExpressCardCantWake" = Yes
| "PortNum" = 1
| "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| "Ports" = 3
| "bDeviceProtocol" = 1
| "Device Speed" = 2
| "idVendor" = 1033
| "PortNumberOffset" = 0
| "Requested Power" = 50
| "Low Power Displayed" = No
| }
|
+-o HHKB Professional@14110000 <class IOUSBDevice, id 0x1000012bb, registered, matched, active, busy 0 (82 ms), retain 10>
{
"sessionID" = 12720865950447
"idProduct" = 256
"bNumConfigurations" = 1
"iManufacturer" = 1
"bcdDevice" = 258
"Bus Power Available" = 50
"bMaxPacketSize0" = 8
"USB Product Name" = "HHKB Professional"
"iProduct" = 2
"iSerialNumber" = 0
"USB Address" = 9
"IOUserClientClass" = "IOUSBDeviceUserClientV2"
"bDeviceSubClass" = 0
"bDeviceClass" = 0
"bcdUSB" = 272
"locationID" = 336658432
"PortNum" = 1
"IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
"non-removable" = "yes"
"bDeviceProtocol" = 0
"USB Vendor Name" = "Topre Corporation"
"Device Speed" = 1
"idVendor" = 2131
"Requested Power" = 50
"IOGeneralInterest" = "IOCommand is not serializable"
"Low Power Displayed" = No
}
-
flabbergast
- Location: Southampton, UK
- DT Pro Member: 0120
- Contact:
To elaborate my pointless contributions, the "bcdUSB" is the USB version number the device is claiming to use (binary-packed-decimal). So: 272 -> 1.1; 512 -> 2.0; 768 -> 3.0. E.g. your iphone is using USB 2.0, and HHKB is 1.1.
-
Muirium
- µ
- Location: Edinburgh, Scotland
- Main keyboard: HHKB Type-S with Bluetooth by Hasu
- Main mouse: Apple Magic Mouse
- Favorite switch: Gotta Try 'Em All
- DT Pro Member: µ
Yeah, that squares with the bandwidth figures in the GUI. Off the top of my head, all these keyboards and controllers are USB 1.1: CM NovaTouch, Ducky Shine 3, Soarer's Controller/Converter, Xwhatsit's Controller, Matias Ergo Pro, HHKB, Topre Realforce, and Apple's own. That includes a few boards with integrated USB 2 hubs: the hubs are USB 2, but the boards controllers still attach as USB 1.1. Think I saw one USB 2 native daredevil recently though. Perhaps it was the Cherry MX Board 6.0. I'll check it when I'm next home. Only got the HHKB with me.
-
hbar
- Location: Germany
- Main keyboard: ħα
- Main mouse: ħα
- Favorite switch: Campagnolo Ergopower
- DT Pro Member: -
Just for reference, the CM Novatouch uses an MSP430F5510 controller from TI, which, according to the datasheet, is compliant with USB 2.0 but doesn't support high-speed transfers (which is unnecessary for a keyboard anyway). I'm not quite sure what the differences are between USB 1.1 and 2.0 other than the high-speed mode (I used to know -- maybe the size of a single bulk transfer can be up to 512 bytes in 2.0 but only 64 bytes in 1.1?), but they are certainly irrelevant for a keyboard. Identifying your keyboard as USB 1.1 seems to be a good idea in my view just in case some braindead piece of software or hardware expects a keyboard to use USB versions before 2.0. (It's the same reason you shouldn't create a DVD-video directory structure on a CD-ROM, even if many software players can deal with it, because many standalone devices wouldn't even try.)
That being said, I fully support any move away from AVR to a better platform, ARM probably being the easiest to agree upon. I don't think, however, that a move to PIC is a step in the right direction, and I don't know Freescale so I can't judge it. I do, however, know MSP430, and that is the one I would personally go for.
Are there plans for porting tmk_keyboard to another platform, anyway? If so, I would certainly vouch for the MSP430 as a good candidate.
ħ
That being said, I fully support any move away from AVR to a better platform, ARM probably being the easiest to agree upon. I don't think, however, that a move to PIC is a step in the right direction, and I don't know Freescale so I can't judge it. I do, however, know MSP430, and that is the one I would personally go for.
Are there plans for porting tmk_keyboard to another platform, anyway? If so, I would certainly vouch for the MSP430 as a good candidate.
ħ
Last edited by hbar on 05 Jul 2015, 11:07, edited 2 times in total.
-
Halvar
- Location: Baden, DE
- Main keyboard: IBM Model M SSK / Filco MT 2
- Favorite switch: Beam & buckling spring, Monterey, MX Brown
- DT Pro Member: 0051
There are plans I think to port the TMK controller to Teensy 3.1 which uses an ARM Cortex-M4 SoC.
Is there a compact breakout board that's comparable to the Teensy available with the TI MSP430? I don't know much about the TI line of microcontrollers.
Is there a compact breakout board that's comparable to the Teensy available with the TI MSP430? I don't know much about the TI line of microcontrollers.
Last edited by Halvar on 03 Jul 2015, 12:07, edited 1 time in total.
-
Muirium
- µ
- Location: Edinburgh, Scotland
- Main keyboard: HHKB Type-S with Bluetooth by Hasu
- Main mouse: Apple Magic Mouse
- Favorite switch: Gotta Try 'Em All
- DT Pro Member: µ
You vouch for it because you're familiar with it?
I wouldn't trust Freescale to find the arse end of a pair of trousers. They were miserably shit at making CPUs back in the G4 days before Apple shitcanned them.
Seriously: ARM.
Edit: Oh right, TI. Well, that's a step up at least. But still. Seriously: ARM. No point going from one costly yet low end ISA to another when ARM has the mainstream mass and momentum.
I wouldn't trust Freescale to find the arse end of a pair of trousers. They were miserably shit at making CPUs back in the G4 days before Apple shitcanned them.
Seriously: ARM.
Edit: Oh right, TI. Well, that's a step up at least. But still. Seriously: ARM. No point going from one costly yet low end ISA to another when ARM has the mainstream mass and momentum.
-
twiddle
- Main keyboard: Shine 3 TLK MX Brown
- Main mouse: Sensei
- Favorite switch: MX Blue
- DT Pro Member: -
Thing is, the value in your descriptors that specifies your USB version is by and large irrelevant. The primary thing that hardware uses to determine the speed of transfers is by detecting pullups on a d+ or d- line, and optionally giving a k-chirp to the host to signify high-speed. On that basis I don't really see any problems with listing controllers as using usb2, myself.
Personally I won't be investigating MSP430, though it was a platform I initially considered. This is primarily because the ARM ecosystem means that my knowledge gained is much more portable, as well as the fact my existing hardware debugging setup (the J-link in the picture above) is arm-only, though it works with just about every manufacturer's arm chips I can think of so I dont need to worry as much about vendor lock-in. When I finish evaluating my current crop of prototypes and select a manufacturer, I'll be hopefully incorporating a HAL of sorts so that the firmware can be more easily ported to other ARM mcus in the same way mbed does.
Regardless I am appreciative of you confirming the novatouch's controller, hbar. I am sort of suprised to be honest, I would have expected Holtek (ducky et al) to be much more competitive price-wise, as an example, at the quantities CM would be purchasing.
Personally I won't be investigating MSP430, though it was a platform I initially considered. This is primarily because the ARM ecosystem means that my knowledge gained is much more portable, as well as the fact my existing hardware debugging setup (the J-link in the picture above) is arm-only, though it works with just about every manufacturer's arm chips I can think of so I dont need to worry as much about vendor lock-in. When I finish evaluating my current crop of prototypes and select a manufacturer, I'll be hopefully incorporating a HAL of sorts so that the firmware can be more easily ported to other ARM mcus in the same way mbed does.
Regardless I am appreciative of you confirming the novatouch's controller, hbar. I am sort of suprised to be honest, I would have expected Holtek (ducky et al) to be much more competitive price-wise, as an example, at the quantities CM would be purchasing.
When I talk Freescale I am exclusively referring to their Kinetis line of ARM microcontrollers, which are much different to the old Motorola stuff. Not sure if hbar means their 8bit or these 32bit arm chips. All the teensys use Freescale ARM chips, so make of that what you will.Muirium wrote: ↑You vouch for it because you're familiar with it?
I wouldn't trust Freescale to find the arse end of a pair of trousers. They were miserably shit at making CPUs back in the G4 days before Apple shitcanned them.
Seriously: ARM.
-
twiddle
- Main keyboard: Shine 3 TLK MX Brown
- Main mouse: Sensei
- Favorite switch: MX Blue
- DT Pro Member: -
The TI Launchpads are hardly compact but do have a fair few features. They're no good for keyboard controllers due to their size, but 'development boards' as that form factor is known in general are quite useful for learning a platform's capabilities, and they're used as loss leaders by the manufacturers so are really quite cheap. Nucleo boards from STM are 10-15 AUD mostly, even on comparatively powerful cortex chips like CM4s.Halvar wrote: ↑There are plans I think to port the TMK controller to Teensy 3.1 which uses an ARM Cortex-M4 SoC.
Is there a compact breakout board that's comparable to the Teensy available with the TI MSP430? I don't know much about the TI line of microcontrollers.
-
hbar
- Location: Germany
- Main keyboard: ħα
- Main mouse: ħα
- Favorite switch: Campagnolo Ergopower
- DT Pro Member: -
Yes, I know MSP430 and that's why. I also know a whole bunch of other architectures, and if I were to start a new project now without any constraints, it would either be ARM, or MSP430 for truly low-power applications. Both are a joy to program (in assembly), which can't be said of any of the others that I know.
Since I imagine that more and more custom builds will be wireless in the future, I would think that power consumption should have very high priority in selecting a platform. I'm not quite sure (haven't built anything with ARM recently) but I think MSP430 still delivers lower "idle" power in a constantly-scanning keyboard controller than ARM, but that needs to be verified. Also, the MSP430 offers a built-in USB bootloader (just like the ATmega32U4), which means that users can program their new custom keyboard without any dedicated hardware. Should tmk_keyboard be ported to ARM, we need to make sure that there are compatible chips out there that contain such bootloader code from the factory. (I'm not sure what the Teensy 3.1 uses, is that a PRJC-specific boot code, like on the ATmega?)
It is equally important, however, that hardware access to the keyboard shall be required in order to invoke the bootloader (for security). ATmega32U4 and MSP430 do it right, Cypress doesn't (EZ-USB family). Just one thing to keep in mind before selecting any new platform.
If ARM can tick the right boxes, then I agree that it's the way to go.
ħ
Since I imagine that more and more custom builds will be wireless in the future, I would think that power consumption should have very high priority in selecting a platform. I'm not quite sure (haven't built anything with ARM recently) but I think MSP430 still delivers lower "idle" power in a constantly-scanning keyboard controller than ARM, but that needs to be verified. Also, the MSP430 offers a built-in USB bootloader (just like the ATmega32U4), which means that users can program their new custom keyboard without any dedicated hardware. Should tmk_keyboard be ported to ARM, we need to make sure that there are compatible chips out there that contain such bootloader code from the factory. (I'm not sure what the Teensy 3.1 uses, is that a PRJC-specific boot code, like on the ATmega?)
It is equally important, however, that hardware access to the keyboard shall be required in order to invoke the bootloader (for security). ATmega32U4 and MSP430 do it right, Cypress doesn't (EZ-USB family). Just one thing to keep in mind before selecting any new platform.
If ARM can tick the right boxes, then I agree that it's the way to go.
ħ
-
twiddle
- Main keyboard: Shine 3 TLK MX Brown
- Main mouse: Sensei
- Favorite switch: MX Blue
- DT Pro Member: -
NXP devices have an onboard USB bootloader that shows up as a mass storage device when physically connected under certain circumstances. STM and Freescale use custom HID/DFU based protocols for their bootloader, but you can also install a USB MSC bootloader on them. Normally you have to pull a specific pin to logic low to enter these bootloaders which implies physical access. I dont intend to enable OTA firmware updates on any BT designs I implement.
Cortex-M0+ has very low idle consumption and can be put into an optimised low power sleep state on some parts as well. I'll be running some tests when I have my prototypes all functional to ensure power consumption remains at the level I want it to be.
Cortex-M0+ has very low idle consumption and can be put into an optimised low power sleep state on some parts as well. I'll be running some tests when I have my prototypes all functional to ensure power consumption remains at the level I want it to be.
-
flabbergast
- Location: Southampton, UK
- DT Pro Member: 0120
- Contact:
My observations:
- TMK has been ported to Freescale Kinetis K20 line (the makefiles are set up to use MK20DX128VLF5, teensy uses mk20dx128vfh5 which should make no difference to the actual code). It uses mbed libraries (look for 'infinity' in tmk sources).
- Freescale Kinetis K20 line does not come with any bootloader, and no extra space to put it. So haata (infinity keyboard) has coded one, it just resides at the beginning of the 'normal' flash, and all code then has to be compiled to start after it.
- Teensy 3.x line uses an extra chip (I think from Holtek) that serves as a "bootloader", i.e. flashing firmware should be happening, teensy_loader makes sure that that chip takes over, receives new firmware and writes it to the main K20 chip. That part of Teensy is "closed". You can buy just these chips from PJRC, but it's expensive.
- One reason I like STM32 is that they do come with a hardware bootloader, which is activated by pulling a certain pin high during reset.
- ARM is fun, but one thing I found out is that the code (especially higher level than assembly, e.g. C) is usually not really portable between different manufacturers. The main reason is that most code I've seen uses some kind of (usually manufacturer supplied, but not always) HAL. There are some open source libs which provide HAL for different chips (e.g. chibios, freertos, libopencm3, mbed) but none of these cover all the main families to my satisfaction (Freescale Kinetis, STM32, LPC, Cypress).
- Coding in assembly to make the code portable is also not really an option for keyboards, because hardware USB support is different for different manufacturers (I think).
- I know absolutely nothing about MSP430
- I don't know enough about power consumption to contribute. Of course all chips these days advertise as being "low power", but that can (and usually does) means different thing for different manufacturers. AVR chips are also good for "low power" if one takes this to mean that there is a "deep sleep" mode which consumes next to nothing. But this is of course not what would matter for keyboards ...
- Yea but overall I agree with Muirium that ARM is a way to go. There's enough competition now that the chips are still likely to see improvements; and even now they're quite nice. However which ARM in particular is probably a matter of taste.
EDIT: Oh man, again overtaken.
- TMK has been ported to Freescale Kinetis K20 line (the makefiles are set up to use MK20DX128VLF5, teensy uses mk20dx128vfh5 which should make no difference to the actual code). It uses mbed libraries (look for 'infinity' in tmk sources).
- Freescale Kinetis K20 line does not come with any bootloader, and no extra space to put it. So haata (infinity keyboard) has coded one, it just resides at the beginning of the 'normal' flash, and all code then has to be compiled to start after it.
- Teensy 3.x line uses an extra chip (I think from Holtek) that serves as a "bootloader", i.e. flashing firmware should be happening, teensy_loader makes sure that that chip takes over, receives new firmware and writes it to the main K20 chip. That part of Teensy is "closed". You can buy just these chips from PJRC, but it's expensive.
- One reason I like STM32 is that they do come with a hardware bootloader, which is activated by pulling a certain pin high during reset.
- ARM is fun, but one thing I found out is that the code (especially higher level than assembly, e.g. C) is usually not really portable between different manufacturers. The main reason is that most code I've seen uses some kind of (usually manufacturer supplied, but not always) HAL. There are some open source libs which provide HAL for different chips (e.g. chibios, freertos, libopencm3, mbed) but none of these cover all the main families to my satisfaction (Freescale Kinetis, STM32, LPC, Cypress).
- Coding in assembly to make the code portable is also not really an option for keyboards, because hardware USB support is different for different manufacturers (I think).
- I know absolutely nothing about MSP430
- I don't know enough about power consumption to contribute. Of course all chips these days advertise as being "low power", but that can (and usually does) means different thing for different manufacturers. AVR chips are also good for "low power" if one takes this to mean that there is a "deep sleep" mode which consumes next to nothing. But this is of course not what would matter for keyboards ...
- Yea but overall I agree with Muirium that ARM is a way to go. There's enough competition now that the chips are still likely to see improvements; and even now they're quite nice. However which ARM in particular is probably a matter of taste.
EDIT: Oh man, again overtaken.
-
hbar
- Location: Germany
- Main keyboard: ħα
- Main mouse: ħα
- Favorite switch: Campagnolo Ergopower
- DT Pro Member: -
That's good to know. I spotted some ARM bits in the code, but given that it doesn't occur in many places/keyboards, I thought that was an experiment and not ready for production.flabbergast wrote: ↑ - TMK has been ported to Freescale Kinetis K20 line (the makefiles are set up to use MK20DX128VLF5, teensy uses mk20dx128vfh5 which should make no difference to the actual code). It uses mbed libraries (look for 'infinity' in tmk sources).
That's OK, but the bootloader still has to be written at one stage, which requires a JTAG unit.flabbergast wrote: ↑ - Freescale Kinetis K20 line does not come with any bootloader, and no extra space to put it. So haata (infinity keyboard) has coded one, it just resides at the beginning of the 'normal' flash, and all code then has to be compiled to start after it.
Great Scot, this makes it a real mess. I agree on your preference of STM32 for this reason.flabbergast wrote: ↑ - Teensy 3.x line uses an extra chip (I think from Holtek) that serves as a "bootloader", i.e. flashing firmware should be happening, teensy_loader makes sure that that chip takes over, receives new firmware and writes it to the main K20 chip. That part of Teensy is "closed". You can buy just these chips from PJRC, but it's expensive.
You must bear in mind that, as far as the user is concerned, ARM is merely an instruction set. Each device family which uses ARM cores (ST, NXP, TI, Analog Devices, etc.) typically has their own I/O handling. For GPIO, it isn't too bad to support more than one of these, but it gets rather messy for such things as USB.flabbergast wrote: ↑ - ARM is fun, but one thing I found out is that the code (especially higher level than assembly, e.g. C) is usually not really portable between different manufacturers.
Using ARM would mean that C and assembly are exactly equally portable. That's the only extra "portability" you'll get with ARM compared to other platforms.flabbergast wrote: ↑ - Coding in assembly to make the code portable is also not really an option for keyboards, because hardware USB support is different for different manufacturers (I think).
ħ
-
hbar
- Location: Germany
- Main keyboard: ħα
- Main mouse: ħα
- Favorite switch: Campagnolo Ergopower
- DT Pro Member: -
One more thing to consider is, of course, cost. The STM32 used on the smallest Olimex board is listed on Mouser at around €14, the MSP430F5510 at only €4.
The more I think about it, the more I'm convinced it's all about what USB code is there to be maintained in the long run, since each manufacturer has their own interface. BTW, TI has an application note and code for a USB keyboard device, that could make a good starting point.
ħ
The more I think about it, the more I'm convinced it's all about what USB code is there to be maintained in the long run, since each manufacturer has their own interface. BTW, TI has an application note and code for a USB keyboard device, that could make a good starting point.
ħ
-
flabbergast
- Location: Southampton, UK
- DT Pro Member: 0120
- Contact:
Well, not necessarily JTAG, SWD is OK as well, so I think with some trickery you can make do with something like st-link (a clone of which can be bought from China for something like £2). But you're right that it does require an extra piece of hardware.hbar wrote: ↑That's OK, but the bootloader still has to be written at one stage, which requires a JTAG unit.flabbergast wrote: ↑ - Freescale Kinetis K20 line does not come with any bootloader, and no extra space to put it. So haata (infinity keyboard) has coded one, it just resides at the beginning of the 'normal' flash, and all code then has to be compiled to start after it.
Well, twiddle wrote above that NXP chips (LPC*) also come with a "hardware" bootloader, so that's good as well. (For me it comes down to crystal/no crystal, and in this category STM32 wins so far. But I suppose NXP will come soon with their own chips capable of crystal-less USB.)hbar wrote: ↑Great Scot, this makes it a real mess. I agree on your preference of STM32 for this reason.flabbergast wrote: ↑ - Teensy 3.x line uses an extra chip (I think from Holtek) that serves as a "bootloader", i.e. flashing firmware should be happening, teensy_loader makes sure that that chip takes over, receives new firmware and writes it to the main K20 chip. That part of Teensy is "closed". You can buy just these chips from PJRC, but it's expensive.
By the way - I didn't know that atmega32u4 come with a factory bootloader. But that's tangential to the discussion
-
twiddle
- Main keyboard: Shine 3 TLK MX Brown
- Main mouse: Sensei
- Favorite switch: MX Blue
- DT Pro Member: -
No choice here, most Cortex parts only support SWD from what I've encountered. To be honest - I posted on some EE forums a while back and the overwhelming response was 'just get a J-link EDU and you'll be set for life' - 80 AUD later I don't regret it one bit. Basically supports both JTAG and SWD for just about any major ARM licensee's entire range. So far have used it on all three manufacturers I've tested (STM, NXP, Freescale).
You do however also have the option of OpenOCD and a bus pirate for something more versatile that would help you bootstrap. Nucleo boards can be used to program other STM chips, too, for example, most other development boards are the same.
By all means look into some MSP430 stuff for another kb, hbar, I would like to get some alternatives going and it would be good to see others investigating too
I will be sticking with ARM simply because my R+D costs are too high now to justify jumping ship before I see things through, but more options for everybody is the whole point of what I've been doing here.-
flabbergast
- Location: Southampton, UK
- DT Pro Member: 0120
- Contact:
Every manufacturer these days makes "cheap" evaluation boards. For Freescale Kinetis and STM32, they're about €10 (they're called stm32-nucleo or stm32 discovery kit). On this field, MSP430 wins across the board.hbar wrote: ↑One more thing to consider is, of course, cost. The STM32 used on the smallest Olimex board is listed on Mouser at around €14, the MSP430F5510 at only €4.
But I've had a quick look at farnell's prices for chips themselves, and they're priced more-less the same (range £2.50 - £4 depending on package and capabilities).
Yes, this is my main worry.hbar wrote: ↑ The more I think about it, the more I'm convinced it's all about what USB code is there to be maintained in the long run, since each manufacturer has their own interface. BTW, TI has an application note and code for a USB keyboard device, that could make a good starting point.
However once you choose a chip line (be it Freescale Kinetis, STM32F0x2, NXP LPC???) you can find a library w/HAL (or also manufacturer examples, but I wouldn't want to start with those) that has USB examples. (Also, twiddle opted to write one himself for NXP ...)
I've had a look at ChibiOS and libopencm3 examples, and they work fine. Both are open source and have some communities around. But I didn't get beyond compiling examples and trying them out on actual boards, since it would require investing time into learning another HAL and syntaxes and I'm not convinced myself that I want to use them
(Once I tried to write a USB HAL library for AVR XMEGA line of chips, starting from someone elses not-really-working code and the datasheet. I succeeded in the end, but USB was a real b*tch to debug. But at least now I have an appreciation of what goes into that kind of thing, and I know I would much rather start from a working USB library. I've also poked around LUFA's sources, and that was a nightmare - if you only need what's exposed then great, but to find out what's happening in the code was tough. I guess I just don't enjoy Dean Camera's style of coding.
-
flabbergast
- Location: Southampton, UK
- DT Pro Member: 0120
- Contact:
I wholeheartedly agree with this. (I'm kind of in the same boat - I've thrown some money and time in ARM direction, so I feel like I should at least continue for a whiletwiddle wrote: ↑ By all means look into some MSP430 stuff for another kb, hbar, I would like to get some alternatives going and it would be good to see others investigating too