jazz 209 Posted October 28, 2012 Share Posted October 28, 2012 MSP430F550X is full-speed USB devices, 12 Mbits/s (1500 KB/s). Theoretical maximum transfer rate with 19 full-size packets is 19 * 64 bytes / ms = 1200 KB/s. And what about reality? I am working on CNC project, that is working just fine with uC/PC uart connection at 921600 bps. Problem is that uC/PC traffic is fast, but only few bytes are exchanging, and USB with generic drivers (usbser.sys / winusb.sys) is much slower than uart. Well, for uart connection PL2303HXD USB/uart bridge is used, and it can go fast, so what is the problem. Problem is in drivers, and USB for sure can go fast (with any data), but with customized driver, and this story I will leave for some other time. During last few weeks I done some tests regarding (CDC) transfer rate, but today I made application just for this. I read on many places on net that winusb.sys (WinXP SP2, and after) is much better (not only more stable) than usbser.sys. Was hoping that it will maybe resolve my (CNC) problems, but it didn't. Generic bulk transfer (winusb.sys) is not suported by TI USB Stack, anyway it was not problem to implement it. On uC side is the same (CDC) code, only enumeration data are different. On PC side, almost the same code. For CDC ReadFile/WriteFile are used and for generic bulk WinUsb_ReadPipe/WinUsb_WritePipe. I done my first MSP430F5510 board by p2p, long time ago. Later I done another (again p2p) with MSP430F5508. There are 2 4-pins connector, one on left side is for SBW, and another on right side is for USB. Just to show what was used for benchmark testing. If you have something like http://forum.43oh.co...elopment-board/ and poor USB transfer rate, problem is not in board, problem is in software, for sure. Here are the benchmark results for generic bulk transfer. Double buffering and/or ping pong method are/is not used (because it will not give better results). It was 4 MB transfer in both ways, first PC send to uC 4 MB, and after this uC send to PC 4 MB. For each test buffer size (WinUsb_ReadPipe/WinUsb_WritePipe) was changing, 4MB = number of loops * buffer size. It was not dummy transfer, because each side (uC/PC) was marking begining and ending side of packet, before sending, and other side (uC/PC) was checking this values after receiving. Size: 4 MB (4096 * 1 KB) Dir: MSP430 <- PC Time: 8344 ms Rate: 491 KB/s Dir: MSP430 -> PC Time: 8344 ms Rate: 491 KB/s Size: 4 MB (2048 * 2 KB) Dir: MSP430 <- PC Time: 6219 ms Rate: 659 KB/s Dir: MSP430 -> PC Time: 6234 ms Rate: 657 KB/s Size: 4 MB (1024 * 4 KB) Dir: MSP430 <- PC Time: 5157 ms Rate: 794 KB/s Dir: MSP430 -> PC Time: 5171 ms Rate: 792 KB/s Size: 4 MB (512 * 8 KB) Dir: MSP430 <- PC Time: 4656 ms Rate: 880 KB/s Dir: MSP430 -> PC Time: 4625 ms Rate: 886 KB/s Size: 4 MB (256 * 16 KB) Dir: MSP430 <- PC Time: 4375 ms Rate: 936 KB/s Dir: MSP430 -> PC Time: 4359 ms Rate: 940 KB/s Size: 4 MB (128 * 32 KB) Dir: MSP430 <- PC Time: 4219 ms Rate: 971 KB/s Dir: MSP430 -> PC Time: 4235 ms Rate: 967 KB/s This test confirmed information available on net, that host must make request with/for biggest possible data size, and in this case transfer rate will be higher. Changing host request from 1 KB to 32 KB, doubled transfer rate. Nytblade, RobG and bluehash 3 Quote Link to post Share on other sites
Philipp 56 Posted October 28, 2012 Share Posted October 28, 2012 off topic question: what kind of wire did you use for your breakout board? it looks so tidy and pretty compared to my failed atempt soldering a (only) 16 pin SSOP package. i used some very thin magnet wire, or enameled wire salvaged from a little electro magnet. my guess is that it was just too thin or too soft to work with. what is your experience soldering smd components on protoboard? Quote Link to post Share on other sites
jazz 209 Posted October 28, 2012 Author Share Posted October 28, 2012 off topic question: what kind of wire did you use for your breakout board? it looks so tidy and pretty compared to my failed atempt soldering a (only) 16 pin SSOP package. i used some very thin magnet wire, or enameled wire salvaged from a little electro magnet. my guess is that it was just too thin or too soft to work with. what is your experience soldering smd components on protoboard? I used stranded wire, nothing special. The most important thing is to have good magnifier. If you see what are you doing, than everything is much easier. I done some SMD p2p boards before (SOIC mostly), but this one was smallest work till now. I was thinking that poor USB connection (big non SMD resistors, no standard connector...) will have big impact on transfer rate, but it seems that full-speed USB transfer is not sensitive to this. RobG, Philipp, bluehash and 1 other 4 Quote Link to post Share on other sites
Philipp 56 Posted October 28, 2012 Share Posted October 28, 2012 thanks for sharing your experience! I'm not used to work through a magnifier but that might be due to the fact that my current one is mounted on a cheap third hand :/ Quote Link to post Share on other sites
Rickta59 589 Posted October 28, 2012 Share Posted October 28, 2012 That is some nice soldering! Can you tell us more about your technique? Did you super glue the wires down? Did you solder it dead bug and then flip it over? -rick Quote Link to post Share on other sites
MattTheGeek 99 Posted October 29, 2012 Share Posted October 29, 2012 Incredible work. Are you going to put epoxy the IC? Quote Link to post Share on other sites
jazz 209 Posted October 29, 2012 Author Share Posted October 29, 2012 I received some free samples of MSP40F5510 and put in on side (was playing with MSP430F2xx). Friend told me that he have microscope now, and he can give me magnifier that he was using before (for repairing mobile phones) and don't need it anymore. it was big magnifier with good stand (not falling down easily) and with nice adjusting of view position. But it was only 2x ratio, not enough for small things like MSP40F5510. I found some small hand magnifier that my father was using for looking bees, around 4x ratio, and fixed it on the stand from magnifier received from friend. Till now I am using it even when I am working with DIP, because it is very easy to make perfect soldering if you have detailed picture. Working table close to the window, direct sunlight, and that's it. There was possibility to solder each wire to each chip pin, and later to pull all wires through each hole on board and solder it. I tried it, but wire (that I used) wasn't soft, and it was not possible to do it on this way (used before with SOIC). If there is some really soft but hard to brake wire, it will be possible. I done it in different direction. I pulled wire through each hole on board, without soldering, and press it from top with males headers. After this wire was blocked, without possibility to move easily. Trying to find needed length, by cutting part of the wire close to the chip. After wire length was OK, it was soldered to chip pin. It was done in steps, each step with 4 male headers/wires/chip pins. So after 4 wires are soldered to chip pins on top side of the board, and everything was OK, male headers with 4 pins are soldered from bottom side of the board. Didn't used anything for fixing chip on the board before soldering. Just start with 4 wires in each corner to fix the chip, and later continue filling up by 4 on each side of the chip. I was traveling a lot, far away from home and soldering station. Always have some uC with me to waist some free (not working) time. As you can see on picture, bottom side of board is covered by few sheets of paper as protection. I use this kind of packing for every uC (not only for MSP430F5510) p2p board that I have. My point is not that using paper in electronic is right thing, but I didn't have any problems with this kind of packing till now. Board on attached picture is also (I done it later) protected from top side (between male headers, over chip body) by paper, without possibility to make some damage to connections. Just to be clear, before this or any other p2p board that I made, I done some layout preparation, sketches on paper. It's not random job, that will have result on bottom side of the board 20 wires that are going over each other. I like p2p a lot, and for prototyping is good way for sure, but now I am working on PCB CNC machine that will do this job for me. Quote Link to post Share on other sites
jazz 209 Posted October 29, 2012 Author Share Posted October 29, 2012 Back to topic... Benchmark results (CDC bulk transfer, 2 MB, 1 KB buffer) for original TI USB Stack (20 days ago, so it is last version) are here: http://e2e.ti.com/su...6/t/218597.aspx bluehash 1 Quote Link to post Share on other sites
jpnorair 340 Posted October 30, 2012 Share Posted October 30, 2012 Back to topic... Benchmark results (CDC bulk transfer, 2 MB, 1 KB buffer) for original TI USB Stack (20 days ago, so it is last version) are here: http://e2e.ti.com/su...6/t/218597.aspx What MCLK speed are you using? I see your results have 491KB/s, and their's have 511KB/s. Quote Link to post Share on other sites
jazz 209 Posted October 30, 2012 Author Share Posted October 30, 2012 What MCLK speed are you using? I see your results have 491KB/s, and their's have 511KB/s. I was thinking that original TI USB stack will have much worst results, but it is not bad at all. If 510 KB/s transfer rate is enough for you, uC running on 8 MHz is able to support this, and uC running on 25 MHz will wait for host (free time to do some other job). I am running uC at 25 MHz and presented test is for my USB stack done in assembler. I believe that on higher transfer rate (when host will not give much free time to uC) my version will be better (assembler vs C). This small difference between TI and my test (1 KB buffer) can be due many things. TI benchmark is done for CDC (usbser.sys win driver), and my for generic bulk (winusb.sys win driver) that is not supported by TI USB stack. Anyway, I will put benchmark software here, so anybody with small transfer rates will be able to check what is the problem. And will see if somebody is able to come closer with MSP430F55x to 1200 KB/s (theoretical maximum value). Quote Link to post Share on other sites
jazz 209 Posted October 31, 2012 Author Share Posted October 31, 2012 The highest transfer rate that I can reach on ThinkPad R52 (1.86 GHz) with WinXP SP2 and MSP430F5508 (25 MHz, board picture attached) is 1 MB/s, when PC (winusb.sys) make read/write operation at once, without looping. In this case changing transfer size (form 1 MB to 16 MB) don't have much influence on results. Size: 2 MB PC: 1 * 2 MB uC: 32768 * 64 B Dir: MSP430 -> PC Time: 2047 ms Rate: 1025 KB/s Dir: MSP430 <- PC Time: 2047 ms Rate: 1025 KB/s Here are the results in opposite case, when PC buffer goes down to 64 B, with same transfer size. It's is still better than standard uart at 115200 bps, but worst than 921600 bps (max possible rate with MSP430F55x). All standard drivers (usbser/winusb/usblib) have bad results with such transfer, and for better results customized driver is needed. Size: 2 MB PC: 32768 * 64 B uC: 32768 * 64 B Dir: MSP430 -> PC Time: 66500 ms Rate: 32 KB/s Dir: MSP430 <- PC Time: 66515 ms Rate: 32 KB/s Quote Link to post Share on other sites
jpnorair 340 Posted November 1, 2012 Share Posted November 1, 2012 I was thinking that original TI USB stack will have much worst results, but it is not bad at all.... I am running uC at 25 MHz and presented test is for my USB stack done in assembler. ... TI benchmark is done for CDC (usbser.sys win driver), and my for generic bulk (winusb.sys win driver) that is not supported by TI USB stack. I think CDC uses bulk transfers, also. Are you using LPMx and an interrupt? TI uses a busywait loop in their demos, so they are not having any interrupt latency. That would make the difference. Of course, it also makes their demo worthless as a real-world piece of software. Quote Link to post Share on other sites
jsolarski 94 Posted November 1, 2012 Share Posted November 1, 2012 it also makes their demo worthless as a real-world piece of software. Well this is to be expected from the simple demos they provide. They are just starting points to get you going for a real world device. Quote Link to post Share on other sites
jazz 209 Posted November 1, 2012 Author Share Posted November 1, 2012 I think CDC uses bulk transfers, also. Are you using LPMx and an interrupt? TI uses a busywait loop in their demos, so they are not having any interrupt latency. That would make the difference. Of course, it also makes their demo worthless as a real-world piece of software. Yes, CDC (virtual serial port) have bulk type endpoints, but it is different from generic bulk. Anyway, I will do also benchmark with CDC (usbser.sys), to see if there will be any difference in transfer rate. In my USB stack version (1KB, assembler), there is Interrupt only for USB reset/setup packet, and I also don't have any interrupt latency. Other (standard) things regarding USB I don't need (for myself) and there are (right now) not implemented. In each state of transfer PC/uC knows who is sending data to who, and in code are busywait loops. You are working on something else (standard) to support everything (all possibilities, complete) regarding USB, and this is something else. Quote Link to post Share on other sites
jpnorair 340 Posted November 1, 2012 Share Posted November 1, 2012 I'm finishing the latest version of my USB CDC subsystem. It is written in C and now compiles quite small: about 1.4KB -- I have made hundreds of architectural improvements and optimizations over the basic TI USB library, mostly for the purpose of reducing code size. I will benchmark it on 256 byte transfer size soon. My system is not intended for streaming transfers, so in normal usage there is protocol parsing latency. I will write a special benchmark app, though, which does no protocol parsing and uses none of the task-based controls. I am pretty busy with some other things, so I'll probably get to it in about 2 weeks. bluehash and jazz 2 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.