USB USB CDC implementation for 'F32x
|
UBBFriend: Email This Page to Someone! | next newest topic | next oldest topic |
Author | Topic: USB CDC implementation for 'F32x |
Tsuneo Member |
posted July 19, 2006 09:38 AM
USB CDC (Communication Device Class) implementation for 'F32x and 'F34x This code is an implementation of CDC ACM (Abstract Control Model) discussed in the topic, "F320 USB". History
In this code, the USB side is fully implemented, but no UART is attached. Instead, support routines to connect peripherals to it are provided. The purpose of this implementation is to place a start point for further modification. For simple USB-serial conversion, I recommend you to use existing USB-serial chips. The code is based on SiLabs USB_INT (release 1.3). Though the original comments by SiLabs are preserved to respect their work, this implementation has no relation to them. (I also have no relation to SiLabs ) Use it on your own risk as usual. Thanks Patryk, your advices in "Optimization of SiLabs USB examples in code size" are fully reflected to this implementation. Also, thanks Maarten and Frieder, your suggestions in the topic, "Help to convert sample code of USB_INT to compile under SDCC" help me much on this implementation. Tsuneo
#include <c8051f320.h> The code is compiled with Keil or SDCC. The conditional compilation on the code automatically detects the compiler. The work space files, 'Keil_USB_CDC_skeleton.wsp' and 'SDCC_USB_CDC_skeleton.wsp', are provided for SiLabs IDE. SMALL memory model USB spec compliance was checked using USBCV R1.3 beta on Chapter 9. Unfortunately, 'F326/7 cannot be supported because these devices has only two EP other than EP0.
When installed successfully, the device appears on your PC as a COM port.
Following transfer speed was observed on loop back, simultaneous bi-direction transfer (WinXP SP2). SYSCLK Speed (Kbytes/sec) Though I didn't check about transfer speed of single direction transfer, it'll be much faster, from the record of bus analyzer. LEDs and SWs on the 'F320DK are connected to RTS, DTR and CTS, DSR, respectively. But RTS and CTS don't work well because usbser.sys on Windows is weird as noted below.
TX and RX from PC over USB are attached to ring buffers respectively in 'USB_CDC_UART.c'. The data sent to PC is held in RX buffer. The size and memory space allocation for the TX and RX buffer are defined in 'USB_CDC_UART.h'. In this implementation, these output and input of ring buffers are connected directly together in the main loop, 'USB_Main.c', for demonstration. In your modification, these main stream buffers will be connected to the input and output of your peripheral. Ring buffer is easy to use, but its speed performance is not so good. To handle an IN transfer (device -> PC) of steady transfer rate, such as ADC, a double buffer is suitable. Also when the packet size of single transfer is always the same, a double buffer works better. You can find an example of double buffer in the topic '256000 bytes/sec Isochronous transfer' on this forum. Other than these main data transfer path, you'll need to exchange 'trigger' and 'parameters' between the device and the PC. In 'USB_CDC_UART.c', These handshake signals and setting parameters are completely independent from the main data transfer path. ie. Even if you set the baudrate to either 9600 or 115200 on the PC, it has nothing to do with the transfer rate of the TX and RX. Therefore, these signals and setting parameters are used for 'command' from PC and 'reply' from the device. Using or modifying these functions, you can connect any peripherals to PC COM port. Turning macro POLL_READ_BYTE/POLL_WRITE_BYTE into functions saves about 310 bytes in Keil, 130bytes in SDCC. When the code size is more essential for your project than execution speed, apply this modification. To convert these macro to function, comment out these macros at the bottom of USB_Register.h. Edit the INF file, 'CDC_ACM.inf', in the INF folder with your favorite text editor.
Memories (bytes) - v1.4 For the demonstration only - not the absolute requirement Q2. In addtion to virtual com port, can this device equip another USB functions at the same time?
WinXP SP2, usbser.sys (5.1.2699.2180) When the transfer size is just the multiple of 64 bytes (max packet size of bulk IN EP), ReadFile doesn't finish until zero length packet is received, even if the actual transfer size is equal to the requested size. The requests issued (or not issued) by usbser.sys are as follows. You'll find how usbser.sys is weird.
[This message has been edited by Tsuneo (edited May 10, 2008).] IP: Logged |
Bert Member |
posted July 21, 2006 01:22 AM
Thanks Tsuneo, It is a very useful addition to the collection examples for the F320 I already have. IP: Logged |
Tsuneo Member |
posted July 21, 2006 04:11 PM
Updated to v1.1 - Added 'F34x support Download it from the link on the first post (the link was revised). Tsuneo IP: Logged |
Tsuneo Member |
posted August 14, 2006 09:57 AM
Updated to v1.2 - Fixed a minor bug on the interrupt setting for USB endpoints after USB bus reset. The endpoints interrupt was enabled uselessly after USB bus reset, though it is ignored by the USB ISR. Fixed it. - Deleted 'clear toggle' code from the endpoint initialization on Set_Configuration, because it is done by USB bus reset - according to the reply from SiLabs. Tsuneo IP: Logged |
Tsuneo Member |
posted August 19, 2006 12:38 AM
Updated to v1.3 - Optimized the setup stage handling of the standard and class request. This optimization reduces the code size about 150 bytes for Keil, 230 bytes for SDCC Tsuneo IP: Logged |
egawtry Member |
posted August 23, 2006 11:41 AM
I tried compiling this with SiLabs IDE and with Keil, and all I get is "USB Device Not Recognized". Pulling it up with UVCView, it says "Device not Enumerated". The one change I made was changing the include file from 320 to 340. Anyone with ideas? Thanks, [This message has been edited by egawtry (edited August 23, 2006).] IP: Logged |
Tsuneo Member |
posted August 23, 2006 09:27 PM
Hi Erik, Thank you for trying it. CDC ACM requires INF file to install it to Windows, unlike HID. Tsuneo IP: Logged |
egawtry Member |
posted August 24, 2006 11:25 AM
What I am saying is that I don't even get the new hardware dialog. All I get is the error message. I tried forcing the INF anyway, but Windows refused to attach it. To see if it is my board, does anyone have a HEX to post so I can test it? Thanks, [This message has been edited by egawtry (edited August 24, 2006).] IP: Logged |
Tsuneo Member |
posted August 24, 2006 10:50 PM
This is the hex file for 'F34x. keil_usb_cdc_skeleton.hex The compile switch for Keil is almost default, The jumpers on the 'F340 dev board are as follows. (from top to down) All other jumpers are unplugged. Tsuneo IP: Logged |
egawtry Member |
posted August 25, 2006 11:46 AM
Huh. I get the same thing with that HEX file. My hardware must be messed up. I will diagnose and post my results. Thanks, IP: Logged |
Patryk Member |
posted August 31, 2006 03:22 AM
Hello, Tsuneo! I was playing happily with version 1.1 before my holidays, now I'm back and voila - 1.3. Got some questions about 1.1, but that later. Now something about 1.3. 1. USB Reset interrupt (and others except Suspend) is disabled in Usb0_Init() and enabled in Usb_Reset() (in interrupt handler). I didn't run 1.3 yet on my hardware, so I cannot say if it works. I believe it does since you surely checked it :-) It may work: there is 10ms recovery interval after reset signalling and this may fire Suspend interrupt. Since Reset is polled first in ISR, then all is probably done in correct sequence. Anyway I opt for enabling Reset, Suspend and Resume interrupts in Usb0_Init(). SOF interrupt enable may stay in Usb_Reset() to avoid mess until all is configured. 2. Removing 'reset data toggle' code in Set_Configuration() violates USB spec. Note that that device may be configured/unconfigured (SET_CONF(1)/SET_CONF(0) requests issued) many times without USB reset, at least when controlled by other driver than MS one. BTW: MS Platform SDK says that applications are receiving notifications for ports (WM_DEVICECHANGE\DBT_DEVICEARRIVAL\DBT_DEVTYP_PORT\"COMx") without any registration. I confirmed it with CP2102, FTDI and Prolific. This is not the case with this example - only WM_DEVICECHANGE\DBT_DEVNODES_CHANGED messages are received. Any clues? Edited: I'll repeat that turning POLL_READ_BYTE/POLL_WRITE_BYTE into functions saves 150bytes, at least under SDCC 2.5.0. No need to make them reentrant (no overlay will do), since they may be safely called only with ints disabled. Regards, [This message has been edited by Patryk (edited August 31, 2006).] IP: Logged |
Patryk Member |
posted September 05, 2006 05:47 AM
Tsuneo, I'm waiting for your response to 1, 2 and WM_DEVICECHANGE. IP: Logged |
Tsuneo Member |
posted September 05, 2006 09:43 AM
Hi Patryk, Sorry for my late response. "1. USB Reset interrupt (and others except Suspend) is disabled in Usb0_Init() and enabled in Usb_Reset() (in interrupt handler)." Actually, it works.
Surely, Set_Configuration may be issued without bus reset. I recovered it on v1.4. 'Reset data toggle' isn't directly connected to 'HALT'. The USB 2.0 spec defines its handling as follows. 9.4.5 Get Status (usb_20.pdf p256) This sentence only means 'reset data toggle' should be done in ClearFeature(ENDPOINT_HALT). 'Halt feature' is reset to zero independently either in SetConfiguration or SetInterface. Rather, this sentence is the ground to implement it in SetConfiguration. 9.1.1.5 Configured
It's a barter of execution speed and code size. So, I'll leave it to user's choice. I've optimized the code to simplify its logic and code flow. I believe it contributes to both of speed and size. Tsuneo [This message has been edited by Tsuneo (edited September 05, 2006).] IP: Logged |
Tsuneo Member |
posted September 05, 2006 02:26 PM
Updated to v1.4 - Bug fix: 'F32x fail SET_LINE_CODING on high-speed hub - And other minor optimization and revision Tsuneo IP: Logged |
Patryk Member |
posted September 06, 2006 05:33 AM
You're right about 9.1.1.5, I missed it. I found 9.4.5 in a desperate "I have seen it somewhere" search :-) IP: Logged |
Patryk Member |
posted September 06, 2006 10:12 AM
Some suggestions. 1. What for is second Delay() in Sysclk_Init()? No need according to datasheet. 2. Why SDSTL bit for EPs other than EP0 is set in Handle_EP_HALT() and not in Set_Feature()? This dalays intended CLEAR_FUTURE(HALT) effect to next SOF interrupt. If SDSTL bit will be set in Set_Feature(), then Handle_EP_HALT() is completely needless (160 bytes!). STSTL bit may be ignored. 3. Here's simpler implementation of Fifo_Read()/Fifo_Write(): yours 113/46 against my 60/50 bytes (76/66 bytes in reentrant version, but this should be needless). They correctly handle uNumBytes=0 (do almost nothing) as in original. { // unload 'size' bytes from the selected FIFO while (USB0ADR & M_BUSY) {} // wait for USB0ADR ready return; /*------------------------------------------------------------------------------ { // write 'size' to the selected FIFO return; 4. Maybe CMINT, IN1INT and OUT1INT register values should be AND-ed with CMIE, IN1IE, OUT1IE registers before storing in bCommon, bIn and bOut variables in Usb_ISR(), thus truly masking disabled interrupts? Never know when we fall again into this pitfall... Regards, [This message has been edited by Patryk (edited September 06, 2006).] IP: Logged |
Patryk Member |
posted September 12, 2006 06:04 AM
I see you're on forum now, Tsuneo, and I'm waiting for response :-) IP: Logged |
Tsuneo Member |
posted September 12, 2006 07:16 AM
Sorry, I was on a business trip these days. And I must go to another one tomorrow. I'll be back this week end. "1. What for is second Delay() in Sysclk_Init()? No need according to datasheet. "2. Why SDSTL bit for EPs other than EP0 is set in Handle_EP_HALT() and not in Set_Feature()?" The reason I put the Handle_EP_HALT into the SOF interrupt is that I'm not sure STSTL bit must always be cleared when it is set by the SIE. The original SiLabs code always resets it in the EP ISR. But I feel it may not be required. If so, the HALT handling is simplified as you said. HALT and STALL handling for bulk and interrupt EPs "3. Here's simpler implementation of Fifo_Read()/Fifo_Write()" When the whole FIFO data is unloaded by Fifo_Read in a single call, it doesn't matter even if the autoread flag is cleared after the last read. "4. Maybe CMINT, IN1INT and OUT1INT register values should be AND-ed with CMIE, IN1IE, OUT1IE registers" Tsuneo IP: Logged |
egawtry Member |
posted September 13, 2006 12:08 PM
I got the device working using a 342 (320s don't seem to work). There is one problem however. The serial port does not show up using the SetupDiGetClassDevs() function. Is it classed under another standard GUID? I would assume so since Device Manager sees it. There doesn't seem to be a device class for it in Device Manager item details. Anyone with an idea? [This message has been edited by egawtry (edited September 13, 2006).] IP: Logged |
Patryk Member |
posted September 14, 2006 03:12 AM
I believe using usbser.sys GUID will do, but I don't know content of that GUID. What GUID are you using for "normal" COM? serial.sys? serenum.sys? About the lack of WM_DEVICECHANGE: maybe serenum.sys should be installed as upper filter? It is installed for normal COMs (above serial.sys) and for one of USB to UART converters (SiLabs, FTDI or Prolific, don't remember). Just a suggestion to Tsuneo, my knowledge of driver stack is very limited. [This message has been edited by Patryk (edited September 14, 2006).] IP: Logged |
MAVO Member |
posted September 14, 2006 05:47 AM
I have a couple of questions about this nice CDC implementation 1) 2) IP: Logged |
egawtry Member |
posted September 14, 2006 12:22 PM
By the usbser.sys GUID, do you mean the GUID_DEVINTERFACE_SERENUM_BUS_ENUMERATOR as specified in the CDC_ACM.INF file? That only returns the hardware based serial ports. I also scan GUID_DEVINTERFACE_COMPORT which returns the Modems and most USB com ports (including the CP210x). Hmmm... I wonder if I switch the GUID in the INF to COMPORT instead of SERENUM; if that would solve it? I will give that a shot. -Erik IP: Logged |
Patryk Member |
posted September 15, 2006 04:28 AM
The only GUID contained in CDC_ACM.INF is ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318} - is that what you mean GUID_DEVINTERFACE_SERENUM_BUS_ENUMERATOR? I believe it differs from usbser.sys GUID, like with HID: ClassGUID={745a17a0-74d3-11d0-b6fe-00a0c90f57da} in inf file driver GUID (hidclass.sys? hidusb.sys?) {0x4D1E55B2, 0xF16F, 0x11CF, {0x88, 0xCB, 0x00, 0x11, 0x11, 0x00, 0x00, 0x30}} - must be used for SetupDiGetClassDevs() Switching ClassGUID in CDC_ACM.INF won't work: it describes Windows Setup class only, which is named Ports in previous line. I found somewhere in MSDN that ClassGUID is put in inf only to speed up device install. IP: Logged |
Tsuneo Member |
posted September 15, 2006 06:00 AM
Hi Erik (egawtry), I got the device working using a 342 (320s don't seem to work). Do you use high-speed (HS) hub between the PC and the board? Then apply the latest (v1.4) version. I fixed HS hub problem for 'F32x on v1.4 Erik (egawtry) and Patryk, As long as I disassembled usbser.sys, it doesn't register interface GUID to Windows system by IoRegisterDeviceInterface API. This API is usually used to register the interface GUID to the system in a device driver, which is compliant to the recent SetupDi- APIs. I don't know any other way to register the interface GUID from device driver. The device manager list up devices using setup GUID. To retrieve device path using SetupDI- APIs, an interface GUID is required. To find the COM number of the device, look up the registry. The same method described in AN197 is applicable. Patryk, "About the lack of WM_DEVICECHANGE: maybe serenum.sys should be installed as upper filter?" usbser.sys doesn't use serenum.sys as an upper filter. This is the output of DEVCON. It shows printer port, built-in modem, CP2102 and USB-CDC in this order. 'hhdserh' is the filter driver from the HHD serial monitor. >devcon driverfiles =ports >devcon stack =ports Tsuneo IP: Logged |
Tsuneo Member |
posted September 15, 2006 06:21 AM
Hello MAVO, "Is it possible to use it on Windows 98 (2nd or 1st edition)?" I checked it on only WinXP. I suppose it will work, bu not sure. It is said that behavior of usbser.sys has difference among Win98, 2K and XP. The result I wrote is from WinXP SP2. For Win98/98SE/ME, Usbser.sys is downloaded from this web page "2) You state that: Yes. usbser.sys doesn't issue any request when the host application executes these API. I checked it on a hardware bus analyzer. Tsuneo IP: Logged |
Patryk Member |
posted September 15, 2006 06:27 AM
usbser.sys doesn't use serenum.sys as an upper filter When installed with CDC_ACM.INF - yes. But I feel that INF file decides if and which upper filters are installed for given device. [This message has been edited by Patryk (edited September 15, 2006).] IP: Logged |
Patryk Member |
posted September 15, 2006 07:06 AM
When the whole FIFO data is unloaded by Fifo_Read in a single call, it doesn't matter even if the autoread flag is cleared after the last read. My implementation is based on HID_blinky example - it didn't care about clearing autoread flag before last read. But USB_INT example cares! As Fifo_Read() read always whole FIFO in both examples, that doesn't matter. I also found extra read problem when implementing interrupts for EP2 IN/OUT, but there was completely specialized read routine. Anyway I end up with your implementation (I like order, and that DJNZ in loop I cannot achieve using indexing instead pointer) improving Fifo_Read() a little to 100bytes instead of 117 under SDCC 2.6.0.
In Fifo_Write() loop I wait for BUSY before write. Although it is dummy wait in first loop, but we exit that loop sooner on last write. [This message has been edited by Patryk (edited September 15, 2006).] IP: Logged |
egawtry Member |
posted September 15, 2006 11:21 AM
Since the SERENUM was predefined for the INF device class, it needs to be installed that way. A bit screwy if you ask me. Tsuneo, Does anyone have any idea how Device Manager gets the list of ports? Maybe I should enum all devices and parse out the COM ports. I will try that next. -Erik IP: Logged |
Tsuneo Member |
posted September 16, 2006 05:11 AM
Patryk and Erik, Serial modems usually use serenum.sys as a filter driver for serial.sys, as shown in DEVCON output in my previous post. As the source code of serenum.sys and serial.sys are provided in WinDDK, I read them through. As the result, serenum.sys seems to be promising. a) SetupDi-API compatibility by serenum.sys Serial.sys correctly registers GUID_CLASS_COMPORT as described in "Plug and Play external COM Device Specification" from MS. However, usbser.sys doesn't register this GUID. In this point, usbser.sys is weird too. b) WM_DEVICECHANGE compatibility Though it isn't clear whether WM_DEVICECHANGE is enabled by serenum.sys without any registration or not, we can register the device notification with GUID_SERENUM_BUS_ENUMERATOR at least, and it'll return DBT_DEVICEARRIVAL/DBT_DEVICEREMOVECOMPLETE. c) Device detection OK, as the next step, I'll examine INF file modification to attach serenum.sys. Tsuneo IP: Logged |
Patryk Member |
posted September 21, 2006 08:36 AM
USB_ISR.c, line 241:
Shouldn't there be '&&' in place of '||' according to comment? What is purpose of this check? SUEND may rise right after this check and we will "put new data on FIFO" anyway. IP: Logged |
Tsuneo Member |
posted September 21, 2006 12:24 PM
Yes, it must be '&&'. There is still a little possibility to come across SUEND here. Umm.. I examined most of SiLabs code, but missed it. Thanks. Tsuneo IP: Logged |
Patryk Member |
posted September 22, 2006 08:22 AM
I still cannot fully understand that SiLabs SIE implementation. Terminology in datasheet seems to differ from USB spec. For example F320 datasheet p. 161: 15.10.Endpoint0 Below is what I (after USB spec) mean by transfer, transaction, stage, phase etc. by example of, say, GET_DESCRIPTOR request. Control transfer Can you help, Tsuneo, with some state diagram or more detailed explanation about EP0? I need to verify that firmware in every detail, it look somewhat flawed to me. Consider my second question ("What is purpose of this check? SUEND may rise right after this check and we will "put new data on FIFO" anyway.") Regards, IP: Logged |
egawtry Member |
posted September 22, 2006 12:31 PM
A fix for the INF so enumeration works: This will make Windows enumerate the COM port normally. Tsuneo, maybe you want to put this into the zip file? -Erik [This message has been edited by egawtry (edited September 22, 2006).] IP: Logged |
Tsuneo Member |
posted September 22, 2006 07:20 PM
Patryk, Please see "Figure 3-5" of AN139 (AN139 rev1.3 p10) "1.A data packet (OUT or SETUP) has been received and loaded into the Endpoint0 FIFO..." "2.An IN data packet has successfully been unloaded from the Endpoint0 FIFO and transmitted to the host;..." "3.An IN transaction is completed (this interrupt generated during the status stage of the transaction)." Tsuneo IP: Logged |
Tsuneo Member |
posted September 22, 2006 07:22 PM
Thank you Erik, I'll include your INF file to the zip file in the next update. Tsuneo IP: Logged |
Tsuneo Member |
posted September 24, 2006 02:17 AM
Patryk, "What is purpose of this check? I also feel this part of the implementation a little dirty. This is supposed Control read (IN) transfer sequence. host SIE firmware
host SIE firmware In this case, the IN FIFO is cleared by SUEND as long as INPRDY is set to '1' by the firmware before the premature SETUP arrives. INPRDY: IN Packet Ready (C8051F32x.pdf rev1.1 p164) However, when premature SETUP arrives before the firmware sets INPRDY, the IN FIFO isn't cleared. This is the point you are talking about. Premature SETUP is issued by host as an error recovery. Tsuneo [This message has been edited by Tsuneo (edited September 24, 2006).] IP: Logged |
Patryk Member |
posted September 25, 2006 06:21 AM
Tsuneo: you always got some spare helping hand :-) (here AN139). I thought I read all SiLabs USB application notes, and now I see it is only partially truth: all from Applications page :-| Why this one isn't listed there (only on USB Products page) is a sweet secret of SiLabs :-) I'm beginning to read it in hope it answers some questions. Thanks! [This message has been edited by Patryk (edited September 25, 2006).] IP: Logged |
mmk New Member |
posted October 03, 2006 10:38 AM
Hi, Can anyboday provide some help: Is there a way to get a USB device to enumerate as more than one virtual com port using the CDC? If yes what are the steps to do so? Thanks!!! IP: Logged |
Tsuneo Member |
posted October 03, 2006 11:10 AM
Hello mmk, "Is there a way to get a USB device to enumerate as more than one virtual com port using the CDC? If yes what are the steps to do so?" Short answer - It cannot. Long answer - The Windows built-in driver, usbser.sys, doesn't accept multiple port configuration. Many people (including me ) has attacked it, but no one succeeds. "CDC device with multiple serial port" from USB.org Surely, when you manage to write a custom device driver instead of usbser.sys, it can. But, it isn't realistic. Find an existing product, such as, Do you actually need COM port? You can assign 'direct' USB ports as many as the number of endpoints on the device. Tsuneo IP: Logged |
egawtry Member |
posted January 05, 2007 02:18 PM
My Micro crashes every time Update_Line_State() is called. Any ideas? Also: You need to disable interrupts while reading or writing to the FIFOs, otherwise they overrun. // TX buffer (host --> UART), UART side if( TXcount == 0 ) EIE1 &= ~0x02; // disable USB interrupt dt = *TXRDPtr; TXcount--; EIE1 |= 0x02; // enable USB interrupt return dt; // RX buffer (UART --> host), UART side EIE1 &= ~0x02; // disable USB interrupt *RXWTPtr = dt; RXcount++; EIE1 |= 0x02; // enable USB interrupt } [This message has been edited by egawtry (edited January 05, 2007).] IP: Logged |
Tsuneo Member |
posted January 05, 2007 07:26 PM
"My Micro crashes every time Update_Line_State() is called. Any ideas?" Oops, sorry it's a bug.
"Also: You need to disable interrupts while reading or writing to the FIFOs, otherwise they overrun." I don't think so. Rather, when COMGetByte() and COMPutByte() are used in another interrupt such as UART, Handle_In2() and Handle_Out2() must be modified to disable this interrupt, as follows.
Tsuneo [This message has been edited by Tsuneo (edited January 05, 2007).] IP: Logged |
egawtry Member |
posted January 08, 2007 12:35 PM
With that I have successfully implemented a direct transfer to the 342's UART, thus replacing the CP210x with a chip with flexibility and doesn't need the drivers. I have tested it at 2400 to 115200 baud without any glitches - I would test it faster but my hardware COM port on the PC won't go any faster. Does anyone know why SiLabs didn't use this method on the CP210x? It seems to be MUCH better since it uses the built in serial port driver. I wonder if it would work on Linux or a Mac without additional drivers? -Erik [This message has been edited by egawtry (edited January 08, 2007).] IP: Logged |
Tsuneo Member |
posted January 08, 2007 06:32 PM
"Does anyone know why SiLabs didn't use this method on the CP210x?" a) Windows built-in device driver, usbser.sys, had many bugs and defects on its feature in the early OS version. Therefore, the manufacturers of USB-UART chips should provide their original device drivers b) The USB CDC spec doesn't support CTS handshake line.
Yes, Linux and MacOSX have built-in device driver for CDC ACM. This Atmel appnote suggests how to use CDC ACM devices in various OS. "USB to Serial Adapter" from Atmel Tsuneo [This message has been edited by Tsuneo (edited January 08, 2007).] IP: Logged |
egawtry Member |
posted February 02, 2007 10:55 AM
Anyone know how to get CDC working with Vista? The usbser.sys and serenum.sys exist, but the INF crashes when I try to use it. Part of it may be that there is no layout.inf. I tried figuring it out from MS documentation, but all they talk about is a cell phone version of CDC that doesn't work anyway. -Erik IP: Logged |
Tsuneo Member |
posted February 02, 2007 01:14 PM
Hi Erik, Maybe "include=mdmcpq.inf" is the key, but I didn't try it. "How to use or to reference the Usbser.sys driver from universal serial bus (USB) modem .inf files" from MSDN Tsuneo [This message has been edited by Tsuneo (edited February 02, 2007).] IP: Logged |
egawtry Member |
posted February 10, 2007 01:55 PM
That did the trick. It is bad that we need a separate INF for Vista. MS messed up there. Right now it is the only USB serial port that I can find that actually works with Vista. -Erik IP: Logged |
grantb4 Member |
posted April 03, 2007 06:52 PM
Hi, Can someone please summarize shortcomings, problems, bugs in using this CDC implementation? I'm not so much referring to the Tseneo's code, but more on Microsoft's end (usbser.sys, etc). In other word, if one were to implement a device as well as possible, what problems would remain? It sounds like one limitation may be that you can only have one such device plugged into the PC. Is this correct? Does this same problem occur on Linux? Any other things like this? Thanks, IP: Logged |
thyagaraj New Member |
posted April 05, 2007 12:56 AM
Hello Tsuneo, The USB_UART_CDC code was really very useful for one of our USB to UART solution using the F321. Please let me know the changes that are to be done in the code for UART to USB conversion.That is, I would like to convert the UART data(from a different PC) to USB(of my PC) and receive it on the Hyperterminal. IP: Logged |
Tsuneo Member |
posted April 05, 2007 04:04 PM
thyagaraj, Isn't it better to apply an existing USB-to-UART chips like SiLabs CP210x for simple VCP application? This VCP implementation works when you extend the function of the USB-to-UART chips. b) 'Smart' converter Tsuneo IP: Logged |
frief Member |
posted May 29, 2007 08:05 AM
Hello and thanks Tsuneo for your USB CDC implementation!) I've a question about the CTS handshake handling in USB_Main.c line 196: if ( Switch1State ) line_state |= CDC_DSR; if ( Switch2State ) line_state |= CDC_CTS; Update_Line_State( line_state ); CDC_CTS is defined as 0x80 which would according to usbcdc11.pdf table 69 be "reserved (future use)". Is CDC_DCD meant there? Greetings, IP: Logged |
Tsuneo Member |
posted May 29, 2007 10:18 AM
Yes, as you pointed out, the CDC spec (usbcdc11.pdf) lacks CTS signal handling. This implementation of CTS is good just for MacOS X. It doesn't work for Windows and Linux. Tsuneo IP: Logged |
sbj New Member |
posted June 12, 2007 12:10 PM
I'm trying to get the implementation to work for F326. I'm using hyperterminal and can't seem to get the data to transfer to the board. Any ideas? IP: Logged |
Tsuneo Member |
posted June 12, 2007 06:15 PM
Hi sbj, "I'm trying to get the implementation to work for F326." Visit this topic, "VCP on F326" Tsuneo IP: Logged |
thyagaraj New Member |
posted July 05, 2007 05:02 AM
Hello Tsuneo, We have modified the CDC skeleton for a USB to UART conversion code.The code is working fine except for one problem.The UART to USB conversion works fine for any baud rate. What could be wrong IP: Logged |
xiaofan Member |
posted July 22, 2007 12:46 PM
Just want to point out that this thread is continued on the following thread. http://www.cygnal.org/ubb/Forum9/HTML/001336.html IP: Logged |
Tsuneo Member |
posted May 10, 2008 07:18 AM
Updated to v1.5 - Rewrote most of the source code to fit to composite device - Added ZLP to terminate the bulk IN transfer - Fixed bug of FIFO_Read_generic() - Revised the INF file to support Vista The link is on the first post above. Tsuneo IP: Logged |
Kaiser New Member |
posted September 18, 2008 01:32 PM
Are there any tricks to making this work with Keil uVision 3? I'm using an F340 eval board. It will compile with uVision, but when I download and run it I get a "USB Device Not Recognized" message from Windows (XP Pro). I assume there is something wrong with my project setup, but I don't know where to begin! Thanks IP: Logged |
Patryk Member |
posted September 19, 2008 03:59 AM
Some spottings in CDC v1.5: 1. In USB_Main.c, Usb_Suspend(): Missing Clock Detector must be disabled before disabling internal oscillator to avoid reset. Clock Multiplier should be disabled too: someone reported on forum that it need to be disabled to achieve current below 300uA. 2. Mistake in comment in USB_Standard_Requests.c, Set_Configuration(), line 709: 3. IS_POWER_OF_2() can be used to enable optimization in USB_CDC_UART.c. // TXRDIdx &= (TXBUFSIZE - 1); // when TXBUFSIZE is just power of 2 you can use: #if (IS_POWER_OF_2(TXBUFSIZE))
[This message has been edited by Patryk (edited September 19, 2008).] IP: Logged |
Tsuneo Member |
posted September 20, 2008 08:16 AM
Kaiser, Check listing (.LST) and map (.M51) file on the output of these IDEs.
I'll update it following your advise. Tsuneo IP: Logged |
Kaiser New Member |
posted September 23, 2008 11:44 AM
I figured this out. If anyone else tries to make it work in uVision, the problem was with trying to run with a Large memory model. It works out-of-the-box if you set it to use a small memory model. I also got it to work with a large memory model by forcing all of the variables declared in USB_ISR.c to be in idata (they might not ALL have to go there - I was trying to make it work without spending too much time on it) IP: Logged |
l456789 New Member |
posted November 23, 2008 04:03 AM
Hi,I use 'USB_CDC_skeleton_15.zip' on F320 test.I found short TX RX,when PC send data,PC only receive one time. I use 9600bps.Where have error? ------------------ [This message has been edited by l456789 (edited December 29, 2008).] IP: Logged |
jsuijs New Member |
posted February 02, 2009 02:03 AM
Hi all, I am a newby on USB and hope you can point me in the right direction. Searching for option, I come across two: use a HID driver or write your own cdc driver. Both have rather much impact (I have to start on windows driver developemnt and I was wondering if there is cdc driver out there that does what usbser.sys is supposed to do and could be configured to work with my setup. Any help will be appreciated! Joep IP: Logged |
egawtry Member |
posted February 05, 2009 09:28 AM
l456789, We cannot find a problem without seeing the code. Most people here in the forum don't speak or read chinese. Please link to your code, not the website. jsuijs, A CDC uses usbser.sys, which is built into Windows. All you need is an INF file. For Vista 64 you need to have it certified with a cat file. If you need control along with a serial port, take a look at the thread I had to fix a few things (as shown in the thread), but otherwise it works great! -Erik [This message has been edited by egawtry (edited February 05, 2009).] IP: Logged |
eyeore New Member |
posted March 17, 2009 07:30 AM
Can anyone please clarify how the device is expected to deal with unsupported parameters in SetLineCoding request? Should it return STALL? IP: Logged |
JJcal New Member |
posted March 31, 2009 11:04 PM
Hi... Great work on the demo, but I can't get it to run. I get the first character typed to echo in RealTerm on Com 4 just as expected, but then no more. I am running the '320 dev board and Win XP with Keil compiler. Suggestions anyone? IP: Logged |
egawtry Member |
posted April 01, 2009 09:06 AM
1. Did you convert all the init functions to 320 from 34x? 2. Make sure that you have the mod for the SetLineCoding() bug as described in this thread. 3. Hook up the debugger and see where everything stops. -Erik IP: Logged |
JJcal New Member |
posted April 01, 2009 10:20 AM
I've checked through the code to make sure the '320 options are there. Characters come in, get read from the incoming ring buffer, and placed in the outgoing ring buffer, but never make it back to the PC. Everything keeps running, just doesn't transmit anything. I get an interrupt (IN2_FIFO_empty) on the first character output, and then no more. [This message has been edited by JJcal (edited April 01, 2009).] IP: Logged |
egawtry Member |
posted April 02, 2009 07:19 AM
Hmmm, I am more familiar with the CDC Composite code, could you try that? (It does the same thing but also provides an HID connection.) If that doesn't work, then I can really help. Otherwise, we (you, me and everyone else reading this) can try to debug things here. You could try posting what you are using for your main() while loop. -Erik IP: Logged |
jeremy Member |
posted December 12, 2009 06:41 PM
Hi, We seem to be running into a problem where when we get an STSTL interrupt, there is also a packet in EP0 FIFO (OPRDY = 1). The return statement in "if (ControlReg & rbSTSTL)" means this packet is ignored by the firmware, and eventually Windows sends a USB reset after a 5 second timeout. This is happening in maybe 1% of cases, and is probably aided by the fact that our USB interrupts are off for a few ms. I have removed the "return" to fix this, but this creates a new problem: sometimes after the STSTL, OPRDY is set, but all bytes in the SETUP packet you read out are the same. To resolve this, we check for 8 identical bytes after reading the SETUP packet, and discard it if so. IP: Logged |
lakata New Member |
posted October 25, 2010 03:05 PM
Typo in code found: if ( endpoint == EP3_IN ) should be if ( endpoint == EP3_IN ) IP: Logged |
grantb4 Member |
posted April 05, 2011 10:48 AM
Thanks lakata ... and of course Tsuneo! IP: Logged |
grantb4 Member |
posted May 19, 2011 04:39 PM
BTW, I haven't gotten to the bottom of it yet, but the CDC_Skeleton_15 does not appear to work correctly under Win2k. It enumerates OK and a COM port is created. But data transfer only works from host to device. IP: Logged |
egawtry Member |
posted May 20, 2011 06:02 AM
That is because CDC was not implemented propertly by MS until XPSP3. -Erik IP: Logged |
grantb4 Member |
posted May 20, 2011 12:04 PM
Thanks Erik. I tested it on a Mac Mini running OS-X 10.4 and Ubuntu Linux v7.1 and it works great so far. XP as well, of course. I just have to figure out what direction I want to go with the serial number string... (it's discussed here: http://www.lvr.com/usb_virtual_com_port.htm ) IP: Logged |
egawtry Member |
posted May 24, 2011 09:45 AM
I dynamically build the serial number off of the factory serial number that we set in the device. The code is simple, just a unicode string (every other byte a 0 with double zero at the end). IP: Logged |
ferika Member |
posted July 19, 2011 09:18 AM
Hi! Can i hope, that it will go working on XP SP3 ? Like reported here - COM3 recognized ok, but no function. Both directions dead. I does the correction described near above, so that may be not that problem. Or - can enyone post me a realy working HID or other similar firm to make USB to RS232 bridge with WinXP SP3 built in drivers? Inf ok, but no new drivers needed pls. With C8051F32x pls! Thx, IP: Logged |
egawtry Member |
posted July 19, 2011 02:12 PM
I use the CDC on XP SP3, Vista, Win7, MacOS/X, and Linux. Works great on all of them. IP: Logged |
All times are CT (US) | next newest topic | next oldest topic |
Have you seen our MCU Knowledge Base?