I am doing i2c code with multiple slaves but one of slaves which is vcsel laser driver only contain 11 bit, 3 for address and eight memory I have no idea how to communicate and tell it to emit laser. I am trying to use memory address 001b.
I am doing i2c code with multiple slaves but one of slaves which is vcsel laser driver only contain 11 bit, 3 for address and eight memory I have no idea how to communicate and tell it to emit laser. I am trying to use memory address 001b.
You'll have to write the code in C to change the GPIO configuration to Open Drain w/Pull-Up if you don't have external ones.
You'll then need to sequence writes to the SCL/SDA pins to emulate the data/clocking expectations in the data sheet.
Might this conflict with the other I2C devices? Perhaps, I don't know these are my parts. You'll have to experiment.
Would it be simpler to switch back and forth between I2C and bitbanged mode? Again this is a call you'll have to make, clearly bitbang mode would be more involved, but you could code it to recognize which device you're addressing, and change the address and data widths to match expectations of each device on the bus. Then you'll need to determine if they play well or not. Data sheet's probably not going to tell you either way. You'd see if they NACK as usual to their own addresses, and that affirms they are decoding their own address properly.
Will software drop out of a Google search? There's probably some examples of bit bang I2C, the VCSEL perhaps? The concept of driving the pins in a more direct fashion is not a new one. Should be some close cousins you can adapt.
Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
You must make sure there is no slave address conflict possible on the same bus, or split into 2 buses otherwise. Bitbang I2C exist for more than 20 years. Just make sure your transaction is short -say 10 msec or less- if bare metal. Bit bang means speed it up to hang time as litlle as possible.
It is pretty easy to make 400 kbps bus with 48MHz core. Just be careful how you implement half bus clock period delay. Think compiler brand and compiler optimisation decorrelation for a rugged code that is debug time free.... invest a bit more time to think before coding yields big time saving afterwards. Thinking issues ahead is faster than debugging them later.
