标签: pointers

Jack Ganssle posted a blog about a book called Understanding and Using C Pointers by Richard M. Reese. I'm a hardware design engineer by trade. The best you can say is that I dabble in the software side of things. The subtleties of pointers have long confused me, so I decided to purchase this book.   Personally, I think this book is well worth the price if you want to move beyond the "training wheel" stage of C programming. I learned a lot. Unfortunately, I didn’t learn as much as I thought I'd learned, because I cannot wrap my brain around a programming problem.   Here's the deal. This all pertains to my current BADASS Display project, which -- as you will doubtless recall -- is going to feature a 16x16 array of tri-colored LEDs as illustrated below.     I'm actually using Adafruit's NeoPixel Strips for this little beauty, with the control of the display being performed by an Arduino Mega microcontroller development board.   I'm planning on using 16 NeoPixel strips, each containing 16 pixels, and each implementing one of the vertical columns in the array. The idea is to take an audio stream from my iPad, split out its spectral components into sixteen frequency "buckets," and then present the results in spectrum-analyzer-form on my display. (I'm still pondering how to extract the frequency spectrum data from the audio stream, but that's a problem for another day.)   Purely for the sake of discussion, let's assume that my NeoPixel strips are named "strip ," "strip ,"… "strip ." Meanwhile, the lowest LED (i.e., the one nearest to the bottom of the array) on each strip is numbered 0, while the highest LED is numbered 15. Let's further assume that whatever is processing my audio stream, it generates a series of sixteen five-bit values called "bucket ," "bucket ,"… "bucket ." Each of these five-bit values represents the current amplitude associated with that bucket, from 00000 2 (no LEDS lit) to 10000 2 (all LEDs lit).   Actually, my previous statement is not strictly true, because these five-bit values actually represent the number of the highest (vertically speaking) LED being lit. The way in which we subsequently display this information depends on what we wish to do -- we could display a solid bar of LEDs from LED 0 up to and including the LED in question, or we could simply light up this topmost LED, or… the list goes on.   But we are wandering off into the weeds. What I would ideally like to do is to have a function called "lightStrip()" that I can call from the main body of my program. Perhaps something like the following:     But then we come to the way in which the folks at Adafruit have created their libraries and instantiate their NeoPixel strips. I think this is done in C++, but -- thankfully -- the gory details are hidden from me. A stripped-down version of the instantiation might look something like the following:     The first parameter is the number of pixels in your strip (16 in this case), while the second parameter is the number of the digital I/O pin you wish to use to drive this strip (1 in this case).   Later on, in the body of your code, you can use calls like the following:     In the case of the "strip.setPixelColor()" function call, "i" is the number of the pixel (ranging from 0 to 15 in our case) whose color you wish to specify using three eight-bit values for the red, green, and blue channels. The interesting thing is that the "strip.setPixelColor()" function doesn’t actually drive the strip itself. It just stores the new color values in an array in memory. This means you can specify the color values of any and all elements in the strip without actually writing to the strip each time.   Once we have all of our ducks in a row, as it were, we use the "strip.show()" function to upload all of the color values into the strip. Now, we can instantiate multiple strips called "strip0," "strip1," "strip2," and so forth if we wish. But this is where I grind to a halt. How can I pass these different strips into my "lightStrip()" function? I know that in regular C it's possible to pass a pointer to one function as an argument into another function, but how does that relate to what I'm talking about here? All I can say is that any thoughts you care to share will be very gratefully received.

Several weeks ago I read Jack Ganssle's blog about a book called Understanding and Using C Pointers by Richard M. Reese. I'm a hardware design engineer by trade. The best you can say is that I dabble in the software side of things. The subtleties of pointers have long confused me, so I decided to purchase this book.   Personally, I think this book is well worth the price if you want to move beyond the "training wheel" stage of C programming. I learned a lot. Unfortunately, I didn’t learn as much as I thought I'd learned, because I cannot wrap my brain around a programming problem.   Here's the deal. This all pertains to my current BADASS Display project, which -- as you will doubtless recall -- is going to feature a 16x16 array of tri-colored LEDs as illustrated below.     I'm actually using Adafruit's NeoPixel Strips for this little beauty, with the control of the display being performed by an Arduino Mega microcontroller development board.   I'm planning on using 16 NeoPixel strips, each containing 16 pixels, and each implementing one of the vertical columns in the array. The idea is to take an audio stream from my iPad, split out its spectral components into sixteen frequency "buckets," and then present the results in spectrum-analyzer-form on my display. (I'm still pondering how to extract the frequency spectrum data from the audio stream, but that's a problem for another day.)   Purely for the sake of discussion, let's assume that my NeoPixel strips are named "strip ," "strip ,"… "strip ." Meanwhile, the lowest LED (i.e., the one nearest to the bottom of the array) on each strip is numbered 0, while the highest LED is numbered 15. Let's further assume that whatever is processing my audio stream, it generates a series of sixteen five-bit values called "bucket ," "bucket ,"… "bucket ." Each of these five-bit values represents the current amplitude associated with that bucket, from 00000 2 (no LEDS lit) to 10000 2 (all LEDs lit).   Actually, my previous statement is not strictly true, because these five-bit values actually represent the number of the highest (vertically speaking) LED being lit. The way in which we subsequently display this information depends on what we wish to do -- we could display a solid bar of LEDs from LED 0 up to and including the LED in question, or we could simply light up this topmost LED, or… the list goes on.   But we are wandering off into the weeds. What I would ideally like to do is to have a function called "lightStrip()" that I can call from the main body of my program. Perhaps something like the following:     But then we come to the way in which the folks at Adafruit have created their libraries and instantiate their NeoPixel strips. I think this is done in C++, but -- thankfully -- the gory details are hidden from me. A stripped-down version of the instantiation might look something like the following:     The first parameter is the number of pixels in your strip (16 in this case), while the second parameter is the number of the digital I/O pin you wish to use to drive this strip (1 in this case).   Later on, in the body of your code, you can use calls like the following:     In the case of the "strip.setPixelColor()" function call, "i" is the number of the pixel (ranging from 0 to 15 in our case) whose color you wish to specify using three eight-bit values for the red, green, and blue channels. The interesting thing is that the "strip.setPixelColor()" function doesn’t actually drive the strip itself. It just stores the new color values in an array in memory. This means you can specify the color values of any and all elements in the strip without actually writing to the strip each time.   Once we have all of our ducks in a row, as it were, we use the "strip.show()" function to upload all of the color values into the strip. Now, we can instantiate multiple strips called "strip0," "strip1," "strip2," and so forth if we wish. But this is where I grind to a halt. How can I pass these different strips into my "lightStrip()" function? I know that in regular C it's possible to pass a pointer to one function as an argument into another function, but how does that relate to what I'm talking about here? All I can say is that any thoughts you care to share will be very gratefully received.

When I first saw Richard Reese's Understanding and Using C Pointers , my reaction was "What! An entire book just about pointers?". It is actually a pretty good source of information about this critical subject. At times it is a bit repetitive; in other cases I think a more detailed explanation about an example would have been helpful. C pointers are a sore subject for a lot of people. Much C code is obviously written to avoid them; those developers probably don't have a deep understanding of the subject. Competent assembly programmers know that a pointer is akin to assembly's indirection and so they figure that the C version is no big deal. But in C they are far more nuanced than when working at the mnemonic level. The book is generally well-written and accurate, though a couple of flagrant mistakes were odd, like a comment that you can make a number negative by setting the MSB. Well, yeah, that will be negative but flipping the MSB will probably not yield the desired result. The subject is completely covered, and not just in isolation. For example, there's plenty about dynamic memory use, which is, of course, a place where pointers are required. The chapters give a good sense of the material: Introduction * Dynamic Memory Management in C * Pointers and Functions * Pointers and Arrays * Pointers and Strings * Pointers and Structures * Security Issues and the Improper Use of Pointers * Odds and Ends The chapter on security is of less interest than one might think. An experienced C developer will consider the issues identified as boneheaded mistakes. These include things like dangling pointers and the like. Perhaps a novice might find this information other than obvious. The last chapter talks about memory-mapped peripherals, aliasing, and threads, and has a very good description of callbacks. The author also goes into some OO concepts in detail, showing how to implement polymorphism in C. I'm not sure what the point(er) of that is; you might as well just use C++. Experts will get little to nothing from the book. Novices will learn a lot; much more than they will get about the subject in any other C book I have read. I'd highly recommend it for them after they learn the rudiments of the language. Those at the intermediate level will surely profit from reading Reese's book, probably more than they realise. The book cries out for a set of student exercises. It's easy to read a three line example and understand the principles. Until one tests one's knowledge by writing code and struggling to remember needed syntax the lessons won't be firmly implanted in the brain. What do you think? Are you proficient with using pointers?