|
|
View previous topic :: View next topic |
Author |
Message |
Backfire
Joined: 12 Oct 2020 Posts: 46
|
I2C Poll Function |
Posted: Wed Sep 15, 2021 2:37 am |
|
|
Morning (from where I sit) everyone,
I've a quick question I was looking for some background information on.
I'm running a PIC18F25K20 which is attempting to talk to a PIC16F1512 over I2C. I *have* got them passing some bytes, but I'm hoping someone can review my logic, in order to improve the reliability of the comms, which are a little sporadic in their current operation.
My sending code is;
Code: |
Buffer[0] = 0b10000000 + ID;
//fprintf(SERIAL, "Buffer: %X\r", Buffer[0]);
while(!I2CDeviceReady(0x20));
I2CACK = i2c_transfer_out(0x20, Buffer, 1);
|
And my receiving code is;
Code: |
if(i2c_poll())
{
output_high(LED);
index = 0;
{
buffer[index] = i2c_read();
index++;
}while(i2c_poll());
fprintf(CONFIG, "Buffer:%s\r", buffer);
}
|
This triggers the printf statement in the reception code twice, while I would've only expected it to trigger once, with all the bytes collected from the iterative i2c_read() calls?
My implementation is at the limit of device memory, so I'd prefer to avoid the ISR route, as this code only needs to collect a maximum of two bytes over I2C, (after receiving the address, that is).
Hoping someone can see the flaw in my logic! Many thanks in advance. |
|
|
Backfire
Joined: 12 Oct 2020 Posts: 46
|
|
Posted: Wed Sep 15, 2021 3:29 am |
|
|
I also see in a 'Newsdesk' article on CCS's news page that they post an example usage of an i2c function as:
Code: | i2c_transfer_out(EEPROM_STREAM, 0xA0, &rAddress, 1); |
Whereas in the example files there is also an implementation as such:
Code: | i2c_transfer_out(I2C_SLAVE_ADDRESS, buffer, 1); |
I'm curious as to what the difference is here, as I suspect it's where my lack of understanding is causing my issues. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19509
|
|
Posted: Wed Sep 15, 2021 3:49 am |
|
|
Remember a transfer sends the target address, then the data.
So poll will go true, when the address byte is received, and then again for
the data byte. |
|
|
Backfire
Joined: 12 Oct 2020 Posts: 46
|
|
Posted: Wed Sep 15, 2021 3:54 am |
|
|
Hi Ttelmah,
thanks for your reply. I seem to be getting 3 triggers of my printf(...) statement though, when my sending code is as described:
Code: | I2CACK = i2c_transfer_out(0x20, Buffer, 1); |
Whereas I'd expect two executions, based on the address reception, and then the data byte? |
|
|
Backfire
Joined: 12 Oct 2020 Posts: 46
|
|
Posted: Wed Sep 15, 2021 4:00 am |
|
|
After altering my code to dump my intended reception buffer, this is the output upon the I2C being sent the data byte. So the i2c_poll() triggers three times seemingly.
Code: |
Buffer[0]:
Buffer[1]:<NUL>
Buffer[2]:<NUL>
Buffer[3]:<NUL>
Buffer[4]:<NUL>
ID:0
Buffer[0]:
Buffer[1]:<NUL>
Buffer[2]:<NUL>
Buffer[3]:<NUL>
Buffer[4]:<NUL>
ID:0
Buffer[0]:[Warning: "81h 0Dh" is a byte sequence outside the Unicode basic multilingual plane (plane 0)! Only Unicode plane 0 is supported by .NET Framework and thus YAT (yet).]
Buffer[1]:<NUL>
Buffer[2]:<NUL>
Buffer[3]:<NUL>
Buffer[4]:<NUL>
ID:0
|
|
|
|
Backfire
Joined: 12 Oct 2020 Posts: 46
|
|
Posted: Wed Sep 15, 2021 4:38 am |
|
|
Even separating the i2c_read()'s accross multiple functions, I still seem to be 'collecting' the address byte twice. I've now divided my code thusly:
In main() loop:
Code: |
if(i2c_poll())
{
if(i2c_read() == 0x20)
{
output_high(LINK_LED);
BoardCmd = GetI2CCommand();
}
fprintf(CONFIG, "Board:%x\r", BoardCmd);
}
|
Where:
Code: |
int8 GetI2CCommand(void)
{
int8 index = 0;
char buffer[5] = {0};
while(i2c_poll())
{
buffer[index] = i2c_read();
fprintf(CONFIG, "Buffer[%u]:%x\r", index, buffer[index]);
index++;
}
return 0xA1;
}
|
But, my debug dumps are showing the I2C address seemingly being collected again:
Code: |
Buffer[0]:20
Buffer[1]:81
Board:a1
|
Shouldn't the read() in the address-checking function call clear the register for Buffer[0] == 81?
Apologies if I'm missing something simple! |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|