dwelch67 wrote: ↑
Tue Dec 19, 2017 7:02 pm
Nope, just stating that a break is a framing error. uarts are not all built equal (although a lot like/try to clone the 16550). So if there isnt a specific break detect and/or it doesnt work then perhaps a combination of framing error and rx data maybe you can assume break from that. I have not looked at these uarts on this topic so dont know what I would try...
"Nope"? Sorry if I was unclear, that's exactly what I meant
I wanted to say detecting break in a framing error handler seems to be a good idea. My thinking was like this:
1. On RPi with a serial cable on pins 14/15 PL011 can distinguish between framing error and a break, so it is possible
to tell them apart
2. If AUX does not detect break, only framing error, then the same algorithm PL011 uses could be used by software in a framing error handler
3. To implement 2. one would need all the information PL011 hw has and use in that algorithm
4. Because break in length is not a multiple of a character length, to continue normal operation, one would need a re-sync
I'm 100% sure about 1., 2. and 4. What I don't know, is 3. Originally I was thinking about dumping all the device's registers in a dummy handler, and then feed it with several breaks and framing errors, and see in the dumps what's the difference (if any difference exists at all, there's a chance what PL011 hw uses to tell them apart is not exposed in user readable AUX status registers at all). Maybe a rx data is required, but not sure, I'd bet on it's not doable. Let's say break is 1,5 length of a character. In that case you'll need a longer than 1 character length to be able to detect framing error (to make sure it's not a valid zero character you're receiving). That means you are left with a less than 0,5 length signal remaining, which (I assume) cannot be read as a normal rx data, hence the need for a re-sync in the first place.
But I'm just guessing here, and doing think experiments. Framing error handler that can detect break by software seems doable in theory, but definitely needs more empirical information. If you cannot read all the information in the error handler, including reading shorter than a full character length signal, or if there's no difference in AUX register's bits for a framing error and a break, then software emulation cannot be done in practice for sure. Your idea led to a theory that can be checked by some experiments, which is really great! I like that!