As already mentioned in this question Reading and writing with smbus package, there are chips that apart for standard SDA and SCL lines use a third communication line. This means that this “modified” I2C communication cannot be made using standard kernel and smbus
library, which advantage is that communication is very orderly (perfect SCL pulses).
I already managed to bitbang communication using RPi.GPIO
library. The communication works, but it is uneven and each clock pulse has different length, since RPi.GPIO
library (and probably Python
itself) is just too slow.
Now I want to write my own library for the communication with the chip. In order for library to work properly, I have to solve two problems:
- Would it be appropriate to use standard I2C Raspberry Pi pins (8, 9) and one arbitrary pin for that? Maybe this is not good idea because it might create a conflict with kernel and
smbus
library? What do you think? - How should I write this communication to be as orderly as possible – should I write special
C
routines within myPython
program and what commands should I use to access the pins?
I would prefer solutions that don’t use other communication libraries (e.g. RPi.GPIO
, pigpio
)
-
Pins 8 and 9 have nothing to do with I2C. Are you using a Pi? – joan 3 hours ago
-
Let us first agree on Rpi4B pinout: imgur.com/gallery/2bwBacj. – tlfong01 2 hours ago
-
Let us also agree on the version of the datasheet MCP4728 Quad 12-Bit DAC EEPROM Datasheet – DS22187E 2010 Microchip ww1.microchip.com/downloads/en/devicedoc/22187e.pdf. – tlfong01 2 hours ago
-
Your proposal is a bit confusing. Let us focus on the LDAC pin how your extra line/signal can deal with it:(1) penzu.com/p/a42cfe42. I need to read the datasheet one more time and ask you some questions for clarification, perhaps tomorrow. – tlfong01 1 hour ago
-
(1) On second thought, I think I better as soon as possible give my comments on the OP’s proposal of using 3 lines as a new version of I2C, because I don’t wish to mislead others to think that we should discuss this proposal further. I would suggest to move this question to the EE stackExchange, and let the EE guys give their opinions. (2) I am interested in this DAC + EEPROM chip because I have been using this type of chips for my Micky Mouse projects on PID servo control and digitized volume control of audio power amplifiers. / to continue, … – tlfong01 9 mins ago
-
MCP4728 as the datasheet says, is very useful for these applications of mine. (2) But I STRONGLY DISAGREE and think that the OP’s suggestion of a 3 line I2Cis AMATEURISH. I read the LDAC signal description again and I don’t think anything wrong to use Rpi GPIO to control the LDAC input. If we don’t want to use one more signal line for GPIO/LDAC, an alternative is to use a I2C interfaced MCP23017 GPIO. – tlfong01 1 min ago Edit
-
I think both ways and perhaps many other similar ways are clean. Designing a 3 wire I2C is a very very overkill, not to mention of wasting a huge amount of time. I don’t wish to discourage the OP, but I do think his thinking a bit weird. – tlfong01 1 min ago Edit
Categories: Uncategorized