PIC16F1455 -- USB interface - Page 1
Forum section: electronics / general

author: Teemo
author_rank: Regular Contributor
timestamp: January 15, 2013, 05:45:40 pm
content: 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

author: MikeK
author_rank: Super Contributor
timestamp: January 15, 2013, 10:01:40 pm
content: 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.

author: Teemo
author_rank: Regular Contributor
timestamp: January 15, 2013, 11:00:03 pm
content: Thanks MikeK! This certainly gives me hope, that might be able to do it.From Microchips Application Libraries it is hard to find things.

author: MikeK
author_rank: Super Contributor
timestamp: January 17, 2013, 12:58:21 am
content: 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.

author: Teemo
author_rank: Regular Contributor
timestamp: January 17, 2013, 09:43:37 am
content: 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.

author: poorchava
author_rank: Super Contributor
timestamp: January 17, 2013, 10:59:49 am
content: 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).

author: ivan747
author_rank: Super Contributor
timestamp: January 17, 2013, 11:11:40 am
content: Adding an FT232 means added cost but it makes sense for a one-of project. But learning USB on a PIC is useful.

author: Baliszoft
author_rank: Frequent Contributor
timestamp: January 17, 2013, 01:11:17 pm
content: Quote from: poorchava on January 17, 2013, 10:59:49 amCould 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.

author: Teemo
author_rank: Regular Contributor
timestamp: January 17, 2013, 02:06:50 pm
content: Quote from: poorchava on January 17, 2013, 10:59:49 amI 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.

author: JoannaK
author_rank: Frequent Contributor
timestamp: January 17, 2013, 03:13:11 pm
content: 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?

author: andersm
author_rank: Super Contributor
timestamp: January 17, 2013, 03:52:26 pm
content: 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 theirtop-of-the-line modeluses 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.

author: poorchava
author_rank: Super Contributor
timestamp: January 17, 2013, 05:08:33 pm
content: 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.

author: Baliszoft
author_rank: Frequent Contributor
timestamp: January 17, 2013, 06:29:43 pm
content: 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.

author: jerry507
author_rank: Regular Contributor
timestamp: January 17, 2013, 08:04:28 pm
content: 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.

author: Baliszoft
author_rank: Frequent Contributor
timestamp: January 17, 2013, 08:27:27 pm
content: Quote from: jerry507 on January 17, 2013, 08:04:28 pmI 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.

author: MikeK
author_rank: Super Contributor
timestamp: January 18, 2013, 11:51:06 pm
content: 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.

author: Smokey
author_rank: Super Contributor
timestamp: January 19, 2013, 02:41:02 am
content: 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.

author: JoannaK
author_rank: Frequent Contributor
timestamp: January 19, 2013, 04:51:44 am
content: 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.

author: MikeK
author_rank: Super Contributor
timestamp: January 19, 2013, 05:02:50 am
content: 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.

author: Teemo
author_rank: Regular Contributor
timestamp: January 21, 2013, 12:12:49 pm
content: 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.

author: baljemmett
author_rank: Unknown
timestamp: January 21, 2013, 06:42:00 pm
content: Quote from: Teemo on January 21, 2013, 12:12:49 pmYou 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.

author: astrononenov
author_rank: Newbie
timestamp: January 21, 2013, 09:28:57 pm
content: 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.

author: jerry507
author_rank: Regular Contributor
timestamp: January 21, 2013, 10:08:28 pm
content: 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).

author: Teemo
author_rank: Regular Contributor
timestamp: January 22, 2013, 12:40:03 pm
content: Quote from: astrononenov on January 21, 2013, 09:28:57 pmAll 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?

author: astrononenov
author_rank: Newbie
timestamp: January 22, 2013, 03:42:13 pm
content: There you go..

author: Teemo
author_rank: Regular Contributor
timestamp: January 22, 2013, 04:21:57 pm
content: Thank you astrononenov!

author: JoannaK
author_rank: Frequent Contributor
timestamp: January 23, 2013, 12:27:50 am
content: Interesting comments at the Hardwareprolife.h file. Apparently some combination of the usb-capable chip+ demo-board will not work due excessive noise at the Vcc.

author: hans
author_rank: Super Contributor
timestamp: January 24, 2013, 04:44:17 pm
content: Quote from: poorchava on January 17, 2013, 05:08:33 pmYou make it sound its all Microchips fault, but on other platforms it is exactly the same issue.Some guys from NXP Cortex m3 devision gave a workshop at our college on their series of microcontrollers, and they said that debugging USB is a pain. It always will be. I do agree, a seperate FTDI USB chip is much easier, but much more expensive.I've worked with USB on microchip parts, and once the hardware is up and running it isn't that difficult. I got a USB combined device running with a CDC COM Port + HID Joystick (4 analog axis, 32 buttons, POV hats etc.) in no time. Works a treat.I used a PIC24FJ64GB004 in combination with a PICKIT2. Writing software without a debugger is doable, but takes a bit more time and effort.I think such cheap controllers can be very interesting because you let it do the same thing as a FTDI chip, but alot much more if you write a little bit of software. For e.g. , you could have the PIC controller read system voltages, temperature, and connect the UART to your main controller which is application specific. Write a composite USB device, so you can have multiple UARTs, and dedicate one to system and one to the application. And that for 2$-3$ in parts cost + a little bit of development time.For bigger controllers its doable to integrate it into 1 chip, but is more challenging as previously mentioned.Moreover, with a CDC USB COM Port there is no issues with wrong baudrate, because there isn't any baudrate.FTDI chips can run 3MBaud, but that's barely the UART section which connects to a FIFO buffer. The USB section only works fast in a limited set of conditions. I can't recall the maximum speed I achieved with both though..

author: Baliszoft
author_rank: Frequent Contributor
timestamp: January 24, 2013, 04:54:54 pm
content: Quote from: hans on January 24, 2013, 04:44:17 pmI am running roughly 4mbits with a pic18f14k50 using bulk transfers and with an unoptimized asm code. I guess i could achieve at least 6mbits or even more, but since i only need ~300k for my application, i never took any efforts to make it faster.

author: Subra
author_rank: Newbie
timestamp: February 19, 2013, 12:33:25 am
content: I am new to PIC. I have been using Freescale so far. For my current application, the PIC16F1455 with USB interface looks perfect pricewise and capabilitywise. This is my question. PIC microcontroller will control a device based on input received via WiFi. The WiFi networking card connects wia USB port. If I connect this networking card to USB pins of PIC16F1455, will I be able to get the commands transmitted via WiFi? I need help in the USB area to extract the command.Thanks,Narayanan Subramanian

author: JTR
author_rank: Regular Contributor
timestamp: February 19, 2013, 02:38:31 am
content: Quote from: Subra on February 19, 2013, 12:33:25 amYou got the correct answer on the microchip forum.http://www.microchip.com/forums/fb.ashx?m=706959You cannot use this PIC as it is not HOST capable.

author: ColdKeyboard
author_rank: Contributor
timestamp: July 09, 2013, 02:51:31 pm
content: With the working example that astrononenov posted, I've managed to make Microchips HID - Custom Demo to work.I had to edit the HardwareProfile file and also chagne some definitions (configuration bits) for this for work but as soon as I configured the devicecorrectly and burned down the hex file, I got notification that USB device is connected and Microchip example software is connecting to it without any problem.I just wanted to say, astrononenov thank you very much for sharing your code! It really helped me alot!Cheers!

author: JTR
author_rank: Regular Contributor
timestamp: July 09, 2013, 09:38:06 pm
content: Quote from: JoannaK on January 23, 2013, 12:27:50 amYes, I found the same issue on a proprietary stack not having taking close enough notice of your post on the comments in the hardwareprofile.h file. Lucky it is just an easy fix and a correction to a out of spec hardware design. I was worried initially...

author: iwl
author_rank: Newbie
timestamp: August 20, 2013, 03:36:49 pm
content: Just compiled usbserial.zip and imediately worked on my New 1455 very good work to adapt it To the standalone chip from the demo board code.Having an USB device with one 14Pin chip 2caps and some wires - amazing.

author: george46
author_rank: Newbie
timestamp: October 07, 2014, 02:24:40 pm
content: I have given up. Does anybody want to earn some bucks and put a working usb on a chip using the PIC16F1455 (OR THE PIC18F1455)?I will provide the 1ms poll and using irqs are fine. Please respond only if you can work through a registered company.

author: JTR
author_rank: Regular Contributor
timestamp: October 08, 2014, 08:39:51 am
content: Quote from: george46 on October 07, 2014, 02:24:40 pmDamn! I deregistered my company.Pity, I don't expect anyone else has written USB stacks for the 16F1455 in both C and assembler...

author: dannyf
author_rank: Super Contributor
timestamp: November 04, 2014, 08:02:10 pm
content: :the compiler would only do an 8-bit multiply. :for sure, microchip isn't the gold standard for compiler development but it is very hard to imagine that they got something this simple wrong, given the large installed base, long history of the compiler, and lack of user complaints on that particular issue.maybe you can provide a short piece of code to demonstrate the issue?otherwise, it sounds like overflowing, a mistake novice programmers sometimes make.

author: andersm
author_rank: Super Contributor
timestamp: November 04, 2014, 08:54:56 pm
content: Quote from: DiligentMinds.com on November 04, 2014, 08:24:51 pmJust to be clear, XC8 only supports C90. And int is a 16-bit type, which is clearly stated in the documentation.

author: dannyf
author_rank: Super Contributor
timestamp: November 04, 2014, 09:07:56 pm
content: I think it is a lot more convincing if you provide a piece of code demonstrating the bug. Otherwise, it is unverifiable and coding errors remain a real cause.it is also fair to the compiler vendor too: if you were in their shoes, you would want facts, not some gut,s fuzzy recollection of what might have caused the issue.hope it helps.

author: dannyf
author_rank: Super Contributor
timestamp: November 13, 2014, 12:01:44 pm
content: QuoteI think it is those incidents like that that really hurt your credibility. Lots of fluffy and no substance.If you think the compiler has made a mistake, it is easy enough to just post the lines that the compiler had issues with and everyone could see for themselves what was not working.Copy-and-paste the code is far more efficient to convince people of the compiler issues you have identified than all those words that mean nothing.