Created 31.10.2010/JKN

Usb Cdc Serial Driver For Mac. Hi, folks, have others noticed this problem? Fairly recently during a Sierra or High Sierra update, a suitable. Application software can access the USB device in the same way as it would access a standard COM port. This software is provided by Future Technology Devices.

3.10.2014

Breaking news!

Thomas Missonier provided attached Makefile to compile the code under Windows/Cygwin and 'pic-config.h' file for use with 20 MHz crystal. Thanks Thomas!

30.3.2013

Update!

I've updated the project for SDCC 3.2.0 and included support for GET_LINE_CODING whichhelps overzealous Windows programs like Hyperterm to work with it.

Updated and improved thanks to Ron Musgrave's pestering, thank's Ron, I enjoyed the whole process.

Don't forget to README.txt file for further details.

This page introduces a minimal firmware that implements a USB Virtual Serial Port for Microchip PIC18F4550 processor.

The code has been optimized to use minimal amout of memory (both Flash and RAM) and tuned to work well with the Free SDCC C-compiler.

The code size is less than 2500 bytes and it requires about 230 bytes of RAM memory and it is capable of transferring almost 1 MB/sec (if only the PIC could generate any data at that speed!).

Why Virtual Serial Port

One of the hurdless that faces anyone who wants to interface a modern PC with the real physical world is the fact that most new computers have neither a serial port nor a parallel port that could be utilized to interface with external world. Most come only with USB and Etherner connections.

How to use xlminer. While USB standard is realy not that bad once you get into grips with the basics, it can be very intimidating. To make matters worse using USB often requires writing device drivers which can be even more intimidating. If you want to support the most common operating systems, Mac OS X, Linux or Windows, the task just gets bigger, easily beyound the resources of a lone developer.

But if you make your device appear as virtual serial port then the drivers will be provided by the courtesy of the operating system ie all the operating systems have built in drivers for serial ports.

Samsung does not indicate that this is a PostScript printer. There would be no reason to use the Generic PostScript driver. The Samsung ML-2250 uses the PCL6 printer language. I would suggest that you download the latest Gutenprint drivers. When you set up your printer use the Generic PCL6 driver from Gutenprint. Matt Mac Mini G4; B&W G3/300. Samsung ML-2250 Driver Software Download for Windows, Mac and Linux. The following drivers are solutions for connecting between Printer and Computer. “ Samsung-Driver.net ” is a web-based installer that will download and install Samsung ML-2250   Printer Drivers and Software needed for The Samsung printer currently connected. How to Install Drivers Samsung ML-2250 Driver for Mac OS: Download the driver file that you need to your Macintosh. After the download is complete, you will find the installer package icon on the desktop. Extract files, if you do not find the installer package icon. Double-click the installer package icon on the desktop. Samsung drivers net.

True, there are libraries, I especially want to mention libusb , which make it relatively easy to access and develop a class of USB devices without writing drivers. And libusb is cross platform which I like a lot. Still it is an other dependency for your project and requires a native library to be linked with your host side application which is more work if you want to do cross platform application development with languages like Java, as I do.

Serial ports are easily accessible from various programming languages including C/C++, Python, Java, VisualBASIC etc.

Using the CDC ACM library

It sounds a bit grand to call this a library when in reality it is just one source code file and a three files with USB related '#define's. I've created a ready to compile sample project that implements a virtual serial port that just echoes back everything you send to it. You can download the source code from here.

A word of warning about the source code: it was taken from a project that is fully functional but I had to clean it up a bit and remove some personal stuff. It compiles and there is a high probability that it works but I have not had the time to test it after the clean up. If you find any problems, please let me know.

Prerequisites

In priciple you should obtain your own PID and VID for your device from the USB consortium (or more easily from Microchip) but for simple testing and development it is ok to use what I have in the code ie Vendor id = VID = 0x0408 and Product id = PID = 0x000A.

To use the library you need to have 'GNU autotools' and 'SDCC' installed and in your 'path'. You can of course compile the code without the autotools as there are just half a dozen files to compile. To program the firmware into the device you need the Microchip PICKit2 programmer and the 'pk2cmd' software that supports it on the 'path'. If you don't have the PICKit2 you realy should get one, at USD 35 it is a steal and it is supported on Linux, Windows and Mac OS X.

And naturally you need a PIC18F4550 device with 4 MHz xtal. It is also possible to use the other PIC18F series devices and crystals but some changes to the link and config options maybe necessary.

Compiling

To compile the code unzip the project into a directory and just cd to the directory where you have the code and type make. This should compile the code and program it to the device if you have the PICKit2 in readiness. The object code and resulting hex file will be placed in a directory obj parallel to the source directory.

Testing

To test it you need a terminal emulator. Plug your device to the USB port, open the terminal emulator, select the correct port and everything you type should be echoed back to the terminal.

Testing on Mac OS X

In Mac OS X type ls /dev/tty.usb* to get a list of USB virtual serial ports and then use the built in screen terminal to talk to it.

For example:

Testing on Linux

In Linux type ls /dev/ttyACM* to get a list of USB virtual serial ports and then use the built in screen terminal to talk to it.

For example:

Testing on Windows

In Windows you need to install an .inf file that will associate your device with the built in driver.

To install the 'driver' plug in the device and go to the Device Manager. Look for an 'Unknown device' and select 'Properties' for that device, then select 'Install Driver', browse to the cdcacm.inf file which is included with the project files.

Note the file has not been tested after clean up so there maybe some errors.

Also note that if you change the PID/VID of the device (and in the long run you should) then you need to update the cdcacm.inf file and re-install it.

After succesfull installation the device should appear as a COM port and you can use a terminal emulator such as PuTTY or TeraTerm to talk to it.

Understanding the Library

The library realy is simple to use, basically there are two functions and two buffers for transferring the data in and out of the device, there is a function that needs to be called periodically to poll the USB bus, there is a function to initilize the library and auxiliary functions to implement standard putc/getc functionality.

Note that the library code is written from the device point of view, ie 'tx','put' means that the device sends something to the host which maybe confusing because on this is called 'input' direction in USB terminology and the host code would use 'read' functions to receive the data. Just thought I'd mention this.

Polling

You need to call the function usbcdc_handler() at least once every millisecond or in response to USB interrupt, which is the preferred way. If do not use interupts and forgot to call 'usbcdc_handler() regularly then your code will hang if it is waiting for a data transfer to complete.

In the example (see main.c) code this is handled as follows:

Note that in the example code I've actually used my own 'tiny printf', instead of the SDCC standard library function, see printft.h/printft.c.

Further Improvements

I've no intention to 'improve' this code in any major way as I see that the major feature of this library is it's simplicity and small code size. However, there is one bigish buffer (64 bytes) called setup_packet which I'm pretty sure could be refactored to overlap the tx/rx buffers, saving 64 bytes of RAM.

That's all folks

Hope this helps someone out there to implement some great little gadget!

br Kusti