LCD Instrumentation for Cougar Controller

[harlequin2]

Originally Posted by DJBecker

Some of the code that I'm known for is Linux networking -- I wrote essentially all of the network device drivers until about 2000. You aren't calibrated to feedback if you think thought anything there was a harsh comment. A real review would be much harsher. The early Linux mailing lists would leave you shaking in the corner.

And to put it in perspective, 100x more people will read this comment than will read the source code. I'm guessing that exactly three people have read the code to this point.

I've been working on a bms ("Low cost BMS") and its pretty much done, but I'd like to incorporate my "master control unit" functionality into Freyguy's LCD. He has room enough in unused memory, I think, and if I don't use the CAN port I may have pins for a s/w UART.
My stuff is all in C and while I could combine it with Chris's assembly language, it would be neater and tidier to do the whole thing in C. If you have converted the original stuff, can you tell me where I can download it from? You may have put that info on here before and if you have my apologies, but I haven't searched through the whole thread. Lazy b----er!

[Freyguy]

Hi Harlequin2,
It looks like DJ’s link is still active back on post 386. Don’t think the C conversion was ever finished.
Looking at what would be applicable within my code, I’d say driving the LCD, UART and reading/writing to EEPROM. I wonder if it would be easier to use available CCS C libraries for the PIC?
Example HD44780 16x2 LCD code (4-bit mode with R/W tied low) was found here-
CCS :: View topic - Flexible LCD driver

[harlequin2]

Originally Posted by Freyguy

Hi Harlequin2,
It looks like DJ’s link is still active back on post 386. Don’t think the C conversion was ever finished.
Looking at what would be applicable within my code, I’d say driving the LCD, UART and reading/writing to EEPROM. I wonder if it would be easier to use available CCS C libraries for the PIC?
Example HD44780 16x2 LCD code (4-bit mode with R/W tied low) was found here-
CCS :: View topic - Flexible LCD driver

If he didn't finish it, then I'll treat it with some reserve, but worth a look to see what he did do.
I already use quite a few CCS library functions although I modified the LCD driver along the lines of the link you gave so's I could use pins to suit my pcb layout. Also, the UART routines. Haven't used eeprom in what I have done so far, but yes, you are right in looking at those for your Cougar LCD board. I guess you followed the link I sent you for the CCS compiler! It has lots of good stuff and easy to use too, although a bit ROM hungry. I find that if you strip out a lot of their "general" stuff and trim it to fit the micro you are using, you can shrink it down quite a bit.
I originally used the printf function to write to the LCD but found it consumed ROM at a tremendous rate, so I wrote my own routines for formatting and writing my own data which allowed me to fit my control unit into the 3.5k in the 16F1826. But now I have discovered the 16F1827 which is the same but with 7k rom and 385 bytes of RAM, so I am tempted to do some function creeping!
But time to look at your stuff now and see if I can get my functions into it while preserving most of what you did. The CAN bus can all go and some of the alarm outputs and that'll give me enough pins for a s/w uart to talk to my bms modules.
The bms is fitted to my car now and doing its thing quite nicely, but its a nuisance having a separate control unit.
Oh wow, I just looked at that link, what a lot of stuff. Modifying it for CCS alone is a lot of work! I wonder how efficiently it compiles compared with the size of your ASM stuff? This is not something I am going to rush into.

[DJBecker]

Originally Posted by Freyguy

Hi Harlequin2,
It looks like DJ’s link is still active back on post 386. Don’t think the C conversion was ever finished.

The goal of the C code was to compile to (almost) exactly the same ASM instructions as the hand written code. There are many places where a native C version would be written differently, but that wouldn't generate the same instructions.

There are only a few spots where there is a mismatch. For instance, I haven't figured out a way to get SDCC to generate and propagate the carry bit for 24 bit arithmetic.

The code was essentially complete when I first posted, but I have made minor refinements since then. I just checked in the few minor modifications that I made since August. For instance, I figured out a better set of compile options and function entry code that let me control which registers are saved in the interrupt handler. It now matches the ASM where before it saved a larger set of registers in a different order.

[harlequin2]

OK, I'll have another look at your posting, thanks. I haven't done more than a cursory glance at it as yet, same for Freyguy's asm code.
Was there a particular reason why you wanted the C compiler to generate the same asm instructions or was it just so you could be sure it would work the same without having to debug new C code if it didn't do quite what you expected?

I haven't even seen that it uses 24-bit arithmetic! Take your word for it, but wow! I managed to get my bms done with 8 bit integer arithmetic and still keep sufficient accuracy and resolution.

[DJBecker]

Originally Posted by harlequin2

Was there a particular reason why you wanted the C compiler to generate the same asm instructions or was it just so you could be sure it would work the same without having to debug new C code if it didn't do quite what you expected?

I was so that I understood exactly what the code was doing. Not what the comments said.

Originally Posted by harlequin2

I haven't even seen that it uses 24-bit arithmetic! Take your word for it, but wow! I managed to get my bms done with 8 bit integer arithmetic and still keep sufficient accuracy and resolution.

There is a 24 bit value tracking the battery capacity. That's just barely enough precision. Any less and you accumulate significant error with the SoC in some conditions.

[harlequin2]

Originally Posted by DJBecker

There is a 24 bit value tracking the battery capacity. That's just barely enough precision. Any less and you accumulate significant error with the SoC in some conditions.

Perhaps you will be patient and explain to me just why this is?

[mora]

I'm going to add external current sensor to read amps directly from battery pack. 400A Tamura sensors are out of stock at Mouser and Digikey. I was wondering if I could get away using 600A Tamura sensor instead of 400A and only by changing amp scaling parameter in software?

[Freyguy]

Mora,
Yes, that would work. Since its max range is 750A vs 500A you’d need to set bAmp_scale to 24 to account for 1.5x decrease in sensitivity.
There are other options if you’d rather use a LEM. I see the LEM HASS 200S is available at Digi-key. That has a max range of 600A so is more comparable to the Tamura 400A(500A max).
bAmp_scale would need to be set to 19 for that one.
LEM HASS devices are more expensive, but they also have a larger aperture for the bus bar or cable. Tamura is 8mm x 15mm. LEM is 10.4mm x 20.4mm.
My 2/0 gauge cable barely fit into the Tamura aperture even after I stripped off a small section of the jacket.

-Chris

[mora]

Went for HASS 200S. Do I need to use first pin (Vref in/out) at all?

Also I can't find parameter bAmp_scale from .ASM -file. I see sAmp_scale but comment says it scales amp reading from serial input instead of external current sensor.