Jump to content


New Member
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by burkart

  1. Success!!! So the code no longer gets hung up on a NACK. Woot! Now I'm gonna try to figure out how to have the code retry a set number of times before it gives up and moves on.
  2. I'm using a PICKit 4 for programming and debugging. I am using 2k ohm pull-ups. The transitions look nice and crisp, no ramp-ups when the bus is released. For debugging I have the I2C speed set to 100kHz, but everything still works at 1MHz. As you can see in the image below, the slave is sending ACK when everything is peachy. So the question now is how is the code reacting to a NACK. What I've noticed is, after the first byte is transmitted and there is nothing there to respond back to the master, the master then sends the next byte, and all subsequent bytes endlessly, interestingly the value of these bytes is the value of the first byte, plus one, as if the master is requesting a read operation. I'll debug and see if I can further understand the behavior and operation of the I2C driver, specifically what it's doing to monitor ACK and NACK.
  3. So I made the code changes. When there is nothing on the I2C bus, the driver still goes into an endless loop. When I debug I notice that it never gets to time out, or rather the variable "to" never gets to count down from 50000. I am guessing PIR3bits.SSP1IF interrupt flag gets set and it breaks out of the mssp1_waitForEvent function. But if there is nothing on the bus why is this flag setting? Is this the correct interrupt to be monitoring? I don't know enough to know if I'm asking the right questions, but I am thinking that if the Master device on the I2C bus sends out an address and does not receive an ACK from the slave, shouldn't a time-out routine be looking for that slave's acknowledgement? Do I have that right?
  4. So this is where my limited grasp of C stops me. Using that last bit of code you posted, I see what you are doing, but I get an error upon compiling. mcc_generated_files/i2c1_driver.c:100:1: error: (192) undefined identifier "i2c_status" mcc_generated_files/i2c1_driver.c:100:18: error: (196) struct/union required mcc_generated_files/i2c1_driver.c:100:20: error: (192) undefined identifier "I2C_ADDRESS_NACK" I'm gonna crack my C textbook open and see if I can't figure this out.
  5. Hello All, I am working on a project (in MPLAB v5.10) with a PIC18F27K40 (PIC18 library v1.77.0) and I'm using the MCC (v3.85.1) generated I2C drivers, I2CSIMPLE from the Foundation Services. I can read from and write successfully to devices on the I2C bus. The problem comes when I try to communicate with a device that's not on the bus, the micro goes into an endless loop waiting for i2c_status to not be busy. My knowledge of programming in C is about 6 on a scale of 10, and for programming for embedded purposes, about 5 out of 10. I would like to have it so that I can check if a specific device is present on the I2C bus, and also be able to recover from errors on the bus without it going into a loop indefinitely. This I2C driver is pretty complex, and I am having difficulties wrapping my head around it. How would I make it so that the driver just returns an error or something I can check for status, rather than loop endlessly until the operation completes, which it never will? I have not edited any of the MCC generated code. This includes leaving the IRQ enable line commented in the i2c_master.c file, so instead it polls instead of using an interrupt to check if the i2c operation has completed. // uncomment the IRQ enable for an interrupt driven driver. // mssp1_enableIRQ(); Following is an example of how I am calling the i2c driver. i2c_write1ByteRegister(address, 0x0D, 0x07); // GPPUB pull-ups on pins 0-2 I am attempting to initialize a port extender, MCP23018, specifically enabling some pull-up resistors. I would like to issue this command, and if the extender is not present, then the micro will perform some tasks differently. With the port extender present the write operation works as expected and everything is fine. Of course the problem is when the extender is NOT on the bus to acknowledge. I have another question as well. This driver seems to operate a little slow. When watching the bus with a logic analyzer I noticed a rather long pause between bytes. I went looking through the i2c driver and in i2c1_driver.c I found the following code which I suspect is the cause. inline void mssp1_waitForEvent(uint16_t *timeout) { // uint16_t to = (timeout!=NULL)?*timeout:100; // to <<= 8; if(PIR3bits.SSP1IF == 0) { while(1)// to--) { if(PIR3bits.SSP1IF) break; __delay_us(100); } } } What is the purpose of the 100 us delay in the while loop? Reducing or eliminating the delay results in reducing or removing the pause between byte transactions, but I don't know enough to know how else this edit will effect the driver. Also, what is the commented out code at the top of the function used for? Is this part of the infinite loop problem I mentioned above? -- James Burkart
  • Create New...