* ack/nack in write operation
@ 2011-07-14 15:52 Michele Da Rold
[not found] ` <4E1F10B9.3080507-jTUIOkKm3KASWr57yraSmw@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Michele Da Rold @ 2011-07-14 15:52 UTC (permalink / raw)
To: linux-i2c-u79uwXL29TY76Z2rM5mHXA
Hello everybody,
I'm new to i2c development some don't kill me if my questions are stupid!!
I'm using bitbanging i2c driver for an AT91 devices,
the AT91 is master and I have a slave that reply, during a write, with a
NAK after last byte.
The i2c specification permit this solution but i2c linux driver no.
(i have see the possibility to set the I2C_M_IGNORE_NAK but ignore all
NAK and isn't right!)
There is a solution or I have to modify the code?
Thank you
Michele
^ permalink raw reply [flat|nested] 4+ messages in thread[parent not found: <4E1F10B9.3080507-jTUIOkKm3KASWr57yraSmw@public.gmane.org>]
* Re: ack/nack in write operation [not found] ` <4E1F10B9.3080507-jTUIOkKm3KASWr57yraSmw@public.gmane.org> @ 2011-07-14 16:26 ` Jean Delvare [not found] ` <20110714182607.3a3d710f-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org> 0 siblings, 1 reply; 4+ messages in thread From: Jean Delvare @ 2011-07-14 16:26 UTC (permalink / raw) To: Michele Da Rold; +Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA On Thu, 14 Jul 2011 17:52:25 +0200, Michele Da Rold wrote: > Hello everybody, > I'm new to i2c development some don't kill me if my questions are stupid!! > > I'm using bitbanging i2c driver for an AT91 devices, > the AT91 is master and I have a slave that reply, during a write, with a > NAK after last byte. > The i2c specification permit this solution but i2c linux driver no. Can you please quote the part of the I2C specification which you think says this? I read it differently (page 10 of I2C 2.1 specification, section 7.2: Acknowledge): "Usually, a receiver which has been addressed is obliged to generate an acknowledge after each byte has been received, except when the message starts with a CBUS address." "If a master-receiver is involved in a transfer, it must signal the end of data to the slave-transmitter by not generating an acknowledge on the last byte that was clocked out of the slave. The slave-transmitter must release the data line to allow the master to generate a STOP or repeated START condition." So, a master-receiver must nack the last byte, but a slave-receiver must not. So your slave device is misbehaving - or you are actually trying to write more bytes to it than it can handle. > (i have see the possibility to set the I2C_M_IGNORE_NAK but ignore all > NAK and isn't right!) This should indeed be avoided unless you really have to use it. > There is a solution or I have to modify the code? First ensure that you are sending the right number of bytes to the device, with the correct sequence. If you think you're really doing the right think, get in touch with the vendor of the slave device and ask them why their device misbehaves. -- Jean Delvare ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <20110714182607.3a3d710f-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>]
* Re: ack/nack in write operation [not found] ` <20110714182607.3a3d710f-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org> @ 2011-07-15 8:03 ` Michele Da Rold [not found] ` <4E1FF460.1000908-jTUIOkKm3KASWr57yraSmw@public.gmane.org> 0 siblings, 1 reply; 4+ messages in thread From: Michele Da Rold @ 2011-07-15 8:03 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA Il 14/07/2011 18:26, Jean Delvare ha scritto: > On Thu, 14 Jul 2011 17:52:25 +0200, Michele Da Rold wrote: >> Hello everybody, >> I'm new to i2c development some don't kill me if my questions are stupid!! >> >> I'm using bitbanging i2c driver for an AT91 devices, >> the AT91 is master and I have a slave that reply, during a write, with a >> NAK after last byte. >> The i2c specification permit this solution but i2c linux driver no. > > Can you please quote the part of the I2C specification which you think > says this? I read it differently (page 10 of I2C 2.1 specification, > section 7.2: Acknowledge): > > "Usually, a receiver which has been addressed is obliged to > generate an acknowledge after each byte has been > received, except when the message starts with a CBUS > address." > > "If a master-receiver is involved in a transfer, it must signal > the end of data to the slave-transmitter by not generating > an acknowledge on the last byte that was clocked out of > the slave. The slave-transmitter must release the data line > to allow the master to generate a STOP or repeated > START condition." > > So, a master-receiver must nack the last byte, but a slave-receiver must > not. So your slave device is misbehaving - or you are actually trying > to write more bytes to it than it can handle. > Refer to fig.11 of specification 2.1. But I think that I was wrong. I agree with your opinion. >> (i have see the possibility to set the I2C_M_IGNORE_NAK but ignore all >> NAK and isn't right!) > > This should indeed be avoided unless you really have to use it. > >> There is a solution or I have to modify the code? > > First ensure that you are sending the right number of bytes to the > device, with the correct sequence. If you think you're really doing the > right think, get in touch with the vendor of the slave device and ask > them why their device misbehaves. > I'm in touch with vendor, I'm waiting for his reply. Thank you Michele ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <4E1FF460.1000908-jTUIOkKm3KASWr57yraSmw@public.gmane.org>]
* Re: ack/nack in write operation [not found] ` <4E1FF460.1000908-jTUIOkKm3KASWr57yraSmw@public.gmane.org> @ 2011-07-15 9:13 ` Michele Da Rold 0 siblings, 0 replies; 4+ messages in thread From: Michele Da Rold @ 2011-07-15 9:13 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA Vendor resolve the problem. Thank you for your help Michele Il 15/07/2011 10:03, Michele Da Rold ha scritto: > Il 14/07/2011 18:26, Jean Delvare ha scritto: >> On Thu, 14 Jul 2011 17:52:25 +0200, Michele Da Rold wrote: >>> Hello everybody, >>> I'm new to i2c development some don't kill me if my questions are >>> stupid!! >>> >>> I'm using bitbanging i2c driver for an AT91 devices, >>> the AT91 is master and I have a slave that reply, during a write, with a >>> NAK after last byte. >>> The i2c specification permit this solution but i2c linux driver no. >> >> Can you please quote the part of the I2C specification which you think >> says this? I read it differently (page 10 of I2C 2.1 specification, >> section 7.2: Acknowledge): >> >> "Usually, a receiver which has been addressed is obliged to >> generate an acknowledge after each byte has been >> received, except when the message starts with a CBUS >> address." >> >> "If a master-receiver is involved in a transfer, it must signal >> the end of data to the slave-transmitter by not generating >> an acknowledge on the last byte that was clocked out of >> the slave. The slave-transmitter must release the data line >> to allow the master to generate a STOP or repeated >> START condition." >> >> So, a master-receiver must nack the last byte, but a slave-receiver must >> not. So your slave device is misbehaving - or you are actually trying >> to write more bytes to it than it can handle. >> > > Refer to fig.11 of specification 2.1. > But I think that I was wrong. I agree with your opinion. > >>> (i have see the possibility to set the I2C_M_IGNORE_NAK but ignore all >>> NAK and isn't right!) >> >> This should indeed be avoided unless you really have to use it. >> >>> There is a solution or I have to modify the code? >> >> First ensure that you are sending the right number of bytes to the >> device, with the correct sequence. If you think you're really doing the >> right think, get in touch with the vendor of the slave device and ask >> them why their device misbehaves. >> > > I'm in touch with vendor, I'm waiting for his reply. > > Thank you > Michele > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Michele Da Rold ECS s.r.l. via del Candel - 55/D - 32100 Belluno (Italy) Tel. +39 0437 33101 Diretto +39 0437 359635 Fax +39 0437 359631 michele.darold[at]ecsproject[dot]com - http://www.ecsproject.com P please don't print this e-mail unless you really need to. Avviso di riservatezza Le informazioni contenute in questo messaggio di posta elettronica e/o nei file allegati, sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Vi ricordiamo che costituisce comportamento contrario ai principi dettati dal Dlgs. 196/2003 il trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-07-15 9:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-14 15:52 ack/nack in write operation Michele Da Rold
[not found] ` <4E1F10B9.3080507-jTUIOkKm3KASWr57yraSmw@public.gmane.org>
2011-07-14 16:26 ` Jean Delvare
[not found] ` <20110714182607.3a3d710f-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2011-07-15 8:03 ` Michele Da Rold
[not found] ` <4E1FF460.1000908-jTUIOkKm3KASWr57yraSmw@public.gmane.org>
2011-07-15 9:13 ` Michele Da Rold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox