Simple USB on PIC application: which driver is best? - Page 1
Forum section: electronics / projects

author: scrat
author_rank: Frequent Contributor
timestamp: November 10, 2010, 01:15:16 am
content: Hi all,These days I'll start making a simple PC-based data logger, through a USB enabled PIC (18F4550).At the moment it has to sample analogue values at at least 100Hz, and a minimum of 10s acquisition time is required. However, since capabilities of the PIC are much higher than this, it will be nice to do something more.I'd like to have the possibility to both see the waveform displayed into a VC++ app and to import data into Matlab.I see at least 2 possibilities:- using a VC++ app that will write to a file, the file can be imported into Matlab. Since I have already written some code (based on the Microchip examples), in this case I probably will only have to solve some timing issues, to be sure not to loose any samples. As a drawback, the exchanging by file is a little unsatisfying.- using a serial COM or other USB driver easily interfaceable with Matlab (and VC++, of course).Which driver will you choose? WinUSB, CDC (serial emulation), HID, ... Which speeds can I achieve, is transmitting samples in real-time?Which is the most versatile? Is there a portable solution (for example, to use into Matlab on a non-Windows platform)?Thanks.

author: migsantiago
author_rank: Frequent Contributor
timestamp: November 10, 2010, 02:04:23 pm
content: HelloIf you want to write your code very fast and easily, use CDC and just use the SerialPort Class on the .NET Framework. The downside is that every CDC device requires a driver for the OS.If you want a driverless device, use HID (my favorite USB Class).True plug&play. You have to use an HID library to read your PIC, but there are plenty of freeware libraries out there.http://www.lvr.com/hidpage.htm#MyExampleCodeOh and about the speeds...CDC is kinda slow on a PIC18. I remember I ran some tests and speed is not constant, this may be a problem if you're looking for real-time sampling.HID can achieve 64kB/s per interface (512kbps). If you add more HID's to one single PIC, speed can be improved.

author: scrat
author_rank: Frequent Contributor
timestamp: November 10, 2010, 03:34:14 pm
content: Thanks Santiago! I admit I was looking especially for your advice, since I've read some of your previous posts on this subject.If the CDC serial emulation is enough for my present purpose (maximum 1kB/s), then I will use it, since Matlab supports serial ports too.I'll ask some more questions, not necessarily related to the project:-If I was now leaving the idea of cross-platform implementation, which would be the fastest class in absolute, for real-time?-Are the HID Custom Demos from Microchip a good starting point? Does anyone only need the .NET Framework to run them on a Windows PC? Is it possible (and easy) to use them with other libraries?Thanks once more,Sandro

author: Unknown
author_rank: Unknown
timestamp: November 10, 2010, 04:26:47 pm
content: Quote from: migsantiago on November 10, 2010, 02:04:23 pmThis is only on Windows as far as I know. Most modern OS's support CDC out of the box, just like HID and mass-storage.Quote from: migsantiago on November 10, 2010, 02:04:23 pmDon't you need at least an .inf file with the correct product/vendor ID's for Windows to even power up the device?

author: migsantiago
author_rank: Frequent Contributor
timestamp: November 10, 2010, 04:29:31 pm
content: You're welcome.If you're planning to run at 1kB/s (8kbps),CDC is the perfect choice. In my tests I was trying to achieve 128kB/s with CDC, and the not constant speed of the PIC18 implementation made me stop using it.About cross-platform, I guess you're talking about a migration from OS to OS (Win, Linux, Mac, etc.). Well, I have tried to run a CDC pic device on Linux, and I did not have luck. It's kinda annoying because you have to write a driver for each OS, as far as I know. I'm not a Linux expert.HID is truly plug & play and OS independent. All OSes should include native HID drivers.About the fastest class... that does not depend on the OS, it depends on the horsepower of the microcontroller that is running the USB connection. For example, an HID device can be implemented on an AVR via software (no hardware modules involved), but the actual speed can't go higher than Low Speed. A PIC18 USB enabled device can actually run at Full Speed.Yes, HID Demos from Microchip are good. I've not tested them since I've worked with CCS compiler HID Demos.Reading an HID device from a PC requires using some DLLs from Windows. You can use and invoke them however you want... via .NET Framework, via Borland, via Labview, etc. The easiest and most available method is to use the .NET precompiled libraries.Quote from: alm on November 10, 2010, 04:26:47 pmHi AlmAs I was saying before, I tested a CDC pic device on Linux and it couldn't be enumerated. The native drivers did not recognize it. The CDC device worked fine in WinXP using a .INF file.About HIDs, they don't require any driver under Windows. Have you ever installed a new keyboard and Windows has asked for a driver?

author: Unknown
author_rank: Unknown
timestamp: November 10, 2010, 04:43:59 pm
content: Quote from: migsantiago on November 10, 2010, 04:29:31 pmCDC devices usually work fine on Linux and Mac, though I've never tested the PIC implementation. Sounds like a bug somewhere, maybe the implementation wasn't entirely compliant with the spec?Quote from: migsantiago on November 10, 2010, 04:29:31 pmThat could also be fixed by having a large driver database, it doesn't prompt for driver with many other common USB devices either, but that's because they ship the driver/inf file. I've seen some very basic devices that basically use it for power shipped with a driver (don't know if it was just an INF or an actual driver), so I assumed Windows needed them for everything. Seems mass storage and HID (any others?) are the exceptions.

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 10, 2010, 04:54:28 pm
content: Don't Know if this is of any use to you (so please don't flame me)http://www.sfcompiler.co.uk/forum/search.php?mode=resultsJust search the forum for more info.Sword fish can be downloaded herehttp://www.sfcompiler.co.uk/swordfish/and is a basic compiler and is easy to get started with.Two versions are available, the free one and the paid for version.The free version is only limited in the mpu it supports (essentially) and is very tight in it's code generation.Hope it helps.

author: migsantiago
author_rank: Frequent Contributor
timestamp: November 10, 2010, 05:20:29 pm
content: Quote from: alm on November 10, 2010, 04:43:59 pmYeah, I also think that it didn't work on Linux due to some descriptor out of place, but not as a bug. We tried to modify a RS232 cell phone driver to install the CDC pic device and had no luck... again, I'm no Linux expert.And also yes, it does not require a driver because it's already shipped in with the OS. I don't recall other USB class that does not request for a driver, MSD and HID are the most common ones, yes. Maybe the Audio USB class is another one that does not ask fro drivers.

author: Bored@Work
author_rank: Super Contributor
timestamp: November 10, 2010, 06:59:24 pm
content: Windows comes with CDC drivers (Usbser.sys). Just that Microsoft decided not to attach them to a device by default if the USB device claims to use the CDC protocol.It is just a design decision. The Linux developer trust a device when it says "I am doing CDC", the Windows developers don't. Instead, the Windows developer assume there will "never" be a naked CDC device, but only devices which use CDC as a low-level protocol, and an additional high-level protocol, like a modem interface on top. So the Windows developer assume a CDC device anyhow needs a specific installation to get both protocols attached.To tell windows that a USB CDC device really means it, you need an .inf file. The file just tells Windows to attach the already existing CDC driver to devices with that particular VID/PID (vendor ID / product ID).If you know your device's VID/PID you can easily write your own .inf file. If you need an official template get Microsoft's WDK.

author: TechGuy
author_rank: Regular Contributor
timestamp: November 11, 2010, 08:49:32 pm
content: Unless you plan on writing your own PIC USB code and the Windows driver, you only realistic option is to use the PIC USB Framework code and driver supplied by Microchip for the 4550. I believe there are third parties offering USB development tools but they are usually very expensive. Writing your own USB framework from scratch would probably take a 1000 hours or more. Writing your own Windows USB Kernel Driver is also complex, and will also take a few hundred hours to learn. Note you can't use Visual Studio to create Drivers, You must use the Microsoft driver kit. To my Knowledge, the PIC 18F4550 USB framework will not work with the standard Microsoft USB drivers.Link to the Microchip USB framework:http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2651&param=en534494Several years ago I was able to get about 700 Kbs using Bulk USB transfers on a PIC 18F4550. I used the Microchip USB framework with USB 2.0 Full-Speed Bulk transfers. Note that the USB packet size is limited to 64 Bytes.XLSoft has a PIC USB driver toolkit for Windows which is about $4000 USDhttp://www.xlsoft.com/en/products/jungo/usb_device.htmlNote that the Microchip wasn't terrible stable when I was working with it a few years ago. I often had to reboot the Windows PC after making code changes to the PIC. Unfortunately I don't think Microchip ever release the Windows Driver source code for thier USB driver.

author: migsantiago
author_rank: Frequent Contributor
timestamp: November 11, 2010, 11:10:23 pm
content: Quote from: TechGuy on November 11, 2010, 08:49:32 pmHi TechguyThe mpusbapi.dll source code is written in Borland and is fully downloadable from Microchip. Is that the driver you're refering to?

author: scrat
author_rank: Frequent Contributor
timestamp: November 12, 2010, 01:06:19 am
content: @TechGuyWriting the USB firmware and driver from scratch is not to be considered due to its complexity.I have already used the Microchip USB framework, modifying that code on the PIC and PC side I created a sample application (acquiring from the ADC and commanding PWM duty-cycle). I also made a plot on screen showing the 50 acquisitions taken at a certain sampling time in a single shot. This was made with WinUSB driver, which is from Microsoft, and that Microchip adopts in one of the examples.As I said, for the application I'm doing now I want a stable sampling time and "infinite" recording, in other words a real-time acquisition and transfer of data to the PC, and I'd like to have data into Matlab. This is why I was not sure if the WinUSB is the proper driver to use, and in fact the simplest solution (especially if thinking about Matlab) is the serial emulation, even if, for a higher speed, I'd need something other.I don't know why packet size is limited to 64 bytes with "Microchip's" WinUSB, I remember higher numbers possible with the bulk transfer, according to the standard...However, thanks to all for replying.I will go on on the serial emulation way now, but since you've made the thread become interesting, goin on with more infos will be useful for me and others (I think these issues are quite common).Maybe a simple "tutorial" on how to implement a simple USB application starting from the Microchip examples would be a good thing, since the things to do are simple and the possibilities it opens are wide. If I will have a bit more of time, I'll write something down.

author: migsantiago
author_rank: Frequent Contributor
timestamp: November 12, 2010, 02:12:34 pm
content: Quote from: scrat on November 12, 2010, 01:06:19 amA full-speed Bulk packet con only be as high as 64 bytes. A High-Speed Bulk packet can hold up to 512. PICs cannot do High-Speed.If you want to transfer more bytes, consider using an isochronous full-speed endpoint which can transfer up to 1023 bytes. The bad part is that isochronous endpoints have no error correction.Maybe my tutorial may help you...click!(if you don't speak spanish, you can use the embedded translator).

author: TechGuy
author_rank: Regular Contributor
timestamp: November 12, 2010, 06:34:30 pm
content: Quote from: migsantiago on November 11, 2010, 11:10:23 pmno the mpusbapi.sys (windows kernel driver). The DLL is just the library that used to communicate with the kernel driver.QuoteInstead of going with USB, another practical option would be to go with TCP/IP ethernet. An UDP packet has a data size of about 1400 bytes. The only issue is that the 18F series is RAM deficient ( < 5K of RAM), unless you use one of the version that permits external RAM attachment. I never understood why most Microcontrollers have so little RAM. If I recall correctly the PIC32 series has models with 128K to 256K of RAM which is sufficient for a good TCP/IP impementation. With TCP/IP you are no longer limited to the USB driver, and you can connect your device to a switch instead of the limited range of USB, slaved to a single computer.TCP/IP communication is really easy and works a lot like Serial I/O. You open a TCP connection to a remote device and you and send and recieve data just like you would with a serial connection. The TCP/IP stack handles all of the packet decoding, error checking, packet re-ordering, etc. 100 Mbit Eithernet will be a lot faster than the 18F4550 Full Speed USB (12 Mbit).I believe the Microchip TCP/IP Development library is free. but you need the compiler. I have purchased the C18 compiler but I haven't pulled the trigger on buying the C32 compiler yet. I am hoping that Microchip drops the price (currently at $895 USD) next year.I would have liked to go to ARM instead, but the development tools for ARM are just way to expensive, in the $4K to $6K range. I don't know why MCU manufactures don't change reasonable prices for development tools. If they were affordable they would sell a lot more product. So far Microchip is has one of the lowest costs for development tools.

author: scrat
author_rank: Frequent Contributor
timestamp: November 15, 2010, 01:24:36 pm
content: Thanks, I never thought of using TCP/IP, mainly because I know little about it.The possibility of interfacing devices at a distance and accessing them from multiple points is an interesting feature, which would make a big difference in some cases.Now I'm testing the CDC emulation solution into Matlab, seems to work, but I need to verify acquisition and timing with a reliable scope. It took a while to fix some stupid things, but indeed it was a work that could be done in a day, if working continuously.About the C18 compiler, it's free in its student's version (it doesn't allow for optimization after the first 60 days, if things are unchanged since a couple of years ago). You can either use the HiTech compiler, which Microchip provides for free (base version only).I have always used the student's version of C18 compiler. Besides the hardware peripheral libraries have quite a lot of bugs, the compiler was enough for my simple stuff, and with MPLAB ICD2 it's possible to set breakpoints and use the watch, too.Simple and cheap tools are a strategic move for MCUs market, and IMHO I add readable and comprehensive datasheets. Comparing a MCU datasheets from Microchip and TI reveals a big difference. Perhaps, TI's datasheet contains everything, but it's very hard to find.

author: TechGuy
author_rank: Regular Contributor
timestamp: November 17, 2010, 12:46:29 am
content: Quote from: scrat on November 15, 2010, 01:24:36 pmI never use the Hardware Peripheral functions, its fairly easy to roll your own, but I do use the USB framework and will in the future use the TCP/IP library. I think the free versions of the Microchip and Hi-tech Compilers limit the number of lines compiled. I believe the updated version of C18 is just the Hi-Tech C compiler now.I never much cared for TI documentation. In my opinion is one of the worst in the industry. Its really a shame that TI doesn't put more effort into their documentation.

author: migsantiago
author_rank: Frequent Contributor
timestamp: November 17, 2010, 01:16:47 am
content: Quote from: TechGuy on November 17, 2010, 12:46:29 amThe Hitech compiler in its lite version does not limit the number of lines, it just does not compile with optimizations.It's hard to think that C18 is being replaced by Hitech. The syntax each compiler uses is kinda different.

author: scrat
author_rank: Frequent Contributor
timestamp: November 17, 2010, 02:08:49 pm
content: Quote from: migsantiago on November 17, 2010, 01:16:47 amAre these differences only on compiler directives or do they introduced some non-standard language syntax?I don't remember non-standard words into C18, but I'm not an "advanced" user, so I could miss something.

author: migsantiago
author_rank: Frequent Contributor
timestamp: November 17, 2010, 03:43:39 pm
content: I've seen some #define differences and that's all. C18 and Hitech are both ANSI standarized.

author: scrat
author_rank: Frequent Contributor
timestamp: November 17, 2010, 04:54:20 pm
content: Quote from: migsantiago on November 17, 2010, 03:43:39 pmAs it should beSo it should not be so difficult to make a code written for Hitech work with C18 and viceversa. I think I actually made it once, but never tested the result.However, Microchip certainly won't substitute one of them with the other (to guarantee backward compatibility), I think they will only improve both engines by using the good features of each one, in future versions.If I had to use PICs a lot for my work, I'd rewrite my library, one peripheral at a time, when I need it, and at my own taste (conventions, etc). One simple bug can make you waste much time, and that's quite frequent, in my little experience.Another thing I'm always interested in is how companies structure their firmware. A good frame where to work is a big help for starting and debugging, IMHO. For example, is it frequent to use OSes (like RTOS) on 8-bit MCUs?

author: migsantiago
author_rank: Frequent Contributor
timestamp: November 17, 2010, 05:52:15 pm
content: Yes, there are RTOS implementations for small uC (PIC18 for example). I don't know how often they're used.I think that a good and well-thought firmware implementation should never use an RTOS. RTOS is good for timings, but it burdens the CPU with more processes.

author: scrat
author_rank: Frequent Contributor
timestamp: November 17, 2010, 06:24:54 pm
content: Quote from: migsantiago on November 17, 2010, 05:52:15 pmI knew of RTOS, but I still don't know anyone who seriously uses it!I thought it was used when multiple "processes" were on simultaneously with no strict timing specs, for example managing user interfaces and slow I/O, while a strict timed process is running.It seems that these are beautiful things for informatic engineers, but not for EE.