----- Original Message -----
From: "demolitron"
To:
Sent: Monday, April 27, 2009 3:05 AM
Subject: [piclist] Re: PIC User Interface Help requested
> I've been playing with the DSPic line and PIC18s as well.

[clip]

> If anyone knows I'm doing this the hard/wrong way please
> shine the light on me. Anyways, I got the code size down
> a LOT smaller, then I started adding more

I don't think there is a WRONG way, some ways work better than others, but
there is no best way for every application.

One "common" way is to use scaled fraction arithmetic. If you notice, the
16 bit parts support scaled fraction natively. I think Microchip has some
example code for the 8 bit parts, too. If you think about it a bit, the
only time the absolute value really matters is when you convert it for
display. With scaled fraction, you basically let all 1's (of however many
bits you decide to use) represent 99.9+% of the full scale value. If you
multiply something with a full scale value of 5 by something with a full
scale value of 10 the result has a full scale value of 50.

This has the added advantage of helping you keep your eye on what matters,
and when you have complex calculations, it helps you decide what it
insignificant and can be dropped.

--McD

I take no offense really. I have about 10 of these left in my parts cabinet and I'm using them up. I've been playing with the DSPic line and PIC18s as well. They are nice.

I ended up scrapping the printf routines and switched from floating point to 8.8 fixed point. This was the first time I'd written my own print routines. I had a few head scratch moments!

Essentially I am doing a divide by ten, adding the remainder to '0' and then repeating the loop until I've reach how every many characters I want.

For the fixed point I do the whole number the same as an int, but the fractional part is multiplied by 1000 and then divided by 256. This gives me how every many thousandths and then I print it out like an int.

If anyone knows I'm doing this the hard/wrong way please shine the light on me. Anyways, I got the code size down a LOT smaller, then I started adding more monitoring options, features, fail safes, etc... Its back up again, but at least I know my code is slightly more efficient.

--- In p..., dlc wrote:
>
> I don't mean to call your baby ugly but the 16f877a is a real dinosaur.
> You can get higher capacity, faster chips at either the same price
> or less with a little searching in the Microchip parametric search. I
> think that I'd start there.
>
> DLC
>
> demolitron wrote:
> > Hello,
> >
> > My initial searches have produced little information and if someone here could point me in the right direction it would be great.
> >
> > I am building a smart battery charger. The interface is constructed from a PIC16F877A, a 16x2 parallel LCD display, and 4 switch inputs. I am using Hi-Tech PICC for a compiler. And yes, I know C will produce large code and ASM would be better but I just don't like coding in ASM all that much... I do it when speed/accuracy is a must.
> >
> > I've done almost everything I want, but the code has grown to nearly 100% utilization! I think my UI state machine complexity and sprintf calls are really inefficient.
> >
> > I would like to be enable user modification of about 18 integer and 8 float variables that would be written to EEPROM. In addition to showing some 8 run-time variables gathered from sensors. Some kind of MCU efficient text based menu framework or tutorial would be ideal. Anyone know of someplace I could go to find it?
> >
> > Thanks for your help!
> >
> >
> >
> >
> >
> >
> >

I don't mean to call your baby ugly but the 16f877a is a real dinosaur.
You can get higher capacity, faster chips at either the same price
or less with a little searching in the Microchip parametric search. I
think that I'd start there.

DLC

demolitron wrote:
> Hello,
>
> My initial searches have produced little information and if someone here could point me in the right direction it would be great.
>
> I am building a smart battery charger. The interface is constructed from a PIC16F877A, a 16x2 parallel LCD display, and 4 switch inputs. I am using Hi-Tech PICC for a compiler. And yes, I know C will produce large code and ASM would be better but I just don't like coding in ASM all that much... I do it when speed/accuracy is a must.
>
> I've done almost everything I want, but the code has grown to nearly 100% utilization! I think my UI state machine complexity and sprintf calls are really inefficient.
>
> I would like to be enable user modification of about 18 integer and 8 float variables that would be written to EEPROM. In addition to showing some 8 run-time variables gathered from sensors. Some kind of MCU efficient text based menu framework or tutorial would be ideal. Anyone know of someplace I could go to find it?
>
> Thanks for your help!
>
>
>

----- Original Message -----
From: "demolitron"
To:
Sent: Wednesday, April 22, 2009 6:52 PM
Subject: [piclist] PIC User Interface Help requested
> I've done almost everything I want, but the code has grown
> to nearly 100% utilization! I think my UI state machine
> complexity and sprintf calls are really inefficient.

Of course, my knee-jerk reaction is that this is a simple enough case that
assembler would be easier, but with an 877 you should have plenty of memory
for C.

First, look at the code produced by your state machine. I would be surprised
if this were the problem; it is pretty easy to create efficient state
machines in C. But if you are concrned about it there may be an
opportunity. In my exploration of C compilers, though, each has something
it does astonishingly poorly. This might be the case here, although I sort
of doubt it.

Then, of course, get rid of printf/sscanf/etc. These things are huge memory
hogs, and most of the time, you really don't need them.

> I would like to be enable user modification of about 18
> integer and 8 float variables

One also has to ask why on earth would you want to use floating point
variables in a battery charger. These tend to be more time hogs than space
hogs, but if you are printf-ing float variables, well, you shouldn't be
surprised that your memory has disappeared.

Floating point variables are all about dynamic range. If you have real
world sensors that are probably only good to 1% or so, then even 16 bits is
way overkill. There can't possibly be anything in a battery charger that
requires a dynamic range of more than, say, 10^3 or 10^4, well within the
range of a 16 bit integer.

As high level languages go, C is pretty good at reminding you when you are
paying a price, but it is far too easy to write x = 2.7 * y; without really
understanding what that means. Stop and think about what you really want to
do, and about the significance of your data.

As a side benefit, you will discover that printf isn't quite so important.

72/73 de WB8RCR http://www.qsl.net/wb8rcr
didileydadidah QRP-L #1446 Code Warriors #35

Hello,

My initial searches have produced little information and if someone here could point me in the right direction it would be great.

I am building a smart battery charger. The interface is constructed from a PIC16F877A, a 16x2 parallel LCD display, and 4 switch inputs. I am using Hi-Tech PICC for a compiler. And yes, I know C will produce large code and ASM would be better but I just don't like coding in ASM all that much... I do it when speed/accuracy is a must.

I've done almost everything I want, but the code has grown to nearly 100% utilization! I think my UI state machine complexity and sprintf calls are really inefficient.

I would like to be enable user modification of about 18 integer and 8 float variables that would be written to EEPROM. In addition to showing some 8 run-time variables gathered from sensors. Some kind of MCU efficient text based menu framework or tutorial would be ideal. Anyone know of someplace I could go to find it?

Thanks for your help!