Using the analog discovery with waveforms 3, it seems like the UART interpreter is telling me things that are incorrect. I could be completely wrong, and maybe I don't know enough about UART framing to tell, but if that's the case let me know,
The data stream I am sending is arranged like so:
[FF pad byte] - [data(lower 6 + 2 tag bits)] - [FF pad byte] - [data(upper 6 + 2 tag bits)] - [FF pad byte] - [checksum]
As you can see, those bits appear to be there, correctly, but the interpreter doesn't seem to think so.
Byte 1, the first FF, is recognized successfully.
Byte 2, the first data + tag bits, is marked as "Framing Error". From what I understand, framing errors occur when the STOP bit does not occur at the correct time. Clearly however, the STOP is bit is there, as the signal is HIGH where STOP is marked.
Byte 3, the second FF, is recognized successfully.
Byte 4, the second set of data + tag bits, is marked as "BREAK". What this means, I have no clue. The line drops low after the last FF so why isn't this recognized as a new start bit? I also believe that set of bits is correct.
Byte 5, the last FF, is correct.
Byte 6, the checksum, is also marked as "BREAK", yet appears to correctly be there.
Also, this interpretation is heavily dependent on my time scale.
The above image is at 0.01ms/div (20 MHz)
At 0.02ms/div (10 MHz), the "BREAK"s go away, and are replaced with framing errors (still, seemingly incorrectly).
And you can CLEARLY see that bit #7 in the second packet is a 1, yet the interpreter tells me the value is "h0"
Finally
0.05ms/div(4MHz)
All the errors are gone, and the 2nd packet is supposedly an h80
Question
krb686
Using the analog discovery with waveforms 3, it seems like the UART interpreter is telling me things that are incorrect. I could be completely wrong, and maybe I don't know enough about UART framing to tell, but if that's the case let me know,
The data stream I am sending is arranged like so:
[FF pad byte] - [data(lower 6 + 2 tag bits)] - [FF pad byte] - [data(upper 6 + 2 tag bits)] - [FF pad byte] - [checksum]
To get a much better look at the bits, go to: http://s306.photobucket.com/user/Krb686/media/waveforms_uart_bug.png.html?o=0. Then hover over the image at my photobucket, and click the zoom icon that appears in the top right.
As you can see, those bits appear to be there, correctly, but the interpreter doesn't seem to think so.
Byte 1, the first FF, is recognized successfully.
Byte 2, the first data + tag bits, is marked as "Framing Error". From what I understand, framing errors occur when the STOP bit does not occur at the correct time. Clearly however, the STOP is bit is there, as the signal is HIGH where STOP is marked.
Byte 3, the second FF, is recognized successfully.
Byte 4, the second set of data + tag bits, is marked as "BREAK". What this means, I have no clue. The line drops low after the last FF so why isn't this recognized as a new start bit? I also believe that set of bits is correct.
Byte 5, the last FF, is correct.
Byte 6, the checksum, is also marked as "BREAK", yet appears to correctly be there.
Also, this interpretation is heavily dependent on my time scale.
The above image is at 0.01ms/div (20 MHz)
At 0.02ms/div (10 MHz), the "BREAK"s go away, and are replaced with framing errors (still, seemingly incorrectly).
And you can CLEARLY see that bit #7 in the second packet is a 1, yet the interpreter tells me the value is "h0"
Finally
0.05ms/div(4MHz)
All the errors are gone, and the 2nd packet is supposedly an h80
Link to comment
Share on other sites
17 answers to this question
Recommended Posts
Archived
This topic is now archived and is closed to further replies.