For a first timer using the above services, I must say – I am impressed. Very impressed!
But, as soon as I started assembling, I noticed the first mistake I’ve made in the design process: the values of the LED current limiting resistors for the test boards were off – way off! With a 10k resistor at +5V DC, don’t expect to see the LED too bright! I have exchanged all 8 of them with more appropriate ones – with a value of 270 Ohms. The open source schematic on EasyEDA has been updated since.
As a warm up exercise, I assembled the test board first and the actual port expander second. The second problem I have noticed was the pin headers on the port expander. I thought using ones with slightly longer pins would do, but as the USB connector of my UNO was in the way, I was forced to use another set – as an adapter on the bottom side of the board.
The third problem – and this one was a significant (but definitely not without a resolution!) – was that the two pin headers on the port expander board (one for the extended inputs, the other one for the extended outputs), although in parallel, their axes didn’t overlap – which wasn’t the case for the companion/test shield!
This had no impact for the intended use of the port expander board (I ultimately would connect proto wires directly on it), but in this case it implied I couldn’t use the companion board – as is – which was a pity.
So I decided to sacrifice the test board, by removing the traces from the pins leading to the DIP switch, drilling one extra hole (by an offset of 100 mil) so that I can align the input pin header with the output one. I then drilled 8 additional holes just beneath each pin, solder wrapping wires to each one and routed the wires through the holes to the bottom side of the board:
I ended up using blue nail polish to mask the imperfections as much as I can.
After this, I was ready to re-stack my boards, upload the code from my BitBucket repo, and test everything out:
And it didn’t work! Then I remembered that it would probably be best if I use the UNO with an I2C scanner first, and what I realized as a result, was I had to update my device addresses to:
#define OUTPUT_DEV_ADDR 0x38 #define INPUT_DEV_ADDR 0x39
And it didn’t work again! I then noticed that the value of the chip capacitors is larger – much larger (I wonder how that happened :)) – than what is recommended, and as it was also suggested you could do without – I ended up removing them all together.
Then it worked as expected!
Now I just have to mount this extender board onto my robot chassis, and start programming! But this is for a different post.