#qi-hardware IRC log for Friday, 2017-06-02

promachDocScrutinizer05: do you have any idea why 16550 UART needs to have two separate 8-bits divisor latches instead of one single 16-bit divisor latch ?04:56
DocScrutinizer05promach: for stuff like 1200/75 or somesuch? generally for different baud speeds for TX and RX13:55
promachwhat 1200/75 ?13:56
DocScrutinizer051200bd uplink, 75bd downlink14:22
DocScrutinizer05or vice versa14:23
promachDocScrutinizer05: have you ever used 1.5 stop bits for UART ?15:00
DocScrutinizer05nope :-)15:00
DocScrutinizer05actually stopbit settings are non-critical15:01
DocScrutinizer05it's the least severe "error" that can happen in serial transmission. sending with one stopbit and receiving with 2 is "worst", causing an error flag but no data corruption or other problems. Sending with two or 1.5 and receiving with 1 stopbit goes unnoticed15:03
DocScrutinizer05after all when you have a delay in providing next byte to send, you have an arbitrary high number of virtual stopbits anyway15:05
DocScrutinizer05basically you need the stopbits only to have an edge to sense when next startbit arrives at RX15:08
Action: erichvk_ will have trouble sleeping, not knowing if serialised data structures are necessarily a kolmogorov space15:08
DocScrutinizer05so in theory you could even use zero stopbits, which would rely on delays and bytes ending with a stopbit-level bit, to sync the RX hardware to TX15:09
wpwrak0 stop is likely to get you a lot of framing errors, even if you always have a little bit of delay. also, implementations probably won't look for a start bit until after the stop bit time (after all, they're still checking for framing errors at that point)15:11
DocScrutinizer05I said "in theory". There are no RL implementations of that15:12
DocScrutinizer05afaik15:12
DocScrutinizer05any implementation would of course *not* check for framing errors15:13
wpwrakok. joerg's UART+. well, why not. i guess it would work. you'd just have to make sure you get _any_ edge every once in a while, for clock synchronization.15:15
DocScrutinizer05there are encodings (some sort of modified NRZ?) that don't use "stopbits" and introduce an escape of sorts (a special 'inverted' symbol) when too many bytes in a row don't provide an implicit "stopbit" symbol, I.E last bit sent is not different to the startbit-symbol for too long15:16
wpwrakor "bit stuffing"15:16
DocScrutinizer05this is not called UART though15:16
wpwrak.. which may be what you mean with the inverted symbol15:18
DocScrutinizer05yep15:18
DocScrutinizer05I was a tad fuzzy with that description above. It's literally over a decade since I last looked into it15:19
wpwraki.e., tx: if you've sent N zero bits and are about to send another zero, send a one first, and reset the counter15:19
DocScrutinizer05:nod:15:19
wpwrakrx: if you've received N zero bits, discard the next one. if the next is a zero, raise hell.15:19
DocScrutinizer05:nod: 215:19
DocScrutinizer05the "escape"15:20
--- Sat Jun 3 201700:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!