The Digilent RS232 UART reference component (downloads found on the PmodRS232 and Nexys2 pages, at least), does not do what many (including myself) might expect.
If one looks at the documentation, one can see on page 4 that it expects to see 8 data bits PLUS a parity bit. That is quite unusual - most devices sending data over RS232 send a TOTAL of 8 bits (not including the stop and start bits) -- either 7 bits plus parity or 8 bits with no parity.
Now, if one doesn't bother to check the parity, and does not send characters one right after the other, or if one includes two stop bits (this last one I have not actually tried), it may appear to work fine. The first stop bit gets interpreted as a parity bit, and the second stop bit (or the empty time between characters) works just like a stop bit - though if one is using parity, parity errors are likely to be raised by the reference component. BUT, if one sends two characters one right after the other, then parity errors and/or framing errors are quite likely. Also, if one is only expecting 7 bits of data, one might be surprised by the extra bit.
Its not a huge deal, and not difficult to fix (one can just rip out everything having to do with parity, and just take in 8 bits with no parity, for example [or do the parity computation once you have all 8 bits], or add an interface flag to tell it whether you want 7 bits and parity or 8 bits and no parity, and adjust things accordingly), but I thought I would put a posting out here - I spent a several hours debugging the input section of a little 12 bit computer (whose design goes back to 1973) before I caught on to what the problem actually was.
Question
cube1us
The Digilent RS232 UART reference component (downloads found on the PmodRS232 and Nexys2 pages, at least), does not do what many (including myself) might expect.
If one looks at the documentation, one can see on page 4 that it expects to see 8 data bits PLUS a parity bit. That is quite unusual - most devices sending data over RS232 send a TOTAL of 8 bits (not including the stop and start bits) -- either 7 bits plus parity or 8 bits with no parity.
Now, if one doesn't bother to check the parity, and does not send characters one right after the other, or if one includes two stop bits (this last one I have not actually tried), it may appear to work fine. The first stop bit gets interpreted as a parity bit, and the second stop bit (or the empty time between characters) works just like a stop bit - though if one is using parity, parity errors are likely to be raised by the reference component. BUT, if one sends two characters one right after the other, then parity errors and/or framing errors are quite likely. Also, if one is only expecting 7 bits of data, one might be surprised by the extra bit.
Its not a huge deal, and not difficult to fix (one can just rip out everything having to do with parity, and just take in 8 bits with no parity, for example [or do the parity computation once you have all 8 bits], or add an interface flag to tell it whether you want 7 bits and parity or 8 bits and no parity, and adjust things accordingly), but I thought I would put a posting out here - I spent a several hours debugging the input section of a little 12 bit computer (whose design goes back to 1973) before I caught on to what the problem actually was.
Link to comment
Share on other sites
3 answers to this question
Recommended Posts
Archived
This topic is now archived and is closed to further replies.