Zephyr CI Test Shield

[jfischer-no]

For some time we have been discussing the idea about Zephyr CI test shield. An example is the mbed CI Test Shield.

The shield may be used to test drivers(API) like I²C, SPI, GPIO, UART, ADC, DAC. The shield should be stackable, so that a logic analyzer or a sensor shield could be connected easily. However, the benefit of this is very limited, since apart from I²C's SDA, SCL and possibly SPI no other pins can be used. The same would apply to the additional connectors to third party modules or boards (e.g. Grove modules).

CI Test Shield draft, major differences to mbed CI shield:

• UART TX and RX are connected (a jumper could be added)
• no temperature sensor, the sensor API/driver can be tested with dedicated sensor shied

What I would like to place on the shiled is the optional connector for the Adafruit Feather Wings.

[stephanosio]

The shield should be stackable, so that a logic analyzer or a sensor shield could be connected easily.

For basic I/O testing (i.e. I2C, SPI, GPIO, UART, ADC, DAC), instead of relying on an external logic analyser, it would be more advantageous to put a small FPGA (e.g. Intel MAX10 with embedded flash and ADC) onto the shield to emulate various common interfaces on demand.

The FPGA can be hooked up to the CI host system via either USB-UART (for maximum compatibility with the existing infrastructure), or JTAG (for maximum capabilities).

For testing external devices such as sensors, the shield containing such devices can be stacked on top of (or below) the FPGA shield; in this case, FPGA could act as a simple logic analyser if necessary.

I think this approach should provide the ultimate hardware CI testing automation everyone dreams of.

[jfischer-no]

The shield should be stackable, so that a logic analyzer or a sensor shield could be connected easily.

For basic I/O testing (i.e. I2C, SPI, GPIO, UART, ADC, DAC), instead of relying on an external logic analyser, it would be more advantageous to put a small FPGA (e.g. Intel MAX10 with embedded flash and ADC) onto the shield to emulate various common interfaces on demand.

The FPGA can be hooked up to the CI host system via either USB-UART (for maximum compatibility with the existing infrastructure), or JTAG (for maximum capabilities).

For testing external devices such as sensors, the shield containing such devices can be stacked on top of (or below) the FPGA shield; in this case, FPGA could act as a simple logic analyser if necessary.

I think this approach should provide the ultimate hardware CI testing automation everyone dreams of.

oh okay, that with the logic analyzer was not meant for CI. But yes that with FPGA and LA is great, then it should also have a warp drive and replicator, a CI shield that makes tea :tea:...

[stephanosio]

oh okay, that with the logic analyzer was not meant for CI. But yes that with FPGA and LA is great, then it should also have a warp drive and replicator, a CI shield that makes tea 🍵...

well, using FPGA itself as a logic analyser is not really that far-fetched, especially when there are things like openVeriFLA around: https://opencores.org/projects/openverifla

And yes, you can emulate all sorts of peripherals with FPGA as necessary too: https://opencores.org/projects?expanded=Communication%20controller

p.s. Using Intel-Altera IP cores (SignalTap II, NIOS II, all the Avalon peripherals) could actually further reduce the amount of effort required to get this working, but there is likely to be multiple licensing issues ...

[microbuilder]

In terms of features, I think it would be useful to include the following part in the design in addition to the I2C EEPROM.

• 2.048V (or some similarly convenient) precision voltage reference. I've used this one, but it's just a suggestion: https://www.digikey.com/product-detail/en/texas-instruments/LM4040AIM3-2.0-NOPB/LM4040AIM3-2.0-NOPBCT-ND/2350610

Also, it would be good to include a chip that uses I2C clock stretching just to be able to test if a driver or peripheral supports this feature or not. It's a problem I've run into in the past, and it isn't always clear if chips play well with I2C clock stretching or not so being able to test for this may be useful. One device I'm aware of that does use clock stretching is the BNO055.

[jfischer-no]

@microbuilder I had two (1.024V and 2.048V) voltage references in the schematic, but then removed it because I had in mind that the shield is more about functionality testing, the precision of the voltage is not very important and could also be done with the resistors connected to the A0..A5 pins. About I2C, anything that just needs SDA and SCL can be topped up as the CI shield should be stackable. btw, BNO055 is not a cheap one :-)

[microbuilder]

@jfischer-phytec-iot Fair enough, and being stackable we can design a sensor shield, etc. Also ... I apparently clicked the wrong button commenting since I see I close the issue 🤦‍♂️😂 Thanks for reopening.

I have some footprints for the Adafruit Feather connector in Eagle, though it looks like you're using another CAD tool. It's a good footprint choice to include, though, since it isn't massive but it's relatively easy to source breakouts using that pinout.

An alternative to consider is the Click mikrobus interface which is even smaller and has a very large family of breakouts readily available through the major distributors, and more and more boards from the silicon vendors seem to be using this lately: https://www.mikroe.com/mikrobus ... that seems like a viable option as well?

[jfischer-no]

I think we can close it, see also https://github.com/zephyrproject-rtos/zephyr/issues/68400