DT-Ints latency and other interrupt conciderations

[Darrel Taylor]

With PBPL, all internal System and T? variables are LONGs.

All multiplications and divisions are done as Longs, even if they are byte vars.
Most things that get put in a System var with a CALL to the library are done as a Long.

IF ByteVar1 >= ByteVar2 THEN             ; <-- Long 
IF ByteVar1 = ByteVar2 THEN              ; <-- Byte
WordVar = WordVar /* Const               ; <-- Long
ByteVar1 = ByteVar1 + Const              ; <-- Byte
ByteVar1 = ByteVar1 + (ByteVar2 >> 2)    ; <-- Long
ByteVar1 = ByteVar1 + (ByteVar2 >> 1)    ; <-- Byte

Having 32-bit vars is nice, ... unless you need speed.

Is there a particular reason you need PBPL?
Maybe we can cut that down to word sized math so you can go back to PBPW.
<br>

[HenrikOlsson]

Thanks Darrel,
That explains it for sure - but it kind of sucks.... :-/

Basically, the Position and the Setpoint variables are the only longs and the reason for PBPL.

The setpoint is calculated by adding or subtracting the number of steps that has arrived since the last servoloop. For the position I get the lower 16bits from the hardware QEI counter and the upper 16bits by keeping track of the number of over/underflows with the RollOver ISR.

Man, I'm painting myself into a corner here....

BTW, how come these two...

ByteVar1 = ByteVar1 + (ByteVar2 >> 2)    ; <-- Long
ByteVar1 = ByteVar1 + (ByteVar2 >> 1)    ; <-- Byte

...are treated different?

Thanks for all the help, I appreciate it!

/Henrik.

[Darrel Taylor]

Basically, the Position and the Setpoint variables are the only longs and the reason for PBPL.

The setpoint is calculated by adding or subtracting the number of steps that has arrived since the last servoloop. For the position I get the lower 16bits from the hardware QEI counter and the upper 16bits by keeping track of the number of over/underflows with the RollOver ISR.

If that's all there is ... it's a piece of cake for PBPW.

Man, I'm painting myself into a corner here....

I think not.

BTW, how come these two...

ByteVar1 = ByteVar1 + (ByteVar2 >> 2)    ; <-- Long
ByteVar1 = ByteVar1 + (ByteVar2 >> 1)    ; <-- Byte

...are treated different?

A single shift right compiles to a

    BCF STATUS,C
    RRF _ByteVar2,F

or, RRNCF for an 18F.

But for 2 or more shifts, it puts the value in a system reg, saves the number of bits to shift, then calls a library routine to actually do the shift. Therefore ... LONG.

Let me try to figure out the PBPW way. (should be easy)
I think all the info is already in this thread.
Anything missing that might help?
<br>

[HenrikOlsson]

Thanks Darrel,

At the Piclist I found some signed 32bit math routines. I copied the add, subtract and the needed support routines (addba and negateb) as add and subtract is the only 32bit ops I need (at the moment at least).

After some trial and error I managed to get these working on the 18F2431 by replacing the skpnc with btfsc, STATUS, C and clrc with bcf STATUS, C. I also made it so that the REGA, REGB and MTEMP variables are declared as PBP variables and then preceeded by an underscore in the actual ASM code. I saved it as a separate file and INCLUDE it in the program together with DT-Ints and inc_PID.

I've replaced my LONG-ops in the DoServo code with calls to these routines, it compiles with PBPW and as far as I can currently see it runs correctly. I haven't tried to apply any step-pulses to see what it does "in real life" but I used TMR1 to time the DoServo routine (including the PID) and worst case I've seen so far is 207uS. ~100% increase in performance compared to when compiled with PBPL.

I've also sent various variables (like the 4 bytes 'building' the 32bit position variable and the pid_Error variable) to the PC and it all looks to be correct. I need to test this much much more but what I'm currently worried about is if there are some bank-switching or RAM issues that I need to take into consideration with these math routines.

I consider it pure luck that I've got it working this far and I'm afraid once I'll start to add more variables and code I'll break it - and I'll have no clue why.

/Henrik.

[Darrel Taylor]

Great minds think alike ....
I had a similar idea, although started with different code from the net.

I guess it's good you got yours working, because I'm still struggling to convert it to 18F's.

I will continue anyway, because it's really cool.
It will be extremely useful for everyone else too.

And if you have problems with yours, it might fill the gap.

Best regards,

[HenrikOlsson]

Many thanks Darrel,
Looking forward to see what you come up with as it will most definitely be better than my hacks.

Generally speaking, when using 18F devices and declaring variables in PBP but using them in ASM by preceeding them with an _underscore. Is there ANYTHING I should be doing in the ASM code to make SURE it'll work? When lookinh at ASM code I keep seeing BANKSEL, PAGESEL etc but don't know if it applies to 18F and/or when the variable is declared by PBP. I see in the datasheet for the 18F2431 (that I'm currently using) that the RAM is divided into banks and this is what I'm worried about.

As I said, I consider it pure luck that I've gotten this far - that and the fact that the forum has been unaccessable during the whole day which has kind of forced me to read up and do some trial and error - a good thing! ;-)

Anyway, it's almost 2AM here, time for some sleep I guess.

/Henrik.

[boroko]

I have been watching with great interest.

This Thread and PID-filter routine (2nd try) (page 1) PID-filter routine (2nd try) (page 2) are very exciting.
I have a need for a small servo driver and I just can't bring myself to spending $115 for another Gecko 320. They are wonderful, but this app is just a small servo and doesn't justify it. The UHU looks perfect, but I really don't care to jump off of the PIC ship.
I'm afraid that all I can offer is my encouragement.

Thanks
Bo

[Darrel Taylor]

Henrik,

Well, my intent was to solve your problem ...
But I'm afraid I may have just muddied the waters even more.

I do believe this will help a great deal though ... fingers crossed.

N-Bit_Math.pbp
http://www.picbasic.co.uk/forum/showthread.php?t=12433

Best regards,