[SOLVED] USB CDC ADC PWM control PIC18F4550

[aftar mukhriz]

Hello All,

Right now, I'm trying to control PWM at pin C2 using ADC reading from pin A0. I have connected potentiometer to pin A0 and connected LED with resistor at pin C2. When I connected USB to the PC and opened up Tera Term, ADC reading can be displayed but LED is not responsive. I also tried to control PWM without USB using code in this forum:
https://www.ccsinfo.com/forum/viewtopic.php?p=120731
and it works. Below is my code for using USB.

[PCM programmer]

Your code shown below has a change from the sample code in other thread.
You changed it to use CCP2. But CCP2 outputs PWM on pin C1. You want
it on pin C2.

Edit the line below and put it back to CCP1. Then it might work.

[Ttelmah]

There are significant problems with your clock settings.

#fuses XT,NOWDT,NOPROTECT,BROWNOUT,PUT,NOLVP
#fuses HSPLL,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN,NOPBADEN
#use delay(clock=4M)

Now these show you as using an 'XT' crystal, so up to 4MHz. You speak
as if you are using a 4MHz crystal, but you have 'PLL5'. Now 'PLL5', tells the
chip to divide the oscillator by 5 to feed the USB PLL. So you are running
this at 800KHz, when it requires 4MHz....
However you also have the HSPLL fuse selected, which says to take the
CPU clock from the USB PLL, not from the crystal. So with the USB
PLL at 24MHz (which is what it would give from 800KHz), the CPU would
be running at 9.6MHz, not the 4Mhz you specify.... :(
There is another issue, that in general, running the CPU at 4MHz, can
have problems handling USB. USB needs significant performance from the
CPU, and normally around 8MHz is the slowest that will be reliable.
I'm surprised the USB does actually work. Almost certainly the compiler
or chip are 'defaulting' to a working configuration, but it is not what you
think it is....

So, assuming you do have a 4MHz crystal, change the fuses and clock
to:

#fuses XTPLL,NOWDT,NOPROTECT,BROWNOUT,PUT,NOLVP
#fuses NODEBUG,USBDIV,PLL1,CPUDIV4,VREGEN,NOPBADEN
#use delay(clock=16M)

This says to clock the USB off the 4Mhz crystal (PLL1), and to clock
the CPU off the USB PLL/6 = 16MHz. Change your ADC divisor to
/16. (just to confuse you CPUDIV4 gives /6 when used with the USB PLL).

This then should give you a running CPU and USB.

Then, there has to be at least Tacq between one ADC reading and the
next. As posted you read the ADC and set the PWM thirty times. Why?.
Read the adc a number of times, average the readings, and set the PWM
once. With a delay in the loop between the ADC readings.
When you currently do this loop, it tries to read the ADC 'flat out' without
any pause. At this point every thirty readings (so only a very few uSec),
it'll send the 'value' to the PC. This loop never exits, and will be sending
data far faster than the interface will support.

So, something more like:

[aftar mukhriz]

Thank you, PCM programmer for the pointer. I made silly mistake there. Thank you, too for your reply, Ttelmah. Actually, I'm using 20MHz crystal for this project. But, your reply helps me understand a bit on the fuses setting. So, I have changed the fuses and clock to below:

[Ttelmah]

Generally on the PIC, the internal ADC clock should not be used if the CPU
frequency is above 1MHz. In the data sheet for your PIC, the table
'Tad vs. device operating frequencies', has a note against the RC entry:

For device frequencies above 1 MHz, the device must be in Sleep for the
entire conversion or the A/D accuracy may be out of specification.

If you want to use the RC oscillator (internal), then you have to start the
conversion and put the PIC to sleep.

This same table also shows the maximum frequencies supported for a
given division.

Now /16, was for a 16MHz master clock. For 48Mhz, you would
need to use /64. However they don't warrant the ADC for device
frequencies above 40Mhz.

However, you are not running at 48MHz. You are running at 32Mhz, so
/32 for the ADC.

It is critical to get your head round the CPUDIV values. They are not
obvious....

What happens is that when the CPU is running off the crystal oscillator,
there are four CPUDIV values. DIV1, DIV2, DIV3 & DIV4. These give
/1, /2, /3 & /4. When you run off the USB PLL, these same values have
different meanings:

[temtronic]

To follow up what Mr. T is saying....
I printed out the 'clock' diagram to SEE just how to get that PIC with USB to work. There's a LOT of paths and combinations !!!
Once you've chosen a 'path' then you can figure out what fuses, clock options should work.
it was a LOT simpler 25 years ago....grab a real xtal, 2 caps and PICs ran.

[aftar mukhriz]

Thank you, Ttelmah & temtronic for the feedback given. My mistake is that I thought CPUDIV2 will produce 48MHz clock frequency. So, huge thanks for the table.
Next, based on the info in this forum, https://www.ccsinfo.com/forum/viewtopic.php?t=56171, I just want to confirm that the way to sleep internal clock is to set ADC clock with correct divisor, am I right? So, I changed the ADC clock from this:

[Ttelmah]

No,
The size needed is simply based on the size of the ADC value, and how
many you add up. So 1023 * 32 = 32736, which fits nicely into the int16.

[temtronic]

Depending on the type of 'sensor' and accuracy you require, you may not need 32 readings. Try 16 or 8 or 4 or 4. They make QUICK math..... using say 10 or 12 samples makes the 'math' more complicated... computers love binary math....

[aftar mukhriz]

Thank you, Ttelmah and temtronic.
So, the size of ADC data depends on the sum and value that I set, right? If I set the sum to i<16 and the value to sum/16, the ADC would be 1023*16 = 16368, right? Still, I need to assign unsigned int16 for sum and value due to both of them are larger than 255 for unsigned int8.
If my understanding is wrong, can someone point me to the right direction? Thanks for your time.
As for temtronic's comment, what I understand is that if I reduce the sample readings to let say 16 readings, though lesser samples, it will increase the PIC speed since lesser samples are needed for data processing, am I right? As for 10 to 12 samples, I believe the keyword is binary, is it?

[Ttelmah]

You are right in the analysis.

[aftar mukhriz]

Thanks, Ttelmah. However, is my analysis from temtronic's comment correct?

[Ttelmah]

Imagine you do (say) 10 samples, and have the code take:

sum/10

If you look at the size of the code, you will find this is perhaps 10* larger
than if you do:

sum/8

It also takes an enormous amount more time (perhaps about 30* as long)...

For averaging on a micro-controller, it is 'best' to use a 'binary' number
or samples, so 2, 4, 8, 16, 32 etc..
This reduces both the size and time needed for the division.

So as a general rule, for things like this, always try to ensure the final
division is by a binary number.

[aftar mukhriz]

Wow, huge thanks to you, Ttelmah and temtronic. Maybe later I'll try to use /10 or /12 like temtronic suggested to see the difference. Thanks again to both of you.
_________________
Learning process never ends

[Ttelmah]

Have fun.

For an example of the speed involved, /10, on an int16 takes 70.8 uSec
on a 20MHz processor. /8 takes less than 2 uSec!...