PIC16F1455 -- USB interface

[Teemo]

Hello!
Adding USB interface to projects seems quite popular these days. And now this 8 bit PIC chip caught my attention.
The PIC16F1455(/59).
Anyone used this chip already?
Is it possible to run the usb at this chip as virtual COM port? Like FT232, only without FT232.
http://ww1.microchip.com/downloads/en/DeviceDoc/41639A.pdf

[MikeK]

I haven't used that particular chip, but any of the USB-capable PICs are capable of acting as a virtual COM.  I have the 28-pin 18F2455 acting as a virtual COM right now.  Your chip certainly has enough RAM and code space to do it.

EDIT: I should add that Microchip's Application Libraries includes code for a virtual COM port.  All you would need to do it change the necessary parts for your particular chip.

[Teemo]

Thanks MikeK! This certainly gives me hope, that might be able to do it.

From Microchips Application Libraries it is hard to find things.

[MikeK]

Do you already have this chip?  I put a couple on my next order, which won't be for a while.  But if you wanted to test it I could compile a simple COM tester program for that chip.  I'm not offering to build anything beyond that, but it would be a test to satisfy both of us.

[Teemo]

Hi MikeK!
I do not have the chip yet, I also have it in my next order.  I would be very happy if you can share simple USB COM program.

I  just started to learn C language. My previous programs are in assembler, and for 12F 16F chips, so with this new chip I  am trying to add USB connection to those without having to reprogram to 18F series.

I tried compiling some examples form Microchip's Application Libraries for PIC16F1455(/59) but it seems that the library code do not have full working examples for that chip yet. There is so much to define and I can't figure out what to #define and where. The tip you gave first to look into those libraries was very helpful to get me started anyway. I guess I can figure out this C logic over some time.

[poorchava]

I have one suggestion for people trying to do USB on PIC16/PIC18:

GO BUY FTDI.

I have had projects with integrated USB PICs and I'll be damned if I ever want to do that again. Only viable way to do USB on USB-enabled controllers from Microchip is to use FTDI (or similar, I am referring to FTDI as 'generic USB<->uart/spi bridge).

[ivan747]

Adding an FT232 means added cost but it makes sense for a one-of project. But learning USB on a PIC is useful.

[Baliszoft]

I have had projects with integrated USB PICs and I'll be damned if I ever want to do that again.

Could you be a bit more specific? I am working on such a project (with PIC18F14k50) at the moment and havent't experienced any strange behavior. Writing the USB firmware is not an easy task though, once properly written it will outperform any FTDI solution.

[Teemo]

I have one suggestion for people trying to do USB on PIC16/PIC18:

GO BUY FTDI.

I have had projects with integrated USB PICs and I'll be damned if I ever want to do that again. Only viable way to do USB on USB-enabled controllers from Microchip is to use FTDI (or similar, I am referring to FTDI as 'generic USB<->uart/spi bridge).

I already waited for someone to suggest using FDDI . Yes, can you be specific about problems you experienced, so we can avoid some? It is the programming, right?
Anyway I am stuck with the idea of PIC talking directly to USB. Not to mention that this FDDI chip costs about 5 times more than PIC itsef.

[JoannaK]

I wonder how they manage to make all those cheap USB devices, like mouses etc. I'm quite sure not all of them can be custom ASIC.s, since there are so many different set of features and manufacturers? I would expect at least some of them to be cheapish mikrocontrollers with inbuild USB:s?

[andersm]

AFAIK, mice often use cheap microcontrollers. Cypress seems to be a popular brand. One of the gaming mouse makers make a big point in their ad copy of the fact that their top-of-the-line model uses an ARM MCU - but these days that's probably where the cost/benefit sweet point lies. The MCU also seems mostly used to drive cosmetic LEDs and an LCD menu display.

[poorchava]

Ok, so the main problem is that USB is nasty when it comes to timing. Microchip's stack works to some extent, but for some reason they noted in documentation that inperrupt driven operation is not recommended and experimental, so best solution is to use polling, which in many cases makes writing software pain in the ass. This is because USB requires control transfers typically once every 1ms. And if u ask: yes, I have tried interrupt driven operation, but the context switching time was very high and it caused problems with contant timing of other interrupts. You couldn't set that to low level, because it made connection unstable.

Another thing is that you CANNOT debug an MCU running USB, at least not without ICE debugger. This is because when you pause the program, the USB module also stops functioning, which means that PC detects USB fault and connection is lost. And the only way to recover the connection was to reconnect the usb and repower the MCU. I can't exclude possibility that it was USB stack which was at fault. And No, the USB module in PICs doesn't have any hardware protocol logic, only plain hardware layer which means that there is no handshake or control transfer automation and you have to do it all by yourself.

Another thing is that USB is a total pain in the ass when you would want to use it in other mode than virtual COM port. You not only have to write software for MCU but also develop a device driver for Windoze, which is task for a masochist.

Also: IIRC Microchip's stack had some weird licensing scheme, which forbode you from releasing you source code if the program contains the Stack, which is quite weird given that you can download that stack for free.

I think that claiming PICs superior transfer rate over FTDI+PIC is not necessarily right, because in case of FTDI you use it as a COM-port with high baudrate (FTDI website claims that some chips are capable of 3Mbaud) and in case of internal USB there is quite large code overhead and lots of CPU time is lost for dealing with packets etc.

[Baliszoft]

You are right. Still, you have the possibility to make your own working usb stack (which is not! impossible) and this will make your hardware either cheaper and/or better/faster.

I admint that USB on the protocol level is not a project for beginners, they certainly should get along with an FTDI chip. That is ok, if you have to blink some leds, but i would not use it for anything serious (and high bandwidth). Everytime when i see FTDI running as a virtual com port makes me smile .

[jerry507]

I use Microchips usb functionality on a product of mine. Bootloader and serial. Works just fine. Yes, there is the debug issue but that's a problem with EVERY SINGLE integrated USB module on every micro. The same thing goes with any other vendors micros, arm or whatever for drivers. Obviously you need to do driver programming if someone isn't giving you a driver.......

FTDI chips are expensive and come with their own problems. I don't use them anymore on cost basis alone. If you want to use something, use microchip or silicon labs USB-Serial chips.

[Baliszoft]

Obviously you need to do driver programming if someone isn't giving you a driver.......

I am using LibUsb, a free library for windows (and the rest) until i will get bored and will have time to develop my own driver.

[MikeK]

As promised, here is a compiled demo program for the 16F1455 to act as a virtual COM port.  When connected it displays an intro message, and then it echoes all characters back to the host.  It expects a 12MHz crystal.

I can't vouch for it, as I have no chip to test it on.  I took a source file for the 18F2450 and made the changes for the 16F1455.

[Smokey]

I've used FTDI in a few projects before, but I just got done with my first PIC USB project using an 18f4458 (for the 12-bit ADCs).  Here is my feedback based on that.  I'll just mix up the good stuff and the bad stuff.

0) To use the built in USB, your crystal frequency needs to be a multiple of 4.  That's because they need to divide and PLL the crystal frequency to be 98Mhz then back to 48Mhz for fast USB.  Just something to be aware of.  If it's not a multiple of 4 or you get the prescaler and PLL fuses wrong, the PIC will still work but USB won't.
1)  The USB stack takes up a bunch of memory on the chip.  Like 30% for some compilers.  Make sure you take that into consideration when sizing the chip. 
2) CDC (virtual serial port) is built into windows.  You don't need any special drivers to make a virtual serial port on windows.  What you do need is an .inf file that tells windows that the USB device with a specific VID/PID that just got plugged in is supposed to get a virtual serial port.  I didn't totally get that when I started.
3) The PIC CDC serial port can run really fast.  I mean like as fast as your terminal can handle it.  Remembering the 1200baud days, I had to stop and make sure I really wanted to set hyperterminal to 921600.  This means that an integrated USB solution will be able to dump out data, even using the CDC port, way faster than running UART->FTDI->USB.  The other cool thing is that the PIC doesn't care what speed the terminal tried to connect to it on.  It just does it.  No speed matching problems.
4) If CDC isn't fast enough for you, you can always change your PIC code to support HID (which is also built into windows) or some custom deal which actually would require a driver to dump data REALLY fast.
5) The compiler manufactures have licenses on the USB stacks that aren't always the most hacker friendly, but some guys over at DangerousPrototyes actually developed a completely free and open source PIC USB stack from scratch.  It's crazy.  I haven't used it but it's supposedly stable, fully supports CDC and HID, and is actively developed.
6) Dealing with CDC on windows can be a little bit of a pain because of the necessity to create the port every time the device is plugged in.  Windows REALLY doesn't like it when you reset the PIC while you have an active CDC connection.  It just hangs the port till you disconnect and reconnect again with the port closed.  An FTDI solution can stay connected while the PIC resets.  You are screwed with both solutions though if you have the terminal open and unplug the USB.  Not something you had to deal with using a real serial port.

So after all that's, whats my take on PIC USB?  Well that depends on the project.  The learning curve is a little higher, but not super bad.  I got down on PIC USB for a while when I was starting, but now that I have a functional framework that I can reuse, I'm warming up.  If your project only needs the capability of a standard serial port and you have no intention of using any of the other USB features like HID or mass storage, then FTDI is a really attractive solution.  You literally don't need to learn anything new to code on the PIC with an FTDI hanging off it.  Just send UART messages like normal and it saves a lot of space so you can use a cheaper chip from any of the PIC families.  That said, PIC USB is really cool.  USB has so many modes built in that it opens up a lot of options for high speed communications.  In a way it's like adding in a CPLD instead of discrete logic.  Discrete logic works, but with a CPLD you can always reconfigure it later with just a code change. 

There ya go.  2cents.

[JoannaK]

As a note for those who try to implement Usb with a pic using C-code. I have now spend some time to look the code different C-compilers produce and I would definitely recommend against XC8 (free version). This is kinda unfortunate cause it's most likely the first C anyone might try with their new MplabX installation. But the code generation of the XC8 is so bad, that code may end up twice the size and 2-4* slower than with other systems. 

Usb format has quite hard timing requirements on acknowledges and bus turnaround, so I would not be surpriced if at least some parts of the problems could be due lousy C-compiler used. Unfortunately I have no real good numbers of the available C-compilers, but IMHO it would be smart to look what kind of code actually will be generated.

[MikeK]

Yeah, I don't use Microchip's compiler.  That demo program I posted was written in an obscure language called JAL.  It compiled to 1.5K (out of an available 8K for that chip).

There's a USB stack on Dangerous Prototypes (in ASM I think), which is even more code efficient.

[Teemo]

Hello! Thanks to everybody for the good info.

I was just about to ask MikeK for the source code, but if it is in JAL language it is not that much interesting to me as I have decided to learn C.
I will look up that Dangerous Prototypes code, this sounds interesting, even better if it is in asm.

My latest plan is to develop the code for the 16F1455 in XC8, based on the Microchip Application Libraries and compile it on the demo Pro mode. Then take look at the assembler code it produces, optimise it manually and take note the resources it uses. And the end result being the assembler macros collection for USB virtual serial port, that I can use in the future projects, without worrying about the XC8 pro mode expiring.

[baljemmett]

My latest plan is to develop the code for the 16F1455 in XC8, based on the Microchip Application Libraries and compile it on the demo Pro mode.

You may want to check the compiler requirements for the Application Libraries -- I don't know if it affects all of them, but the TCP/IP stack doesn't seem to support XC8...  I had a go at hacking it up by fixing compilation errors whichever way I could, but the result didn't actually work.  Had to install the old, no-longer-recommended C18 compiler to get a working binary out.

[astrononenov]

I have compiled the CDC Serial converter demo from the Microchip application library for PIC16F1455, using MPLABX and XC8 1.12 in free mode. I tested it on a real chip, it seems to work fine. The only circuit used was 10k between MCLR and VSS, 470nf between VUSB and VSS and 100nf between VCC and VSS, with the chip powered from USB. No crystal required for USB operation.

[jerry507]

Our bootloader was busted in XC8 too, so we're staying away from it for a while. Not worth the trouble since you can just get C18 (sans optimization obviously).

[Teemo]

I have compiled the CDC Serial converter demo from the Microchip application library for PIC16F1455, using MPLABX and XC8 1.12 in free mode. I tested it on a real chip, it seems to work fine. The only circuit used was 10k between MCLR and VSS, 470nf between VUSB and VSS and 100nf between VCC and VSS, with the chip powered from USB. No crystal required for USB operation.

All right! Good work astrononenov! So now we know for sure that it can be done using 16f1455 and XC8. Can you share your demo code here?

[astrononenov]

There you go..