Search the Community

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

I am trying to do a simple test to measure the output of the DAC using the ADC. The datasheet for the DAC states very clearly that if you have enabled the DAC output pin this will override any pin output functions including the digital output (TRIS) the weak pull-ups and the digital input threshold circuit (so ANSEL behaves like it is set to 1): But MCC is generating a warning saying that my setup is incorrect. Since the output settings are overriden when the pin is a DAC output this warning should not be created when the pin is a DAC output which makes it behave as needed. Besides there should not be any problem measuring an output pin using the ADC when it is an output anyway? I do not understand why the warning is claiming that it "requires" this pin to be set as input. Perhaps it would be better if the warning said "this pin is being driven by the device, if you are trying to measure an external voltage this will interfere with your readings, you can avoid this by disabling the pin output drivers by making the pin an input" or something to that extent? Required Boilerplate: Component Version Device PIC18F74K40 MCC 3.75 MPLAB-X 5.10 Foundation Services 0.1.31 PIC18 Lib 1.76.0

I am trying to configure the DAC on the 47K40 Xpress Evaluation board using MCC and I am confused about what I see. The screen I see is to the right -> I can understand that the Vref+ and Vref- fields are necessary when you are using the input pins for a reference but it is really confusing when the Vref+ is shown and it is read-only AND it shows an incorrect value as it does here. I would have expected that if I select Vdd as the reference the Vref+ value would either be hidden, or that it would have the same value as Vdd. I also do not understand why the Output of the DAC is referred to as "Required ref", this talk of "Ref" all over the place is very confusing to the unsuspecting user. You should call the DAC out Value the Required DAC out Value above the line you show the result of the calculation, and when the references are set to Vdd or Vss then Vdd should match Vref+ and Vref- should be 0 even if those are read-only - even better just hide them if they should not be used! It turns out that Vref+ and Vref- are ignored if you have selected Vdd and Vss, and that Required Ref actually means the output that you desire to get from the DAC, for those as confused as I was. When you select the Vref+ pin as the reference then Vdd field is ignored. It also seems that the Vdd and Vref+ fields allow you to enter values way outside the electrical specs of the device, it does create a note that this is the case, but I would have expected a proper warning for something dangerous like this, at first I did not even notice this as it was green and just a note. Lastly when I select to use the FVR _buf2 as the positive reference for the DAC the screen no longer makes any sense. Now I can only edit Vdd (which is 5v) but my Vref is set to 2.048V via the 2x buffer on the FVR, but the Vref+ field is read-only so I cannot update it. MCC is however using the correct input reference of 2.048 as can be seen by the output being limited to 1.984V even when I require 3V. Required Boilerplate: Component Version Device PIC18F74K40 MCC 3.75 MPLAB-X 5.10 Foundation Services 0.1.31 PIC18 Lib 1.76.0

Ok, so every time I set up a pin as an output MCC insists on making it "Analog". It looks like this setting has something to do with the ANSEL register, but surely an output is not Analog so why do they do this?