Breaking News
View Comments: Newest First | Oldest First | Threaded View
<<   <   Page 2 / 3   >   >>
dyson_
User Rank
Rookie
Pointers are just addresses
dyson_   4/23/2014 1:29:50 PM
NO RATINGS
Max,

Looks like you are getting some excellent help from other posters but I thought I would just chip in with my hardware oriented thoughts.

Someone may have pointed (sic) this out already but pointers in C/C++ are just memory addresses.  A pointer to a function is the address of that function in memory.  Granted, the syntax for decalring a pointer to a function can be a bit mystifying but, hey thats just syntax.

You can make a pointer point at any bit of memory (there is even a generic pointer type: void* ) That said, things can go wrong in strange ways if you mess up your pointer and read/write memory you did not intend to. (data changing unexpectedly, the dreaded segmentation voilation, etc)

If ptr is decalres as a pointer to type T you read by "dereferencing":

x = *ptr;

where x is a variable of type T

You write the memory like this:

*ptr = x; // write to memory at where "ptr" points

You set the value of the pointer (i.e. the memory address) by assigned to it like any other variable:

int *ptr; 

ptr = (int *)0x1234; // some arbitrary address that is unlikely to be vaild!

The (int *) is a "cast" which makes the expression 0x1234 be of the type int * , a pointer to int

Often harware peripherals will be mapped into the memory space so you write to their control registers by pointing to the approprate address with a pointer fo a type of the same size as the peripheral register (more correclty the space it takes up in the memory map) and writing to the memory with *ptr = <some expression>;

I could go on but I suspect the books express it better...

 - Dyson 

djohns
User Rank
Rookie
Re: Addresses and objects
djohns   4/23/2014 12:04:33 PM
NO RATINGS
(another long post, sorry)

It is usually better to put a little abstraction between the logic of your main code and the actual hardware.  What happens if you decide to make an HD version of the display and want 24 columns instead of 16? Or the neo pixs are no longer available or a hot new type becomes available, if you have built the program around a specific display you have more work changing it over. You could create a separate .cpp file for the hardware like this:

 

// pixels.cpp

#include "pixels.h"


#include "Adafruit_neopixels.h"

 


#define PixelsPerStrip 16
#define StripsPerDisplay 16;

Adafruit_NeoPixel strips[StripsPerDisplay]; // make this global to this .cpp file,but no one else!

 

int InitPixels(int& numrows,int& numcols)
{
 int Success = 0;
// init the strips here. If something goes wrong set Success to an error code


 numcols = StripsPerDisplay; // pass back parameters of the current display
 numrows = PixelsPerStrip; // assume strips are vertical and row and col are relative to the top left corner of display
 
 return Success;
}

void LightUpPixelBuffer(int row, int col, int red, int green, int blue)
{
 // map row and col to the appropriate strip and pixel in the strip and set it

}

void ShowDisplay()
{
 // signal all the strips to display their new states
 // i.e. loop through all the strips and call show() on them
}

 

in your main routine include "pixels.h" in which you declare the three routines above. Call InitPixels once at the beginning of your main routine and pass it two variables, numRows, and numCols, which it returns to you with the geometry of your display. Determine row and col from your analysis of the waveform.  You call LightUpPixelBuffer() to set the display value of a pixel.  Since it looks like neopix lets you set a bunch of them and then show them all at once, you could do the same and call ShowDisplay() after you have set all the pixels for one time frame.  When calculating which pixels to turn on, use the variables numRows, and numCols instead of hard coding in 16.


This way you could create a display of any size and not have to change the main code.  Get a new display technology? just create a new .cpp file for it and implement the three routines and you're good to go. 


One more thought, you might want a main loop that you go through at set time intervals, ie. a refresh rate,  for example, 30 times per second.  For each pass you could do your waveform calculations, set your pixels, and refresh your display, wait until time for the next loop, and repeat. 

This would let you do animations on the leds. If you kept a current value of a pixel and a target value, by changing the current value in steps until it reaches the target value, you could fade the pixels to a new color. If you define a pixel class like this it could help keep track of things better:
class Pixel
{
private:
 int thispixelsRow, thispixelsCol; // used to map to the hardware display
 int target_r, target_g, target_b;
 int current_r, current_g, current_b;
 int r_step, g_step, b_step;
public:
 SetTargetValue(int r, int g, int b, ...); // set new target value, and calculate how big the steps need to be to go from the current colors to the new target colors. Example if you calculate the step size to be one 15th of the difference between the current value and the target value, and you step 30 times a second, you get a half second dissolve


 Animate(); // call this once everytime through the main timing loop. It adds the step value to the current pixel value until current pixel is same as target

 DrawPixel(...); // draw current pixel to the device using its row and col values
};

 


In the main routine you declare an array of these Pixel classes numCols * numRows long and map it by ndx = curRow * NumCols + curCol;

Now, call set targetValue for each pixel based on your wave form, then loop through the array, call Animate() and DrawPixel().  Finally, call ShowDisplay() to blast it to the display.

JeffL_2
User Rank
CEO
Re: Here's a few other "pointers"
JeffL_2   4/23/2014 10:59:07 AM
NO RATINGS
Here's a link to a fairly small "freebie" analyzer program that has a 1/3-octave mode that you can install on your PC and have a look to get some ideas:

http://download.cnet.com/AudioAnalyser/3000-2170_4-10781338.html

(CAREFUL! If you install from this link don't "agree" to anything EXCEPT the download itself, or you may find yourself installing some rather vicious "adware" you probably DON'T want on your system.)

"Back in the day" these types of programs were called "real-time analyzers" (RTAs) and they were fairly routinely utilized to "set up" the "house" equalizers for studio monitor loudspeakers, movie or stage theater, stadium, church or concert sound applications. The "sound guy" would rig the speakers to output a "pink noise" source, then hook up a microphone on a LONG extension cord and locate it in various areas, you'd use it to "aim the horns" and such as well. I remember when the first (analog-hardware-based) handheld 1/3-octave RTA came out (I don't think the early ones even had a simple display "freeze" mode, let alone memory!), everyone was amazed you could "integrate" that much into a battery-operated small unit - now of course it would hardly be worth mentioning as a smartphone app!

Max The Magnificent
User Rank
Blogger
Re: Goertzel verses FFT
Max The Magnificent   4/23/2014 10:39:57 AM
NO RATINGS
@stwomey: If you are still pondering about frequency detection you might conceder using the Goertzel algorithm to detect the energy in the 16 bins.

I've never even heard of this. According to the Wikipedia: "For covering a full spectrum, the Goertzel algorithm has a higher order of complexity than Fast Fourier Transform (FFT) algorithms; but for computing a small number of selected frequency components, it is more numerically efficient."

But don't I want to cover the entire spectrum, in which case thsi is more complex?

But then the Wikipedia goes on to say: "The simple structure of the Goertzel algorithm makes it well suited to small processors and embedded applications."


My head hurts LOL

Max The Magnificent
User Rank
Blogger
Re: Addresses and objects
Max The Magnificent   4/23/2014 10:35:43 AM
NO RATINGS
@djohns: Perhaps an analogy might help with the pointer mystery...

Good analogy -- I think I understand the main concepts involved with regard to thinks like passing pointers to functions -- but I always say that just before things crash and burn LOL

Max The Magnificent
User Rank
Blogger
Re: An object, not a function
Max The Magnificent   4/23/2014 10:32:36 AM
NO RATINGS
@JVISOSKY000: Better would be to declare the strip array as pointers, and use the 'new' operator...

There's a 'new' operator? I really do need to learn more (well, some/any) C++. Having said this, I understand what your code is doing -- I will try this to see what happens when I compile it.

Max The Magnificent
User Rank
Blogger
Re: Here's a few other "pointers"
Max The Magnificent   4/23/2014 10:29:52 AM
NO RATINGS
@JeffL: Then again maybe I'm just a LITTLE obsessive about this stuff...

Don't be silly -- you aren't obsessive at all (LOL) -- if you have the time to chat further about this, email me at max.maxfield@ubm.com and we can set up a call.

Max The Magnificent
User Rank
Blogger
Re: Here's a few other "pointers"
Max The Magnificent   4/23/2014 10:27:49 AM
NO RATINGS
@JeffL: How is color going to be applied, there's a convention that "acceptable" levels at the bottom are green, levels above that are yellow, even higher are red, will you "go conventional" or do something out of the ordinary?

Check out my earlier blogs (including the videos) -- I want to experiment with lots of different schemes -- that's one of the things the control panel at the bottom of the display will be used for (see Part 4) -- to switch between different display modes.

Max The Magnificent
User Rank
Blogger
Re: Here's a few other "pointers"
Max The Magnificent   4/23/2014 10:24:49 AM
NO RATINGS
@JeffL: Will there be a provision to "calibrate" this so it can read actual sound levels?

I will need some way to calibrate it -- I haven't thought how yet.

 

How about a "master level" channel to one side to show the unfiltered level?

I guess I could use one of the channels for this -- the great thing about this sort of display is that you can do pretty much anything...

Max The Magnificent
User Rank
Blogger
Re: Here's a few other "pointers"
Max The Magnificent   4/23/2014 10:21:44 AM
NO RATINGS
@JeffL: Also I imagine you'll want to make this display logarithmic, with each LED representing 2 or 3 decibels higher level, and maybe even make the lower LEDs represent larger values (so the display comes closer to handling the much larger dynamic range that the ear responds to than just 32 or 48 decibels)?

I had planned on making it logarithmic on the vertical axis -- but I hadn't thought much beyond that. Any advice you can provide woudl be very gratefully accepted (my email is max.maxfield@ubm.com).

<<   <   Page 2 / 3   >   >>
Flash Poll
Radio
LATEST ARCHIVED BROADCAST
EE Times editor Junko Yoshida grills two executives --Rick Walker, senior product marketing manager for IoT and home automation for CSR, and Jim Reich, CTO and co-founder at Palatehome.
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Top Comments of the Week