#avr Logs

Apr 02 2022

05:00 AM specing_ is now known as specing
12:44 PM WormFood: If I run a serial port, at an 8.5% error rate, which is obviously way outside of it's recommended range, how successful do you think I'd be? Would you think there would be a lot of errors? Actually no, it runs perfectly. Never gotten an error yet...my target speed is 460.8Kbps, and my actual speed is 500Kbps. I expected an occasional error, but nope, working fine.
12:49 PM cehteh: its not about baudrate, x% are x% no matter if its 300Baud or 115200baud
12:49 PM WormFood: no
12:49 PM cehteh: and its about tolerances/drift .. and how satuated your link is
12:49 PM WormFood: it's slightly more complex than that
12:49 PM cehteh: yes just generally speaking
12:50 PM WormFood: because it depends on more than just your clock speed...it also depends on the clock speed on the other side.
12:50 PM WormFood: if the other side is high, and I'm low, then the tolerances come more into play
12:50 PM cehteh: when yours is +8.5% and the other happens to be -5% ... then you may run into problems esp when you have something like echoing back everything send
12:50 PM WormFood: but, if they're on speed, and I'm slow, now I'm allowed to be twice as much out of tolerance.
12:51 PM WormFood: it echos nothing.
12:51 PM cehteh: one sides buffer will fill and overflow
12:51 PM WormFood: no
12:51 PM cehteh: yes just example
12:51 PM WormFood: the buffer means nothing in this case
12:51 PM WormFood: it has all to do with the timing.
12:51 PM cehteh: when you dont echo, dont satuate the link and it works then .. it works
12:52 PM WormFood: what? There are 2 lines. Saturate it or not, does not matter.
12:52 PM qu1j0t3: Two lines there are.
12:52 PM cehteh: avr's sample the pin 6 times per bit or 3 times in the x2 mode iirc
12:52 PM WormFood: the timing tolerances on async serial communications is what matters
12:52 PM WormFood: no, x2 or normal mode just sample 3 times
12:53 PM WormFood: but in x2 mode, the samples are spaced more apart
12:53 PM cehteh: really? i thought i remebered that the samples are cut in half too
12:53 PM WormFood: so, in normal mode, it samples the serial on clock pulse (relative to that packet) on pulse #10,11,12, and in X2 mode, it'd sample at #9,11,13 clocks
12:54 PM WormFood: those numbers are not accurate, I just show their relationships
12:54 PM WormFood: is my explanation clear enough to understand?
12:54 PM WormFood: I know I'm right, I was just going over the serial info in the datasheets the other day.
12:55 PM cehteh: anyway you can calculate by that how much it could tolerates, it syncs on the start bit, then 10 bits (or 11) follow last one is the stop doesnt matter
12:55 PM WormFood: I'm not talking about that bit. I'm talking about the internal clock, in reference to a single bit
12:56 PM WormFood: so, a UBBR of 32, means there are 32 clock pulses, for each serial bit of data
12:56 PM cehteh: so lets say 10*3 samples ... 30 samples for receiving, will 8.5% skew that enough that the last bit cant be recogized?
12:56 PM WormFood: yes, no problem
12:56 PM cehteh: i didnt do the calc but i didnt expect a problem either
12:57 PM WormFood: it's 8 data bits, so 10 bits total with the start and stop bits (which you know), and it works fine at 8.5% error rate
12:57 PM WormFood: but, if the other side, was out of tolerance in the opposite direction, then I'd expect problems at that error rate.
12:58 PM cehteh: there is a +/- 1 sample clock shift too which may affect it slightly ,, but then you are ok
12:58 PM cehteh: yes
12:58 PM WormFood: however, this is a usb serial port interface, and I expect that helps to make sure things are in sync.
12:59 PM WormFood: anyways, I know a lot of people would cringe, and say you can't run at 8.5% tolerance, because it's outside of the absolute recommended ratings.
12:59 PM cehteh: problem is what i saied first: when both directions are satuated and the software somehow expects it can send as much as it can receive (like echoning) it will sooner or later run into problems
12:59 PM cehteh: (when sending is solwer)
01:00 PM WormFood: and one thing I wanted to play around with, is sending data at the wrong bit rate, and have it represent meaningful data on the other side.
01:00 PM cehteh: funny node was my early echo testing where i send \n only but it replied with \r\n ... which eventually made the send buffer overflow
01:01 PM WormFood: I mean, like have the transmitter at 115.2k baud, and the receiver at 57.6k
01:01 PM cehteh: i tihnk thats becomeing pretty hard
01:02 PM WormFood: well, each bit at 115.2k is 1/2 the size of each bit at 57.6k
01:02 PM cehteh: yes but you have the framing
01:02 PM WormFood: send the right bit pattern at 115.2k and it can be meaningful at 57.6k
01:02 PM cehteh: you may put the receiver in 9 bits mode
01:02 PM WormFood: yes, that too
01:03 PM cehteh: and your sender may make sort unaccounted pauses between stop and start bits
01:03 PM cehteh: that'll totally mess things up
01:04 PM WormFood: I had already made up tables, of which characters at 115.2k could be meaningful at 57.6k, and if you can switch between 5,7,9 bit mode, without a hiccup in the data stream (which I think it can't do), then I could do some interesting things.
01:04 PM WormFood: you can't rely on that, especially with usb serial ports
01:04 PM cehteh: thats what i mean
01:05 PM WormFood: each byte would have to start with a 1, to finish out that 1/2 sized start bit
01:05 PM WormFood: the stop bit, can be recognized as the rest of the byte as all 1s
01:05 PM WormFood: I mean, if you put a pause after the character, the idle will be read as data and the stop bit
01:06 PM WormFood: anyways, I thought it was an interesting idea, and I wanted to experiment with it. My idea was to send a message, that basically indicated you're at the wrong baud rate.
01:07 PM WormFood: as if garbage wasn't enough to tell you ;)
01:08 PM cehteh: connecting to a ongoing transmission is already bad enouhg :D
01:09 PM cehteh: my usual approach is that the client sends a "terminal reset sequence" .. and the µC does some heartbeat messages,
01:10 PM cehteh: after the client sends that it waits for the heartbeat and only then the connection is deemed to be sane
01:12 PM cehteh: heartbeats are only send when the µC input buffer is empty (and the terminal reset sequence clears it)
01:14 PM WormFood: are you talking about flow control?
01:17 PM cehteh: no
01:17 PM cehteh: talking about connecting to a runnin µC that sends data out already
01:18 PM cehteh: when you connect in the middel of some transmission you get some garbage
01:31 PM WormFood: well, that is just design at that point, and all in software
01:42 PM WormFood: I saw the back of a late 1970s model serial terminal, and they support the following bitrates: 75 110 150 300 600 1200 1800 2400 4800 7200 9600 19200 <-- I've never seen anything advertised to operate at 75 or 150bps, but I know 110bps is still used today.
01:45 PM cehteh: for debugging my CLI unicode handling i turned it into 30bps ... pretty nice when you can see how a line is redrawn :D
01:46 PM cehteh: was kinof "hold my beer, my terminal supports double width chinese characters, why shouldnt my µC"
10:18 PM mikee is now known as saxicola