How long does this take to execute

[HenrikOlsson]

It compiles to this:

0001                      M L00001
0001   140F               M         bsf     PORTD,  000h
0002   3000               M         movlw   0
0003   188F               M         btfsc   PORTD, 001h
0004   3001               M         movlw   1
0005   00BA               M         movwf   _Sw1
0006   33FA               M         bra     L00001

So as far as I can see the part IN the actual loop takes either 5 or 6 cycles, then the jump back to the start of the loop is another 2 cycles.
At 32MHz each instruction cycle is 125ns.
It doesn't seem to make any difference if it's for a 16F or 18F but be aware that if you have the WDT enabled it's possible that the compiler "injects" an instruction to clear it depending on where, in a larger program, this snippet ends up.

/Henrik.

[dsicon]

just what i needed to know, thanks and hello again Henrik

so if i had 4 pairs of lines like above inside the loop (different pins) then i would have
6 * 4 = 24 cycles
24 + 2 = 26 cycles
26 * .125 = 3.25uS
sound about right ?
i am not doing anything that requires high precision regarding number, if it was 2x slower i would be ok, if it was 3 - 4x i would need to know to make context adjustments

not incredibly speedy is it ?
that's only 300kHz for 6 pins

just to be clear
so 1/32MHz = 31nS
one instruction cycle = 4 clock periods ?
(this is starting to come back to me, it fades so quickly if you don't do this every day)

this is probably fast enough though and i assume reading a whole port would be about the same as reading a pin ?
in some areas that should speed things up quite a bit

[HenrikOlsson]

Hi,
Yes, one instruction cycle is 4 Clock cycles. That's where the Fosc/4 you see all around comes from. At 32MHz each instruction cycle (1/32M)*4 or 125ns.

Reading a whole port is obviously faster than Reading the 8 pins indvidually if that's what you're asking.

Four "sets" of those two line compiles to

000004                    M L00001
000004 8082               M         bsf     PORTC,  000h
000006 0E00               M         movlw   0
000008 B282               M         btfsc   PORTC, 001h
00000A 0E01               M         movlw   1
00000C 6E1A               M         movwf   _Sw1
00000E 8482               M         bsf     PORTC,  002h
000010 0E00               M         movlw   0
000012 B682               M         btfsc   PORTC, 003h
000014 0E01               M         movlw   1
000016 6E1B               M         movwf   _Sw2
000018 8882               M         bsf     PORTC,  004h
00001A 0E00               M         movlw   0
00001C BA82               M         btfsc   PORTC, 005h
00001E 0E01               M         movlw   1
000020 6E1C               M         movwf   _Sw3
000022 8082               M         bsf     PORTC,  000h
000024 0E00               M         movlw   0
000026 B282               M         btfsc   PORTC, 001h
000028 0E01               M         movlw   1
00002A 6E1D               M         movwf   _Sw4
00002C D7EB               M         bra     L00001

I count 20 instructions. Some of them (the btfsc) may take two cycles to execute but when they do the instruction AFTER the btfsc is skipped so in the end it'll still take 20 cycles, something I didn't take into account in the previous post. 20 * 125ns = 2.5us.

With that said I'm far from an expert in assembly programming so I truly hope someone that is corrects me if I'm wrong.

If you can explain what you're trying to do it may be easier to help you choose the best/fastest option.

/Henrik.

[dsicon]

at the moment this is good, i am just roughing in some rough estimates for various parts of the overall program loop

at this stage whether it is 5 vs 6 shouldn't matter, 20 vs 5 or 6 might

where i am going to need some real help i think is when i get to the RS485 output which needs to run continuously 512 bytes in the overall loop at 250k baud,
the program will need to respond to switches and things and is reading about 30 analogs which produce the serial stream

[HenrikOlsson]

DMX512 by any chance?
If you really need a continous stream at 250k baud then I think you need to some careful planning (and I guess that IS what you're doing with these test so thumbs up!).
At 250k baud you've only got 40us to do stuff Before you need to feed the next byte the UART (well you CAN wait up to 80us since there'a basically a single byte buffer) between each byte.

[dsicon]

yes, DMX
Jeff did it for me many years ago @4MHz, but it was 100% assembler, i don't think picbasic was around then

and there was much less other stuff to do on that one than this new one which is on the boards now, less channels, less functionality
what about the Instant Interrupts ? would that help here ?
do i need an 18F for that ?

[HenrikOlsson]

The correct 18F would allow you to run at 64MHz while I believe the 16F tops out at 32MHz but I might be wrong, haven't verified. Another benefit is that an 18F series device will allow you to have a single 512byte wide array for your DMX data. This doesn't work in the 16F series (max array length is 96). I'm not saying it can't be done on a 16F series just that I think you need some good reasons for selecting a 16F series chip over an 18F series device.

DT-Ints (Instant interrupts) is available for both 16F and 18F series so that doesn't matter but for this application I'm not entirely sure they're the correct aproach, especially if you're writing the ISR in PBP (which you are since you're using DT-Ints.....). The reasom I'm not too sure they're the right aproach is the overhead they add due to the system variable save/restore it has to do each time an interrupt occurs. This takes dozens and dozens of instruction cycles and at an interrupt rate of 25kHz it's going to eat away you're processing power.

With that said there are ways around that but they're not straight forward and you really need to know what you're doing so instead I'd look at one large loop type program calling tight subroutines with known execution time(s) and keep feeding the UART in between. Like,

* Feed the UART - OK, we've got 40us to do something useful.....
* Start the ADC - it'll take xx us to complete - go do something else....
* Read a pin
* Do something with it
* Write a pin
* Wait for the UART, Feed it.
* ADC done? Get result.
* Start ADC, next channel.

And so on.

An interrupt driven sender would be cleaner and if "all" the ISR is doing is indexing a 512 byte long array then examining the generated code and manually saving ONLY the system variables actually USED by the ISR will make DT-Ints work a lot faster but as I said, it's tricky and a very sensitive and delicate way of doing it from a code maintanence and expansion perspective.

/Henrik.