Alternative controller experiments

[nickw]

Well, I don't think I need an RTOS or anything like that, and I'm actuallly interested in writing the keyboard parts of the code myself. I've done a fair bit of microcontroller programming, but mostly in assembler, and I've never touched USB. (so digging through the many layers of code to find what I need to change is a challenge) I think once I get past that initial hurdle of getting the USB HID parts working at a basic level I'll be good to go.

[flabbergast]

Well I went for chibios not because I thought I need a RTOS, but because I wanted a layer between the hardware and my code that would support a reasonable amount of ARM chips (at least STM32 and Kinetis). The only other option was libopencm3; in the end I decided for chibios. Actually the way chibios is structured, its HAL is sort of independent of the kernel, see this post by the chibios author.
Finally, the RT kernel doesn't require too much overhead (and has a bunch of very useful features which I got used to by now

The vendor supplied libs (like cubeMX and whatever kinetis chips come with) provide the HAL layer, with the disadvantage that they're incompatible with each other, and often geared towards use from eclipse or some other "big" IDEs.

Anyway, for me, writing hardware-level code for USB is a pain (I did write some bits of the low-level USB driver for chibios for kinetis chips). The trouble with starting from scratch is that that USB has several layers and when bugs come it is often hard to see from which layer does the bug come from. So that's why I wanted to start with a well-tested and cared for bottom layer (hardware to packet level + working interrupts + working EP0 code), so that I can focus on the actual USB HID stuff.

[drojf]

Edit: mbed usb is only supported for STM32F4XXX series . so please ignore the below.

Spoiler:

Well, I don't think I need an RTOS or anything like that, and I'm actuallly interested in writing the keyboard parts of the code myself. I've done a fair bit of microcontroller programming, but mostly in assembler, and I've never touched USB. (so digging through the many layers of code to find what I need to change is a challenge) I think once I get past that initial hurdle of getting the USB HID parts working at a basic level I'll be good to go.

You can try using the mbed online IDE (or the offline mbed libraries if you like). It's really easy to use, libraries are open source...check it out, it's not a closed platform by any means.

https://developer.mbed.org/handbook/USBKeyboard
https://developer.mbed.org/handbook/USBMouseKeyboard

To get started, go here: https://developer.mbed.org/compiler/, make a new blinky project, then copy in the usb code. When you hit 'compile' it will come up with an error - click "fix it" and it will show some lirbaries which you might need to import. Select the top one (the USB library).

I'm pretty sure mbed doesn't run a full OS unless you specify to add it in, if you're worried about it being bloated. I compiled the keyboard example just then and it was 21kB.

Should work with any of the mbed compatible boards (many STM32 boards, and more). Full list of platforms here: https://developer.mbed.org/platforms/

If you're going to go the Arduino route, I would recommend this library: https://github.com/NicoHood/HID

And finally, if you're interested in going full low level USB, this blog post has a description of how you can do it, including how to use Microsoft Message Analyszer to analyse USB packets (I only learned about this tool recently, haven't even tried using it yet): http://andybrown.me.uk/2016/01/09/f042usbhid

EDIT: see below...actually, maybe usb capture using Wireshark is better: http://desowin.org/usbpcap/

[flabbergast]

Yes, that article by Andy Brown is great, thanks for the link!

What put me personally off mbed is that it's geared towards their online IDE (and like my vim, make and offline coding and (for me opaque) C++ codebase. Well.

(And if we're talking sizes, my keyboard example over chibios has 8.5kB.

[drojf]

You can still use mbed offline if you like, see https://developer.mbed.org/handbook/Exp ... toolchains

I should really try chibiOS some time, I've come across it before but wasn't sure whether many people used it/how often it was updated. I also didn't realize it supported so many architectures, the wikipedia page for ChibiOS doesn't seem to show all the supported architectures.

[flabbergast]

Yea, I know I can use mbed offline... but it's not "meant" for that, so... well, not my cup of tea. Still it's a great platform for some purposes (e.g. quickly trying out sensors on various platforms).

ChibiOS - hm. The developer is working on it all the time (just have a look the commit history - note github lags a few days behind the main svn repo). He also answers questions on the forum quite quickly, but you generally get about 5 posts a day total. So it's hard to say how many people actually use it, although there's a commercial side which is invisible to me.

Architectures - the main platform is still STM32, there are drivers for everything. Other ports are usually developed by the community, so they're in various stages. For instance the official kinetis port doesn't have much, only the basic stuff (enough for me, although I had to do some work on the USB code; for instance I think there's no DMA support and things like that). But now and then there are people on the forum contributing various things to other ports (e.g. the AVR port has been getting some attention lately).

It's grown on me.

BTW, back to the original question - there's a new thread here, someone's written USB keyboard app for STM32F1, using libopencm3: workshop-f7/5x5-stm32f1-t12699.html

[nickw]

Cool. That is probably what I am looking for.

[narm]

And finally, if you're interested in going full low level USB, this blog post has a description of how you can do it, including how to use Microsoft Message Analyszer to analyse USB packets

I recently went through some usb hid debugging on linux and used wireshark together with the usbmon kernel module. Simply modprobe usbmon and fire up wireshark, select the usb bridge you are interested in (find a quiet one on your machine for your project, one of mine was tied only to a front facing usb socket), and capture away.

[flabbergast]

I recently went through some usb hid debugging on linux and used wireshark together with the usbmon kernel module. Simply modprobe usbmon and fire up wireshark, select the usb bridge you are interested in (find a quiet one on your machine for your project, one of mine was tied only to a front facing usb socket), and capture away.

Yes, this is the method I use as well. It works pretty well (once I figured out how to filter the packets I didn't want, coming from usb hub and the ARM debugger). Just chiming in to say that on some distros I needed in addition to mount debugfs manually.

[drojf]

well...looks wireshark USB debugging works on Windows too:

http://desowin.org/usbpcap/

I would definitely prefer to use Wireshark for debugging since the interface is familiar / it's got lots of support if you have problems.

[twiddle]

Just to show I aten't dead:

[SCh]

Well I went for chibios not because I thought I need a RTOS, but because I wanted a layer between the hardware and my code that would support a reasonable amount of ARM chips (at least STM32 and Kinetis). The only other option was libopencm3; in the end I decided for chibios. Actually the way chibios is structured, its HAL is sort of independent of the kernel

I am working on a STM32F1 based board, and had run into some stability issues with opencm3. Would love to look at Chibios but their RT layer is GPLv3. To write a USB keyboard app, would it be necessary to use Chibios RT layer as well as HAL layer? Is the HAL layer for USB handicapped in any way when run without RT layer (such as having to be threaded due to API design)?

[flabbergast]

My code uses the ChibiOS kernel as well. BTW what I wrote is a "mid level layer" for TMK, and the rest of TMK is also GPL'd, if that's a problem for you. However my actual USB code is (I think) RT independent.

[SCh]

My code uses the ChibiOS kernel as well. BTW what I wrote is a "mid level layer" for TMK, and the rest of TMK is also GPL'd, if that's a problem for you. However my actual USB code is (I think) RT independent.

Thanks for quick reply. I am not intending to reuse your code/TMK. However I would like to hear your experience with Chibios HAL layer for USB. I would rather not start a porting project until I am sure it has a good chance of working
- Is the HAL USB a good and functional API set when used without the RT layer?
- How does the HAL USB API compare with other common USB libraries such as V-USB in terms of quality and design?

[flabbergast]

- Is the HAL USB a good and functional API set when used without the RT layer?

I personally have no experience with this; although there are some demos in the chibios tree that don't use the kernel.

- How does the HAL USB API compare with other common USB libraries such as V-USB in terms of quality and design?

In chibios there are 2 layers to any driver: common code, and then a hardware specific layer. IMO the common code is well written and well abstracted; the hardware specific layer depends on who maintains the code (for STM32 it's the main ChibiOS author, so that code is quite good). VUSB is not good for this kind of comparison - it was written specifically for bit-banging USB on AVR chips, so it's full of very specific AVR tricks (I'm not saying VUSB is bad - it's actually quite wonderful, but different from any other USB HAL).
As for the API, I'd say it's not that different from other USB libs - you need to define descriptors and the usual callbacks for USB requests. Normally it's all asynchronous, but there are also versions that wait for the USB operations to complete.

[hbar]

Hello chaps,

I'm thinking of designing my next keyboard prototype and wondering which MCU to use. I already have a KL27Z, which has a built-in voltage regulator and doesn't require a crystal, is there any hope that I can get tmk/chibios running on it at some point? I'd prefer it to other ARM MCUs if I can simply because it needs so few external components.

[twiddle]

I haven't updated the thread for a while, but more recently I've been looking at using more of the STM32 parts. We spoke about it earlier in the thread, but some of the STM32F0 parts do crystal-less USB, and I've been using the 1262 3v3 regulators from microchip which only need a single cap for operation: http://ww1.microchip.com/downloads/en/D ... 21373b.pdf
I find that the two parts being added to the BOM don't really make that much difference to cost or board complexity.
The regulator is 70c AUD in 25s, 90c in 1s, and the SMD cap is less than a cent.

Main reason I've been moving further away from the Kinetis parts is that, aside from Kinetis Design Studio, I've found the software side of things somewhat lacking - both LPC and STMicro have vastly superior libraries and documentation available. Not to mention that if I want my designs to be relatively approachable to somebody who hasn't surface-mount soldered before, the STM32 TSSOP parts are vastly easier to work with than the QFPs that Kinetis are packaged into.


Having said that, to actually answer your question, according to https://github.com/utzig/ChibiOS-Kinetis, Kinetis support is included in ChibiOS mainline, and a quick google shows some example code as well.

[drojf]

Agree about the regulator. I think the main advantage is board space rather than cost (if you're making an ultra tiny USB dongle or something commercially).

some of the STM32F0 parts do crystal-less USB

Specifically, the STM32F0x2xxxx, so the STM32F042xxxx, STM32F072xxxx (out of the stm32f0 series). As twiddle said, you can get (some of them) in TSSOP or .8mm pitch QFP if you don't have the soldering setup to solder the .5mm QFP parts.

I would tell you to buy a stm32f103 board off ebay + st-link debugger (official or clone) and stick it in your keyboard, but last time I bought a couple, the usb connector didn't have it's data lines connected (I think broken usb connector). But everything else worked, and I have no doubt the other boards were ok. It's fairly physically small, so if you're just doing a one-off prototype then that might be the easiest way. They go by the name "STM32F103C8T6 ARM STM32 Minimum System Development Board Module" on Ebay.

You can also buy an official Nucleo development board and use that for both development and as a debugger (for the above Ebay boards or your own custom board).

[HaaTa]

The kinetis stuff doesn't really need a crystal for USB. The original Infinity 60% keyboard didn't use one. Though the clock won't be to USB spec. But yeah, as for the crystal, on most (all) kinetis chips, you just need to add the crystal, it has built in load capacitors.

[hbar]

Is anyone working on the nRF51 or nRF52 front? I do quite like the SDK they ship (and even have a fairly simple build environment set up), but have no idea how to properly implement BLE's HOGP on it. The controller should be able to pair to multiple devices (so it's easy to move the board between hosts), and as if that weren't already hard enough, reading the code and documentation reveals other subtleties such as whitelists, advertising, etc., which mean nothing to a layman at first. The HID keyboard example in the SDK is also grossly simplified, so I can see a lot of work coming my way before I have a working keyboard controller.

[hbar]

Here's a wake-up call from Nordic: they have announced the nRF52840, which now has USB device functionality on-chip, and can be run off 5V. That plus BLE sounds like my dreams come true.

[pomk]

I have a working implementation done with nrf51. I'll be posting it to git in the following weeks. As for the nrf52840, the usb functionality is nice, but the 5v tolerant voltage input is unusable for battery operation due to its high q, a separate regulator is needed if you wish to use a rechargeable battery that goes over 3,6 volts. I'm eagerly waiting for the first production revision!

[HaaTa]

nice, I saw the nRF52840 at CES. I think I have a dev kit somewhere (haven't had time to even open the box, lol).

I may be interested in adding kiibohd/KLL support for the Nordic chips

[pomk]

Just remember to add wireless DFU support as well
I only added support to change the layer layouts as well as fn remapping wirelessly using wireless uart when a key combo is pressed on boot.

[HaaTa]

Yeah, will probably need a custom bootloader and such.

[hbar]

I have a working implementation done with nrf51.

Great, I'm looking forward to it. Which SDK version are you using? I ended up using three separate versions for the three types of chips I have (or will have soon): 11 for 51822aa, 12.3 for 51822ac, and 13.0 for 52832, each being the latest one supporting a softdevice on each device. I was thinking of writing something from scratch, but your efforts might save me a lot of time, especially if you have layout-over-the-air working already (which implies a solid understanding of BLE concepts, which I'm lacking at the moment).

5V is only really relevant for USB, and my battery of choice would be LiFePo4 anyway, which is nominally below 3.6V.

[spindle]

Hi, I've been working on my own control too. I use atxmega32a4u. The footprint allows it to fit under one cherry switch. Here's some of the prototypes: .

[rrrsss]

I don't know if pomk and hbar is still subscribed to this thread, but if you have an implementation for the nRF51/52 that would be great to see.

[pomk]

I’m doing final cleanup on it. Will post it before christmas.

[NealXu]

Hi...i am a new user here. In my case i want to add a crystal for inter-chip communication. Basically the internal clock has a lot of noise which is bad for synchronization. The Freescale stuff is nice because you just need to add the oscillator.

pcb assembly service china