PIC16F1825 Bug in OSCCON

For general Flowcode discussion that does not belong in the other sections.
DirkB
Posts: 85
http://meble-kuchenne.info.pl
Joined: Thu Dec 10, 2020 3:55 pm
Has thanked: 1 time
Been thanked: 4 times

Re: PIC16F1825 Bug in OSCCON

Post by DirkB »

Sorry, I forgot the program with the PWM.
Attachments
SpeedCheck3.fcfx
(14.54 KiB) Downloaded 505 times

medelec35
Matrix Staff
Posts: 2086
Joined: Wed Dec 02, 2020 11:07 pm
Has thanked: 644 times
Been thanked: 702 times

Re: PIC16F1825 Bug in OSCCON

Post 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.
Martin

medelec35
Matrix Staff
Posts: 2086
Joined: Wed Dec 02, 2020 11:07 pm
Has thanked: 644 times
Been thanked: 702 times

Re: PIC16F1825 Bug in OSCCON

Post 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 4986 times
Martin

BenR
Matrix Staff
Posts: 1952
Joined: Mon Dec 07, 2020 10:06 am
Has thanked: 510 times
Been thanked: 698 times

Re: PIC16F1825 Bug in OSCCON

Post 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.

DirkB
Posts: 85
Joined: Thu Dec 10, 2020 3:55 pm
Has thanked: 1 time
Been thanked: 4 times

Re: PIC16F1825 Bug in OSCCON

Post 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

DirkB
Posts: 85
Joined: Thu Dec 10, 2020 3:55 pm
Has thanked: 1 time
Been thanked: 4 times

Re: PIC16F1825 Bug in OSCCON

Post by DirkB »

Hello Martin,

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

Thaks
Dirk

medelec35
Matrix Staff
Posts: 2086
Joined: Wed Dec 02, 2020 11:07 pm
Has thanked: 644 times
Been thanked: 702 times

Re: PIC16F1825 Bug in OSCCON

Post 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 4964 times
You won't have much control over duty.
Attachments
SpeedCheck3 PWM 4MHz.fcfx
(15.12 KiB) Downloaded 613 times
Martin

DirkB
Posts: 85
Joined: Thu Dec 10, 2020 3:55 pm
Has thanked: 1 time
Been thanked: 4 times

Re: PIC16F1825 Bug in OSCCON

Post 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

mnfisher
Valued Contributor
Posts: 1630
Joined: Wed Dec 09, 2020 9:37 pm
Has thanked: 142 times
Been thanked: 761 times

Re: PIC16F1825 Bug in OSCCON

Post 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

Post Reply