Teensy 4.0 First Beta Test

[mjs513]

Tracked it down to this leftover line in the AudioStream.h.

	int16_t x;/////////////////////////////

Committed a fix on github just now.

https://github.com/PaulStoffregen/co...9bd12017bd2e07

Maybe I should make a beta9 installer to roll up all the changes?

Morning Paul.
Hope you are feeling better? Just checked Frank's version of audiostream.h and his version has that fix in it. Maybe wait a little and let us check the delta's between his imxrt.h and whats in the core then do roll up for b9?

EDIT: Ok, I must have missed something because I just checked the imxrt.h matches what Frank has, no dups and the define that is in file is there. I am creating a PR to update the audiostream files: Update to Audiostream files #351

[KurtE]

Kurt,
OK commenting out debug stuff got simple sketch running. I still get errors requesting SPI CLK of 15mhz with flex clock @30mhz. no errors for slower SPI CLK speedsl

Updated Flex IO speed: 30000000
SPIHZ 15000000
547 us 15.0 mbs
errs 1023 [3] 1
0  0 0
1  1 0
2  2 129
3  3 1
4  4 130
500  244 250
501  245 122
502  246 251
503  247 123
504  248 252
1020  252 254
1021  253 126
1022  254 255
1023  255 127

scope shows pin 4 running at 14.7 mhz

FYI - I just pushed up a different implementation of the SPIFlex(buf, retbuf, cnt), that may work differently. At least it is not hanging on my test program.
I put the reads and writes more in lock step, that is it:
puts first char out, waits until it can put second char out does write, waits until it can read something, reads it in, waits for wri.... until the end when it waits to read in the last two chars...

Also pushed up fix that internal to the transfer function it was using an uint16_t for count where I might pass in > 64K....

I had test program do: SPIFLEX.flexIOHandler()->setClockSettings(3, 2, 0); // clksel(0-3PLL4, Pll3 PFD2 PLL5, *PLL3_sw)

Which should give the Flex IO speed of 480000000U/(3) = 160mhz
If I ask for 30mhz I am getting about 25mhz.

I need to play around some more but you might give it a try. I am seeing some interesting stuff with the DMA version and my SPI pin (which is not controlled by FlexIO).
You see normal stuff:


But if I look at the DMA output:
You see a jitter going the CS pin.



That is the test code does stuff like:

  digitalWriteFast(CS_PIN, LOW);
  SPIT.transfer(buffer, rxBuffer, SMALL_TRANSFER_SIZE, event);
...
void asyncEventResponder(EventResponderRef event_responder)
{
  digitalWriteFast(CS_PIN, HIGH);
  event_happened = true;
}

The Async code should have setup the TX/RX transfers up to 32K and when the ISR happens if the request was for more than 32K it should restart the DMA and only after all that has completed should the event responder be called... But in this case the transfer size was 128...

EDIT: Should mention that I don't see the CS pin output being corrupted like this if I remove the call: SPIFLEX.flexIOHandler()->setClockSettings(3, 2, 0)
So left the FLex bus running at : 480000000U/(2*8) = 30mhz

Edit2: Looks like I need to do a little more testing/updates, that is my dual display SSD1306 is hanging when I do the Flex display update along with the SPI doing Async update... Will try some more hacks here...

[KurtE]

FlexIO SPI Transfer update

I think I have now removed the total hang. The code now looks at the SHIFTERR register, which will be set if we do get an overrun and lose a character. So it won't loop any longer...

In my case it does not matter in SSD1306 as I don't need the return values.

Next up try try SSD1306 update async as well...

[Frank B]

@Paul,

I think,I need help here..
I can't find the problem with the i2s-input.

[mjs513]

@Paul,

I think,I need help here..
I can't find the problem with the i2s-input.

Been playing with it since last night and just can't see it. Update is getting called - connections look like they are getting made (did a bunch of prints) but could figure out where the linkage goes between i2s1 rx and i2s2 tx - assuming that is the connection.

[KurtE]

Again probably not it, but everytime I see something like I can not get input X to work... Now I assume that maybe that signal is routed to multiple pins and you need to choose the right one in the Select Input Dairy registers...

For example the pin 7 (1:RX_DATA) is pin B1_00

Again I have not double checked the actual Audio subsystem names: but for example if you look at pages 874-875,
you see: (IOMUXC_SAI1_RX_DATA0_SELECT_INPUT and if this is the right system and pin, it looks like this register would need to be set to 2 to choose this pin...

[Frank B]

Kurt!
Genious! that was it! :-)
works now.

[mjs513]

Kurt!
Genious! that was it! :-)
works now.

Kurt.
Never even thought of that even though I've been playing with pin config constantly with encoder and flexcan. I will double what Frank said, you are a GENIUS.

EDIT: One quick line has it working:

IOMUXC_SAI1_RX_DATA0_SELECT_INPUT =2;

Hit me over the head with something. Yes it works.

[Frank B]

https://github.com/PaulStoffregen/Audio/pull/279

I'll delete my copy audio_imxrt now, since Paul have merged it - (a little bit too early, but ok) ..

[mjs513]

https://github.com/PaulStoffregen/Audio/pull/279

I'll delete my copy audio_imxrt now, since Paul have merged it - (a little bit too early, but ok) ..

Frank.
For i2s_slave aren't the changes going to be pretty close what you did for master. Was just looking at - is there an example to try test against?

EDIT: Based on Paul's comment about "const" vs "progmem", do we still want to update examples to "progmem"

[Frank B]

Frank.
For i2s_slave aren't the changes going to be pretty close what you did for master. Was just looking at - is there an example to try test against?

EDIT: Based on Paul's comment about "const" vs "progmem", do we still want to update examples to "progmem"

I tried the microphone sketch form the tutorial - but this requires a: microphone

Were the data does not fit into the DTCM: Yes, of course
Others: Don't know.. due to their nature "Example" - I'd say yes, too.. what do YOU think?

[mjs513]

I tried the microphone sketch form the tutorial - but this requires a: microphone

Were the data does not fit into the DTCM: Yes, of course
Others: Don't know.. due to their nature "Example" - I'd say yes, too.. what do YOU think?

I can tell you the tutorial example works with the mic - I put one on mine along with the pot. It does work once we put Kurt's fix in Forgot about your shield

Easy enough to put it into progmem especially for the large wavetables. I will go through them and add them later - need to go take my afternoon nap - I have to stop getting up so early.

[KurtE]

Glad that worked!

I have been bit a few times by it, so when all else fails...

[Frank B]

@mjs, sleep well ..

Added 2nd I2S Output - with our breakout, we can use the switch to switch anytime, even when it's playing, between both outputs (- edit: You need to add 2 more "patchcords" to the new output) "AudioOutputI2S2"

Good night. I'll go sleeping a bit earlier today, too..


https://github.com/PaulStoffregen/Au...d90ace917dec96

[KurtE]

FlexIO and SPI and SSD1306 - testing...

I had not yet done any testing using Flex IO pin the unit 2:...
Also I had not updated my SSD1306 test library to allow the Async updates on the Flex SPI, yet...

So I decided to hack up the Multiple display test program as I have a few more of the displays sitting around from the T3.5/6 beta days...
So hooked up a third display this one was a 64 pixel high one...

Then hacked up the animation test, to work with all three displays and try to have them run reasonably independent of each other and update using DMA SPI...

That is the function looks like:

typedef struct  {
  int8_t x;
  int8_t y;
  int8_t deltaY;
} star_positions;

void testanimate(const uint8_t *bitmap, uint8_t w, uint8_t h) {
  int8_t f;
  star_positions icons[NUMFLAKES][ NUM_DISPLAYS];
  uint32_t loop_count[NUM_DISPLAYS];
  uint8_t iDisplay;
  for (iDisplay = 0; iDisplay < NUM_DISPLAYS; iDisplay++) {
    SSD1306_FlexIO *pdisp = display_list[iDisplay];
    // Initialize 'snowflake' positions
    Serial.printf("Display %d\n", iDisplay);
    for (f = 0; f < NUMFLAKES; f++) {
      icons[f][iDisplay].x   = random(1 - LOGO_WIDTH, pdisp->width());
      icons[f][iDisplay].y   = -LOGO_HEIGHT;
      icons[f][iDisplay].deltaY = random(1, 6);
      Serial.print(F("x: "));
      Serial.print(icons[f][iDisplay].x, DEC);
      Serial.print(F(" y: "));
      Serial.print(icons[f][iDisplay].y, DEC);
      Serial.print(F(" dy: "));
      Serial.println(icons[f][iDisplay].deltaY, DEC);
    }
    loop_count[iDisplay] = 0;
    pdisp->setTextSize(2);      // Normal 1:1 pixel scale
    pdisp->setTextColor(WHITE); // Draw white text
  }

  // Main loop
  for (;;) { // Loop forever...
    for (iDisplay = 0; iDisplay < NUM_DISPLAYS; iDisplay++) {
      SSD1306_FlexIO *pdisp = display_list[iDisplay];
      if (!pdisp->displayAsyncActive()) {
        pdisp->clearDisplay();
        // Draw each snowflake:
        for (f = 0; f < NUMFLAKES; f++) {
          pdisp->drawBitmap(icons[f][iDisplay].x, icons[f][iDisplay].y, bitmap, w, h, WHITE);
        }
        loop_count[iDisplay]++;
        pdisp->setCursor(0, 0);     // Start at top-left corner
        pdisp->print(loop_count[iDisplay], DEC);
        pdisp->displayAsync(); // Show the display buffer on the screen

        // Then update coordinates of each flake...
        for (f = 0; f < NUMFLAKES; f++) {
          icons[f][iDisplay].y += icons[f][iDisplay].deltaY;
          // If snowflake is off the bottom of the screen...
          if (icons[f][iDisplay].y >= pdisp->height()) {
            // Reinitialize to a random position, just off the top
            icons[f][iDisplay].x   = random(1 - LOGO_WIDTH, pdisp->width());
            icons[f][iDisplay].y   = -LOGO_HEIGHT;
            icons[f][iDisplay].deltaY = random(1, 6);
          }
        }
      }
    }
  }
}

All three displays have been running pretty well:

After maybe half an hour the larger 3rd display has hung... I think it is still updating, but the controller got confused. I remember similar things happened with the earlier tests as well. Probably flaky display/too long of wires...

Edit: In case anyone is interested, I had to pull out my older Saleae Logic 16, to trace all three SPI conversations. Not nearly as fast as the Pro, but does come in handy for things like this

[mjs513]

Audio with sdcard

Just tried the WavFilePlayer example. I put SDTEST1.wav on the card but nothing being played. For the card on the audioshield:

#define SDCARD_CS_PIN    10
#define SDCARD_MOSI_PIN  7
#define SDCARD_SCK_PIN   14

When the sketch starts it is showing 11,12, 13 for SPI pins. The sketch does have setMOSI, setMISO, and setCLK but looking SPI.cpp, it just does a return so new pins can't get set.

So I guess this will have to go on the to do list

EDIT: It could be something else as well - but guess one thing at a time. Not sure if the breakout board rewired the SPI connections on the shield to use 11/12/13. But then - I haven't checked if those pins will support spi? Have company now - so have to stop.

[defragster]

Mike - IIRC T4 pin 13 hits the Audio board pin 14 by PCB wiring - software would use #define SDCARD_SCK_PIN 13

[mjs513]

Mike - IIRC T4 pin 13 hits the Audio board pin 14 by PCB wiring - software would use #define SDCARD_SCK_PIN 13

Yep. I decided to run sd card listfiles example to verify it was 11, 12, 13 and sure it enough it listed the single file I have on the card:

Initializing SD card...SPI MISO: 12 MOSI: 11, SCK: 13
SPI MISO: 12 MOSI: 11, SCK: 13
initialization done.
SYSTEM~1/
	INDEXE~1		76
SDTEST1.WAV		16787550
done!

and I can see the clk on the scope. Unfortunately when I run the simpleplayer example I don't see the clock even with the correct pins set. So now time for some debugging

[defragster]

Did you remove the DAC from simpleplayer example? AudioOutputAnalog dac; // play to both I2S audio board and on-chip DAC

Not sure if that would cause trouble?

[mjs513]

Did you remove the DAC from simpleplayer example? AudioOutputAnalog dac; // play to both I2S audio board and on-chip DAC

Not sure if that would cause trouble?

Hey Tim. My fault - told you the wrong file I was using - I actually testing with WavFilePlayer. Sorry for the confusion. What perplexes me the most is that I don't see the SPI clk on the audioshield when I run the example. So have to trace the calls and make sure there ae #if 0's laying around.

EDIT:
Frank/Tim
Uncommented some of debug prints:

Playing file: SDTEST1.WAV
AudioPlaySdWav consume, size = 512, buffer_offset = 0, data_length = 20, space = 256, state = 8
unknown WAV header

Think I ran into this once before and can't remember why.


EDIT2: Ok not the audio library. I placed two other files that I had that I used with the propshield.Only 1 of the files played. The one from 2001 where HAL says "There are some extremely odd things about this mission". Kind of appropriate

[PaulStoffregen]

@Kurt - Do you have flexio changes for imxrt.h? Please send a pull request when you're ready.

I started working on USB host. It compiles and faults. Will work on it more tonight, and if I get it to enumerate any device, will package up a beta9 installer. Or without USB host working, probably beta9 Wednesday evening.

[KurtE]

@Kurt - Do you have flexio changes for imxrt.h? Please send a pull request when you're ready.

Thanks, I put the structure into imxrt.h, which is in: https://github.com/PaulStoffregen/cores/pull/353

I updated the flexio_t4 library to check if structure was already defined, else it will define.

At some point may see if we want more of this library code as part of release...

[defragster]

Kurt - you might want to pull the updated Audio from PJRC github - I got Frank's RAW directory to build Audio - with that and your copy of FlexIO stuff I'm not sure my system is legit, but going back to the SD1306 example I got warned about PROGMEM redefine?

T:\arduino-1.8.8T4_146\hardware\teensy\avr\libraries\Adafruit _GFX\glcdfont.c:13:0: warning: "PROGMEM" redefined
#define PROGMEM

and
T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4/avr/pgmspace.h:28:0: note: this is the location of the previous definition
#define PROGMEM __attribute__((section(".progmem")))

I suspect that is a real issue that needs to be put under #ifdef IMXRT - or maybe a more generic #ifndef PROGMEM ???

[KurtE]

I have seen that as well. I have not touched the adafruit gfx library, but looks like we need to as it appears like on the T4 it may have a new meaning?

[MichaelMeissner]

I have seen that as well. I have not touched the adafruit gfx library, but looks like we need to as it appears like on the T4 it may have a new meaning?

Note, at least with the 1.45 release, the Teensydunio version of Adafruit_GFX is out of date compared to the Adafruit version (at least 6 months out of date). The teensy Adafruit_ST7735 library is seriously back level (several years). I'm not sure what we should do about ST7735, but GFX probably should be updated at some point.

The file in Adafruit_GFX does:

#ifdef __AVR__
 #include <avr/io.h>
 #include <avr/pgmspace.h>
#elif defined(ESP8266)
 #include <pgmspace.h>
#else
 #define PROGMEM
#endif