-
Popular Contributors
Nobody has received reputation this week.
-
Similar Content
-
By KM1
Hello,
I have run into a strange (for me) issue with the rtcounter module as provided by MCC and shown by the example program in the blog area of this site. I am using MPLabX and XC8, both up-to-date versions and I am trying the example on a pic18F47k40 xpress board. The issue is I set an output (RA4) in main after initializing the pic and then enter the while(1) loop where the rtcount_callNextCallback(); is called. The output now is turning on and off. The off duration is typically ~60u seconds, and on time can be varied with changes to the timer interrupt settings (I use a 1mS timer0 in 16 bit mode) and the number sent to the callback. Approximately every 3mS, the off time increases such that that cycle (only) is approx 50% duty cycle.
Turning the output on or off in the callback routine has no effect - I initially wanted to toggle on and off at a speed visible to the eye. Commenting out the callback in the main loop stops the output from going low.
I have checked errata and used the data sheet to confirm register settings, I tried moving the current-limited LED from RA4 to RA2, and I have studied the example program looking for obvious differences that may cause this behaviour.
I would appreciate thoughts and/or suggestions.
Keith
-
By burkart
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
-
By Orunmila
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 -
By Orunmila
This is the LAB manual for the 2018 masters class which showed how to use I2C and Timers on the HPC curiosity board. The last lab shows how to use the BLE Click board to connect to your cellphone and send the touch data over this channel.
-
By Orunmila
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?
-
