PDA

View Full Version : Picbasic pro speed issues?



CuriousOne
- 18th July 2013, 17:21
Hello.

Just for curiosity, I wrote the simple program:

CYCLE:
HIGH GPIO.0
LOW GPIO.0
GOTO CYCLE

Tried to run it on PIC12F683, with internal oscillator configured @ 4 mhz.
Measured output pulse frequency on GPIO.0 with digital scope. It was 100khz.

Configured internal oscillator to 8mhz.

Output pulse frequency become 200khz.

So, can be such performance decrease considered as normal?

Is it same for all MCUs?

I have to write some real-time functioning program, so I need to know the hardware limits. Since the looping sequence is one of the simplest one, I was expecting at least 1mhz with 4mhz oscillator, not 100khz.

aerostar
- 18th July 2013, 18:28
HIGH and LOW are not simple commands !, they make the port an output first - this takes a certain number of operations, then sets the port HIGH.

If you want speed then make the port an output to begin with then set it high or low as needed. eg GPIO.0=1 for high

as in all things read the manual...page 144

CuriousOne
- 18th July 2013, 19:06
Well, I don't actually "want speed", I'm getting used with hardware, to know what expect and how to handle, just the 1st results were discouraging, this is why I asked, maybe I'm doing something wrong? as you proove, I was wrong. Tomorrow I will try your loop and post back the results.

HenrikOlsson
- 18th July 2013, 19:33
Hi,
As have been said, and to add a bit: HIGH/LOW are commands which not only set the pin HIGH and LOW, it also makes the pin an output even if it already IS an output. Your code, compiled for a 12F683 (yes, it's different when compiled for other targets) results in the following ASM output:

_Cycle
bsf GPIO, 000h
bsf STATUS, RP0
bcf ((GPIO) + 80h), 000h
bcf STATUS, RP0
bcf GPIO, 000h
bsf STATUS, RP0
bcf ((GPIO) + 80h), 000h
bcf STATUS, RP0
goto _Cycle

All instructions takes one cycle except the GOTO which takes two and if you count the number of cycles you'll get 10. With the PIC running at 4MHz each instruction cycles takes 1us so the loop takes 10us to complete which matches your 100kHz measurement exactly.

Now, if you'd do something like this instead:

TRISIO.0 = 0

Cycle:
GPIO.0 = 1
GPIO.0 = 0
Goto Cycle

The resulting ASM code looks like this:
.
bsf STATUS, RP0
bcf TRISIO, 000h
bcf STATUS, RP0

_Cycle
bsf GPIO, 000h
bcf GPIO, 000h
goto _Cycle

Now the actual loop is only 4 cycles instead of 10 so you'd get 250kHz instead of 100kHz when operating the PIC at 4MHz - quite a difference.

/Henrik.

CuriousOne
- 18th July 2013, 19:49
Thanks!

Perfect explanation.

Maybe there are results of how much each command on average "consumes".

And regarding the other PICs, will be loss the same as with that one, or it will be less or more?

CuriousOne
- 27th July 2013, 08:05
I've compared pic12 and 16 series on above operation. when clock is the same, speed is also same. how 18xxx will perform, any ideas?

Demon
- 27th July 2013, 16:04
I can't see an 18F doing more than 1 instruction per cycle. I would think that's when multiple core CPUs come in, but that's another architecture.

I have seen 18Fs run at 64MHz though.

Robert

Demon
- 27th July 2013, 16:09
...
Now the actual loop is only 4 cycles instead of 10 so you'd get 250kHz instead of 100kHz when operating the PIC at 4MHz - quite a difference.

/Henrik.

At 64MHz, you'd get 16 times faster, 4MHz.

Robert