BTW, the code: ((char *)&var)[varplace] &= 0x0F; Works perfectly. Thanks again -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
