 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : I2C issue narrow down
| Author | Message | ||||
| viscomjim Guru  Joined: 08/01/2014 Location: United StatesPosts: 925 |
Playing with I2C and am encountering a problem that is very repeatable. I have 2 uMites set up, one as master and one as slave. Both units are up and running with the attached code, using 2 instances of MMedit. I control C the slave and hit run again. No matter what the first byte the master sends (I'm just sending one byte), the slave always has a 2 received. After that, the slave reads the master properly. I never stop the master running the program, just the slave and always get a 2 the first time. If I cycle power on the slave, then it receives the correct byte from the master every time. I am not sure if I added the code correctly in this post... Code running on Master: DO INPUT "ENTER COMMAND ";CMD SENDCMD CMD RCVCMD LOOP SUB SENDCMD CMD I2C OPEN 100, 1000 I2C WRITE &H26, 0, 1, CMD IF MM.I2C THEN ERROR "Slave did not respond" I2C CLOSE END SUB SUB RCVCMD I2C OPEN 100, 1000 I2C READ &H26, 0, 1, RCVBCK PRINT "RECEIVED BACK =";RCVBCK IF MM.I2C THEN ERROR "Slave did not respond" I2C CLOSE END SUB Code running on Slave: OPTION AUTORUN ON I2C SLAVE OPEN &H26, 0, 0, WriteD, ReadD DO WATCHDOG 1000 LOOP ReadD: I2C SLAVE READ 1, CMD, RCVD PRINT "COMMAND =";CMD;" RECEIVED =";RCVD IRETURN WriteD: SNDBCK = CMD + 1 I2C SLAVE WRITE 1, SNDBCK IRETURN |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
WARNING - this is MY interpretation of the problem. When the SLAVE starts from a cold start, the I2C buffer pointers are equal and pointing to the start of the buffer. If the slave device interrupts the receiving routine, when the routine restarts, one of the pointers is reset but not both. This causes the apparent extra data. The solution when you only want one byte is to be prepared to receive more data than you expect and only use the last byte. I will try to produce a working example later today. Jim VK7JH MMedit MMBasic Help |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Jim, Did you ever find a way to clear the buffer after the receive was complete? |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
I am at work now and cannot test this, but, do you think the "clear" command would work for this situation? |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
It looks like "clear" does not make a difference with I2C. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
JIm, we will have to wait for a fix to the I2C commands. For now, try the following code for the slave: option autorun on
dim cmdline(256) I2C SLAVE OPEN &H26, 0, 0, WriteD, ReadD DO WATCHDOG 1000 LOOP ReadD: I2C SLAVE READ 255, CMDline(0), RCVD CMD=cmdline(RCVD-1) PRINT "COMMAND =";CMD;" RECEIVED =";RCVD IRETURN WriteD: SNDBCK = CMD + 1 I2C SLAVE WRITE 1, SNDBCK IRETURN Jim VK7JH MMedit MMBasic Help |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Jim, That is a very clever way to do that. I will load this and report back. I really appreciate you looking at this. EDIT: First of all, THAT WORKED!!!! - I ran this several times and here are the results... Upon power up of the slave, cmd byte comes in properly as before with rcvd being 1. With control C and run, cmd byte comes in properly with random number for rvcd for first use, then rvcd is 1 for any after the first received. After more control C and run, whatever the random number for rvcd was, it increments by 1 each time. So bottom line is, the cmd is correct everytime. Thanks for your help, hopefully there will be a fix soon, but this will work splendidly for now. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
Good news. Jim VK7JH MMedit MMBasic Help |
||||
 Print this page |
