Go Down

Topic: I2C TinyWireS: send a "NACK" (Read 129 times) previous topic - next topic

obucklin

Hi

I've got a raspberry pi looping through 12 AtTiny's to request data from each. The tiny's don't always have new Data, and I was wondering if there was a good way to deny that request, so the Pi can move on to the next sensor without attempting to read the whole 7 empty bytes. I was considering just doing TinyWireS.stop() for long enough for the pi to time out and move on, but I'm not sure that would be faster...

Anyboody have any great ideas? It would be appreciated! Thanks

pylon

Quote
Anyboody have any great ideas?
I don't know if that's a great idea but what about transferring the status in the first byte? So the Raspi can ask for the first byte and (theoretically) continue to read the rest if the status says that there is new data. Theoretically because the software on the Raspi doesn't support this process but you have to start a new request to ask for the complete 8 bytes again. It might get tricky to check for the stop condition in the slave though.


The TinyWireS I know (you keep the link to your library secret) doesn't support a stop() method. And even if it does the only way to react is by stretching the clock which definitely won't make your process faster. And if you do that until the Raspi times out, how do you know about that? You might block the bus too long resulting in many errors. It's almost never a good idea to abuse the tools offered by a standard, even if you actually would gain a bit performance. Sooner or later this will hit back.

obucklin

I think what I might do is a basic request(address+read bit) from the Pi which gets a data-ready status as a byte from the tiny using onRequest(). If that confirms that data is ready, then the pi would send the read command and read the data block. That would be 2 bytes for the former as opposed to 10 bytes for the latter.

pylon

Quote
That would be 2 bytes for the former as opposed to 10 bytes for the latter.
My result is 9 bytes for the latter (1 address byte, 1 status byte and 7 data bytes). Where is your additional byte from?

obucklin

1 address write byte, 1 status/register/command byte, 1 address read byte, 7 data bytes

pylon

Ok, shame on me, please accept my excuses.

Go Up