The diagram was a bit more towards functionality. What I mean to say, one board transmits and the other receives it. Sorry, I couldn’t picturize it clearly.
Yes, loopbacking a single board would be a much better choice, but it is only possible if more than one interfaces are available. Generally I2C, SPI, GPIO are available in more than one quantity, so loopbacking is possible.
Thanks,
Junaid
Ya, but the point is in I2C and SPI; which will be the master and slave? There are currently no I2C or SPI slave drivers present for the BBB.
Plus it would require synchronizing the software on both sides, which could introduces possible false pass/fails.
I do really like the idea of hardware unit testing though, how about a cape that has a device for every protocol, a voltage source, some LEDs and some buttons? That way you could test pretty much all the IO without any setup.
Yes, I agree that there will be clock synchronization issues, but they can be handled by wrapping the synchronous protocols around by asynchronous events, like 2 GPIOs change state from 00 to 01 to 11, followed by I2c transaction, followed by GPIO state change from 11 to 01 to 00.
Yes, both master and slave mode development is required.
Plus it would require synchronizing the software on both sides, which could introduces possible false pass/fails.
I do really like the idea of hardware unit testing though, how about a cape that has a device for every protocol, a voltage source, some LEDs and some buttons? That way you could test pretty much all the IO without any setup.
Having a set of hardware will definitely be a much simpler and effective approach. I was thinking in terms of creating a generalized hardware that can be used for testing a large number of protocols, but now I can see some complexities around.
Junaid