USB vs Serial SX-Key
Hi All;
I have used the serial SX-Key rev F for a very long time now, and have just now powered up my new USB Key. The installatin was painless, but·to my amazement, in DEBUG it refreshes the IDE window with a full complement of data (SX48) at only half the speed of the old serial Key.
I had expected the USB to be much faster than the serial, and was looking forward to that. But alas, another technology "improvement" (much like Windows) is actually performing more poorly. The old serial Key·varies from·60 to 100 mSec, and the new USB key takes twice that.
Go figure!
On top of that, in DEBUG the new USB key will not·RESET the SX48 out of sleep mode..... I must use the MCLR for that. Is this normal??
On the plus side, I do like the fact that it is USB powered, and can program a low voltage system without having to separately power the Key from 5Volts.
Cheers,
Peter (pjv)
I have used the serial SX-Key rev F for a very long time now, and have just now powered up my new USB Key. The installatin was painless, but·to my amazement, in DEBUG it refreshes the IDE window with a full complement of data (SX48) at only half the speed of the old serial Key.
I had expected the USB to be much faster than the serial, and was looking forward to that. But alas, another technology "improvement" (much like Windows) is actually performing more poorly. The old serial Key·varies from·60 to 100 mSec, and the new USB key takes twice that.
Go figure!
On top of that, in DEBUG the new USB key will not·RESET the SX48 out of sleep mode..... I must use the MCLR for that. Is this normal??
On the plus side, I do like the fact that it is USB powered, and can program a low voltage system without having to separately power the Key from 5Volts.
Cheers,
Peter (pjv)
Comments
there are two "bottlenecks" on both types of the SX-Key: The data transfer between the SX-Key IDE and the SX-Key (both versions operate at 57.6 kBaud), and the serial data transfer between the SX-Key and the target device. This is a special serial protocol performed via the target's OSC2 pin. It is a bit difficult to specify a transfer rate for this. The SX-Key firmware makes use of a FIFO buffer for optimized communication speed.
Both protocols, i.e. SX-Key IDE <--> SX-Key, and SX-Key <--> Target SX are the same on both, the serial SX-Key, and the SX-Key USB. Therefore, I guess that the speed decrease you have noticed can only be caused on the USB/Serial driver side. As you may have noticed, the SX-Key USB makes use of the FTDI 232R chip to interface to USB. Please make sure that you have installed the most recent VCPI driver from FTDI (available on both, the Parallax and the FTDI Internet sites). The driver will also be installed automatically when you install the most recent version of the SX-Key IDE supporting the SX-Key USB. Any drivers that may have been automatically intalled by the MS-Windows hardware detection may cause a decrease in speed. Therefore, install the FTDI drivers before you connect the SX-Key USB to a USB port for the first time.
>> On top of that, in DEBUG the new USB key will not RESET the SX48 out of sleep mode..... I must use the MCLR for that. Is this normal??
No, this should not be normal. I found out that the new SX-Key USB is more sensitive than the "old" serial SX-Key regarding "parasitic" loads on the OSC1 and/or OSC2 pins. For example, I found out that the relatively long copper traces for the OSC1 and OSC2 signals on the Parallax SX28 ProtoBoards can cause the behavior you have described.
The same may happen when you connect the SX-Key USB to a target system with the resonator/clock generator removed but a resistor still installed between the OSC1 and OSC2 pins.
I'm frequently using the SX-Key USB together with the Parallax PDB, or with my own SX28/48 board designs w/o such problems where in all such cases the OSC1/OSC2 signal traces are as short as possible.
> On the plus side, I do like the fact that it is USB powered, and can program a low voltage system without having to separately power the Key from 5Volts.
Yes, I also like this feature. Guess who did the SX-Key USB re-design
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
The FTDI chipset on the otherhand requires that the serial communications talk to a fifo on the FTDI chip, then the data is packed into packets, and·transferred to the usb host on a 16mS (default) timer, and then it is processed by the host, and transferred to a virtual com port driver, and then to the·SX Key·IDE.·The real problem here is the 16mS Timer (The rest of it is really quite fast!). Data is only sent every 16mS, unless the packet payload is 62bytes or larger.
It would be nice if the IDE were rewritten to communicate with the SK-Key through FTDI's direct drivers, and the latency timer were set to a default time of 1mS...
Anyway, You're not the only one who noticed...
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Nick
www.parallax.com/Store/Education/CustomKits/tabid/134/List/1/catpageindex/2/ProductID/378/Default.aspx?txtSearch=usb+serial&SortField=ProductName%2cProductName
...or...
www.parallax.com/Store/Education/CustomKits/tabid/134/List/1/catpageindex/2/ProductID/379/Default.aspx?txtSearch=usb+serial&SortField=ProductName%2cProductName
Thanks,
PeterM