DT-Ints latency and other interrupt conciderations

[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,

[HenrikOlsson]

Hi,
Today I've had somewhat of a breakthru :-)

I went back for another try of having the servo code in the main routine but this time I took out DT-Ints all together. Currently there are three interrupts but only one of the ISRs (DoStep) is actually ASM. The other two are PBP but apparently they aren't using any system variables so I seem to get away with it - for now.....

The latency for the DoStep ISR is now down to 2uS compared to 8.5uS before (and 29 from the beginning). This made it possible to get a step-rate of at least 60kHz without noticable problems - and this is still with 20Mhz osciallator. I'm still using the 32bit add & subtract routines I mentioned earlier but I plan to try N-Bit_Math once I get the next hurdle/challenge sorted:


With the servo/PID code now running in the main loop I'm trying to figure out how and where I should add the "front end". The front end needs to be able to send and recieve commands thru the USART as it'll be used to setup the various PID parameters, get current position and status etc.

Previously, when the servo/PID code was run as a low priority interrupt, I had some basic HSEROUT statements in the main routine sending out current position etc at intervals to help me debug the system. But now I had to take those out as they would otherwise hold off the execution of the servo/PID code.

My guess is that HSEROUT/IN is out of the question, or perhaps I could use them by creating my own serial buffers and then HSEROUT (and/or IN) one character per pass thru the main loop or something like that.

Any ideas on a good way to approach this?

Thanks!
/Henrik.