[Simulavr-devel] more info on serialrx/feedback issue

[Joel Sherrill]

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
address@hidden        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985