nrf: implement audiobusio.PDMIn

[dhalbert]

There's a separate PDM peripheral with a built-in decimation filter.

[sommersoft]

As I work through this, a couple things are becoming apparent that will need to be addressed with regards to SAMD vs nRF differences:

• nRF PDM, with its baked-in structure, requires much less setup and thereby less user configuration than SAMD. So, should I approach shared-bindings->common-hal with weak links & ignored args? Or, #ifdef accordingly? For example, SAMD takes both bit_depth and oversample kwargs during construction; nRF is 16bit only and has aforementioned decimation negating oversampling.

• Expanding on the above differences, how should the documentation be addressed in shared-bindings/audiobusio/PDMIn? The only thing I can think of is to just section it off for SAMD/nRF usage. I can't conceive of any other way, since the builds are by version not chipset.

Thoughts, wisdom, and any other comments?

[tannewt]

I usually approach this from the "Throw an exception if unsupported" tact. Not sure what you need weak links for.

If nRF is 16 bit in it should be able to do 8bit by shifting it all. That'll save recording memory.

As you get at, I wouldn't have separate documentation per chip. I'd instead make sure the docs say supported functionality may vary chip to chip.

[sommersoft]

So, I'm past RAM management hurdles; well, it doesn't error out at least.

Now on to the part I really have like no experience in. I was under the impression that with the nRF52840 PDM periph's built-in decimation, I don't need to run it through filter_sample. It should already be in PCM, but as shown below, i don't have full 16-bit samples. I started reading up on the particulars/theory on PDM, PCM, etc today so I'll keep trying to understand this side.

Here's the sample of what I'm getting at the moment: (its @tannewt talking during S&T, btw)

>>> with audiobusio.PDMIn(board.D0, board.D1) as pdm:
...     pdm.record(b, len(b))
... 
100
>>> bar = [bin(k) for k in b]
>>> bar
['0b0', '0b0', '0b1111111111111111', '0b1111111111111111', '0b1111111111111000', '0b0', 
'0b1111111111111000', '0b1111111111111111', '0b1111111111111000', '0b1111111111111111', 
'0b1111111111110001', '0b111', '0b1111111111110001', '0b1110', '0b1111111111101001', 
'0b10100', '0b1111111111011010', '0b11101', '0b1111111111010100', '0b110010', 
'0b1111111110111101', '0b1001000', '0b1111111110100000', '0b1100110', '0b1111111101111100', 
'0b10010111', '0b1111111100111100', '0b11101100', '0b1111111011000000', '0b111000001', 
'0b1111110100100000', '0b1110000111001110', '0b111100101001', '0b1111110011000101', 
'0b1001100010', '0b1111111011100000', '0b101001010', '0b1111111101100101', '0b11010110', 
'0b1111111110011010', '0b10001010', '0b1111111110110100', '0b1011011', '0b1111111110110111', 
'0b110110', '0b1111111111001111', '0b100000', '0b1111111111011001', '0b11000', 
'0b1111111111101000', '0b10001', '0b1111111111110000', '0b111', '0b1111111111101110', 
'0b1111111111111111', '0b1111111111110111', '0b1111111111111111', '0b1111111111110110', 
'0b0', '0b1111111111110111', '0b1111111111111111', '0b0', '0b0', '0b0', '0b10', '0b0', 
'0b1111111111111111', '0b1', '0b1111111111111111', '0b1111111111111111', '0b0', 
'0b1111111111111110', '0b0', '0b0', '0b1111111111111111', '0b1111111111111111', 
'0b1111111111111110', '0b1', '0b1111111111111101', '0b1', '0b0', '0b0', '0b0', 
'0b1111111111111111', '0b1', '0b0', '0b1', '0b1111111111111101', '0b1111111111111110', '0b0', 
'0b1111111111111111', '0b0', '0b1', '0b1111111111111111', '0b11', '0b1111111111100100', 
'0b1111111111111100', '0b10', '0b1111111111111111', '0b0']

[tannewt]

What does it look like if you print it as signed 16 bit numbers? It looks like its swinging around 0. (The long numbers of all ones are negative.)

[tannewt]

Fixed by #2075