| 00:23.16 | *** join/#qi-hardware infobot (ibot@rikers.org) |
| 00:23.16 | *** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware |
| 00:23.16 | *** mode/#qi-hardware [+v infobot] by ChanServ |
| 04:18.13 | *** join/#qi-hardware _whitelogger (~whitelogg@uruz.whitequark.org) |
| 04:18.13 | *** mode/#qi-hardware [+v _whitelogger] by ChanServ |
| 04:25.41 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:56.48 | promach | DocScrutinizer05: 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 ? |
| 06:26.24 | *** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-jzflmyjapwvuxawx) |
| 07:07.10 | *** join/#qi-hardware tavish (~tavish@unaffiliated/tavish) |
| 08:11.46 | *** join/#qi-hardware erichvk_ (~esh@ppp14-2-106-195.lns21.adl6.internode.on.net) |
| 08:21.31 | *** join/#qi-hardware dandon (~dandon@185.16.52.115) |
| 08:32.31 | *** join/#qi-hardware sb0 (~lekernel@59.152.213.90) |
| 09:25.43 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 12:01.26 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 13:55.35 | DocScrutinizer05 | promach: for stuff like 1200/75 or somesuch? generally for different baud speeds for TX and RX |
| 13:56.53 | promach | what 1200/75 ? |
| 14:22.52 | DocScrutinizer05 | 1200bd uplink, 75bd downlink |
| 14:23.13 | DocScrutinizer05 | or vice versa |
| 14:59.49 | *** join/#qi-hardware wpwrak (~werner@13-145-231-201.fibertel.com.ar) |
| 15:00.47 | promach | DocScrutinizer05: have you ever used 1.5 stop bits for UART ? |
| 15:00.58 | DocScrutinizer05 | nope :-) |
| 15:01.28 | DocScrutinizer05 | actually stopbit settings are non-critical |
| 15:03.06 | DocScrutinizer05 | it'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 unnoticed |
| 15:05.45 | DocScrutinizer05 | after all when you have a delay in providing next byte to send, you have an arbitrary high number of virtual stopbits anyway |
| 15:08.10 | DocScrutinizer05 | basically you need the stopbits only to have an edge to sense when next startbit arrives at RX |
| 15:08.43 | erichvk_ | will have trouble sleeping, not knowing if serialised data structures are necessarily a kolmogorov space |
| 15:09.21 | DocScrutinizer05 | so 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 TX |
| 15:11.52 | wpwrak | 0 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:12.23 | DocScrutinizer05 | I said "in theory". There are no RL implementations of that |
| 15:12.32 | DocScrutinizer05 | afaik |
| 15:13.18 | DocScrutinizer05 | any implementation would of course *not* check for framing errors |
| 15:15.37 | wpwrak | ok. 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:16.05 | DocScrutinizer05 | there 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 long |
| 15:16.31 | wpwrak | or "bit stuffing" |
| 15:16.31 | DocScrutinizer05 | this is not called UART though |
| 15:18.18 | wpwrak | .. which may be what you mean with the inverted symbol |
| 15:18.27 | DocScrutinizer05 | yep |
| 15:19.00 | DocScrutinizer05 | I was a tad fuzzy with that description above. It's literally over a decade since I last looked into it |
| 15:19.18 | wpwrak | i.e., tx: if you've sent N zero bits and are about to send another zero, send a one first, and reset the counter |
| 15:19.31 | DocScrutinizer05 | :nod: |
| 15:19.41 | wpwrak | rx: if you've received N zero bits, discard the next one. if the next is a zero, raise hell. |
| 15:19.54 | DocScrutinizer05 | :nod: 2 |
| 15:20.46 | DocScrutinizer05 | the "escape" |
| 16:46.44 | *** join/#qi-hardware tavish (~tavish@unaffiliated/tavish) |
| 17:42.23 | *** join/#qi-hardware pcercuei (~pcercuei@96.pool85-49-238.dynamic.orange.es) |
| 17:49.10 | *** join/#qi-hardware wildlander (~wildlande@unaffiliated/wildlander) |
| 19:31.28 | *** join/#qi-hardware sb0 (~lekernel@138019142177.ctinets.com) |
| 22:30.23 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 22:32.04 | *** join/#qi-hardware kristian1aul (~kristianp@unaffiliated/kristianpaul) |
| 22:32.18 | *** join/#qi-hardware eintopf_ (~eintopf@unaffiliated/eintopf) |
| 22:40.35 | *** join/#qi-hardware Nik05 (~Nik05@unaffiliated/nik05) |
| 23:09.08 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |