Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control

[MPaulHolmes]

Sure you can send me the code. It probably won't be for a few days. In fact, e*clipse would be a better person.
mora: Yes! 3 blocks in parallel. Each with their own current sensor and their own hardware overcurrent shutdown (and one desaturation detection for all 3).

[shaggythegangsta]

Originally Posted by MPaulHolmes

Sure you can send me the code. It probably won't be for a few days. In fact, e*clipse would be a better person.
mora: Yes! 3 blocks in parallel. Each with their own current sensor and their own hardware overcurrent shutdown (and one desaturation detection for all 3).

i'm attaching the file... with modified code

i'm waiting e*clipse's answer he is checking also the code.

[Magnus_jo]

Thanks Paul Inverter is now running in Trollhättan / Göteborg

Magnus Johansson

[MPaulHolmes]

MAGNUS!!!!! IT IS?!?! Hurray!!!!!! Can I please see what it looks like on a video? I haven't seen it drive a car yet.

[tajman]

Originally Posted by shaggythegangsta

i'm waiting e*clipse's answer he is checking also the code.

Hi shaggy/e*clipse,

I'm hoping one (or both ) of you can help me with some questions I have about the controller code as I understand that Paul is fairly occupied (your input is still very much welcomed though, Paul - in fact anyone who feels so inclined).

I've downloaded the version that is on Paul's Github repository and I've been 'playing' (the best word to describe what I'm doing) with it in Mplab X. I created a project and made some small changes to get it to build for the original 4011 chip (the uart.h header is referenced as UART.h so need to change the name to match and there was a misreferenced config bit entry BORV_27 vs BORV20, I think) - feeling pretty good since I don't really understand what these portions are doing but at least I got it to build

Now Paul sent me the new board PCB and SCH files (thank you Paul!) and I see that the design is centered on the 6015 chip. After creating a new project in Mplab X and changing the code to use the built in 6015 header definitions, I used a brute-force approach (build, check and fix errors - Google, tear hair out, pray, not necessarily in that order - lather, rinse repeat) until the code built successfully. I know this isn't all that is involved in porting to the 6015 platform So now the questions:

(1) What other areas should be considered for porting? (It's been well over 20 years since I've done any microprocessor coding and that was in assembly - its all gone! So any pointers would be appreciated)

(2) Is there any helpful material on C code anatomy for the microp that you can point me to? Something that can help me understand the functional "blocks" of the code so I can more easily relate to it. E.g., I'm assuming there is some initializing of the chip, then some definitions on how the ports allow it to interact with the real world(?), and then actually getting the microp to sense and then react to the real world (read, interpret, write). I really want to fully understand what's going on in the code.

Thanks in advance for any consideration afforded me.

[MPaulHolmes]

Actually, the 6015 is very very similar to the 4011. It just has more pins. I bet the changes you made would let it run on the 6015 right this minute. The new board's pins are ALMOST identical to the 4011 (well, the 4011 is ALMOST a subset. Maybe one pin different. I can't remember which one now). There are a few extra pins on the new board. There are 3 things to address a pin.
PORT
LAT
TRIS

So, if there's an input, let's say it's input1, on port B3. My convention is to do the following:

#define I_PORT_INPUT1 _RB3
#define I_LAT_INPUT1 _TRISB3
#define I_TRIS_INPUT1 _LATB3

Tris is the thing you set to define a port as input or output. 0 means output, 1 means input. So, in the function that configures the inputs and outputs, you would have:
I_TRIS_INPUT1 = 1;

LAT is the thing you write to to set the value of the port. This isn't very relevant for inputs, since it's an input! haha. But if you wanted an output to be high, you would type:
O_LAT_SOME_RAND0M_PIN = 1;

PORT is the thing you read to get the value of the port. Ex:

if (I_PORT_INPUT1 == 1) {
// holy moley! input1 is now high!
}

So, read the port, write the lat!

You also have to initialize inputs as either analog or digital. Analog inputs are configured as analog by default, so you have to explicitly configure an input as digital if it could also be used as analog.
You do that here:
ADPCFG = 0b1111111111000000; // Set the lowest 5 bits to 0 which is analog, and make all others 1, meaning that they are digital. Default is analog. 0b is just like 0x for hexadecimal. 0b means the number is binary.

That would make analog inputs an0, an1, an2, an3, an4, an5 ANALOG, and all the rest would be digital. So, 0 means analog, and 1 means digital.

The basic structure of the code is, make the A/D in sync with the PWM frequeny, (in my case it's 10KHz) so each time the A/D has new values for currents and throttle and temperature ready, you are running the ISR, which runs the clarke and park transforms and inverse transforms, and sets the new PWM duties for all 3 phases. Then, when that time critical part is not running, you try to squeeze in the other interrupt, which is the serial communications.

Really, once you get all the bits configured, it's really just C, and you don't have to think about the details of what chip it is anymore. The 6010a has some quirks that make it a little different from the others, but the 6015 is very similar to the 4011.

[tajman]

Originally Posted by MPaulHolmes

There are 3 things to address a pin.
PORT
LAT
TRIS

Thank you very much Paul! This is very helpful! I actually found a tutorial that may even help me get up to speed with the C syntax:

www dot newbiehack dot com/MicrocontrollerTutorial.aspx - yes I am a newbie

The tutorial is centered on an Atmel MCU however but I can extract the concepts which is what I really want to understand. But the information you provided is a brilliant kick start for me to do the translation. Thanks again!

[e*clipse]

Ohhhhh, OK....

Why don't I attempt to translate both the 6015 and the 6010A code at the same time; both IC's are in the same "family" and almost twins...

Right now I've printed out all 43 pages of code and the pinouts of the 4011 and 6010A. I've done a pin-pin comparison of the chips; I'll add the 6015 to the mix.

Yes, many of the pins are the same for the 6010A and 4011. In general, there is more pin sharing of functions on the 4011.

One of the key things to watch out for is also the PGC and PGD pins. Paul likes to use those pins for programming the IC vs their alternatives. The problem on the 6010A is that AN0 and AN1 use those pins.

Regarding frequency - it would be nice to have a way to adjust for different oscillator frequencies and PWM frequency settings without messing up code behavior later. I would really like to play with the PWM frequency.

Anyway, I'll keep plugging away.

- E*clipse

Originally Posted by MPaulHolmes

Actually, the 6015 is very very similar to the 4011. It just has more pins. I bet the changes you made would let it run on the 6015 right this minute. The new board's pins are ALMOST identical to the 4011 (well, the 4011 is ALMOST a subset. Maybe one pin different. I can't remember which one now). There are a few extra pins on the new board. There are 3 things to address a pin.
PORT
LAT
TRIS

So, if there's an input, let's say it's input1, on port B3. My convention is to do the following:

#define I_PORT_INPUT1 _RB3
#define I_LAT_INPUT1 _TRISB3
#define I_TRIS_INPUT1 _LATB3

Tris is the thing you set to define a port as input or output. 0 means output, 1 means input. So, in the function that configures the inputs and outputs, you would have:
I_TRIS_INPUT1 = 1;

LAT is the thing you write to to set the value of the port. This isn't very relevant for inputs, since it's an input! haha. But if you wanted an output to be high, you would type:
O_LAT_SOME_RAND0M_PIN = 1;

PORT is the thing you read to get the value of the port. Ex:

if (I_PORT_INPUT1 == 1) {
// holy moley! input1 is now high!
}

So, read the port, write the lat!

You also have to initialize inputs as either analog or digital. Analog inputs are configured as analog by default, so you have to explicitly configure an input as digital if it could also be used as analog.
You do that here:
ADPCFG = 0b1111111111000000; // Set the lowest 5 bits to 0 which is analog, and make all others 1, meaning that they are digital. Default is analog. 0b is just like 0x for hexadecimal. 0b means the number is binary.

That would make analog inputs an0, an1, an2, an3, an4, an5 ANALOG, and all the rest would be digital. So, 0 means analog, and 1 means digital.

The basic structure of the code is, make the A/D in sync with the PWM frequeny, (in my case it's 10KHz) so each time the A/D has new values for currents and throttle and temperature ready, you are running the ISR, which runs the clarke and park transforms and inverse transforms, and sets the new PWM duties for all 3 phases. Then, when that time critical part is not running, you try to squeeze in the other interrupt, which is the serial communications.

Really, once you get all the bits configured, it's really just C, and you don't have to think about the details of what chip it is anymore. The 6010a has some quirks that make it a little different from the others, but the 6015 is very similar to the 4011.

[e*clipse]

So I've finished comparing 4011 pinouts w/ 6015 pinouts.

Paul - you're right - only a couple differences.

Paul - could you send me a schematic for that new board?

I'll make sure the code works for that. - Assuming you haven't already done this... hopefully this effort will help yours.

Also - Paul & thingstodo - what is the oscillator frequency on the boards you're running? The schematic I have says 8Mhz.

Paul - the code seems to have a lot of complexity so it will work for everything. What do you think about putting stuff into little sub-programs?

For example, a separate *c or *h file for the different motor configurations. The one that gets used only needs to be in the include list before compiling. It would make it easier to focus on stuff that will be different (like changing or editing the sub-program).

I could also make a display function so a lot of the complexity in main could be removed.

If done right, it will function identically; it will just be easier to adjust stuff.

- E*clipse

[MPaulHolmes]

It does have a lot of complexity for working with all motors. I like the idea of separating it into distinct include files. I think it's too soon for there to be a single hex file for everything. My thinking was, it would be nice to have everything all in one file, so someone could get a single programmed microcontroller, and would then be free to order whatever sort of motor they watned, but during development that's a lot of trouble. When there's so much being changed for specific motor types, it makes more sense to do what you suggest, and just have a file that's dedicated to that motor type.

As usual, I love all your ideas! I'll send you the new schematic/pcb stuff.
EDIT: I forgot. It's a 7.3728MHz Crystal. That 8MHz is what it used to be, but the only way you can do 30MIPS is to use the 7.37.