[En-Nut-Discussion] TWI and Lua problem

Andre Riesberg andre at riesberg-net.de
Mon Apr 11 19:13:12 CEST 2011


uprinz schrieb:
> Andre Riesberg wrote:
>   
>> Bernd Walter schrieb:
>>     
>>> On Sun, Apr 10, 2011 at 11:20:49PM +0200, Ulrich Prinz wrote:
>>>       
>> Hi all,
>>
>> the TwMasterRegWrite and TwMasterRegRead are the better functions.
>> TwMasterRegWrite can send up to 5 bytes, one address, up to three more 
>> address (or data) bytes and another data byte. This is done without any 
>> "byte sending" interrupt.
>> The function TwMasterTransact works reliable for only one data byte.
>> If we want to send more then 5 bytes, we have to write our own function 
>> without interrupts.
>> The automatic stop bit very bad.
>>
>> But I hope there is a solution for this issue!
>>
>> Greetings
>> André
>>
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>
>>     
> André...
>
> Just add the writing of the first byte to the TWDR register in the code. 
> at91_twi.c is your friend around line 370 if I remember corretly.
>
>         /* Set TWI Internal Address Register */
>         outr(TWI_IADRR, iadr);
>         /* Set the TWI Master Mode Register */
>         outr(TWI_MMR, ((unsigned int) sla << TWI_DADR_LSB) | (((unsigned
> int) iadrlen & 3) << 8));
>         outb(TWI_THR, tw_mm_buf[0]);
>         outr(TWI_IER, TWI_TXRDY);
>
> My version of this code seems to directly set the first byte into TWI_THR
> before enabling the interrupts.
> But as you said, the code seems to work for up to five bytes. Let me guess:
> You write 1 byte chip address, 2 bytes in-chip address and 2 byte of data,
> where after the first data it again fails.
>   
I write chip address, one byte in chip address and one data byte (it is 
a 18 channel LED driver). But I think it will work for up to 5 bytes ;-)
> What I wonder about is, that the interrupt is coming so late that we cannot
> even put a single byte into the THR register early enough. So either
> interrupt-handling or buffer management is so slow, that it interrupts the
> I2C communication.
>   
I am away from my office until Friday, but at the weekend I will check 
the timing.
The interrupt will fired at the ack bit, so there is less time to load 
the next data byte.
> Ok, in the stm implementation I think I use real buffer pointers, while in
> the AT91 code there are indexes used. I need to check what assembler code
> differences result of using buffer[i] instead of *bufptr++;
>   
I think this make not a so big difference.
> On the other hand, this is one of the shortest I2C interrupt handler I ever
> wrote :)
>
> Ulrich
>
> -----
> Best regards
> Ulrich
>   
Grettings
André


More information about the En-Nut-Discussion mailing list