Thanks for the suggestion (typecast) a couple of comments:
1. I don't care about telling the compiler that I'm smarter than it
thinks I am ("don't worry about this assignment, it's right") because I
write lots in ASM, so I'm always very careful about what memory actually
has in it.
2. As for BCD. Well, I've had to defend my position on this countless
times from people that tell me that I'm wasting my time maintaining BCD
variables, but here's my defense: I am using BCD integers because:
2a: In order to use the least amount of time "on", I can simply display
bcd variables one character at a time w/ a lookup table. No conversion
needed. The faster my display routine is, the more battery life I have.
2b: Ti put in BCD instructions, so, I'm gonna use them. If they were
really "redundant", then they wouldn't be there (this is RISC after
all).
2c: It's not that hard to do and wouldn't help me in this case. I am
needing to display the number to the user anyway, so I'm able to use the
same bcd display routine as I am using during normal operation.
3. Ya, I'm using a direct connect 4mux lcd (for power savings).
4. Thanks for the help/suggestions (esp. the lesson on forcing RAM).
-Mark
-----Original Message-----
From: mspgcc-users-ad...@lists.sourceforge.net
[mailto:mspgcc-users-ad...@lists.sourceforge.net] On Behalf Of Chris
Liechti
Sent: Wednesday, January 22, 2003 6:34 PM
To: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Preferred method for byte access to unsigned
long
Am 22.01.2003 22:43:14, schrieb "Mark Stokes" <m.sto...@ieee.org>:
>What is the preferred method for allowing byte (or even nibble) access
>to unsigned long variables?
>
>example:
>a setup program that is taking a number off a screen (in BCD) on a per
>character basis (say with a button that steps to each character) and
>places the result in an unsigned long int (preferably still in BCD).
>
>I thought of three methods:
>1. Use a union.
>2. Use a character array and then use shift assignments to initialize
>the proper variables before and after
>3. Try to access the RAM directly (access the unsigned long as if it
>were a character array).
that's the same as 1) but without the help of the compiler
>implementation:
>1. should be obvious
or a union with bitfields for the nibbles, but that will lead to large
code
>2.
>unsigned char testlong[4];
>
> // initialize from RAM
> testlong[0] = ramval & 0x000F;
> testlong[1] = ( ramval & 0x00F0 ) >> 4;
> testlong[2] = ( ramval & 0x0F00 ) >> 8;
> testlong[3] = ( ramval & 0xF000 ) >> 12;
>
> // Mess with testlong using loops, etc
> // Copy value back to RAM
> correctraw = ( testlong[3] << 12 ) + ( testlong[2] << 8 ) + (
>testlong[1] << 4 ) + testlong[0];
>
>3. Access the unsigned int as a string. The compiler complains about
>this. But one way around the complaints is to use a pointer.
>unsigned long int *longpointer;
>
> longpointer = *ramval;
* -> &
> longpointer[0] = (uchar)something;
> etc.
or stress typecasts even more...
unsigned long value;
((char *)&value)[offset] = y; //offset = 0..3
but consider that typecasts are a bad thing, cause you tell the compiler
to
shut up, even if you doing insane things...
>The reason for wanting to access the variable using byte operations is
>that it makes it easy to "step across" ram val with an index. The only
>alternative I can think of is to hard code each "byte" update of the
>ramval (lots of code).
work with bytes or better just a binary number for your display routine.
then
if you realy want, convert to BCD to store it in your settings flash/ram
whatever.
that way you'd simply need a bin2bcd() end bcd2bin()
but i must say that i dont like BCD encoded digits very much. it makes
code only complicated... (it may be resonable for arbitrary precision
integers, where you add digits as needed, but it i dont think that
you're
using this on a MSP ;-)
i'd probably work on a normal number (short variable or whatever) and
only convert to BCD if needed. (you're using a F4xx with LCD driver?)
i'm usualy working with character LCDs and there i can use printf to
output nicely formated numbers :-)
>Thanks for any ideas.
>One last thing: is there a way to force the compiler to use a RAM
>location for a variable as opposed to the Stack (I know, same thing),
or
>a register?
void f(void) {
static int local1; //like a global var but not known to
other funcs.
register int reg1; //*try* to use a register
int auto1; //register or stack, same as auto int auto1 (?)
}
the compiler will try to use the registers for local variables, so you
don't realy
need the register keyword.
chris
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
