Adding GHI Fez Cream driver

[w-eling]

Hello all,

I have a question about a product that was created some years ago to connect Microsoft Gadgeteer sensors to the Raspberry Pi via a special hat, that was called the GHI Fez Cream.

GHI the company that produced the hardware component also wrote the driver library that was written for Windows iot 10. This code uses the Windows.Devices namespace to control the hardware.

FEZ_Cream_SCHEMA.pdf

I have added the hardware schema as you can see it uses the following hardware components:
ADS7830IPWT
PCA9685
PCA9535

The original code can be found here

https://github.com/ghi-electronics/Windows-IoT

The question i have is quite simple. Is it possible to rewrite the driver code to the new dotnet iot library. So i can use this hardware on a Raspberry Pi and dotnet core. I do not have a lot of hardware experience but i am able to write c# code. Are there maybe any hardware incompatibilities you guys no about ? Or should this be doable

[shaggygi]

Here’s a couple of thoughts...

1. It appears the Fez hardware is obsolete, but didn’t verify. Would it be worth working on a binding if so? However, it would be a good exercise to become familiar how to.

2. It might be good to create separate device binding projects (if not already available) for components you listed. Then create a new binding project for the Fez hardware and reference the components in that project.

[w-eling]

Here’s a couple of thoughts...

1. It appears the Fez hardware is obsolete, but didn’t verify. Would it be worth working on a binding if so? However, it would be a good exercise to become familiar how to.
2. It might be good to create separate device binding projects (if not already available) for components you listed. Then create a new binding project for the Fez hardware and reference the components in that project.

Thank you for the reply. You are correct this hardware is not in production anymore and is not available for purchase. But since i have a lot of sensors for this device. And i am not a big fan of Windows iot 10 as an os for my Raspberry Pi it seemed like a great project to learn and maybe somebody else is waiting for a binding for the Fez Cream

I will try to create device bindings for the seperate hardware components. As a start off point for the complete product.

[shaggygi]

@wwombatt sounds good. I would also suggest adding a Sensor folder under the Fez project to store the classes for each of the Fez sensors that can be attached. That will make it easier for others to pick/add what they want to connect to main board in their own projects using this Fez binding.

Thanks for the interest using this repo and good luck.

[joperezr]

Is it possible to rewrite the driver code to the new dotnet iot library. So i can use this hardware on a Raspberry Pi and dotnet core. I do not have a lot of hardware experience but i am able to write c# code. Are there maybe any hardware incompatibilities you guys no about ? Or should this be doable

Just to answer those specific questions, yes it should be possible. In fact, our API Surface is very similar to Windows.Devices.* API, so you shouldn't have many problems porting that library over to our repo. Even if the devices are not being sold anymore, we also have a few bindings on this repo for some legacy devices that are still popular with hobbyist community. As @shaggygi mentioned, thanks for the interest and we will gladly review your PR(s) 😄

[w-eling]

I am starting to do some research and maybe i am asking a realy dumb question but here goes:

I have added the Fez Cream on top of the Raspberry Pi and I have run this command:

i2cdetect -y 1

and the result is this:

Now i am searching for a way to translate this information of the addresses

so i can use the I2cConnectionSettings object can somebody tell me how this works ?

[joperezr]

What this is telling you (assuming that the only device you have connected through I2C is the Fez Cream) is that the device is actually a collection of devices (4 in total) talking to the raspberry all through I2C channel. This is not uncommon, for example, the SenseHat behaves very similar. Before you think about I2cConnectionSettings, I would try to find the docs or datasheets for the Fez Cream that will have more info on which sensor represents each of those addresses.

That said, in order to answer your question, in this particular case, you could use public I2cConnectionSettings(int busId, int deviceAddress) constructor where busId is 1 (since you typed i2cdetect -y 1 where 1 is the bus id) and deviceAddress would be any of the above (0x23, 0x25, 0x48, and 0x70) where each different address is a different sensor on the Fez Cream

Does that make sense?

[shaggygi]

Based on the schematic link above, here are the addresses for each device. The schematic shows the binary value below each.

PCA9535 (IC1): 0x23

PCA9535 (IC2): 0x25

ADS7830IPWT: 0x48

PCA9685: 0x70 Note: All hardware address lines are tied HIGH, so you'd think it would be 0x7F. However, I noticed the datasheet mentioned you can use 0x70 address when interacting with all LED channels at once. So this is probably why it responded with 0x70. I believe i2c-detect command stops scanning at 0x77 as higher addresses are reserved by protocol (or some reason I can't remember 😕). I also came across another thread with similar question. You might want to try 0x7E, as well. Lastly, it appears we already have a binding created for this, so you might want to review and reference it within the Fez Binding.

[krwq]

[Triage] We're not tracking device bindings or driver requests, please create a PR. If there is anything to discuss please reopen