Paul & Sabrina's cheap DIY 144v motor controller

[MPaulHolmes]

One change I've done is to limit the size of pwmDutyFine instead of pwmDuty, to keep the pi loop under control. That's a good idea about ReadThrottle, ReadCurrent, changing to Convert... I had been trying to think of a better name. That's much better.

If I do a ConvertThrottle() every time in main, I'm computing the throttle much more often than I would need to (since it's only read every 16 pwm cycles). Is it better to do it more often outside the ISR than to have a longer ISR? I wasn't sure what the best thing to do was there.

By the way, I'm pretty sure the code is working. I'm fairly certain that the control board now has some bad capacitors. I believe that they were damaged awhile back, perhaps when the controller blew up, and now they are really bad. The oscilloscope made it pretty clear that they were no longer doing their jobs.

I'm not going to be able to test the software until I fix that naughty control board, or I get the new fancy ones back.

[dcb]

Sweet, glad it looks like it works

I envisioned the main loop getting a bit longer eventually, like when you add uart or other user interface fun. And it would only get run as necessary if convert is called in the main loop (still takes cpu time if in the isr).

So it means you wouldn't have to think about the isr timing as much and the main loop timing would be more predictable. But it has to stay short enough that the time between pwm changes is not a hinderance to driveability. Is 30hz smooth enough? Can you do everything you want in the main loop in 0.033 seconds?

[MPaulHolmes]

I've never tried that low of a throttle sample frequency. That's a good point about stuff being added later to the main loop. I get sort of short sighted sometimes. We could always have each of "the stuff" take its turn. Like another counter, with a series of descending

if (counter & 63 == 63) {
}
else if (counter & 31 == 31) {
}
else if (counter & 15 == 15) {
}
...

type of stuff in the main loop to keep the throttle updating fast if it needed to be. I'll try it out at lower frequency once I get a control replacement.

Man, I really need to make a new control section! ya!

[squiggles]

A good rule is to keep ISRs as short as possible, minimises the risk of interrupting interrupt routines.

By now you should be able to gauge the approximate cycle time of your main loop (I guess you already have) so you can build you process priority list.

I will try and describe a concept I like to use to 'balance' the process load. Use a counter to count the number of main loop operations (ie a cyclic counter 0..15,0..15,..) Highest priority stuff might get processed in every loop, however you might find there are four processes you want to run once every 8th cycle. So one gets processed in loop 2 & 10, another is processed in 4 & 12...is this making sense. Ultimate aim is to keep the maximum cycle time as short as possible.


Of course you could have a main loop that actually does nothing, and just run everything from a timer interrupt....but that takes a whole lot of planning.

My apologies if you have already considered all these issues, not intending to waste your time.

[MPaulHolmes]

squiggles, you are not wasting my time! I really appreciate your suggestions. They are very helpful.

I ordered the parts today. The boards came to the engineer too. I need to ship 3 programmed AtMega8's to him, but I can't really test them first, since the old control section isn't working any more. I've simulated them, and one problem is that the simulator doesn't seem to really do a good job with the USART. The USART data register never gets empty in the simulator! It acts like an infinite loop.


void PutCharUSART(unsigned char c) {
// wait until UDR ready
while(!(UCSRA & (1 << UDRE))); // wait until the USART data register is empty.
UDR = c; // send character
}


Oh dear. Maybe I should leave that part out?

[MazdaMatt]

Paul.... never use a while loop that you can get locked into. It could spell disaster. ie, the interrupt keeps dinging and the current keeps flowing, but the throttle never gets sampled and gets "stuck".

I would highly suggest using the uart interrupts instead of polling. I have always hated polling systems in general - especially in communication.

[squiggles]

I think I can see that program hanging.

Back to my last idea.

Lets say you have a timer interrupt triggering every 2msec and you have a global variable
int COUNTER;
Then you main loop could be something like

main()
{
while(1)
}

and you have a timer interrupt like

timer_interrupt()
{
COUNTER++;
COUNTER = COUNTER & 0x000F; // counts 0 .. 15
switch(COUNTER)
{
case 0:
run_high_priority_stuff();
break;
case 1:
run_high_priority_stuff();
do_some_other_things();
break;
case 2:
run_high_priority_stuff();
check_the_pedal();
break;
.
.
.
.
case 15:
run_high_priority_stuff();
}
}


From there everything is written as a function and simply called somewhere in the switch statement.

How is that for a challenge?

[esoneson]

Originally Posted by MPaulHolmes

I need to ship 3 programmed AtMega8's to him, but I can't really test them first, since the old control section isn't working any more. I've simulated them, and one problem is that the simulator doesn't seem to really do a good job with the USART.

Paul,

Why don't you have him mount sockets instead of the AtMega8's? This would make life a lot easier at this stage of the game.

Eric

[dcb]

Matt does have a point, but the solution is complicated enough that I would rather just leave out uart for the moment. Note, there is a program to watch the avr simulator uart: http://www.helmix.at/hapsim/

referenced from here:
http://www.google.com/url?sa=t&sourc...wSsj96RLmjuSNA

I can outline it but cant get into too much detail at the moment:

You need a way to stream characters from the main loop out the uart.

Not only that but you need to possibly offload the processing of a snapshot of the ecu so that it can be pretty printed out the uart and not weigh down the pwm change period too much.

So in main, you check a global flag "printit"
if printit not set then load some globals with the values to print (raw current, throttle,temp,overcurrent, any accumulators) and set printit = true.

in the timer isr, you allocate some time in the distributor (or the distributor calls another distributor) if printit is set to call small enough parts of the conversion to not overrun the timer isr. like functions for each step in the math conversion and for each step in the string conversion and again to send each character out the uart one by one. And finally it resets printit.


Or just bang it out and see how long it takes in execution time

edit: hint: an array of function pointers can be handy thing.

[squiggles]

I have not been following the UART discussion, I would say one thing though, I would not bother to send out anything other than some raw data packets with some identifiers. No point having the controller do any data processing that some external device can easily do. (Guess you already knew that )


Hmm, maybe implementing a simple modbus slave type protocol. External device can write to registers to set parameters and read from registers to get any data it wants.....need to think about that for a moment..