Help choosing a crystal free usb MCU

[Jaunedeau]

Hi,

  I am making a small PCB and I will need to produce a small batch (about 20 pieces). I will hanve to hand-solder everything, so I'm looking for something with a very low part count. I will need USB (at least for firmware updates).

  From the parts that are available at local store, the PIC16F1455 is pretty close to what I needed
-Can be programmed with the pickit3 I already own
-I can do USB with only 1 chip and 3 caps (+1 resistor for first flash, but this one is on my programming cable)

  But it has some drawbacks :
-Few flash available (USB stacks takes more than half of it)
-Annoying page switching (low en PIC architecture )
-No Arduino environnement support (I don't use / like arduino, but other people who will maintain the code would appreciate it)

   Is there any higher-end PIC or AVR or Cortex that can do USB with almost-zero external component, and is available with a 0.65mm or larger pitch, and is not too expensive ? (I have AVR and Pic programmer but no Cortex, so if cortex comes with a cheap programmer or USB Bootloader pre-flashed, it's nice)

Thank you,
John.

[wraper]

Silabs universal bee
http://www.silabs.com/products/mcu/8-bit/efm8-universal-bee/Pages/efm8-universal-bee.aspx
they even have 100mA 3.3 Vreg which can power external devices.

[Jaunedeau]

The EFM8UB20F32G-A-QFP32 seems interesting. It does come with preinstalled USB bootloader, and should not need more than two external capacitor !

If someone has other ideas, let me know. This one is in my short list !

[andersm]

Atmel's SAMD11 is a Cortex-M0+, available in 20- and 14-pin SOIC. However, it doesn't have a lot of flash and no ROM bootloader.

[Delta]

PIC18 series?

[eck]

STM32F042K6T6 seems to fit the bill. The Nucleo board for this can be used as an external SWD debugger/flasher if needed.

[janoc]

STM32F042K6T6 seems to fit the bill. The Nucleo board for this can be used as an external SWD debugger/flasher if needed.

I would rather go for the STM32F103 series or even the STM32F3/F4 series. Not much more expensive, but you get a faster MCU but mainly much more flash and RAM available. The F0 chips can, in theory, run USB, but you are going to be hard pressed to fit a USB stack and some significant user code in the small amount of memory available. 32kB of flash on a PIC or AVR is a ton but it is very little on an ARM. Simple blink a LED code can take 2kB or more, with the vector tables and startup code alone.

Moreover the STM32F042K6T6 is fairly new, the Nucleo board you are mentioning is not all that well supported yet (doesn't work even in mBed, despite the "mBed enabled" logo).

[hans]

PIC24FJ64GB002 has crystalless USB support, 28-pin DIP, SOIC or SSOP (GB004 is 44-pin TQFP 0.8mm). 64KB FLASH, 8KB of RAM

XC16 is based on GCC, however they do not give the -O2, -O3 and -Os away for free.

I don't think there is any PIC32 that has accurate enough crystal, so if you want a 32-bitter you need to go elsewhere (ARM?)
There are also some PIC18s, but honestly I don't know why anyone would bother anymore with those.

[Howardlong]

PIC24FJ64GB002 has crystalless USB support, 28-pin DIP, SOIC or SSOP (GB004 is 44-pin TQFP 0.8mm). 64KB FLASH, 8KB of RAM

XC16 is based on GCC, however they do not give the -O2, -O3 and -Os away for free.

I don't think there is any PIC32 that has accurate enough crystal, so if you want a 32-bitter you need to go elsewhere (ARM?)

I used the PIC24FJ32GB002 in a commercial USB product a few years ago, sold around 10k units, it worked very well. One of the keys was that it didn't need a crystal. I managed to get a USB bootloader in there too. I managed to make it work with a codec to even though it didn't have a codec interface, generating the appropriate signals by wiring the SPI and Output Compare peripherals using the peripheral pin select, but that's a whole other story.

You are right about the PIC32 requiring a crystal for USB, it would have been great in the PIC32MX2xx series. I do wonder sometimes at Microchip's internal communications!

[eck]

I would rather go for the STM32F103 series or even the STM32F3/F4 series. Not much more expensive, but you get a faster MCU but mainly much more flash and RAM available.

Yes, but at least the F103 is not crystal-less, and none of the parts have a package options with pitch > 0.5mm (the small QFP32 F303 doesn't seem to have USB?).

The F0 chips can, in theory, run USB, but you are going to be hard pressed to fit a USB stack and some significant user code in the small amount of memory available. 32kB of flash on a PIC or AVR is a ton but it is very little on an ARM. Simple blink a LED code can take 2kB or more, with the vector tables and startup code alone.

Depends, I have a simple USB stack which emulates a CP2102 serial port running in 3k, including vector tables and startup code. This is on a F103, and no, it's not coded in assember

Moreover the STM32F042K6T6 is fairly new, the Nucleo board you are mentioning is not all that well supported yet (doesn't work even in mBed, despite the "mBed enabled" logo).

Right, if you need mbed, which is nice for for fast prototyping. But it seems STM32CubeMX is fully supported, and I would not expect too many differences to other STM32 parts. The USB block for example looks very similar to the one on the F103.

[Bassman59]

Silabs universal bee
http://www.silabs.com/products/mcu/8-bit/efm8-universal-bee/Pages/efm8-universal-bee.aspx
they even have 100mA 3.3 Vreg which can power external devices.

This.

[janoc]

Yes, but at least the F103 is not crystal-less, and none of the parts have a package options with pitch > 0.5mm (the small QFP32 F303 doesn't seem to have USB?).

Yep, it doesn't have one. However, if one can solder a 32 pin 0.65mm pin pitch QFP, they can for sure solder even 0.5mm 48 pin QFP no problem, even on a home-made board without soldermask in a pinch. The technique is exactly the same. And that will give access to many more parts. There just aren't that many parts made in 0.65mm pitches.

Depends, I have a simple USB stack which emulates a CP2102 serial port running in 3k, including vector tables and startup code. This is on a F103, and no, it's not coded in assember

Well, good for you. The ones I have seen need at least few kB more. Also serial port/CDC device is quite simple - try to do some more complex HID and just the descriptors could be a few kB. Of course, it depends on what exactly are you planning to do with the chip, so the small one could be perfectly fine for your application.

Right, if you need mbed, which is nice for for fast prototyping. But it seems STM32CubeMX is fully supported, and I would not expect too many differences to other STM32 parts. The USB block for example looks very similar to the one on the F103.

The latest Cube has the drivers and everything for these boards, however, I am still battling with getting even a stupid blinky LED to work with it - even their example project isn't working. I am using a "naked" GCC toolchain that they don't provide settings for, only the stupid project files for the IDEs. (Hey, ST, why can't you ship a silly makefile with all the necessary settings instead of all that project crap? We know how to set up a project in an IDE ...), so I had to reverse engineer the settings from that. And apparently something isn't right, because my startup code causes the chip to throw an exception and end up in a loop. I have traced it to a linking issue but I don't have a solution yet.

I have never had such issues with the STM32F303 Discovery board, the F030x chips or F103 series - but there I was able to use the standard peripheral libs and not this HAL nonsense.

Update

I have managed to fix this - it is a problem with GNU linker. If one library contains both a weak and a strong symbol for the same identifier, then the linker will not replace the weak by the strong one. It just picks the weak one. Adding all HAL sources to the compilation of my main code and not to a library has fixed it. 


Re mBed - I don't really need mBed, I found it a bit too limiting to my taste, but in the light of the issues above, I wanted to try it and perhaps lift the known-good gcc flags from the exported project. Unfortunately, the darn thing doesn't support these boards yet!

Update - 14.11.2015
I have just rechecked the mBed website and the new STM32F303K8 and F042x boards are supported now.

[eck]

Yep, it doesn't have one. However, if one can solder a 32 pin 0.65mm pin pitch QFP, they can for sure solder even 0.5mm 48 pin QFP no problem, even on a home-made board without soldermask in a pinch. The technique is exactly the same. And that will give access to many more parts. There just aren't that many parts made in 0.65mm pitches.

Fully agree, once you include 0.5mm as an option, you get many more choices. Besides QFP48 which really covers a lot of different interesting parts across all vendors, you also get TSSOP.

The latest Cube has the drivers and everything for these boards, however, I am still battling with getting even a stupid blinky LED to work with it - even their example project isn't working. I am using a "naked" GCC toolchain that they don't provide settings for, only the stupid project files for the IDEs. (Hey, ST, why can't you ship a silly makefile with all the necessary settings instead of all that project crap? We know how to set up a project in an IDE ...), so I had to reverse engineer the settings from that. And apparently something isn't right, because my startup code causes the chip to throw an exception and end up in a loop. I have traced it to a linking issue but I don't have a solution yet.

I have never had such issues with the STM32F303 Discovery board, the F030x chips or F103 series - but there I was able to use the standard peripheral libs and not this HAL nonsense.

I try to avoid either lib, and use them only as reference. The HAL seems to cover more (polled, IRQ and DMA mode for most peripherals), but it tends to have bigger code size. The smaller and less complex STM32 parts (F0, F1) are actually quite well suitable for bare metal. And then you can skip the startup code altogether

I've been very pleasantly surprised by the EFM32 emlib though. It works as expected, does what it needs to do, and doesn't bring a whole crapload of complexity layers with it (KSDK, I'm looking at you!).

[janoc]

I try to avoid either lib, and use them only as reference. The HAL seems to cover more (polled, IRQ and DMA mode for most peripherals), but it tends to have bigger code size. The smaller and less complex STM32 parts (F0, F1) are actually quite well suitable for bare metal. And then you can skip the startup code altogether

Well, you still need to set up the vector table and the clock tree, as a minimum. Whether you use the ST-provided startup code for this or make your own wouldn't make much difference, that code is fairly minimal.

Unfortunately, this is where the problem is in my case - the clock setup goes cactus because there is some problem with the way GCC links the HAL code. Or rather doesn't, in my case - the clock init code in the HAL is in two functions, one is an empty stub designated as a weak symbol and the other one is the real code. The linker doesn't manage to resolve this in my case and the code jumps to the lalaland once it tries to call that function ...  It is most likely some problem with the compiler/linker flags, but I didn't manage to find it yet.

I've been very pleasantly surprised by the EFM32 emlib though. It works as expected, does what it needs to do, and doesn't bring a whole crapload of complexity layers with it (KSDK, I'm looking at you!).

That's interesting info, I may actually look at these parts too. I chose the ST parts, because they are cheap (especially the incredibly priced dev boards) and easily available, the Energy Micro parts seem to be a bit more expensive on the cursory look.

[Psi]

STM32F042K6T6 seems to fit the bill. The Nucleo board for this can be used as an external SWD debugger/flasher if needed.

I've used the STM32F042 for a project, it works well. At least for what i was doing.
I was programming it with emblocks.
Didn't use its USB though.

[bson]

If you don't need the full-out 32-bit ARM architecture then I can highly recommend the 16-bit MSP430 as a replacement for PIC.  Like ARM, it has a flat address space (unless you try to shoehorn something onto it that really belongs on a 32-bit processor), a gcc/g++ port by Red Hat sponsored by TI, and the TI CCS C/C++ compiler is quite competent.  With careful use of stdint to declare actual sizes and other good practices, like C++ namespaces and use of classes to factor so you can separate say code to drive an LCD panel from the underlying SPI or other bus or peripheral it's actually connected to, porting code back and forth with ARM is very doable.  Unlike XC8/16 which lives in its own little world without the ability to reuse code that's tried and true.  The MSP430 is like a hybrid between the 68k and pdp-11, so is very easy to learn.  Like most sane compilers for instance both TI's and gcc will just remove unreachable code (often the result of macro expansion, like if(false) { ... } else { ... }), both in the compiler and linker.  It has good notions of pure functions, handles volatile and const volatile properly, good linker cmd files to control address space layout - just generally a competent compiler.  The eclipse-based IDE is so-so, and it's Windows only which is a drawback, but overall it's a nice step up from MCP.  And it's free for code up to 16k which frankly is probably about how much you want in a 16-bitter before considering a step up to ARM or MIPS.  Other drawbacks: the series is all 2.0-3.6V (not even 5V tolerant) and no DIPs (but getting an SSOP20 onto a breakout carrier for breadboarding isn't rocket science).

[ElectricGuy]

PIC18F25K50 or 45K50. 32K of Rom.
http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC18F25K50