While Loops Slow??

[Frozen001]

Well I am still having problems, so I have been doing some testing.

Using this exact code:

CMCON = 7								' Disables the Comparitor Pins
ADCON1 = 15								' Disables the A/D Converter Pins
TRISF = $F0								' Define Port F(0-3) as LED Outputs
                      
                                                                         
Define OSC 20							' Sets Oscillator Speed at 20Mhz
Define BUTTON_PAUSE 100					' Sets Button Debounce time to 100 ms
Define I2C_SLOW 1						' Sets I2C Speed to 100KHz



Main_Loop:
PortF.0 = 0
PortF.0 = 1
PortF.1 = 0
PortF.1 = 1
PortF.2 = 0
PortF.2 = 1
PortF.3 = 0
PortF.3 = 1
Goto Main_Loop

The Clock is dead on at 20MHz as measured on an oscilloscope.

Each pin takes about 200nS to go low then return high... Which seems on par with the 18F8722 data sheet stating that it take 4 clock cycles to exicute a command.

I actually measured the old device clock. It is running at 1MHz. Given that the fasted the 18F8722 can run each command, I basically can run 5 commands for each of the old devices clock cycles. Buy looking at my original code a few posts back it looks like I can do what I want to unless the compilier is creating bloated assembly code...

[sayzer]

May be you should try this:

IF PortA = $0B THEN TOGGLE PortB.0
WHILE PORTA = $0B  : WEND

This way, your very fast PIC will wait for your very slow old equipment.

If you do not wait in "while" loop, then PIC will loop thousand times until your old equipment changes its state.

-----------------------

[falingtrea]

There is no way your original code could be 5 instructions or less per loop. Each line of code will create at least 1 instruction. You have 4 lines inside the while, so at least 4 instructions plus two for the while (test and branch) will be executed each loop. For every if statement that is true you will get at least 1 additional instruction if not more.

So now you need to look at the old equipment and determine how fast you really need to detect changes. Is the original equipment running on a 1 MHz clock or is the output signal yopu want to monitor changing at a 1 MHz rate? If the signal you are looking at is changing at a 1 MHz rate, you will need a faster solution to detect it.

[falingtrea]

You know, thinking on it more, maybe speed is not an issue. If you are using the PIC to replace a 7 segment display with a dot matrix display, and you are trying to translate 7 segment lines into characters so you can send characters to a dot matrix display, this is something the human eye is looking at and the 7 segment display may not really be changing at a 1 MHz rate. I bet the old design is multiplexing the 7 segment displays at a much lower rate than you think. What you may need to do is detect which 7 segment digit is active, read the data going to that display and then translate it into a character to send to the dot matrix display. Typically that is milliseconds, not nanoseconds that you are dealing with. Unless the 7 segment displays have 7 segment decoders that the processor is writing to. Then you have to capture data when it is clocked into the decoder register. In that case, you could sense the clock edge and then read the data bus.

[falingtrea]

Hey Frozen001, any luck???

[Frozen001]

Well I boiled it down to the fact that PICBasic makes bloated code when you finally get to the actual number of inctructions it takes to perform certain tasks. My WHILE loops take more instructions than REPEAT:UNTIL loops. I got it working with a lot of tweaking by trying different commands.

[falingtrea]

Well I boiled it down to the fact that PICBasic makes bloated code when you finally get to the actual number of inctructions it takes to perform certain tasks. My WHILE loops take more instructions than REPEAT:UNTIL loops. I got it working with a lot of tweaking by trying different commands.

That's pretty much true of any "high level language". To get the ease of programming, you take a hit on performance. Unless you pay the big bucks for a "optimizing" compiler. And even optimized code doesn't get quite the performance as hand coding in assembly.

Good to hear you got things to work otherwise.