DT-Ints latency and other interrupt conciderations

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

[Ioannis]

Either send or receive characters one by one using buffer and interrupt.

I know you are counting the usecs here but do not see how else can have serial communication. (When will PBP support 24F series??)

If it is not necessary to send or receive while running the PID routine, then maybe a button can branch to the setup routine, do what you want to do, then return to main program.

Ioannis

[HenrikOlsson]

Ioannis,
It'll have to be some kind of interrupt driven buffer routine for both sending and receiving, I think. I'd like to be able to send the current error while the system is running so the following error can be watched in "real time".

I'm currently looking at Microchips AN744 which seems to do pretty much what I need. "All" I have to do is figure out how it works and what I need to do get it working "in" PBP.

/Henrik.

[DDDvvv]

my two cents worth,

im getting 55us on the doservo code. is that possible? im using an 18f4431 @ 20mhz (couldnt get 40mhz going)

the scope is a 2211 tektronix. i thought there was something wrong with it, but its working perfect, and upto calibration.

i have the I_term function every 4th call, hence the long 73us on-time after every three loops on the main int code

here's an image of the scope screen.

all interupts are dt_interupts, in pbc.

thanks for all the ideas.

[HenrikOlsson]

Thats nice, I'm glad you got it working! Are you running the DoServo code as part of an Interrupt service routine? What are you using as "input"?

The long execution time (up to 400uS) I mentioned earlier was when the code was compiled with PBPL, when compiled with PBP it runs a lot faster. With PBP I've timed the PID code alone to as low as 40uS so your 55uS for the complete doServo seems plausible. The fact that it works points in that direction as well ;-)

The problem starts to appear when you:
1) Need 32 bit math for the position and setpoint variables (or anything else). Switching to PBPL makes the execution time of almost all arithemtic operations go WAY up. Without switching to PBPL you have to resort to ASM for the 32bit variables and math.

2) Using step- and direction as the input and DT-Ints with PBP interrupt handler for counting the step pulses. This pretty much kills it above a few kHz due the latency caused by saving and restoring the PBP system variables.

At least that's what I've found this past week. If you have yours running with step and direction input I'd love to hear what kind of steprate you can achieve.

Thanks!
/Henrik.

EDIT: Wait a minute, the "period time" is 55uS (ie. the servo code is run at 18kHz), the execution time is probably closer to 40uS or so. Are you really trying to run the servocode at 18kHz?

[Ioannis]

Ioannis,
It'll have to be some kind of interrupt driven buffer routine for both sending and receiving, I think. I'd like to be able to send the current error while the system is running so the following error can be watched in "real time".

I'm currently looking at Microchips AN744 which seems to do pretty much what I need. "All" I have to do is figure out how it works and what I need to do get it working "in" PBP.

/Henrik.

Checking the RCIF/TXIF or RC1IF/TX1IF (for the 18Fseries) flags I think is enough to see if the UART is ready to send or has received a byte.

Of course the checks and byte read/write to the UART are not free and need your precious time each.

Maybe you have to move to a higher grade PIC like the 24F or even on the 32bit ones but then you also have to say good bye to PBP.

Ioannis

[HenrikOlsson]

Ioannis,
Nah, it should be doable with the 18F series - I'm almost there now. Like I said earlier I have a comercially available drive that is based on the 18F2431 and it works fine, step-rate specified to 400kHz (not verified) and USB interface thru some FTDI-chip.

I've got the code from AN744 working "inside" a very simple PBP program - 5 lines of PBP code and 200 lines of ASM. Now I only need to figure out HOW it works so I get it to do what I need. I may opt for interrupt driven RX and polled TX though.

Anyway, I think I'll start a separate thread for that...

Thanks!
/Henrik.