On Thu, 4 Jul 2013 at 14:44, Frank Schäfer wrote:
Even more interesting would be the Windows driver that has been used
for reverse-engineering. ;) AFAIK, the standard Windows driver
doesn't use the second method (last checked 2-3 years ago)...
The thread opener said he can set the non-standard rate of 250kBaud
under Windows, so either that rate got added to the standard list or
the driver nowadays also supports the second method.
To summarize our current knowledge:
divisor = 2^A * B
with
A = buf[1] & 0x0E
B = buf[0] + (buf[1] & 0x01) << 8
Confirmed.
For default baud rates where that 9th bit gets set when using the
flexible method (e.g. 57600: A=4, B=416) I get the exact same timings
from my logic analizer for both methods.
I've tested this formula and it works from 46 baud to ~1.5MBps. I'm
not sure what happens at higher baud rates - could be a cable
problem.
With my logic analyzer (send a 0x00 byte and measure the time of the
resulting nine bit wide low pulse) I was able to test it for data
rates up to 24MBaud (A=0, B=16).
- B=0 case ? b=value+1 ?
I get unexpected results for B < 16, regardless of the value of A.
- best method for buf[0], buf[1] determination ? (multiple
possibilites to encode the divisior !)
I've come up with the following loop that increases A until B drops
below 512. It uses one more bit in B for rounding at the end, so we
get the baud rate that is closest to the requested one instead of
just truncating the lower bits.
--- snip ---
unsigned A = 0, B = 12*1000*1000*32*2 / baud;
while (B >= 1024) {
A += 2; /* Multiply the predivider by four */
B >>= 2;
}
B = (B + 1) >> 1;
buf[1] = A & 0x0e | ((B & 0x100) >> 8);
buf[0] = B & 0xff;
--- snap ---
cu
Reinhard
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
