USB/serial converters, exactly why are they so slow?

[jrb1]

My son built a minipov (and a minty boost) tonight, worked first time using a very old windows pc that has a serial port, we had a lot of fun waving the thing around madly. I'm not entirely sure I want to hand my 11 year old a little glass container of mercury but the position sensor seems to be the next logical step for improved arm waving madness. I didn't see anyone posting a success story of using any other type sensor, did I miss them?

Any way I'm thinking the old pc doesn't have much life left into it so I quickly tried my ftdi usb/serial converter we use with our BBB arduino clone (the 5v verision of this one I think http://www.ftdichip.com/Products/Evalua ... L-232R.htm) by soldering up a 9 pin serial connector to a 6 pin header. Sadly this didn't work but as I start to read about using these type of converters I was struck with how slow they have to be run. My question is why is this exactly? Can we do anything about this sorry state of affairs?

Cheers,
James

[Amberwolf]

Re: the mercury switch; there are other switches out there that do the same thing via a metal ball inside a plastic box or tube (some are metal tubes); the old StarBird toy had a multi-position one in it's nose section to detect tilt direction (up, level, down) to generate different sounds.

They're still made in one variation or another, and Mouser or Digikey should have some.

No answers for your other questions, though; someone else will have to respond to those.

[oPossum]

Using a serial port for programming uses it in an unconventional way. The handshake lines are rapidly changed during programming. Normal use of the serial ports has infrequent or no change of the handshake lines. Each change of the handshake lines requires a USB transaction to occur. This same transaction could carry tens or hundreds of bytes of serial data. Every USB transaction takes some time to occur. This is a small amount of time, but will occur many times for each byte of data programmed and makes programming much slower than a serial port on the motherboard.

The FTDI cable you have for the BBB can't be used for programming because it doesn't have a DTR line. It has only 4 of the usual 9 lines and not enough of them are outputs (3 are needed for MOSI, CLK, and RESET).

Faster programming using the serial port can be done with a bootloader that uses the serial port in a conventional way. This is what the Arduino does.

The MiniPOV3 can be loaded with firmware that uses the serial port in a conventional way to update the POV image. This makes updates faster and also eliminates the need to recompile the code.

viewtopic.php?f=11&t=4941

[jrb1]

Ahh ok, that makes sense, thanks for the explanation. I was thinking that it was just that it was that it was being used through the serial driver that was the basic issue (plus the unusual use of the handshake lines) so I had a glimmer of a hope I could write a new programmer description for avrdude using the direct pin I/O driver that the FTDI chip also supports. I think what your saying is that won't help because a) it doesn't have enough output pins, and b) there is still going to be the round-trip USB transaction time per operation no matter how we address the FTDI device.

Thanks for the link, a cool approach.

- James

[adafruit]

the above posts are right. also, elexp.com has 'ball' tilt sensors. no mercury!

[jrb1]

We added a mercury switch last night which came with a stern warning about madness and making hats...