Serial Bus Speed on PCs

That scheme requires every end point to know where it is in the grand scheme, but more importantly, to know what other end points are in the system. It also requires the master to address every end point in sequence. How would you address one end point only, or some number of missing slots? This would require the end point keep track of what commands have been sent, as well as who has replied.

I've mulled this about for the last few days, including a priority scheme where handshake lines would be used to pass the priority more mechanically. This priority "token" could be passed through the entire chain of 16 boards and 8 endpoints on each board, but it can also be done by using a priority chain only within the 8 slaves on each test fixture boards. This will provide a burst of serial port operation for about 500 us at a 3 Mbps rate. So if USB has a polling rate of 1 ms, we would get half bandwidth, which would be pretty good. I feel better about blocking 8 commands for a given test fixture than blocking all 128 commands.

Someone had suggested padding the transmitted data to set the timing of the replies. That would work as well, and order would no longer be significant at all. But I'm not comfortable with sending garbage data too control timing. It can make debug more difficult. Too bad there's no way to send a data byte without a start bit! lol

Of course the application doesn't care. No one is worried about the application. The concern is the timing of the messages on the various buses. A message broken up too much may be sent in multiple small pieces resulting in more delays.

I don't "expect" anything of the adapter. They have delays that are largely unexplained, at least in any detail. That's why this is hard to deal with.

Right now I'm looking at using a priority enable across the 8 end points within a test fixture board. That will allow a 400 us message block at 3 Mbps, with 350 us of overlap between the commands and the replies, so 450 us total. That would work well with either a 1 ms polling rate or a 0.5 ms polling rate, if available, and provide 50 us of breathing room for the adapter.

This is a lot like making gears for a mechanical clock, with a calendar and an appointment reminder. LOL

Things like computer locking up (IIUC fixed by newer driver). Or "communication did not work" (no real info). ATM I have enough converters. If I need more/better I will look at FTDI products and possible ask them questions.

It was FTDI who bricked fakes, that was widely discussed. I did not hear about Prolific doing something like that.

It seems that your news agent messed formating of tables. I gave results in two columns, one column for 15 character messages, second for 20 character messages. 0.764s is for 15 character messages,

I last part I was partially wrong. USB-2.0 spec says that transmission between PC and high speed hub is always high speed. For full speed devices hub is supposed to buffer messages and transmit to device at its speed. In effect PC needs two high speed messages per low speed message. My tests above was with converter connected via high speed hub. There was also Stlink dongle plugged into the same hub. To remove effect of hub I tried plugging converter directly into USB-1.1 port on separate USB controller. That led to significantly longer times. I also tried to connect Stlink into separate port so that converter was the only thing connected to the hub. I run several times few cases at 3 Mbits/s, for short messages and low k results vary significanlty, for 120 characters and k = 0 I got times from 6.375s to 6.598s. At 2 Mbits/s in 25 runs I got one outlier at 6.667s, the rest was between 6.029s and 0m6.049s.

Anyway, USB seem to have significant impact on possible speed, with full speed convertor and full duplex trasmission 2 Mbits/s seem to give better speed than 3 Mbits/s. Maybe better USB hub could help (I do not know how to find out size of buffers in my hub, but by the spec hub may have buffers just for 2 bulk transfers or mauch more). Given the above I would expect convertor connected via high speed USB to perform better at 3 Mbits/s.

See above. Note that my test slave started replay after receiving first character. ATM it seems that with enough overlap at 2 Mbits/s I getting repeatably almost optimal speed (even with 1.1 port). But with less overlap there are randomly looking variations, which probably means high sensitivity to precise timing of messages. And at 3 Mbits/s variation seem to be much worse.

Yes, I see that now. Google Groups removes excess spaces. Not a good idea and for no apparent reason. If they want to conserve bytes, maybe they should delete the message contents. That would greatly reduce the noise and only reduce the signal slightly in many cases.

I would not be using a hub at all. This PC would be dedicated to testing and only a mouse would use a USB in addition to the serial dongle. Oh, I think they use a bar code scanner too, so three USB ports.

The priority protocol I described above would overlap after one message. So not a lot of difference.

Thanks for the info. It was very useful.

You do realise it is up to /you/, the person making a post, to snip excess content? For some reason, google posters do this extremely badly

- either they never snip, or they cut too much (including attributions).

Google groups ruins the format of Usenet posts - including removing leading spaces and screwing up line endings. It's one of the reasons why so many Usenet users dislike it.

(Yes, I know you have some particular personal reasons for using GG.)

I guess I should have used a smiley. I was trying to say that much of what is posted here would be better not posted at all... as a joke.

I think there's been a lot of interesting stuff posted in this thread. Maybe not all of it has been useful to /you/, but you're not paying us for the job. So we chatter - sometimes people learn something new or get some new ideas.

Again, I was not being clear enough. By "here", I did not mean this thread. I was referring to newsgroups as a whole.

IT WAS JUST A JOKE!