gsoc-2014-hdmi2usb
Week 6: Time for PCBs!
Motherboard schematics are ready and we’re all set to do the PCBs for motherboard! Last week was spent on organizing the repository, schematics and making various decisions that affected schematics. There is slightly more work to be done on daughterboards schematics and it needs more reviews and fixing.
We began this week by figuring out the best possible autodetection scheme. We discussed about possible use cases for autodetection and how different autodetection schemes would fit into it. First scheme was measuring RC time constant using an I/O pin on the daughterboard. The problem with this scheme was that the RC time-constant measurement using an I/O pin is prone to errors since it depends on logic level thresholds of the I/O pin, which are not clearly documented and their errors are unknown. Slight change in the threshold values can affect our measurement greatly. These thresholds can depend on temperature, VCC, noise and production batch. A reliable way would be measuring the time constant using a voltage comparator and a precision voltage source. But this is the multimeter method and is a bit expensive.
I and Rohit (who’s doing VGA expansion board) settled for I2C EEPROM based detection where each daughterboard will have an inexpensive, pin addressable EEPROM storing ID and configuration data for that daughterboard. The EEPROM slave address gets set on the motherboard, the addresses depend on the slot the daughterboard is connected to.
We were also suggested to take a look on SPI daisy-chaining of EEPROMs, because that would have been the most flexible auto-detection method. I2C based method is addressed based, all EEPROMs with slave address 0 will have expansion board data and EEPROMs with higher address would have module data. If we want to connect more than one expansion board by splitting VHDCI connector, there would be an address conflict in I2C based detection. SPI daisy-chaining would solve that. But it turns out that SPI daisy chaining is not possible for the reasons documented here by Rohit.
I had completed by first run of schematics which got reviewed by Tim. There was a heap of issues with my repository as well as schematics that were fixed one by one.
This week I started the daughterboards and created templates for them. I completed first run of RS232, IR, RS422, GPIO daughterboards. And there are issues with them to solve. It’ll probably take up to a day.
I updated the requirements document to reflect our new decisions. This document never seems to finish because there’s always something new to add or update. As of now there are things to do in that document - like explaining the system diagram I made. The information related to serial communication has become quite fragmented might needs to be more organised. I have to complete the power calculation spreadsheet which will bring out some new limitations and challenges.
It seems we need to wind up the hardware part by this week. We need to:
- Finish daughterboards, get it reviewed.
- Update requirements document.
- Start PCB design, get quote from PCB manufacturers.
- Once again, check and finalize daughterboard depth, motherboard depth and width.
- (Hopefully) complete the motherboard PCB by this week.
