PIC with USB port - any experience?

[Andy_123]

Just want to ask if someone got any experience with new USB 18F PICs?

I just got some 2550 and 4550 and wondering if anyone already used them and can share some info.

I have some PIC experience and in a past we made quite a few USB devices based on combination of FTDI245BM and 18F PICS.

Using these new USB PIC will significantly simplify my hardware, but will require extra effort to figure out USB firmware on the PIC side.

So any help appriciated.

Thanks

 

[Nigel Goodwin]

Just want to ask if someone got any experience with new USB 18F PICs?

I just got some 2550 and 4550 and wondering if anyone already used them and can share some info.

I have some PIC experience and in a past we made quite a few USB devices based on combination of FTDI245BM and 18F PICS.

Using these new USB PIC will significantly simplify my hardware, but will require extra effort to figure out USB firmware on the PIC side.

So any help appriciated.

Thanks

They are still extremely new, but presumably application notes are available at MicroChip?, as they are for the 16C745 series. As you are obviously already aware, doing USB is a great deal more complicated than doing the RS232 you've done previously!.

 

[Andy_123]

They are still extremely new, but presumably application notes are available at MicroChip?, as they are for the 16C745 series. As you are obviously already aware, doing USB is a great deal more complicated than doing the RS232 you've done previously!.

Nigel
Yes, these PICs are extremely new. I downloaded all materials I can find and trying to make setup similar to the USB demo boards. Form my standpoint - as soon as I can get a full understanding of DEMO device FW responsible for USB comms it should be very little difference from using serial port.
I am making custom USB devices for over 2 years and really familiar with USB comms. Using these new chips will significantly simplify my designs. As always there is FW learning curve...

 

[checkmate]

Well ... I spent 3 months going from device firmware to driver. I'm pretty sure you are underestimating the complexities of usb, unless you are content with HID comms. For one, you will not understand a sample firmware until you read the usb specifications. You can either get them from usb.org, or beyondlogic.org which provides an excellent summary.

And for a fully custom usb device, I'd say that the firmware is only 40% of the work. The rest lies with the device driver.

If you have relied on ftdi devices in the past, then you are probably good at serial comms, but it reflects nothing on true usb comms.

 

[Andy_123]

unless you are content with HID comms ... And for a fully custom usb device, I'd say that the firmware is only 40% of the work. The rest lies with the device driver.

At this stage I am planning to use a virtual serial port driver only
The computer application (not mine) works with a virtual serial port, like FTDI uses, so I am planning to use a virtual port drivers to emulate a serail port. I am not looking at HID driver.

If you have relied on ftdi devices in the past, then you are probably good at serial comms, but it reflects nothing on true usb comms.

I agree, FTDI is a plug-and-play USB to serial solution, so I am looking for on-chip replacement for simple function:
- Application sends data block (up to 256 bytes) to a virtual serial port.
- USB interface brings it to the PIC memory.
- PIC does the rest controlling my device.
- Same in opposite direction.

This is a functionality I am looking for now. I think it is can be done.

 

[checkmate]

FTDI chips emulate serial comms, and they provide their own driver for their chip and their chip only. Creating a virtual serial port driver that is specific to your chip, and providing a serial-port-like usb firmware will be going to be a bigger project than implementing a fully custom usb device, at least to me.

If you insist on using their virtual com port driver, you will have to reverse engineer their descriptors, usb requests etc, as I don't remember them publishing it. This can be done either using a very high speed logic analyzer (Remember even usb1.1 signaling rate is 12Mbps), or a hardware sniffer. I havent seen any software sniffers that can capture pre-enumeration usb comms.

Anyway, what I'm trying to say is that the FTDI chip abstracts away a lot of work needed for usb comms. If you want to create an equivalent, it is not as simple as you think. Unless you are prepared to shell out 3 months of your time, maybe even longer, it's better to just stick to the ftdi chip.

Of course, you should not take what I have said blindingly. Hop over to usb.org forums. There are many who have thought your way too. Or even better, bite the bullet and learn real usb comms. I assure you that it will be more worthwhile than any other uC project you have done.

 

[Andy_123]

checkmate
Looks like I am mising something.
Here is a quote from USB page from Microchip:
**broken link removed**

Communication Device Class (CDC) firmware
The Communication Device Class firmware is the most direct way or migrating a serial port (legacy) application to USB. In fact this firmware provides direct emulation of a serial port on PC running Windows 2K and Windows XP. As the PIC18F4550 is attached to the PC, a virtual COMx port is created. All PC software using a COM1-4 port will work without modifications with the virtual COM port if only at a much higher speed (approx 1Mbit/s)

PROS: free, simple to use, easy migration from serial port applications
CONS: data transfer speed limited to about 1Mbit/s, no hardware handshake emulation (not necessary)

Memory requirements: about 4K bytes
Windows drivers: no driver required (Windows 2K/XP), xxx.inf file must be supplied

Based on this note I assume that:

- I don't need a driver, just use a Windows Virtual Port Driver with INF file Microchip provided.
- Modify CDC firmware they provided, not to write this over.
- My Application that uses computer serial port and do not need to be changed.

I downloaded both INF file and CDC firmware as well as schematics for their demo board (really simple demo).

Am I wrong in my assumptions? Am I missing something.
Again I am just starting my research with chips om my workbench and THANK YOU for your feedback.[/url]

 

[checkmate]

Oh, so microchip did a sample firmware for CDC? That would be nice, because during my time, the CDC was unstable and was not recommended for use. I have yet to have seen a really successful implmentation of CDC. That's why all usb-to-serial vendors provide their own driver instead of simply using CDC. All the resources were on Mass Storage and HID. Infrom me if it works. I would like to know too.

 

[Andy_123]

Oh, so microchip did a sample firmware for CDC?

I don't know how good this CDC FW - have nothing to compare.
It is just recently released (looks like by 3-rd party company).
At thi point I am preparing hardware test board with 18F4550, want to make it similar to the DEMO they have.

I just started looking at the source files, nothing real yet.
I'll let you know about results.

Another thing I am not sure is PID/VID that I can use.

FTDI lets customers use FTDI's VID with PID range assigned to my company by FTDI.

With Microchip we can start by using default PID/VID.
For commercial product will have to buy registration from usb.org - it was kind of costly last time I looked few years ago as we were looking at TI USB chips.

 

[BF9000]

CDC Firmware

There doesn't seem to be any straightforward app notes for the new 18 series USB PICs. Notice that anything written in assembly on the Microchip site is for the older USB PIC's. If you are already familiar with USB, impementing a CDC class device is not extremely difficult. After setting up your BDT, just monitor the status bits and respond to the requests accordingly by reading from the EP1 out buffer and determining the reqest type. Most of the work is in tediously creating tables for the descriptors. The enumeration was a bit tricky as well. I referenced the USB in a Nutshell from https://www.beyondlogic.org/usbnutshell/usb1.htm . I'm in the process of writing the asm code and hoping to finish this week. I'll keep posted.

 

[BF9000]

EP0 Out buffer, correction

I mistyped, I do mean read from endpoint0 (not EP1) buffer. I am very intersted in knowing if anyone has a good asm version for any CDC working yet.

 

[Andy_123]

Quick update:
Ran into unexpected problem - can't program 4550 with my parallel port programmer and ICprog software. Selecting 18F452 as 4550 not supported by ICprog yet.
Any ideas?
Need to load at least a bootloader.

 

[pboese]

Greetings

I've just plunged into the world of PIC programming and of course I choose to start with a PIC18F2550. The main reason is the lure of USB. So I'll be watching this topic with great interest. I'll post my own findings, successes and failures as I work my way though the project I've started. The posts to date have been very enlightening.

 

[bmcculla]

Silicon Labs has a USB controller in their line of 8051s. They provide a generic driver that works with a simple API in the firmware. I'm designing a project with it now - haven't gotten to the USB part yet but it looks fairly easy with their generic code.

Silicon Labs controllers are a bit more expensive ~$12 for the USB controller but they are so easy to use and are really fast with good peripherals.

 

[Andy_123]

Just an update:
I got CDC formware working with 4550 using Microchip example and modified version from **broken link removed**

As a side note, you must specify __config or set configuration manually based on your crystal.
I got it working with 20MHZ resonator:
OSC/5 PLL to 96MHz
Main clock 96/2
USB clock 96/2

Using picpro2 parallel port programmer with WinPic800 software.
This seems to be the only 3-rd party software that support USB pic today.

From this point I will try to add a bootloader - serial first as I had it running before with different PICs
USB bootloader will be next.

 

[df.isys]

PIC18F4550 USB & Assembly Code

Does anyone have example firmware written for the PICDEM FS USB board in assembly ?