DT-Ints latency and other interrupt conciderations

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

[DDDvvv]

thanks for the prompt reply.
right now im fighting with the step/dir int routine, which is not showing any sign of life. so im assuming that step/dir is not working.

whole routine is in the interrupt, (just as you had it)except the lcdout, which is the only command in the main routine.

yes, that is 18khz according to the scope. is that not good?

the only motor connection is the encoder and im using leds to show hpwm output. saves a lot on h-bridges and smoke from explosions.
will eventually move to the power control module once everything is figured out.

[HenrikOlsson]

Running the PID-loop at 18kHz is probably overkill, for motorcontrol somewhere between 1000 and 2500Hz seems to be common depending on inertia of the motor etc but YMMV.

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

[Ioannis]

The AN I think is 774 not 744. The driver you have might be based on pure assembly. What clock does it have?

Ioannis

[HenrikOlsson]

Of course, you're right! I've mentioned it twice now and managed to get it wrong both times.

Obviously I don't have access to the source code for the drive but I was told by the developer that he was using MPLAB+BOOSTC (that probably means ASM for the time critical stuff and C for the rest). I don't know what oscillator speed it uses but I suspect it's 10*4MHz.

/Henrik.