gsoc-2014-hdmi2usb
Daily snippet
- More github repository issues resolved and a few more added to the pile :D
- Discussed PIC18 USB pin assignments: We shifted around pins to get access to hardware I2Cs, SPIs and UARTs in best possible way. All thanks to Tim and his spreadsheets!
- While I was making the RS422 daughterboard I noted that the differences between RS422 and RS485 are not that trivial - RS422 have unidirectional lines and support simplex or full-duplex mode. RS485 can have a bidirectional line and is designed for multitap networks. So it can have simplex or half-duplex modes. http://www.ad-net.com.tw/index.php?id=62
- A really nice guide that differentiates between RS422 and RS485: http://www.diit.unict.it/users/scava/dispense/II/RS485.pdf
- Figured out that flow control in RS422 and RS485 is not needed which is well explained here: http://en.wikibooks.org/wiki/Serial_Programming/RS-485#Handshaking I like the way handshaking is explained in 2nd sentence.
- There's RTS flow control which is used only if supported by software. And it doesn't hurt to provide support for RTS control in hardware by giving a jumper option.
- Another way of flow control which is sometimes built into the converter hardware is called Automatic Send Data Control. In this method a controller within the converter enables the RS485 transmitters *as soon* as it sees data coming from UART TX and shuts off the transmitter so Hi-Z state after a *certain time* of inactivity. The terms "as soon" and "certain time" are critical here and are highly baud-rate dependent. This is baud-rate specific and hence application specific. This is also not a part of any of the EIA-4XX standard and it might be a marketing thing.
- If the Automatic Send Data Control is needed and the software doesn't support RTS control we can force it in the FPGA or the PIC18F by manipulating RTS. Here's when board auto-detection can be useful.