Paul & Sabrina's cheap DIY 144v motor controller

[dlaing]

Paul call me David.

Soon we'll have your ISR lean and mean.

[dcb]

Hope I'm not intruding, but here is an outline of how I might handle interrupts (just using bytes for example)

PHP Code:

volatile byte current //most important
volatile byte throttle
volatile byte temperature

volatile adcMode=9;// (9 = ready, 0 = throttle, 1 = temperature,  2 = current)


ISR timer1(){//16khz timer isr
static byte distributor=0; //unsigned
  if(adcMode==9){//wait for last adc request to finish
   distributor++;

 adcMode=2;//default to current read

 if(distributor==128)
   adcMode=1;//read temperature once out of every 255 calls (~ 60hz)
 else if(distributor==0)
   adcMode=0;//read throttle once out of every 255 calls (~ 60hz)

   ADMUX &= (128+64+32+16);
   ADMUX +=adcMode; //select channel

   ADCSRA |= 64;//start adc conversion
 }
}


ISR adcComplete(){
  if(adcMode==0)
    throttle=ADC
  else if(adcMode==1)
    temperature=ADC
  else 
    current=ADC  
  adcMode=9;//signify that we are ready for another reading
}

main(){
 init()
 while(true){
  cli
  byte tmpTemp=temperature
  byte tmpCurrent=current
  byte tmpThrottle=throttle
  sei
 
  do interesting things to the pwm or  whatever based on tmp variables here

 }
} 


[MPaulHolmes]

dcb, it appears you have mastered the art of the interrupt. Thank you for taking the time to put that together. I'm going to go over it with a fine tooth comb and really understand it. Thank you. (don't tell anyone, but I didn't know there was a command called iret. I thought that was just in x86 assembly. hehe.)

[blackpanther-st]

Originally Posted by MPaulHolmes

I think I need to sample the current during each pwm period, which is kind of bad because it eats up so much of the system resources. That's 2/3 of all computing time gone! But I guess it's worth it. Throttle is only needed at maybe 1kHz frequency or perhaps 500Hz. Maybe inside that ISR, I could take turns with current and throttle? Maybe skip a current sample every 16 times, to allow time for throttle? And then every 32000 times or so, skip both current and throttle to take temperature? Then, there should be 1/3 of the processing time avalailable for "other things..." Duh Duh Duhhhhhhh!

If I do throttle and temp outside, maybe that would be fine! Maybe just set a flag inside the ISR that says "timeToReadThrottle", and then I get to it when I get to it? I would have to disable the interrupts when I got to the throttle conversion moment so nothing weird would happen, but that's OK! I might try that! heck ya dude! You can't teach that, it's instinct! hahaha!

Human response time isn't exactly all that quick compared to your micro-controller, so a few more milliseconds of process time between throttle reads should not be a problem or even noticeable up to about 50 milliseconds.

I forgot if you have hardware over current protection or if it is all in the software? If in software you will need that read every cycle to protect your power section. but if this is done in hardware and you are only reading for current to throttle position control, then I think that you could probably do something like take a sample every fourth cycle or so,( lengthen the number of cycles between current reads until it starts to feel like the controller is beginning to lose track, and then shorten it up a bit.

What I am curious about is if you can still keep your read point synchronized on the peek of current the cycle, if you are only taking samples every 4rth - 8th - whatever the code is set for. I do believe that keeping it on peek will be necessary.

If keeping it on peek is not possible, one workaround might be to use a hardware filter to smooth out the output of your current detection circuit going to your micro-controller read pin for the current; filtering only needs to be strong enough to cover your PWM frequency and no more. ( also be particularly careful not to filter or dampen the output to the current limiting circit. )

[blackpanther-st]

I see someone has already addressed some of this while I was writing.

[MPaulHolmes]

Oh ya, there's hardware overcurrent protection. No filtering or dampening the path straight to the comparator/nand gates. It disables the driver in like 3 or 4 microseconds, and the microcontroller clears the flip-flop to re-enable everything. Right now I re-enable the mosfet driver when the next pwm interrupt happens.

[blackpanther-st]

OK that sounds good!

Are there two comparator/nand gates?

One for the hardware over current protection, and one for the microcontroller?

If so then it should be fairly easy to filter after the comparator/nand gate going to the microcontroller. That is if you need to; from what DCB posted it seems to me that you might be able to keep your synchronization as I was asking about before.

[MPaulHolmes]

The LEM Hass current transducer (hehe, I love that word) output splits. One path goes to the comparator that triggers the flip flop to change states if there is an overcurrent event, and the other path goes straight into the A/D channel of the microcontroller after an RC filter. That's sort of up in the air right now with the new design, as to what is the best filtering approach. The LEM output on the first controller was really noisy, but this next control board is much better, so we'll see what sort of filtering is best.

[blackpanther-st]

That sounds as if it should work with just a little tweaking of the values.

Curious are the two halfs of that split output are isolated, in the sense that the presence of the filter on one, will not affect the other?

[MPaulHolmes]

I had that same question. I asked 2 engineers about it, and they said that as long as the filter was "after" the comparator, then it should be fine. I got clarification that "after" was indeed the situation in the schematic, so I just went with that. I'm going to ask the engineer that's doing the testing to check that out, though. It seems that the presence of an RC filter on the other branch could affect the comparator, but I'm not sure.