PIC16F1825 Bug in OSCCON
-
- 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
Sorry, I forgot the program with the PWM.
- Attachments
-
- SpeedCheck3.fcfx
- (14.54 KiB) Downloaded 506 times
-
- 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
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.
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
-
- 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
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.
That would be impossible if the osc is running at 500kHz.
Martin
-
- 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
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. 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.
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. 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.
Regards Ben Rowland - MatrixTSL
Flowcode Online Code Viewer (Beta) - Flowcode Product Page - Flowcode Help Wiki - My YouTube Channel
Flowcode Online Code Viewer (Beta) - Flowcode Product Page - Flowcode Help Wiki - My YouTube Channel
Re: PIC16F1825 Bug in OSCCON
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
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
-
- 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
Hi Dirk.
Attached is the best I can do.
It's a PWM of 4MHz. You won't have much control over duty.
Attached is the best I can do.
It's a PWM of 4MHz. You won't have much control over duty.
- Attachments
-
- SpeedCheck3 PWM 4MHz.fcfx
- (15.12 KiB) Downloaded 613 times
Martin
Re: PIC16F1825 Bug in OSCCON
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
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
-
- 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
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
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