Alternative controller experiments

[baked_cake]

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.

[twiddle]

Just a quick little teaser:




It lives!!

[vvp]

Do you intend to publish your schematic? I would like to look why so many parts (what they do).

[twiddle]

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.

[Muirium]

Full speed USB? Do you mean something beyond USB 1.1? That would be unusual, to say the least, for a keyboard controller!

[twiddle]

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.

[flabbergast]

Full speed USB? Do you mean something beyond USB 1.1? That would be unusual, to say the least, for a keyboard controller!

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 limit

[vvp]

My guess is that Murium confused Full Speed (12 Mb/s) with High Speed 480 (Mbit/s). Full Speed is still within USB 1.1 and the differential pair is still unbalanced (pullup on D+).

[Muirium]

Ah, slippery old USB. Here's what I'm on about:

USB Chart.png (102.96 KiB) Viewed 6872 times

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!

[twiddle]

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.

[flabbergast]

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).

[twiddle]

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.

[vvp]

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

And maybe there are ports for OSX too.

[Muirium]

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

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
          }

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…

[flabbergast]

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]

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]

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.

ħ

[Halvar]

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.

[Muirium]

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.

[twiddle]

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.

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.

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.

[twiddle]

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.

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.

[hbar]

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.

ħ

[twiddle]

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.

[flabbergast]

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.

[hbar]

- 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 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.

- 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.

That's OK, but the bootloader still has to be written at one stage, which requires a JTAG unit.

- 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.

Great Scot, this makes it a real mess. I agree on your preference of STM32 for this reason.

- 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.

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.

- 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).

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.

ħ

[hbar]

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.

ħ

[flabbergast]

- 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.

That's OK, but the bootloader still has to be written at one stage, which requires a JTAG unit.

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.

- 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.

Great Scot, this makes it a real mess. I agree on your preference of STM32 for this reason.

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.)

By the way - I didn't know that atmega32u4 come with a factory bootloader. But that's tangential to the discussion

[twiddle]

That's OK, but the bootloader still has to be written at one stage, which requires a JTAG unit.

Well, not necessarily JTAG, SWD is OK as well

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]

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.

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.

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).

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.

Yes, this is my main worry.

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]

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.

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 while