Hi,
I misread the enumeration. The pin is
tristated so that much is OK.
I am now leaning to some type of timing issue.
In the following trace, "C" is when the change
handler is invoked inside SerialRX. It indicates
a number of state changes. "S" is the beginning
of the Step method.
Ct-2147483647-h
Ct-2147483647-h
Ct-0-l
Ct-0-l
S4-0-LS4-0-LS4-0-LS4-0-LS4-0-L
S4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-L
S4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-L
S4-0-LS4-0-LCt-0-lCt-0-lS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-L
S4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-L
S4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-LS4-0-L
Ct-2147483647-h
Ct-2147483647-h
Ct-0-l
So my interpretation is that the pin is changing
faster than the Step method sees.
I did one run where I printed the baudrate out in
step and it is always 9600. This appears to match
the value I hand calculated for Ubrr based upon
a cpu frequency of 4000000.
OUT 0x09, R24 Ubrr=0x19
The value of timeToNextStepIn_ns in the SerialRX::Step
method is computed 1e9/baudrate/16 and always has one
of the following values.
+ 6510 ns
+ 45570 ns (skip 7)
+ 91140 ns (skip 14)
I know the UART internally is using a by 16 divide but
if SerialRX is reassembling the bits based upon the "real
timing" of a RS-232 transmission, then isn't that math
wrong? 9600 baud is ~ 1 character a millisecond. Is
the Step method sampling too fast?
--
Joel Sherrill, Ph.D. Director of Research & Development
[email protected] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
Simulavr-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/simulavr-devel
