Page 2 of 2

Re: PIC16F1825 Bug in OSCCON

Posted: Mon Oct 23, 2023 2:27 pm
by DirkB
Sorry, I forgot the program with the PWM.

Re: PIC16F1825 Bug in OSCCON

Posted: Mon Oct 23, 2023 2:28 pm
by medelec35
Hi Dirk.
You are not comparing like for like.
Assembler is going to be much faster as with the free version of the microchip C compiler there are more overheads than if using assembly language or the paid version of the XC8 compiler.
If you use assembly language on the 16F1825 then greater speeds than on the 16F688 will be possible.

Re: PIC16F1825 Bug in OSCCON

Posted: Mon Oct 23, 2023 2:51 pm
by medelec35
I changed the settings of the PWM of SpeedCheck3 and the highest frequency I can get is 2.7 Mhz
That would be impossible if the osc is running at 500kHz.
Max PWM Frequency 16F1925.png
Max PWM Frequency 16F1925.png (12.86 KiB) Viewed 4989 times

Re: PIC16F1825 Bug in OSCCON

Posted: Mon Oct 23, 2023 4:02 pm
by BenR
Hi Dirk,

The chip is running at a rate of 8 million instructions pre second and the output pin is toggling at 500KHz, that seems about right to me. That equates to 16 instructions for your loop which also seems about correct. A jump instruction is at least 2 instructions and so the loop is two instructions and the if is two instructions. The output icon will do things like setting the data direction register as well as pushing and popping the stack. You are also likely using the free unoptimised version of the XC8 compiler which likes to add meaningless nops into the assembler code.

If you want to try and go faster then you could use C for your output to get rid of a few instructions. See this.
SpeedCheck3.fcfx
(10.75 KiB) Downloaded 505 times
You could as well if you wanted try the pro version of the XC8 compiler, I think you get it for free for so many days and it can be licensed on a monthly basis.

A fairer speed test is to use the delay icon and then check to see if the delay matches up with the required time. This is our classic 1 second flasher test.

As for MIDI, I'm assuming you're trying to bit bang it? Why not use a hardware UART. This is going to be a lot more reliable and will do all the nasty timings for you. If you must bit bang it then I would use the UART Software (timer) component instead of a standard software UART channel. This pushes the timings to a timer interrupt and allows you to queue incoming and outgoing data which greatly improves reliability.

Re: PIC16F1825 Bug in OSCCON

Posted: Mon Oct 23, 2023 4:57 pm
by DirkB
Hello Ben,

I am using the XC8 Pro compiler. It compiles within a few seconds and the hex file is much smaller. For Midi I always use the hardware UART.
What do you mean by "If you want to try and go faster then you could use C for your output to get rid of a few instructions. See this."

Thanks

Dirk

Re: PIC16F1825 Bug in OSCCON

Posted: Mon Oct 23, 2023 4:57 pm
by DirkB
Hello Martin,

what exactly did you change in the settings of the PWM?

Thaks
Dirk

Re: PIC16F1825 Bug in OSCCON

Posted: Mon Oct 23, 2023 6:47 pm
by medelec35
Hi Dirk.
Attached is the best I can do.
It's a PWM of 4MHz.
16F1825 PWM  4MHz.png
16F1825 PWM 4MHz.png (19.54 KiB) Viewed 4967 times
You won't have much control over duty.

Re: PIC16F1825 Bug in OSCCON

Posted: Wed Oct 25, 2023 3:13 pm
by DirkB
Hello,

just for my understanding. With PLL, the clock is 32Mhz. The PIC needs 4 instructions for one command. So it works as
if it is clocked with 8 Mhz and only one instruction is needed for one command. instruction for one command, right?
When and where in the programme is a clock frequency of 32 Mhz used? This is still not conclusive for me. Is the clock
frequency at the clock output also divided by four. If so, why?

Dirk

Re: PIC16F1825 Bug in OSCCON

Posted: Wed Oct 25, 2023 4:03 pm
by mnfisher
Yes,

Each instruction takes (a minimum of) 4 clock cycles to execute - so The effective instruction rate on a chip with a 32Mhz clock is 8MHz. Changing the clock to 8Mhz would give 2Mhz instruction rate.

Most MCUs have instructions that take one or more clock cycles with each instruction having several phases. More powerful processors will execute several instructions in parallel (so maybe one instruction is loading, one decoding etc, prefetching next instruction) Things like jumps tend to throw the processor instruction pipeline too,

RISC (reduced instruction set) chips have a simpler instruction set - where each instruction takes, typically, one clock ccyle. However you might need multiple instructions to do the same work as one instruction on a CISC (complex instruction set) processor.

Most code doesn't need to be particularly fast - so get it to work first then optimise the bottlenecks..

Martin