D@n

You can convert PDM to PCM before the FFT or after.  That's an engineering choice.  Both will work.  Often the PCM gives you lower logic, and more headroom for the FFT--but that may require more engineering than what you are up to at present.
Try this: Simulate and verify every component individually.  Dump the outputs of the component to a text file that you can read and verify with Matlab.  Make sure you get what you want along the way.
Just as a heads up, frequency estimation is often more difficult than just taking an FFT of an incoming waveform.  I've done it.  The FFT approach was the first one I tried.  Depending on the details of the sample rate and the FFT size, you may have too many bins or not enough.  You are also very likely going to be distracted by harmonics.  If you've never "seen" the output of an FFT given real life signals, you should do that first.  It's very instructive.  The "best" way to do that is often via a scrolling raster, but ... video requires memory, often external memory, and ... that's likely to be a bit beyond a beginner's first project.  For now, perhaps you should consider capturing data and running it through the algorithm you'd like on your PC (matlab?  Octave?) to see what real-life data looks like.  Perhaps you might even wish to read audio from your computer's sound card, to get an understanding for how rich real data sets can be.  Unfortunately, that 7Segment display isn't going to give you enough feedback to know how to debug an algorithm like this, applied to so rich a data set as the real world.  You will need software help along the way.
Dan

@Ahmed Alfadhel
To understand what's going on, check out table 8 of the datasheet on page 15.  Basically, the DAC provides outputs between 0 and max, where 0 is mapped to zero and all ones is mapped to the max.  In other words, you should be plotting your data as unsigned.
To convert from your current twos complement representation to an unsigned representation where zero or idle is in the middle of the range, rather than on the far end, just toggle the MSB.
Dan

@skandigraun,
I'm not a physicist, so others might correct me here, but has I understand things audio waves are compression waves.  To "read" them, you need to create a diaphragm that will move as the compression wave moves, and then you can read the position of this diaphragm over time.  The PMic does this with a MEMS microphone.  Consider this to be the meaning of those twelve bits.
Be careful with that twelfth  bit: it is a sign bit.  You may need to extend it to the left some to understand it properly.  For example, { int v; v = (sample<<20)>>12; }.
It is possible to get volume by simply averaging the absolute values of the various samples.  While crude, the estimate should work.
Getting frequency is harder.  Doing that requires a Fourier transform.  However, sound is very often composed of many frequencies, as the attached picture shows.  In that picture, time goes from left to right, frequency from bottom to top, and energy comes out of the page.  It's taken from the opening of the Cathedral's recording of "Echoes from the Burning Bush."  The clip starts with laughter, but otherwise has speech within it.  I would particularly draw your attention to how speech has a fundamental frequency associated with it, followed by many harmonics of that same frequency--as shown in the picture.  The result is that it can be difficult to say which frequency is in use, as many are present at the same time.
One of the book's I have on my shelf is Cohen's "Time Frequency Analysis."  In it, Leon Cohen goes through and compares many algorithms for frequency evaluation.  At one time I had a paper written that proved that the Short Time Fourier Transform, among his list but widely criticized, was the *only* frequency estimation problem that preserved certain key properties of spectral energy estimation: 1) all energy values should be non-negative, 2) all frequency shifts should produce frequency shifts in the estimation, 3) time shifts should produce time shifts in the estimate, and 4) that the estimate have and achieve the "best" time-frequency resolution as measured by the uncertainty function.  Perhaps I'll find a venue for publishing it in the future.  For now, you might wish to study the discrete time Short Time Fourier Transform, which is appropriate for the data coming out of the PMic.
At one time, I tried to build a digital tuner from sampled data.  Such a tuner requires exactly what you are asking for: knowing the frequency of the incoming data.  Further, it requires the assumption that there is only one incoming frequency, even when multiple are present (as the diagram shows).  To get there, I evaluated the autocorrelation signal that I got by taking the Inverse Fourier Transform of the magnitude squared of the output of a Fourier transform, and looking for the biggest peak.  This operation, taking place in time, usually but not always found the fundamental frequency I was looking for.
One more thought: you can find forward and inverse Fourier transform code, in Verilog, here, just in case you need it. 
Hope that helps,
Dan

Just to close the discussion, and for anyone else reading, here's the command that turned character 0x01 into a backslash.  Note the required <ESC>[3p at the end:
<ESC>[0;16;8;4;2;1;0;0;1d<ESC>[3p
Dan