A pic based Charge Controller

[Mr RB]

Nice work Pommie! I think the options also needs to incude the load dump setpoints, that is the main operating feature after all. Will Swordfish basic allow the whole 8k?

Nickelflippr- wouldn't it be easier to turn the load on/off in software? The ADC already knows the battery voltage so doing it in software means it's easy to adjust high/low battery setpoints (ie the hysteresis) and also allows the option of a programmable time delay which might be prudent between dump cycles etc.

 

[Pommie]

The menu data is just a test to see if the menu system works. I don't think it will be very suited to this purpose but a cut down version may be useful. I think Swordfish will allow all the ROM to be used but we would have to switch to an 18 series chip. If I get time over the next couple of days I'll swap the 886 for a 18F2620 and get it working in Swordfish as I think this will provide greater flexibility.

Mike.

 

[AtomSoft]

Can you post a normal schematic for me? Im working on LCD init right now since in Proteus its kinda retarded heh

 

[Pommie]

What you have is correct and it looks like it is almost working. Maybe the delays are wrong. Try dropping the speed to 4MHz with osccon=0x61; Or, even 0x51.

Thanks for this.

Mike.

 

[AtomSoft]

Heh it was my fault actually i didnt set the OSC in Proteus lol ti was using 1mhz heh stupid Jason heh

How do the button work? I have had much time to look through code but buttons confuse me here. They dont seem to work

 

[Pommie]

From D4 to D7 are back, up, down, enter. So pressing the bottom button should move the > character down and pressing the rightmost button should enter that sub menu.

Edit, the top line "Main Menu" doesn't do anything, it is just a heading.

Edit2, as they are arranged your buttons are like a joystick, good choice.

Mike.

 

[nickelflippr]

Nickelflippr- wouldn't it be easier to turn the load on/off in software? The ADC already knows the battery voltage so doing it in software means it's easy to adjust high/low battery setpoints (ie the hysteresis) and also allows the option of a programmable time delay which might be prudent between dump cycles etc.

Software could be the way to go, certainly more flexible. Just like the idea of setting and forgetting, zero controller cycles spent, and send control back to the main loop checking conditionals etc. Not to say that some filtering, hysteresis, or feedback of some sort may be required for the comparator. If pin usage becomes valuable, then the extra two or three pins may be a problem.

Dump cycles in what way? The HPWM controls the frequency of the output, which no doubt will be important. In GCBasic the HPWM 1, 8, 191 means CCP1 or channel one, period approximately in khz, and 8 bit duty cycle value. If Dump cycles, as in Dump load for X period, then back to float voltage for X period, than that's yet another part of the program.

Willing to try out whatever methodology offered up .

 

[AtomSoft]

Pressing buttons dont do anything are you setting it as input afterwards? Ill have to look through the code

 

[Pommie]

It works fine with the real hardware, does Proteus handle the internal pullups correctly?

Mike.

 

[AtomSoft]

not sure im going to see if its the diodes. when i press button the light doesnt change.

 

[nickelflippr]

Haven't looked at the menu code, but aren't the diodes backwards in the schematic. Ra6 wouldn't be able to tell which button is pushed, unless it's analog input with associated button resistors or'd together.

 

[Pommie]

Try changing the diodes for 10k resistors. Got to go to bed now but let me know how it goes.

Mike.

 

[AtomSoft]

ok sure will..

 

[AtomSoft]

Tried this and no good. I wish i understood your method heh

From what i can see... you are using a XOR to check the PORTB bits. I assume you are using this to check the current value and test it against a users press.

How do you know when a user presses a button. What happens when the user holds the button down then it will create a flag with the same bits to XOR and you will get no result.

I dont know lol can someone explain the way it works or supposed to in this case (my Proteus side)

 

[Pommie]

I have to go to bed now, 2:45AM here. We'll pick this up tomorrow. Thanks for your patience.

Mike.

 

[AtomSoft]

Ok no problem. Ill see ya tommorrow heh

 

[AtomSoft]

heh just though id post a AVI of a UART MENU i made as a test...

**broken link removed**

Its best to RIGHT CLICK the link and save the video then view it

 

[Pommie]

I must have been tired last night. Changing the resistors to 10k was silly, they should be 1k.

I see what you mean now about leaving A6 as output. I've changed the code and commented it.

#define KeyEn porta.6
#define KeyEnTris trisa.6
#define KeyTris trisb

#define KeyDelay 30
#define KeyRepeat 10

#define key_none    0
#define key_back    1
#define key_up      2
#define key_dw      3
#define key_enter   4

unsigned char keys=0,previous,edges,KeyCount;

char ReadKeyPad(){
char i;
    previous=keys;              //keep copy of previous state
    option_reg.7=0;             //WPUs on
    KeyTris|=0x3c;              //B2-B6 input
    KeyEnTris=0;                //A6 output
    KeyEn=0;                    //and low
    [color=red]delay_us(10);[/color]               //see text below
    keys=(portb>>2)&0x0f;       //read keys
    keys^=0x0f;                 //invert them so 1=pressed
    KeyEnTris=1;                //switch en back to input
    KeyTris&=0xc3;              //switch b2-b6 back to output
    if(keys==0)                 //if no key pressed
        return(0);              //return zero

    //now do key repeat and delay stuff
    //keys xor previous gives us a 1 if a key has changed
    //ANDing this value with the new keys pressed gives
    //keys that were 0 last time and 1 now = new presses

    if(((keys^previous)&keys)==0){  //if no new presses
                                //must be repeating key
        if(--KeyCount!=0)       //decrement key count and
            return(0);          //return zero as time not up
        KeyCount=KeyRepeat;     //reset key timer
    }else{
                                //must be new key press
        KeyCount=KeyDelay;      //set initial delay  
        edges=((keys^previous)&keys);//see above
    }
    i=0;
    while((edges&(1<<i))==0){   //change bit pattern into 1 to 3
        i++;
    }
    return (++i);               //and return it
}

If it still doesn't work can you set a break point to see what is in keys when a key is pressed.

edit, maybe Proteus is taking pin capacitance into account. Try adding the line in red to see if it fixes it.

Mike.

 

[AtomSoft]

no luck. The lines are all high but getting a 0x00 in keys.

how about moving the resistors to the LCD lines instead of buttons?

 

[AtomSoft]

Yes it works with it on LCD lines!! nice menu dude! ill record it now