In many instances of microcontroller firmware design, it's necessary, or desirable, to take four individual bytes and access them as if they were a single 32-bit variable, maybe as a pair of 16-bit variables, or even some other combination. One way to merge the four bytes into a single 32-bit variable would require reading the least-significant byte into the 32-bit location, then shift-left by "8," then OR in the next byte, then shift-left by "8,"...etc.—until the 32-bit variable contains all four bytes.
While this certainly works, it takes a considerable amount of instructions and CPU overhead. However, another approach can be used to create a "zero-code-overhead" technique. This technique involves "fooling" the compiler to cause it to overlay the variables on top of each other.
The following example shows specifically how to do this on one certain microcontroller. These instructions may vary for your particular microcontroller, but the concept remains the same. First, using the #pragma statement, create some variables like this:
#pragma abs_address:0x00 unsigned long LongVariable; #pragma end_abs_address
On this particular microcontroller, the #pragma statements above force the variables into specific locations in RAM. Notice that the #pragma statements seem to conflict because the addresses appear to overlap. The fact that they do overlap is the basis of this technique.
In your firmware, you can now access individual bytes of a 32-bit variable by using the "Byte0," "Byte1,"...etc., references. Likewise, you can load up a 32-bit variable with individual bytes simply by writing each Byte0, Byte1, ...etc., variable.
By using the #pragma for the FourByteArray, you can also reference the bytes of the 32-bit variable as if they were members of an array. In addition, you can create a relative pragma instead of an absolute one, or declare the variable as a record comprising four bytes. But this latter technique potentially changes how code will be compiled (endian issues) and potentially confuses the self-documentation properties of the code. Here's an example:
(1) Declare the #pragmas as shown above.
(2) Create an unsigned char variable "peek"
(3) Next in your firmware, add:
LongVariable = 0x12345678; // put a breakpoint on this line! peek = Byte0; peek = Byte1; peek = Byte2; peek = Byte3; peek = FourByteArray[1]; Byte0 = 0xDE; Byte3 = 0xEF; FourByteArray[1] = 0xAD; FourByteArray[2] = 0xBE;
(4) Put a breakpoint at the first line, then single-step the firmware in the debugger.
(5) Monitor "peek" in the watch window, and watch memory locations "0..3" in the memory watch window as you single-step. You will see the individual bytes of the variables being manipulated as other variables are referenced.
I've never seen a compiler with "#pragma abs address", but most have "union". Who can use this technique?
Anonymous -September 22, 2005
If "union" is the preferred method of handling variable overlaying when possible, why didn't the article mention it? I agree that it's nice to know a workaround when you need it, but the article will steer everbody to the workaround, whether or not they need it.
Anonymous -September 22, 2005
Of the 30+ articles that I have had published over the years, none have generated more feedback than this one. The emails have covered the entire range too.
From designers who are truly curious to understand more, to those who take "shots" at me personally (...which is really pretty lame Mr.Anonymous) because a concept does not quite fit within the guidelines of what they, in all of their infinite wisdom, consider "best".
One of the many interesting things in my position with Cypress is that I get to work on a variety of designs, sometimes very old legacy designs to be converted, modified, or updated. Other times, I have to work within guidelines laid out by others which offer no flexibility in the allowed coding-style or use of certain C-features.
You would be surprised, especially Mr. Anonymous, how many times I have seen the content of this article (among other things) used in designs that have come across my bench in the last 20 years!
As pointed-out by other post'ers on this site, there are many other ways of accomplishing this that might be more applicable for one situation or another.
The point of this article, as well as the point of any publication, is to attempt to educate the reader. Even though you might not choose to use this technique, or other things that you may read, we thought that it might be beneficial for you to see it. This way, you will have an understanding as to what someone else may have done, or have a back-pocket trick should you be working with legacy tools or designs that require some "creativity".
Of course, in the ultra-pure and safe tunnel-cubical of Mr. Anonymous, this is simply (more) useless information. Say ten "Hail Unions" and pray that you never see it again.
Dave -July 19, 2005
Well isn't this silly. I do hope this doesn't prevent some young engineer from using "union", which cleanly does what this mess attempts.
I'll guess that the author doesn't even know that he's simply revealing a shortcoming in his company's C compiler that forces one to resort to what is truly "dangerous, unmaintainable" non portable code. It would seem the author has been dragged from his comfy Basic into the scary world of C.
Shame on the editors for letting this nonsense through.
Anonymous -July 14, 2005
Anybody else care to re-state the obvious? Obviously you can do this using unions. Bet ya' didn't know that you could do it like this too though! Reminds me of the days when we had to get creative in order to solve problems and REALLY understand how a microcontroller works. Nice!
Anonymous -July 12, 2005 (Article Rating: )
Dangerous, unmaintainable code. Avoid.
Anonymous -July 12, 2005 (Article Rating: )
This is ridiculous. Can't you just use a pointer? And if you give me some crazy excuse about no pointer support in your compiler, use a union!
long *lpLongValue = &lpByte0; -July 11, 2005 (Article Rating: )
Interesting. This seems like it will make nice tight code too.
Anonymous -July 11, 2005 (Article Rating: )
Are not the unions supposed to do it too even without absolute addressing and ANSI conform ?
Anonymous -July 08, 2005 (Article Rating: )
Your Comments:
Enter the text from the image below
Please refresh the page if you have trouble reading this text.
Search Electronic Design
Web Seminar
Sponsored By:
Title: Read Pacing: A Performance Enhancing Feature of PCI Express Gen 2 Switch Devices
Reprints
)
)
