Alternative controller experiments

[twiddle]

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

To clarify, I'm using the inbuilt HALs for each manufacturer, I'll be essentially creating a further level of abstraction to allow the USB functionality to be ported. In some ways its more of a keyboard library rather than a USB lib, I guess.

[twiddle]

Closeups of assembled boards (sorry for potato)
Freescale:


NXP:


The astute among you might notice that the freescale board looks a bit, shall we say, greener, than the boards in the first image. This is because there was an electrical fault in main power trace on that design, which meant the chip wasn't receiving the right current. I also had made a mistake in how I routed the SWD header on those boards, because I had made a custom part for them I had the pin sequence running in the wrong direction (vertically rather than left to right). I took the chance to send off for more prototypes of the Freescale board, fixing the electrical issue while also addressing the swd header.
For the NXP board, there were no actual faults as such so I simply handwired a spaghetti of wires to the bare contacts on the board and socketed them onto my debugger, as you can see in the image I posted earlier (the yellow wires).

On the other hand the Freescale v2 with the fixed header has no LED, so is not quite so dramatic, but nevertheless it looks much neater with the Cortex debug cable properly attached:


So, now I have two dev boards that properly enumerate as USB keyboards, I'm moving forward with some firmware development. I grabbed my trusty 5x5 tester I showed earlier in this thread and attached it to the Freescale board, and I've now got a preliminary matrix scanning routine functioning on it.
Here's hoping progress will be substantially faster now.

[hbar]

Nice work, twiddle. Good to see that it's not just me who prefers SMD parts (they are so much easier to solder, in my view).

Let us know how you get on with the firmware. Even if I haven't got the time to create an MSP430 port, just keeping that option in mind could make sure the HAL API is clean and portable.

ħ

[flabbergast]

Pretty cool!

[twiddle]

Nice work, twiddle. Good to see that it's not just me who prefers SMD parts (they are so much easier to solder, in my view).

Probably not the best for my health, even with fume extraction, but I enjoy soldering and enjoy soldering SMD/T parts in particular. I recently got some TQFP-144 samples that I'll be drag soldering when I have a board fabbed for them
The other thing is that SMD passives are pretty universally recommended for ARM chips in the packages I am using, and their size leads to more compact designs with only minor considerations needed if you are going to hand-assemble.

[hbar]

I have to admit that it was quite some time ago that I did my last microcontroller project (which happens to be based on an ARM from Analog), so i had a glance around to see how much things have changed since then. Hereby I partially withdraw my recommendation of MSP430, seeing that TI now offers a new line, MSP432, which is ARM-Cortex-based, and quote even lower power requirements than for MSP430. Sadly, though, there is no integrated USB, and no FRAM, on the single device they offer to date. I'm sure that that's going to change.

So, twiddle, what's your current preference: STM32 or LPC? I'm asking because I'm considering using an ARM-based chip for a keyboard prototype, being completely fed up with Atmel and its programming (and documentation!) the moment I first layed hands upon one (last night, that is). Which one are you currently focusing on? It may be wise to pick the same one for compatibility, but then it may also be wise to pick the other one for parallel work to make sure the API is solid.

I think I need some samples soon...

ħ

[Halvar]

Are you programming in assembly language? I really can't complain about the information and documentation that is available for Atmel AVR on the net (for C). There's a huge hobbyist community, and good books (like "MAKE: AVR Programming"). I would go for ARM cortex for the better specs, but I'd be surprised finding better documentation and samples there.

[hbar]

My projects so far have all been in assembly (without using any manufacturer libraries), but that isn't the problem. I find the ATmega32u4 datasheet very vague, omitting details when it comes to peripherals (mostly the non-CPU side, electrical specifications, etc.), but that might just be because I've been spoiled by the very accurate datasheets from TI, Analog, etc.

Those omissions might not be evident until you try to design a circuit with the chip and find that particular piece of information missing.

ħ

[flabbergast]

Yea, I also find (relevant to me) electrical information hard to dig out of ATMEL's datasheets. On the other hand, the AVR8 line can take a lot of beating (overvoltage, too much noise, and other electrical mayhem) and still work, so maybe that's why they don't bother with datasheets

But I found the programming side of things documented pretty well for ATMEL chips.

But I can't say that ARM datasheets I've looked at are better - for instance I wanted to find out whether crystal is needed for USB operation for a couple of promising ones, and it was (almost) never stated clearly, I had to infer from a couple of innocuous looking remarks here and there.

[twiddle]

Out of the two you've mentioned there, I found LPC to be my preference. Both of those have USB bootloaders, but NXP/LPC is drag and drop whereas STM uses their own customised DFU protocol.
I'm not programming in assembly, either. In fact, my firmware is likely to be using C++ rather than straight C, too. I've got experience doing x86 reverse engineering, so I know my way around assembly, but I don't wish to have to write a USB driver that talks to the SIE directly, so I'm using the peripheral libraries provided by the respective manufacturers. This doesnt directly preclude me using assembly, but I'm more interested in getting my prototypes done in a timely fashion than being some sort of purist, especially when a) the compiler can usually do a better job of generating optimised assembly for me and b) theres no real concerns with code space - the smallest chip I've been working on is the LPC one and that's still 64KB, and LPC's USB stack is implemented in hardware so it uses a really tiny amount of code space.
I don't foresee issues with C++ if I avoid dynamic memory allocation.

NXP also make LPC1114, which is pretty much the only ARM in DIP package available, it doesnt have USB but it was really quite trivial to learn how initialisation and timers and IO work using one sitting on a breadboard.
LPC also had a basic minimal schematic for USB applications in their datasheets which was nice.

The flipside to this is that STM32's Cube configuration tool made it very trivial to get a working keyboard implementation - I was able to get something up and running that actually enumerated correctly, much faster, using Cube. This project is as much about learning about USB as it is just getting something running though, so I opted to try STM's earlier libraries that could be more easily manually configured, and started to run into issues, which is why I moved onto my Freescale and NXP prototypes.. Now I've got both of those working I might take another shot at hand-rolling my own STM implementation, but I thought it worth mentioning that it *was* much quicker to get something working with STM than NXP if you don't care about poking around the internals of the USB stack.

In terms of ARM datasheets, you should really read the reference manual as well as the datasheet- I've found datasheets to be good for overview information but the RM is really where it's all at.
Sometimes its a matter of terminology too - try searching for 'crystal-less' or 'USB IRC' (internal reference clock) or something like that. When I was looking for crystal-less chips, though, I admit I found it easier to just use the manufacturer's search pages because they usually list it as a feature that you can search for.
There's actually a LOT of sample code for cortex chips available from the manufacturers. It's not always directly portable because of the use of manufacturer libraries, but conceptually things are done in very similar ways between chips because of CMSIS so I am finding my experience getting the LPC usb implementation working to be very helpful now I'm trying out Freescale, for example.

Speaking of which I would consider giving Freescale a run for their money. Their FRDM boards are relatively cheap, and they offer a very generous sample program which STM/NXP/EFM don't.. I'm likely to push forward with using them for this project, because they have a nice crystal-less implementation with good documentation (see the picture above? only a handful of caps and resistors needed, the rest of the stuff on that board is for my debug header and the reset/bootloader switches), and I would like to encourage them to continue to make the sample program available after their merger with NXP. I'd like to be able to email them and tell them that the sampling program was directly responsible for me choosing their parts - I'm never likely to order more than a couple hundred chips at most, but hearing that the samples are directly driving sales will hopefully help them to justify maintaining the program.
In addition to this, Freescale have Kinetis Design Studio which has a thing called Processor Expert. This is even easier than STMCube for getting a keyboard implementation up and running, and it looks like this:


You add components to your project and then edit their properties, and can customise what library code is generated to optimise for code space, the IDE itself is Eclipse based so you should find it works on OSX and Linux as well. The keyboard process basically consists of you adding a HID component which automatically adds the relevant USB framework and descriptors, and then you simply need to set up the clock configuration and then click 'configure as keyboard'. Thats it.
So we've actually got a bunch of different options available, which is one of the reasons I'm enjoying having 3 or 4 different manufacturers to play with.

[hbar]

Thanks twiddle, I get your points. My experience over the years has been that using pre-made libraries or code generators are not much use and only get me in trouble at one stage or another, that's why I ended up not using any of those, even if I tried in the beginning. In a few year's time, when everyone is using twiddle's proven keyboard controller code, all that matters is package/soldering/size, external components (that crystal is huge!), and the need for extra hardware (programmer). Currently, it appears that STM32 is the only one that has the potential of being painless in all regards (although I imagine TI will catch up, and they have a useable samples programme).

Just out of interest, since I'm only familiar with low-level USB but not the HID standard: what transfers does a keyboard use -- control, bulk, or interrupt? (Not iso, quite obviously...) How many endpoints are required? Maybe you could quickly share your insight and spare me having to go through specifications and sample code.

ħ

[flabbergast]

Ad USB Keyboard: just one IN interrupt. You can have a look at Dean Camera's sources (LUFA USB library for ATMEL chips, but because of his (weird) standard of writing C code it's actually very easy to understand the USB descriptor: https://github.com/abcminiuser/lufa/blo ... criptors.c
(although to get the actual values one would have to dig through the rest of the library). He's got a bunch of other demos in that lib - I use it to get working descriptors

EDIT: Forgot to say that this is for 6KRO, which is somewhat simpler than NKRO (at least for me).

[twiddle]

While I'll admit that some libraries are not much use or are written poorly, I'd respectfully disagree on the idea of using raw register access for writing your own usb stack from scratch. Putting aside code generators, the libraries themselves are field tested to a substantial degree and you will end up spending much more time writing and debugging your state machine for handling usb setup packets and standard requests and trying to talk to the SIE than actually working on the unique code for your application if you start from scratch. Debugging USB hardware on that level usually requires a protocol analyser or at least capture hardware and that is *very* expensive, at least for hobbyists and educators.
Regardless, you don't *have* to use code generation or libraries to talk to the other controllers, if you want register access they all support it so I'm not sure if I've given you the impression that they are mandatory for freescale/nxp, or you have some other reason for seeing STM as the only painless option?

Just for anybody's reference, the only reason we usually stick to 6kro for usb boards is that the boot protocol for HIDs (what you use at the bios level) is 6kro and it's cheaper and easier to just leave the board in boot protocol mode all the time rather than support both protocols.
There's also a python lib for generating descriptors too, I think.

[twiddle]

What's odd about that lufa code, flabbergast? Seems pretty standard for initialising those structs to me...

[hbar]

Thanks, both of you. Twiddle: STM32 is the only option if you want all three criteria I mentioned covered, because LPC requires a crystal, and Kinetis can't be programmed in the factory state without additional hardware.

I haven't compared their USB SIEs and libraries/ROM codes/etc. simply because I haven't looked at them. My USB experience is with the Cypress EZ-USB FX and FX2, which is probably a lot more complex than any of these (I didn't use iso, but bulk transfers with DMA and their ingenious waveform-based GPIO system on the FX2 is wonderful but can be very hard to get right).

ħ

[twiddle]

Ah, my omission. Some kinetis devices support a usb-based HID bootloader in ROM, check here for a list of the parts.
http://www.freescale.com/webapp/sps/sit ... code=KBOOT The kl27z is one such part, rom bootloader and crystalless was why I picked it.

Do bear in mind I went for a specific 12mhz crystal on the LPC prototype, there are probably smaller ones you can use on the LPC chips without trouble, I didn't base the one I picked on any recommendations from NXP, it's actually just the same one I used on my stm32 board. Farnell/element14 shows about 20 8mhz crystals in 5x3mm size for eg - is this still too much room for you? I've also just managed to find the LPC 11u68 range which have crystal-less low speed usb and the rom bootloader too, according to the site: http://www.nxp.com/products/microcontro ... JBD48.html
Just thought I'd let you know, my knowledge of the product lines involved is less than perfect

[vvp]

Which STM does not require crystal for full speed usb?
Because "USB Hardware Design Guide" (AN0046 - Application Note) for STM32F373 contains:
When designing hardware for a self powered USB Device, consider the following:

• Use a 48 MHz (2500 ppm) crystal.

[twiddle]

The one in my design uses a crystal, but STM32L0x2 has crystal-less USB:
http://www.st.com/web/en/catalog/mmc/FM ... sc=stm32l0

[hbar]

... but no USB bootloader. After some searching last night, I identified the STM32F072 and 042 as the best candidates because they support crystal-less USB as well as the USB bootloader. Strange that the low-power "L" series doesn't give us this combination.

Will check up on Freescale's bootloader when I have the time.

ħ

[twiddle]

Ah right, I didnt think to check that for the L series. It isn't really important to me as I have a j-link EDU, but I'll remember it nevertheless.

[flabbergast]

Yes, STM32F072 and 042 are my favourites. I've made a small breakout board for STM32F042 in TSSOP-20 package (not enough pins for a bigger keyboard, but should be good for playing around). I haven't gotten around to order the chips though (I'm waiting until my order reaches £20 from farnell to get free shipping). So it's not tested yet. (I should say that I've got a very similar board for the USB-less 030, and that one works fine, but with serial bootloader of course.)

https://oshpark.com/shared_projects/2ESB57Jk

I have 3 PCBs from OSH Park, I can part with one if one of you would like (for shipping). I've got all the components except the chip, so if you need those I can include those if you're missing some.

By the way, the STM32 DFU bootloader works with the open source dfu-util (I've tried with 072 on the STM discovery board).

EDIT3: I'll also share the EAGLE files in a bit.

EDIT4: There are a couple of components that aren't really necessary, certainly not for a keyboard purposes - like a ferrite bead and two caps for the analog VCC, I think it's enough to put one cap and bridge the bead pads if analog functions are not needed.

[flabbergast]

What's odd about that lufa code, flabbergast? Seems pretty standard for initialising those structs to me...

Yes, the structs are fine

It's just that all the functions have names which are very long, and because of "versatility" the nesting of functions goes quite deep, and it is scattered among many source files in different directories. I suppose this is inevitable when it supports 3 different architectures (AVR8, XMEGA, UC3), but it makes it very annoying to dig out what the functions are actually doing.

If you compare this to Paul's code for teensy - from that it's relatively easy to understand the USB stack for AVR8, and what's doing what, on which events, etc... On the other hand, he writes descriptors just as a list of hex numbers, so it's annoying to modify

Not that any of this is relevant for the present discussion

[twiddle]

It's just that all the functions have names which are very long, and because of "versatility" the nesting of functions goes quite deep, and it is scattered among many source files in different directories. I suppose this is inevitable when it supports 3 different architectures (AVR8, XMEGA, UC3), but it makes it very annoying to dig out what the functions are actually doing.

This may be heretical given that the official IDEs are eclipse-based and people seem in general to be really picky about using pure FOSS with ARM gcc, but this is one reason I tend to use VisualGDB whenever I'm working with a chip that is supported. This means I can do my development work in Visual Studio and leverage the excellent Visual Assist plugin which IMO is the best indexer/code completion/refactoring tool available for C/#/++ , but still use my j-link and GDB for debugging. I'm sure there's some extensions or whatever for Eclipse, but VAX is fast and is great for finding where symbols are defined as well as locating all references to a symbol in the project, even on very large codebases (I'm an Unreal developer by trade, the engine is 35k files of source and searches with VAX are still nigh instantaneous). The inbuilt search functionality in Eclipse has been really lacking in comparison when I was testing Kinetis Design Studio/LPCXpresso which was disappointing.


Given I can basically get instant results of the sort you can see here, its trivial to use 'jump to definition/jump to declaration' to see what a function is doing, or find where that function is being called. Tends to disguise horribly organised code to the point I no longer need to care, which might be a bad thing for my own code but for reading the work of others it's much easier.
I don't really think this discussion of tools/using others' source as reference is entirely irrelevant, its definitely part of my own experience with using the different controllers, so by all means continue discussing if you wish

By the way, the STM32 DFU bootloader works with the open source dfu-util (I've tried with 072 on the STM discovery board).

Yep, this is what I used on my custom dev board. Was just a bit irritating to find that STM have bolted on their own stuff to the spec, meaning that dfu-util was pretty much the *only* implementation I could find, and its fiddly to use on Windows 8/x64 (have to mess about with overriding the default USB driver to get the program to detect it).

[hbar]

Aaaaaarrrrgggggh, the choice of ARM MCUs from ST, NXP, Freescale, etc. is really amazing. What's more amazing still is the lack of a matrix that shows the really important features of each model. I just discovered that despite being listed on the page of Freescale chips with the ROM bootloader, the KL17x doesn't actually have USB, which I find confusing: they could have at least mentioned that not all chips in the list support USB, even though they have a bootloader. The KL27x is therefore the platform of choice.

ħ

[hbar]

So far, it looks like NXP, ST, and Freescale all have decent offers. In terms of integration, it appears that Freescale wins altogether because you can not only operate crystal-less and program via USB, but leave voltage regulation to the chip as well (only a small 2,2µF capacitor required) and can even be battery-powered with automatic switching between sources (how convenient for Bluetooth!). Now ST has the advantage of offering all this (minus the regulator) in a TSSOP20 package if you need it for easy soldering (not that QFPs are particularly hard, though, with a mini-wave tip I prefer them to everything with larger pitch, in fact). (And, shhhhhh, Freescale offers free samples, the others don't.)

Damn, this thread is starting to become a product selection matrix, something the manufacturers should have created in the first place.

ħ

[twiddle]

Yeah a bit that way, haha
For what its worth I'm strongly considering the Freescale MKL27z for my wired project I'm working on, but I'm looking at a Nordic nRF product for BT. Where did you see the automatic switching mentioned in the specs, though? I didn't spot that.

If you find Freescale's sample program useful, maybe drop them a line to tell them? I am hoping they will keep it going post-merger with NXP.

[flabbergast]

Yes, exactly

Ad Freescale: I've played with mchck (MK20DX128VLF5, same MCU as infinity keyboard, very similar to teensy 3.0). I didn't like the fact that the DFU bootloader was in the main flash: it was annoying to compile into the prescribed space (I needed a special version of the toolchain), I messed it up a couple of times by programming the chip with bad firmware, which meant that I had to dig up the Bus Pirate again... I know - all this is eventually not an issue, when I learn to do things properly, but it made me search for an alternative...

I liked that I didn't need a regulator, but one should be careful with the consumption. For a keyboard it's definitely fine though. Not sure about a bluetooth module.

Free samples: ST offers some as well, although not for the chips I want the most They do have STM32F072CBT6 now (LQFP-48).

I like TSSOP-20 because it's even smaller than LQFP-48. I really like small (as you can tell by my small breakout I suppose). What bummed me about Freescale is that the newer lines (ie. newer than the chip that's on mchck, like KL2*) don't have chips that small.

[twiddle]

My sample requests, from an .edu domain no less, basically languished without any response at all from ST. I guess I'll have to try again - I've been buying all the parts from them and NXP so far.

[flabbergast]

My sample requests, from an .edu domain no less, basically languished without any response at all from ST. I guess I'll have to try again - I've been buying all the parts from them and NXP so far.

OK, I did not actually get anything from them yet. I'll report (.ac.uk domain

[hbar]

I just got my samples from Freescale, I'm currently putting together a wishlist for a good keyboard framework to be implemented on it, and thinking of designing a PCB for it.

How's progress, those of you who already have working hardware?

ħ