by it just didn't work, i meant the programm wouldn't let me see what i was expecting.
But after working a little on the programm, i realized many things were wrong. One of them was no pull-up resistors. So i'm not sure the problem came from the library, even if i thought so a long time.
I modified my programm since, and it seems to work on the buffer.
Just the "Zs" bug me a little, but after what you said, it is normal and can be considered as "1s", so i guess it's alright.
Thank you for your time,
I have a question that needs to be answered.
If i try to read my eeprom and all i get as an answer are "Zs" on the scope, but considered as "1s" by the 6551, should i consider :
- the eeprom didn'it answer, because the sda line remains at Z state, so wasn't pulled up or down
- the eeprom did answer, and the "Zs" are "1s".
I'm asking this, because I'm stuck with the idea that Z means no information from master to slave, and no information from slave to master : sda line free.
But in your previous message, you seemed to say otherwise... and it confused me.
Thank you for answering,
you told me you made it work, and people around the world were pleased with it. Did anyone work on an eeprom AND a ni pxi 6551?
Anycase, could you give me one of your programms working with this library, with an eeprom if you have.
I'm asking this because i already read all the websites about it, and nothing fits exactly with what i'm trying to do.
It is nice to have someone "who knows" to talk to, but you say you can't debug my programms because it's in french.
And i would really like to see an actual working programm, and not only pieces.
I attached an eeprom programm i made. Can you take a look at it and tell me what you think of it, what you think is wrong...
Thank you for understanding me
Hi Johanna -
Just the "Zs" bug me a little, but after what you said, it is normal and can be considered as "1s", so i guess it's alright...I'm stuck with the idea that Z means no information from master to slave, and no information from slave to master : sda line free. But in your previous message, you seemed to say otherwise... and it confused me.
In an output digital waveform, the line states convey what's happening at the I/O points on the device:
So when you see 'Z' in your waveform, that only means the HSDIO device (your 6551) is not sourcing power onto the bus to pull its voltage high or low. When you use an active-drive buffer with only 'Z's and '0's, it is forced to act like an open-drain output instead. I2C's specification requires that all outputs connected to the bus be open-drain. They must pull the line low ('0') to output a low bit and release the line ('Z') to output a high bit. When the line is released, it gets pulled high by the pullup resistors that are connected to a Vcc rail (or by current drivers, in the case of an HS-mode bus). To conform with this spec requirement, I created the IDW library to generate waveforms that use the 'Z' state for high-level outputs and the '0' state for low-level outputs.
When acquiring a waveform, the states '0' and '1' are used to represent low and high levels seen on the input. No information about the other device's output buffers is known to the 6551, so we can't accurately use 'Z' to represent an incoming high or low state. If Hardware Compare is being used, the 'L', 'H', and 'X' states tell the HWC engine what to expect at the input on each sample.
There are several times in a single I2C interaction where the master device (your 6551) will release the SDA line by tristating its buffers so as to allow the slave device the chance to control the line. All these times are defined by the I2C specification. One of the times is when clocking in a bit that is output from the slave device (one of the data bits or an ACK bit). At this time, the 6551 will set the SDA line to 'Z' so it's not controlling the line's voltage, and the slave device will either leave the line alone as well to indicate a high level, or it will pull the line low to indicate a low level. The acquired waveform will show the line as either a '1' (high) or a '0' (low), depending on what the slave device did with the line during that bit time.
If the slave device is unresponsive, it will never pull the line low, not even to acknowledge (ACK) its address. If the device sends ACK in response to its address and then never pulls the line low during data bytes, it is sending back 00h every time you read from it. As long as it acknowledges every byte by pulling the SDA line low during the ACK bit, the slave device is communicating on the bus properly.
Anycase, could you give me one of your programms working with this library, with an eeprom if you have. I'm asking this because i already read all the websites about it, and nothing fits exactly with what i'm trying to do...And i would really like to see an actual working programm, and not only pieces.
Unfortunately, I can't share anything I've worked on because it's all confidential to my customers. I don't have anything generic to share, beyond the IDW Reference Library and the Serial Protocol Communication Reference Design. I know they don't amount to a complete application; the intent is to provide 50-80% of the work needed, then let engineers customize that code as necessary to finish their own projects more quickly than they would normally. Hopefully someone from the community sees your post and can post something they'd like to share.
Hi pgo -
No, as explained in this thread earlier, you can't use IDW with any device that does not support per-cycle tristate. No DAQ device has this feature as of today.
It is possible to create a single-master, single-slave interconnection using active-driven signals from the master, but you still need pullup resistors on the bus for the slave's open-drain I/O. With this setup, you won't be able to hear what the slave is saying any time the master is driving a '1' onto the SDA line. You can create such a solution by hacking the IDW to drive '1' instead of 'Z': a simple find-and-replace on all IDW VIs should accomplish this. However, since it's a modification of the published code, I won't be able to help you troubleshoot the implementation.
Indeed I need simple one-way master-slave connection to drive I2C bus expander like PCF8574 ...
It will be realy cost reduction in systems I build.
I am trying to make my program run at 400k (I²C library); its default value is 100k. I can't find right timings. I thought I'd divide the 100k timings by 4, and I'd work, but no, tHD DAT is condidered as false, with any value I tried...
Does anyone know something about that? Has anyone succeded changing these timings?
Thanks for answering,
I use IDW with NI-6552. When you change fSCL from 100K to 400K, 3 other parameters should change accordingly: tHigh, tSU,DAT and tHD,DAT. A valid tHigh is <=1250nS (50/50 clock cycle), sum of tSU,DAT and tHD,DAT is <=tHigh. Other parameters can remain the same as in 100K.
Hope that helps.
Sorry if this question has already been asked, I couldn't find a way to search just this topic.
I have a component that wants to talk in a sequence of four bytes:
Address, Command, Data 1 and Data 2
According to the data sheet, between each byte, "SCL held low until data is processed." Is there an easy way to implement this in the IDW library?
- single four byte write with automatic pauses (preferred)
- four writes followed by static pauses (seems bad)
- four pairs of write, read (this polling method seems like a lot of overhead)
So far, I have been able to send the address byte and receive the ACK response. Then I observe about 8 cycles of SCL low.