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.
You 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..
Home
Help
Search
Login
Register
