From: Michele Da Rold <michele.darold-jTUIOkKm3KASWr57yraSmw@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: ack/nack in write operation
Date: Fri, 15 Jul 2011 10:03:44 +0200 [thread overview]
Message-ID: <4E1FF460.1000908@ecsproject.com> (raw)
In-Reply-To: <20110714182607.3a3d710f-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
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
next prev parent reply other threads:[~2011-07-15 8:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
[not found] ` <4E1FF460.1000908-jTUIOkKm3KASWr57yraSmw@public.gmane.org>
2011-07-15 9:13 ` Michele Da Rold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E1FF460.1000908@ecsproject.com \
--to=michele.darold-jtuiokkm3kaswr57yrasmw@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.