Alternative controller experiments

[twiddle]

I'm currently trying to get a good setup for working with the nRF51 chips. Nordic don't have very good support for GCC though. The SDK is all well and fine but there's a hierarchy of makefiles, some in the SDK, and then some in the samples that depend on the SDK ones. The SDK makefiles aren't self-contained, ie they expect certain variables to be defined in the sample makefiles.

Problem is, the sample Makefiles are set in such a way that there's a lot of references to BSPs (board support packages) so in order to set my own setup up for a custom board I have to wade through all their additional abstraction, and even assuming I can get that sorted I run into the irritation of having to manually update my makefile for each new source file I add, given that autotools on Windows is never very well supported.
Basically there's a ton of macros to do things like define which of the pre-designed boards are used, how many LEDs it has, etc etc. I don't really care about the actual functionality in the samples, just the initialization code, so I don't want to start with one of the provided samples and remove the unnecessary bits - I'll spend more time trying to strip the crap I don't need from them than if I write it all from scratch.
VisualGDB apparently has Nordic support incoming (which will be sweet, because it'll give me an empty project but handle the Makefile and toolchain for me) but emails to them asking to access it as per their forum post about it haven't had any response.

Nordic do provide Keil projects for the SDK/samples, but I'd still have to wade through all of their HAL bs in the samples to actually find out what I would need for a minimal implementation. Not to mention I detest Keil - say what you like about MS normally but the workflow of VS2013/5 with Visual Assist and VisualGDB is pretty hard to beat, and considering the price (all up about $100, and that is only for the addons, VS Community is free now) I have absolutely no interest in the free crippled keil, or the $3000 unrestricted version.

Once I get the BT chip working, I'll return to the actual application side of things - there's two directions I'm sort of working on simultaneously so I want to get the actual chip for both projects up and running with a minimal HID implementation before I start to pull out the common functionality and get the firmware more well developed.

In terms of firmware functionality, I think on my GH thread TMK was sort of viewed as a high point in terms of functionality. Can't say I'd get feature parity overnight but its a good target to strive for.

[hbar]

Good Lord, you're doing BT already when I haven't even started with USB...

Here are a few ideas of what I think can be improved on TMK:

- Split keyboard support. I'm considering a design with one MCU per half (after all, any shift register or port extender will cost about the same as another controller), which talk to each other via SPI (or maybe I²C). Each has their own USB code, which can be identical or not, and one can choose whether or not macros are synchronized between the two. Whichever is plugged into USB will act as master, the other one as slave, which is automatic. This would allow the user to create a keyboard which can emulate two different keyboard layouts the host expects. In my case, I often switch between computers set up for German QWERTZ (with dead keys) and British QWERTY (with compose character), such a keyboard could support both very easily.

- Mass-storage device for configuration. The layout (including all layers) can be placed into a file on a USB mass storage device supplied by the keyboard after a predefined initialization event (button on controller board pressed during power-up, for instance, physical access must be required). Another file can hold the macros, which can thus be backed up to the PC and restored through the same USB mass storage device.

- The previous point implies that the layout must not be hard-coded as in TMK. The only things that should be hard-coded are the port assignments of rows and columns as well as communication ports to the other half of the split keyboard and to the trackpoint. Layout configuration should be soft, referring to real row and column indices rather than GPIO pins. (This amounts to an extra layer of abstraction, which shouldn't be hard to add, and the ARM has plenty of extra capacity for this)

ħ

[twiddle]

Heh, well I only have very basic USB functionality working at present. As I said, I'm getting the POCs for the different chips working before I do too much, because that way I have a few hardware configurations to run my tests against so cross-mcu portability is maintained right from the start.

I was already considering something like your suggestion about SPI/I2c/some other communication protocol so that the firmware would support split designs, yeah.

Mass-storage wouldn't be bad, but to be honest I would prefer something that doesn't expose the entire firmware stack in that way. Too easy to accidentally nuke the firmware if its a soft mass-storage mode, not to mention the extra code space it would use, and hardware bootloaders don't support multiple split files in the way you are proposing. Some of the chips I intend to be targeting, for eg the NRF chip, don't have a hardware MSC bootloader.

I'm likely to be using HID for reprogramming layouts, I think, at this point, because I know that will work across all the controllers that the firmware could be ported to, it requiring HID of course to act as the keyboard. All I'd need to do is expose an additional HID endpoint that software could talk to if a certain combination was depressed when the board was connected. I did consider even just making the board enumerate as a composite device with a serial terminal that could be used for debugging/reprogramming too, with the right keypresses on startup. That at least has the advantage that it would be helpful for me when doing debugging.

Your last point was basically an assumption for me. My HID tests I have working at the moment are hard-coded, but the first step of the more substantial firmware development will be to implement a class that abstracts the layout from the physical pins, and the second step will be to represent the layout as an object, which makes layer-swapping just a matter of switching the current object.

[twiddle]

Little update for everybody:
VisualGDB now have Nordic support available, so I'll get on that shortly. In the meantime I've been working on my HAL, so I figured I'd give people a little insight into how I'm building it (source will eventually be on Github when I'm at a point that it would be useful for people.
Emphasis will be on using "modern" features of C++ such as constexpr, auto, and templates to make defining things at compile-time both easy to do and easy to read (which I believe is where mbed somewhat falls down).
I'm leveraging these features to avoid dynamic memory allocation and to keep RAM usage down, and avoiding virtual functions/vtables while still maintaining polymorphism (static polymorphism that is).

Code: Select all

class NXP_HAL_GPIO : public HAL_GPIO<NXP_HAL_GPIO>
{
	void SetMode(GPIO_Data Data) 
	{
		(Data.Mode == GPIO_Data::EPD_Input) ? 
			Chip_GPIO_SetPinDIRInput(LPC_GPIO,Data.Port,Data.Pin) : 
			Chip_GPIO_SetPinDIROutput(LPC_GPIO,Data.Port, Data.Pin); 
	};
	void DigitalWritePin(GPIO_Data Data, uint8_t Value) 
	{ 
		Chip_GPIO_SetPinState(LPC_GPIO, Data.Port, Data.Pin, (Value != GPIO_Data::EPS_Low)); 
	};
	bool DigitalReadPin(GPIO_Data Data) 
	{ 
		return Chip_GPIO_GetPinState(LPC_GPIO, Data.Port, Data.Pin); 
	};
};

This sample implements the CRTP pattern in its template definition so that polymorphism can be used at compile-time. Methods will be inlined where necessary for performance (the underlying vendor calls in the above sample are already inlined).
Once the vendor specific implementation is exported into the HAL namespace you end up with an actual application that looks like the following (this is an approximation, but you get the idea):

Code: Select all

int main()
{
	HAL::Clock.InitializeSystemClocks();

	HAL::USB.Initialize();
	HAL::Matrix.Initialize();

	for (;;)
	{
		HAL::Matrix.Scan();
	}

	return 0;
}

Application code doesnt know anything about vendor details, but performance is close to the same of using vendor libraries directly. Application can optionally specify configuration information on a per-platform basis at compile time using traits template specialization. Curious to see what people think

[Engicoder]

I'm likely to be using HID for reprogramming layouts, I think, at this point, because I know that will work across all the controllers that the firmware could be ported to, it requiring HID of course to act as the keyboard. All I'd need to do is expose an additional HID endpoint that software could talk to if a certain combination was depressed when the board was connected. I did consider even just making the board enumerate as a composite device with a serial terminal that could be used for debugging/reprogramming too, with the right keypresses on startup. That at least has the advantage that it would be helpful for me when doing debugging.

I wrote some software for a configurable device that enumerated as an HID. I used SetReport to do configuration programming.

[twiddle]

Always good to hear of other projects 'in the wild' that are using the approach I intend to take, Engicoder.

[flabbergast]

Hey guys! Finally got around to finish the little STM32 breakouts. I am quite happy with them so far, so I need to vent
STM32F042FxP6 breakout:

DFU bootloader working well. It's got a bit more circuitry on the bottom side than really necessary (a ferrite bead and one more cap than really needed). Another two photos, along with a smaller STM32F030F4P6 breakout (that one doesn't have USB): top bottom

And yea, ST sucks in terms of samples - they flat refused the couple of MCUs that I asked for.

Now off to do some programming (I don't really like the ST official HAL/libraries, but I've had a peek at ChibiOS which comes with its own abstraction layer, and seems to have definitions also for mchck and teensy 3.0, so that would be nice if it works).

[Engicoder]

Looks nice! I'm a big fan of the STM32F0x2 chips. I have used them for several projects. I agree with you; the standard libraries from ST, especially the USB device library, are a hot mess.

[mtl]

Has anyone looked into the micro python pyboard? It's big and relatively expensive. It would be great to be able to hack on the keyboard logic in python, however.

After briefly looking at the micro python source code, it looks like some C coding would still be in order to support things like n-key roll over, because the USB stack exposed to python code is very limited.

[twiddle]

I hadn't actually seen that board - I'll have to keep it in mind for my studio projects at the college, it sounds like it might be a contender for something I can get the students to use.
Quick update for everybody - still working on the firmware, another few weeks and I think I'll be at a point of canvassing feedback from interested parties. Feel free to PM me if this includes you.

[flabbergast]

The micro python board looks like fun It seems to me that it's the python version of espruino which runs javascript.

@twiddle: yes, I'd like to have a look at the firmware, but I guess I'm first going to have to get some nordic board(s)...

Meanwhile I did play with chibios and have a working USB (keyb+mouse+teensy_debug) example (for STM32) here. I must say that I quite like chibios - it's lean and clean The only thing is that it doesn't have good enough freescale (teensy 3.* and infinity) support yet (notably, it's lacking the USB layer).

[tlt]

The Adafruit Bluefruit LE Micro - Bluetooth Low Energy + ATmega32u4 board might be good if you want to make a bluetooth keyboard. You can also add a LiPo backpack to it and than you got everything you need. Have not tested it myself but I have previously bought similar components for a project that I haven't finished. This package have the same features but is cheeper and more compact.

[twiddle]

@twiddle: yes, I'd like to have a look at the firmware, but I guess I'm first going to have to get some nordic board(s)...

Ah, well I'm actually not quite there with the Nordic support at the moment. I've been working on the abstraction layer and getting the basic functionality in which consumes it (layer support, reconfigurable matrix, compile-time data structures to minimise RAM usage to enable portability to more restrictive platforms). I'm currently using one of my NXP boards as the first implementation of the HAL, but it's more the design of the HAL itself that I would be curious for feedback on.

[joey]

Please post the current code somewhere, I'd love to take a look even if it isn't finished!

[flabbergast]

@twiddle: Yes, I'd like to have a look at your code as well (might take a bit of time to have an in-depth look, but nevertheless)...

I'm curious about the design. I, at the moment, favour chibios for the HAL layer (because it's pretty clean, provides nice separation from the low-level stuff and seems to be extensible to different ARM chips, so no manufacturer HAL stuff to worry about; and I really like the RTOS features like timers, events, threads, mutexes, etc...), with a keyboard USB stack on top (I've done that), but I'm too lazy to do a proper keyboard logic on top of that (so at the moment I just plugged in all this into TMK, and it seems to work OK). It would be nice to have a look at someone else's (read: yours ideas about proper layer separation and design.

[hbar]

Damn, I've been too tied up recently to do any work on this. I just discovered, though, that tmk is quite cumbersome to configure for new hardware, so I'd welcome a real alternative for my next keyboard (should I make one), and this could be it. That's why it would be very good to see the code.

On the other hand, that espruino project looks really really nice. Not that I particularly like the idea of coding in ECMAscript, but that opens a totally new avenue in the form of the language elm, the compiler of which uses ECMAscript as its target. If (1) espruino can be programmed as a HID device and (2) its interpreter copes with the output of elm, that might be pretty exactly what people like me (*) have been waiting for. I hope we can tick both of these requirements very soon.

ħ

(*): I'm one of those who have accepted John Backus' apology (see Wikipedia if you don't know what I mean).

[Eszett]

What are -- according to your opinions -- the upmost criteria for a microcontroller of a custom built keyboard?
(_) cheap
(_) can handle 5v (from USB), by internal voltage regulator
(_) comes with bootloader, ie. no programmer necessary
(_) works without crystal
(_) at least ..(insert number) I/O pins
(_) package easy to solder
(_) broad community support and popularity
(_) has well organized documentation
(_) compatible with TMK
(_) ..?

[mtl]

If using a mcu on a break-out board, the size, shape, and how it can be mounted are also important. Some of these other features may be more or less standard items: Hardware support for TWI/SPI are important for talking to other devices (or the other half of a split keyboard). A UART suitable for talking to a PS/2 TrackPoint is useful. PWM support (and sufficient timers) for driving LEDs.

[twiddle]

MTL has some good things worth considering.
In terms of my response to your list here are my top considerations

* Comes with bootloader
This is essential for making a product that can be reprogrammed by end users.
* at least ..(insert number) I/O pins
If the MCU doesn't have enough input pins, you end up using an I/O expander or something else which complicates both the firmware and software and probably eats up the cost saving going for a chip with fewer pins.
* has well organized documentation
I'm far less concerned with good community support if the chip has good documentation - if things are written well I shouldn't need to go trawl forums for how to use the parts in the first place.
* package easy to solder
My definition of this isn't necessarily something others would agree with - but by 'easy to solder' I basically mean 'no bga/lga packages that require reflow to solder'. I personally consider any SSOP/SOIC/QFP packages to be easy to solder. I hope to be trying some DFN/QFNs soon.

Cheap/internal regulator/crystal-less etc
It really just depends on how complex the board you are making is and what your space requirements are. If you dont have a lot of room then getting rid of the regulator and crystal makes a big difference, but otherwise it doesnt make a big difference, what you save with a cheap chip you pay in the external components, if you save cost by not including external components you pay more for the chip.

[flabbergast]

mtl has a point - but all the recent MCUs come with all these hardware features - especially if we need "x" pins. So in reality this does not generate too much of a restriction.

I agree with twiddle on the most important bit: comes with a bootloader from factory. Not just because "reprogrammable by end users, and they can't mess up the software bootloader (~ infinity kb)" but also if someone is soldering it themselves they don't need an extra programmer; if I'm soldering a bunch I don't need to program each and every one with a bootloader; and a software bootloader adds its own (non-negligible) amount of programming headache.

The other criteria depends a lot on the actual project. E.g. these:
(_) works without crystal
(_) can handle 5v (from USB), by internal voltage regulator
depend on how much space is on the PCB (the price difference is generally negligible, out of these the crystal is most expensive); this:
(_) cheap
if you're doing one-off than it does not matter, if you're doing >= 100 it does not matter much, and also compared with other KB parts' prices it does not matter; these:
(_) at least ..(insert number) I/O pins
(_) package easy to solder
(_) support for hardware features (SPI, I2C, UART...)
can be generally arranged within a selected family of microcontrollers.

These:
(_) broad community support and popularity
(_) has well organized documentation
(_) compatible with TMK
are kind of interesting. Community/popularity does not matter much of you're relying on existing firmware, but do matter a lot if you're a beginner and want to write your own firmware. Docs matter if you're an experienced dev (I'm looking at you twiddle) and writing your own firmware; otherwise they don't matter much (what I mean is that the current standard manuals that come with MCUs are OK). TMK compatibility - well this is a moving target. TMK now supports Freescale chips to some extent via mbed (so potentially a lot more chips), I've added STM32 support (sans eeprom).

But overall - IMO - if you want to build a one-off (or especially if you want a small run <=50, i.e. other people will use this as well), you might want to stick with "proven technology", meaning ATMEL chips. Otherwise you might be stuck maintaining a firmware yourself, and have a lot of people bitching about this and that (see infinity keyboard). Of course if you're happy doing that, then yes! we need actual keyboards with ARM chips!

We'll see how will matt3o's whitefox do (should have a Freescale chip), especially since it'll go on massdrop, i.e. random non-understanding people will buy it.

BTW - if you want to use a breakout board for some ARM chip - I like making those, get in touch

[Eszett]

I have a problem to mass search for "can do USB well without crystal", since mass seach tools don't include that criterium. So, my question is, which MCU ..
.. can do USB without crystal
.. can handle 5v
.. comes with a bootloader
Any ideas? For example, no LPC or STM32 can handle 5v without external regulator (which I try to avoid).

[flabbergast]

AFAIK, the only two ARM series that can do 5v without an external regulator are Freescale Kinetis (the chips in Teensy 3.* and infinity keyboard) and some Cypress chips (no experience with these at all). No idea about Cypress (last time I looked they only had huge things like LQFP-100), but Kinetis do not come with a bootloader.

So overall I'm not aware of any chip that can do all three you want, Eszett.

Also with Kinetis - they have an internal regulator (probably 2, one for 3.3V and one for 1.8V), and in a very small package, so you should be careful with consumption. Keyboard matrices are definitely fine, but you probably shouldn't try to drive too many LEDs directly from MCU pins.

EDIT: I may be wrong about this - I forgot about Microchip PIC chips. They do have some crystal-less-USB 5V chips. They have their own architecture though. I have no experience with these, and have no idea if they come with a bootloader from factory or not.

[Eszett]

Hi Flabbergast! Yes, I'im eyeing on the PIC chips, even though many users tell, that Microchip MCUs are awfully in terms of documentation and useability. However, if we get them to do the job, we won't complain, isn't it? More awful than freescale, can't be!

After reading this leaflet From Microchip, I searched for possible candidates and came to the PIC18F45K50: easy to solder (DIP), plenty I/O (40 pins), cheap (roughly 3€), can handle 5v, no crystal needed for USB. But Bootloader? That is still an open question ...

[twiddle]

The one thing I found with Microchip alongside their documentation and such was the compiler support was sorta half-assed. There's freeware available, but only up to a point - if I remember correctly you're limited in flash size, and I'm not sure if the current IDE runs on non-windows platforms.
Also - do think about the size of the chips - I bought one of the Microchip DIP USB chips and found that it was really quite massive. On some boards that will be fine, but on others (40/60% etc) it might be too big.

[flabbergast]

I'm also not a big fan of PICs - I've very briefly tried once, and run into similar things as twiddle - getting compilers (to work) was more complicated than I expected (I'm not on Windows, the free choices were very limited, it seemed to me that a lot of people are using paid compilers). Also it would require me to learn a completely new architecture - and I'm now trying to learn ARM

Also with DIP MCUs - it's not actually such a win: you'll necessarily require a bunch of passive components (a few caps, maybe some pull-up/down resistors), so by the time you route those it's actually almost the same as if you use a breakout board (meaning a Teensy or similar) which has even a regulator and/or crystal on board.

Granted, one thing that could be improved in Teensies (for our purposes) is to break out also USB D+ and D- pins.

Anyway - if you're willing to venture into the PIC world, it would be cool - I think PICs in general are not going to die out any time soon - IMO they tend to be used much more than ATMELs in real world things (ARMs are too fragile for things like garage door openers, etc...).

[twiddle]

Minor diversion to show what I've been working on recently...


Custom development board with a bunch of varied peripherals, for my students to meet their 'hardware integration' learning outcomes in the penultimate game project they are about to start in the game development degree that I teach.
I dont have 3d models for everything on the board, but there's a speaker, some buttons, dial, some various LEDs including a RGB LED, a seven-segment display, the thumbstick, and the ESP for wifi support. The board will charge over USB, and uses a lipo battery hence the bare area in the top left.

I would love to have OSHPark do the board, because I am always a fan of the look of their work, and I feel students will take the project more seriously if everything looks professionally developed. However they are just too expensive when time is a factor so I'll probably go with Smart Prototypes again, so it should still look pretty sweet even if I can't have purple+gold.

Microcontroller is the same LPC11u35 that you've seen earlier in the thread, mostly because I have about 10 or so of them and their API isnt too bad.

In my own time I am still working on firmware development.

[flabbergast]

This looks so cool! Teaching this kind of stuff at uni level must be quite fun and interesting... (Although mentioning 'learning outcomes' makes my hair stand on end.) ... I can only wish

[twiddle]

I'm not so much teaching the hardware design process, but the firmware development. It's a game dev degree with a heavy vocational emphasis so there's a lot of flexibility within the projects that I run, so long as students get the opportunity to demonstrate the learning outcomes/baseline criteria required to pass the unit I can pretty much set them whatever task I please, and the optimization required for firmware development is very similar to the sorts of tricks required to get the most out of modern game consoles.
Learning outcomes in my situation essentially is just shorthand for 'what the student must do at a minimum to pass the unit'.

In the context of this particular subject, students will be making a hybrid digital/analog game that either aims to educate or persuade, using this board as a 'smart hub'/input device.

[scott.stamp]

Is that a USB-C controller, twiddle? Interesting choice of demo input peripherals, I like the analog stick. Thing that should exist: Bluetooth-capable, OSH/OSS gaming controller. I'd buy one.

Loving the interest in this. Up here in Canada, it's like ~$30-35 incl. shipping to get a Teensy v2. Parts, PCB and shipping on that neat little ARM board that flabbergast built is only about $12. ($30-35 for four, from Mouser!)

[twiddle]

Actually it's USB mini, Scott.
Closest thing at the moment to your oshw controller is the ps4 controller I reckon. The protocol is reverse engineered to a reasonable extent and the device can use bt or usb to connect to a variety of devices. Not reprogrammable yet but they're a good bit of kit.