While I2C is so common interface, yet every time we need to talk to some new I2C gadget, we have to spend some time to get something working. There are USB I2C dongles available that can do generic I2C transactions, but well none on my desk. So when I received this multisensor module, CR00040:

I instantly had a problem with how to test the sensors? What about making my own USB-I2C gadget? I decided to utilize an existing project that provided I2C access over UHSA protocol, the FPGA and NIOS softcore CPU code for this was there, it was developed for another sensor evaluation platform. So to adapt it I only had to change two PIN locations in Quartus. The most work was to trace the SCL, and SDA from the sensor module via PMOD-to-CRUVI adapter back to the MAX10 pins on the MAX1000 FPGA board. Well in any case the "fix" was done within less than 15 minutes. Does it work also? UHSA is ASCII based protocol so it is possible to "talk" using a keyboard and regular UART terminal. Unfortunately, there is little documentation on the UHSA so I had to look into some python code and the NIOS C sources also.

There are four I2C devices on CR00040, so trying them out one by one:

sending: <a6kfak<a7k..m..m..m..m..m..M>

response: 000801f12f7e632

from the response the three 0's are 3 ACK's from the I2C EEPROM, then come 6 bytes of EUI-48 Identifier code from address offset 0xFA. Yes, the EEPROM 24AA025E48 from Microchip is responding, so at least our I2C bus works!

sending: <bak0fk<bbk..M>

response: 000b1

now we see also 3 ACK's followed with WHOAMI response from the LPS22HB pressure sensor from ST.

sending: <72k91k<73k..m..M>

response: 00061e4

this is the correct response of DevID and REVision bytes from Ambient Light Sensor TSL25403M from AMS.

sending: <c4k36k82k<c5k..m..m..m..m..m..m..m..m..M>
response: 0000f5e7b89f07c23bf19a

and YES the CO2 sensor SCD40 from Sensiron is also responding with its unique serial number.

This is pretty good, time spent 15 minutes creating a generic USB I2C dongle for the CRUVI platform, and then well I spent a little more than an hour creating the UHSA strings to talk to the devices.

This is how the setup looks like on my desk:

I am using MAX1000 as a generic USB to PMOD adapter, then there is PMOD to CRUVI adapter (CR00025: pure passive, only connectors) and finally the CRUVI sensor module CR00040. Please note that there is SCD30 mounted on the MAX1000, it is not used in this setup.

The full source code of the Quartus project and the NIOS embedded code is open source, so if you have any Intel FPGA board that has a USB UART connection you can easily make your own USB I2C dongle and start working with any I2C devices from any application that can work with UART on the host PC. The NIOS subsystem includes only UART and GPIO, I2C is implemented as bit-bang to the GPIO. While in this example only I2C is supported, the same code can be adapted to support multiple interfaces over the same protocol, so you can talk to multiply I2C buses, or SPI, etc.

First CR00040 samples have been shipped to beta customers. CR00040 is compatible with CRUVI LS format so you can mount it directly on CRUVI motherboards like the VHDPlus Core MAX10.

With a PMOD adapter you can use it as if it would be a PMOD this adds more use cases. Also, CR00040 provides additional pin header holes to solder in pin headers, in that case, you can use fly cable, or insert the CR00040 into a solderless breadboard.

CR00040 will be soon available from Trenz Electronic and Arrow.