Jump to content

MSP430 with USB support?

Recommended Posts

I don't understand exactly what you mean -- maybe it's the nomenclature you are using. A packet is fragmented into one or more frames. Therefore, a frame is part of a packet.

- Do you mean that you cannot use packets smaller than 64 bytes? RX or TX?

- Do you mean that you cannot use packets bigger than 64 bytes? RX or TX?


If you understand this, and the issue is truly that you cannot transfer more than one packet per frame, there is no problem -- this is the way USB-CDC works.


Also: Did you use the TI USB Library C code as a starting point, or did you do it from the beginning in assembly? If you used the TI USB library at all, I remember that I had to fix some bugs in the transfer management.

I am working with Windows only, and problem is related to CDC under Windows ("usbser.sys"). Don't know what is situation on Linux or Mac, if problem is present there or not.


If you want to send big amount of data under Windows, at once by CDC, between MSP430F55x and PC, no problem at all. I done my own assembler version, based on TI USB Developers Package, and can reach around 800 KB/s without any problems. And I didn't made some dummy test, I was sending real data, and checking on other side what was received. If software on uC side is slow, speed can be increased by double buffering, but if software is fast (my example) double buffering will not increase transfer rate.


Now, if you want to exchange small amount of data under Windows, at once by CDC, it is completely different story. In my application PC send 10 bytes to uC, and after this uC send 10 bytes to PC (few or many times with user defined delay between sending), all the time, more or less like this. It is normal that in this type of communication transfer rate goes down, but not to 10 B/ms (80000 bps) in my case.


I found many posts on net regarding this problem, and it is not related to MSP430, PIC or any other uC. It is related to CDC Win driver "usbser.sys". For example http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/18572.aspx


USB is slow because driver use only one IRP. Transfer is only done at the first frame after the IRP is sent, and the IRP is only restarted after it is completed. "usbser.sys" driver use only one IRP (and libusb uses only one IRP too).


I was searching last few weeks, for freeware CDC Windows driver that supports many IRP, but didn't found anything, and at the end decided to try "winusb.sys" with generic bulk transfer.

Link to post
Share on other sites

OK, I understand. I have tested on OS X & Linux, which use the same basic CDC driver I think -- it works fine. I should also mention that I needed to fix many issues in the TI USB library interrupt service routine. I also had to fix the initialization routine: the TI USB library examples do not disconnect.


If you are building your CDC stack open source, I can try to link in into my initialization and ISR code. If you are not, my work is on the net: https://github.com/jpnorair/OpenTag/tre ... m/msp430f5


If you are building your CDC stack to be proprietary, please still contact me: I might be interested in licensing, depending on how small it is.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...