Teensyduino 1.52 Beta #3

Status
Not open for further replies.
@Paul:
Wow that was fast.
Maybe it would be good to add a corresponding attribute to DMAMEM. However, this may also waste memory when DMAMEM is used for other things. You could add another #define with a smaller alignment. Technically it makes sense - just wondering if all users still understand.
But you can also specify in the linker script that the single elements are aligned, I think.


I'll check this afternoon if the audio library uses 32-Byte alignment everywhere.
Edit: On the other hand, all audio-buffers are mutiple 32-byte size, so for audio, everything should be ok, anyway..
 
Frank B said:
just wondering if all users still understand.
Click to expand...

I'm pretty sure only a very small percentage of users understand DMA.

Maybe in a glorious but distant future we'll have lots of tutorial material about using DMA. But until then, probably best to just make sure all buffers are aligned and the cache functions are used properly. Very likely most people attempting DMA will copy from existing code. That's how I start every time I do it.
 
@Paul, Yes - There is ADC code working with DMA for T4.x in ADC library. I have it setup using the object @mjs513 mentioned.

I have it using two DMASettings objects to round robbin, as the DMA Channel code with circular buffers never appear to work for me. Often times they would only use the first half, other times they appear to write into garbage areas... So I went with something that worked for me.
 
@Paul... Forgot to mention there are a couple of examples in the ADC library.

Example: adc_timer_dma.

Where I also have it setup to use one (or two) of the Quad Timers, that do not have any PWM pins connected to them, and I have the timer setup to trigger the DMA reads.

The example: adc_dma
Sets up to run the DMA as fast as it wants to go.
 
Paul, is the latest SPI library included in 1.52b3?
It fixes a timing issue.


Edit: Found it - SPI in 1.52b3 is up to date. Thanks

 
Finally, I got audio ADC input working on Teensy 4.0.

https://github.com/PaulStoffregen/Audio/commit/5d6cdd51aae14750047bb468fa3d385218de808a

The code is still very rough around the edges, as you can see from the many TODO and FIXME comments. But it is working, at least with the recently address PassThroughADCtoI2S example.

If anyone wants to look at this, the fixed DC offset is probably the most urgent part to improve. So many other things could be better too, but even with all this less than ideal stuff, it actually sounds pretty decent.

Also a huge caveat is it doesn't do update responsibility, so like USB, it only works if combined with another input or output that causes the library to update. So many things to improve, but at least it's a starting point and a better answer than "that just doesn't work on Teensy 4.0".
 
defragster said:
Also noted there (or related post) that Teensy.exe loader time set on T_4.x is "Off by one hour" for Windows users.
Click to expand...

I've changed the daylight savings (summer) time code in Teensy Loader, which affects the default time on Teensy 4 (but not Teensy 3 - which is set by Arduino's build). Hopefully 1.52-beta4 will fix it for everyone.
 
PaulStoffregen said:
I've changed the daylight savings (summer) time code in Teensy Loader, which affects the default time on Teensy 4 (but not Teensy 3 - which is set by Arduino's build). Hopefully 1.52-beta4 will fix it for everyone.
Click to expand...

Nice, in hindsight it seemed it must have been related to that as after the Teensy update to do that it always seemed 'right' - then the clocks changed … but not building for that every day that 'event' wasn't closely associated.
 
jpk said:
The problem seems to be that SPH0645 violates i2s specs.
Click to expand...

I've ordered a couple of the Adafruit SPH0645 boards from Digikey.

I previously tested I2S with INMP411, which seemed to work well.

I also tested some time ago with whatever mic "OneHorse" used to sell. But sadly, I can't seem to find those now, so difficult to know if they still work. :(
 
PaulStoffregen said:
I've changed the daylight savings (summer) time code in Teensy Loader, which affects the default time on Teensy 4 (but not Teensy 3 - which is set by Arduino's build). Hopefully 1.52-beta4 will fix it for everyone.
Click to expand...

NO…!, daylight saving times are different in US and the rest of the world, and may (hopefully) be eliminated in Europe.
(or does Teensy Loader know where it is used?)
 
WMXZ said:
NO…!, daylight saving times are different in US and the rest of the world, and may (hopefully) be eliminated in Europe.
(or does Teensy Loader know where it is used?)
Click to expand...

It seems to have been working right for IDE generated 'compile times' through the IDE.

Ideally the Teensy Loader just gets it from the OS - now adjusted for local policy for DST from the computer?
 
defragster said:
It seems to have been working right for IDE generated 'compile times' through the IDE.
Click to expand...
IFAIK, this was pre T4.0, where IDE generated a symbol with Loader link time.
On new Teensy Loader this is not controllable by IDE or User (or at least it is not transparent to me, or better, I do not know how Pauls is doing this)
 
defragster said:
Ideally the Teensy Loader just gets it from the OS
Click to expand...

Yes, that's how it was supposed to work, but wasn't. Hopefully it will now. Everyone beta testing gets to be judge of whether it's really working now (or in a matter of minutes.... I'm packaging up 1.52-beta4 now and waiting on Raspberry Pi to finish its build)
 
NEW BETA 4 for TD 1.54 released :: Teensyduino-1-52-Beta-4

PaulStoffregen said:
Yes, that's how it was supposed to work, but wasn't. Hopefully it will now. Everyone beta testing gets to be judge of whether it's really working now (or in a matter of minutes.... I'm packaging up 1.52-beta4 now and waiting on Raspberry Pi to finish its build)
Click to expand...

Confirmed it works - Time now matches PC time on Windows - and turning off PC DST Adjust uses the 'hour behind time' the PC shows.

NEW BETA 4 for TD 1.54 released :: Teensyduino-1-52-Beta-4

@WMXZ - that refer to IDE on T_3.6 was known - just added to confirm the time sent to T_3.6 was working before with 'user selected local time' - Seems Pass through Teensy Loader now does the same.
 
jpk said:
it seems to me that something in the i2s part of the audio library is broken, here is my code:
....
I use the Adafruit SPH0645 mems mic as input connected to a teensy 4 without the MCLK pin wired.
Click to expand...

Good news. I found my box of microphones and I had this exact Adafruit SPH0645. So I wired it up to a Teensy 4.0 and ran you program. It seems to work, at least as well as this microphone works anyway. Here's a quick video of the test I did.


For this test, I modified your program slightly. It prints only the first 20 bins (as much as my camera could record without taking a lot of time to set up a better recording) and I edited it to print 3 digits since the mic's levels are so low. Here's the exact code I ran in that test for the video.

Code: 
#include <Audio.h>

AudioInputI2S             input;
// AudioInputI2SQuad             input;
AudioAnalyzeFFT1024       fft;
AudioConnection           connection(input, 0, fft, 0);

void setup() {
  AudioMemory(50);
}

// copied from the fft example:
void loop() {
  float n;
  int i;

  if (fft.available()) {
    // each time new FFT data is available
    // print it all to the Arduino Serial Monitor
    Serial.print("FFT: ");
    for (i = 0; i < 20; i++) {
      n = fft.read(i);
      if (n >= 0.001) {
        Serial.print(n, 3);
        Serial.print(" ");
      } else {
        Serial.print("  --  "); // don't print "0.00"
      }
    }
    Serial.println();
  }
}

DSC_0794_web.jpg
(click for full size)

EDIT: Here is a better program which uses a high-pass filter to remove the SPH0645's strong DC output and then applies some digital gain before passing the signal into the FFT. It gives much better results.

Code: 
#include <Audio.h>

// GUItool: begin automatically generated code
AudioInputI2S            i2s1;           //xy=180,111
AudioFilterStateVariable filter1;        //xy=325,101
AudioAmplifier           amp1;           //xy=470,93
AudioAnalyzeFFT1024      fft1024_1;      //xy=616,102
AudioConnection          patchCord1(i2s1, 0, filter1, 0);
AudioConnection          patchCord2(filter1, 2, amp1, 0);
AudioConnection          patchCord3(amp1, fft1024_1);
// GUItool: end automatically generated code

void setup() {
  AudioMemory(50);
  filter1.frequency(30); // filter out DC & extremely low frequencies
  amp1.gain(8.5);        // amplify sign to useful range
}

void loop() {
  if (fft1024_1.available()) {
    // each time new FFT data is available
    // print 20 bins to the Arduino Serial Monitor
    Serial.print("FFT: ");
    for (int i = 0; i < 20; i++) {
      float n = fft1024_1.read(i);
      if (n >= 0.001) {
        Serial.print(n, 3);
        Serial.print(" ");
      } else {
        Serial.print("  --  "); // don't print "0.000"
      }
    }
    Serial.println();
  }
}

I'm going to add this as an example in the Audio library, and probably in the future more examples for each specific MEMS microphone. Hopefully that will help in the future when these sorts of issues come up.



Edit Again: I've added this to the library's examples.
https://github.com/PaulStoffregen/Audio/commit/5c5b4e80ada565b7643022ee906f55f29d92e1a6
 
Last edited:
Status
Not open for further replies.
Back
Top