-
Notifications
You must be signed in to change notification settings - Fork 572
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding GHI Fez Cream driver #379
Comments
Here’s a couple of thoughts...
|
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. |
@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. |
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) 😄 |
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:
and the result is this: Now i am searching for a way to translate this information of the addresses so i can use the |
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 Does that make sense? |
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. |
[Triage] We're not tracking device bindings or driver requests, please create a PR. If there is anything to discuss please reopen |
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
The text was updated successfully, but these errors were encountered: