Teensy 4.0 First Beta Test

Status
Not open for further replies.
Note, I've found the OLED displays are sensitive to the SPI bus speed, and different manufacturers seem to have different limits. My wavelan and newhaven displays can tolerate a 18,000,000 SPI, but the Adafruit displays I have need 12,000,000. The TFT displays aren't as problematical. It has been awhile, and I don't think I can do two OLED displays with the Teensy 3.2 but the 3.5/3.6 are fine.

For the longest while, they would not build under the Teensy unless you used the Adafruit versions of the ST7735 and GFX libraries, instead of the Teensy versions. I believe Paul has fixed this with the current release.

Here is an old thread about them:

@MichaelMeissner - @KurtE
Thanks for the warning and reference I am planning on using ST7735R's from Adafruit that I picked up on amazon: https://www.amazon.com/gp/product/B00SK6932C/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1. Going to test if it works with @KurtE's lib tomorrow.

Been working through the UncannyEyes sketch and am stuck on this right now:
Code:
      // SPI FIFO technique from Paul Stoffregen's ILI9341_t3 library:
      while(KINETISK_SPI0.SR & 0xC000); // Wait for space in FIFO
      KINETISK_SPI0.PUSHR = p | SPI_PUSHR_CTAS(1) | SPI_PUSHR_CONT;
otherwise it would have compiled. Have a joystick and photo resistor coming as well.
 
FWIW, I don't (currently) have the Beta 2 hardware. I haven't tried it with the Beta 1 (since I assume it needs to be updated). I used Teensyduino 1.47 beta 4, Arduino 1.8.8.

It is weird, I need a copy of the Adafruit_ST7735 and Adafruit_GFX libraries in my ~/Arduino/libraries directory. Teensyduino can't seem to find the version in ./libraries/TFT/src/utility/Adafruit_ST7735.h.

If you are curious, using my current source (with neopixels turned off), I get:

  • Teensy 3.2, 120Mhz, 2 TFT displays, 5.2v, 0.09a, 78 fps (this uses the ST7735 driver)
  • Teensy 3.5, 168Mhz, 2 OLED displays, 5.2v, 0.25a, 35 fps (this uses the SSD1351 driver)

Note, the power draw was using a WM34C USB power monitor, and using the highest amp power output that I noticed. The TFT display was more consistent in terms of power draw, while the OLED went all over the map.

I also did an older version with sound effects compiled into static memory and it would play a random sound in addition to doing the eyes (using the prop shield and the DAC pin). The Teensy 3.5/3.6 had 7 sounds compiled in, but the 3.2 could only manage 1 sound. Here is the post I did of this with the source. Note, this is for an older version of uncanny eyes.

I discovered in running the two tests, that I had to reset my OLED displays to 11Mhz instead of 12Mhz that I had previously used with my Teensy 3.5, running at 120Mhz or overclocked to 168Mhz. I tried reducing the 3.5 to 48Mhz, and it still had screen corruption, and eventually it would stop updating the screen. I also have a version straight from the Adafruit site that I picked up in January 2019, and I had to reduce the SPI clock speed down to 11Mhz on that version also.

I need to see if it is still a bug that the Teensy 3.2 can no longer handle OLED displays. <edit>I did try it out, and I need to reduce the 3.2 frequency to 24Mhz, and the bus frequency to 8Mhz. If the frequency was higher than 24Mhz, the display became really dim. And even with the SPI bus freqency at 8Mhz, the display kind of shimmers and has ghosting. So I will only use the OLED displays on the 3.5/3.6 (and hopefully 4.0).</edit>

I probably should also hunt up my non-Adafruit OLED displays and re-measure what SPI bus speed they need to use.

So anyway, getting back to the beta, unless mjs513 beats me to it, what libraries that have been ported to do DMA + SPI for the Teensy 4.0, that we can use as a template to modify this application? Given I currently only have the beta1 (1052) board, is that now too old to use?
 
Last edited:
@mjs513 and @MichaelMeissner - As I mentioned I may play a little adding frame buffer and asynch updates to the ST7735_t3(ST7789 library). I think all of the GFX functions funnel through a few calls within the library so should work.
Code:
      // SPI FIFO technique from Paul Stoffregen's ILI9341_t3 library:
      while(KINETISK_SPI0.SR & 0xC000); // Wait for space in FIFO
      KINETISK_SPI0.PUSHR = p | SPI_PUSHR_CTAS(1) | SPI_PUSHR_CONT;
I am assuming you already figured out this one. It is very T3.x specific. It is checking that the fifo queue is not full That is only checking the upper 2 bits of the txcntr, so only will be set when FIFO >= 4... Note only works on SPI, not on SPI1 or SPI2 as their FIFO queues are size 1... (But it is using SPI specific register).

Then the PUSHR register with CTAS(1) - So 16 bits and the Continue bit...

My T4 equivalents are in the ST7735_t3 code (T4 beta branch)
 
Although again not T4 specific, yesterday I was playing around trying to figure out how to handle memory layout differences between some different ST7735 displays...

As I just commented up on Adafruit Github:

I started playing some with this. Starting off with our own library st7735_T3 which also does st7789...

Of trying to add the setRowColStart(x, y) and make it automatically handle the setRotation calls.

Up till now been doing most of my testing using a couple of:
https://smile.amazon.com/gp/product/B00V5846YC/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Which are black and on the back are marked (1.44` SPI 128*128 V2.1) With these, with our library, to work properly in the 4 orientations, I have setup (_xstart, _ystart) used in the offsetting:
0-(0, 32), 1-(32,0), 2-(0, 0), 3-(0, 0)

A couple of days ago I received a different one: https://smile.amazon.com/gp/product/B073R6SQRY/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Red with similar marking, except V1.1

With it to work properly:
0-(2, 3), 1-(3,2), 2-(2, 1), 3-(1, 2)

Right now trying to figure out differences for Rotation 2 and 3 as to handle it. Obviously the easiest solution is to punt and if the user has a different display they could do:

Code:
tft.setRotation(2);
tft.setRowColStart(2, 1);

Wondering if maybe this different boards have the ST7735 hardware configured differently where the first one is 128x160 and the second one is 132x162 and as such offset where their actual usable area is?

Thoughts/Suggestions?
 
Just received a T4 Beta2. Can someone please point me at a post for the latest beta2 external pin ALT mappings? Thanks - not easy trawling through 141 pages of posts. (Imagine these pins will be in concrete now.)

Also, am I correct in thinking that neither GPT1 or 2 output is available on an external pin? What timer outputs are available on topside pins? I'm interested in a substitute for the FTMs of T3x.

Finally, what is the nominal peripheral/timer clock speed on 1062? Cheers...
 
@KurtE

Yep - think I figured it out this morning and did a little hacking - got it to compile and this afternoon will wire it up and give it a test.

As for your question on display resolution, i.e., "Wondering if maybe this different boards have the ST7735 hardware configured differently where the first one is 128x160 and the second one is 132x162 and as such offset where their actual usable area is?" could very well be - looking at the ST7735R and ST7735S and the basic ST7735it states the controller is 132x162 (https://www.crystalfontz.com/controllers/ST7735). So where each display starts their usable screen area is a guess I think. This might be interesting from a LCD perspective: https://www.buydisplay.com/default/...-serial-spi-128x128-lcd-display-module-st7735

EDIT: looking at the datasheet a little more:
Code:
Display Resolution 
-132 (RGB) x 162  (GM[2:0]= ”000”, DDRAM: 132 x 18-bits x 162) 
-128 (RGB) x 160  (GM[2:0]= ”011”, DDRAM: 128 x 18-bits x 160)
 
Last edited:
Just received a T4 Beta2. Can someone please point me at a post for the latest beta2 external pin ALT mappings? Thanks - not easy trawling through 141 pages of posts. (Imagine these pins will be in concrete now.)

Also, am I correct in thinking that neither GPT1 or 2 output is available on an external pin? What timer outputs are available on topside pins? I'm interested in a substitute for the FTMs of T3x.

Finally, what is the nominal peripheral/timer clock speed on 1062? Cheers...

Check out Post #3 this thread page 1 - the beta 2 1062 should match what you received. Did it come with a card in a Teensy 4 package with Teensy 4 on the bottom? - or does it have a white wire on the bottom? In any case AFAIK nothing has shipped form PJRC for some weeks that was not a modified to be like the final shipping 1062 T4 product.

It was noted yes that GPT1 is there on a bottom pad as the usable one brought out of the MCU.
 
@KurtE

Yep - think I figured it out this morning and did a little hacking - got it to compile and this afternoon will wire it up and give it a test.

As for your question on display resolution, i.e., "Wondering if maybe this different boards have the ST7735 hardware configured differently where the first one is 128x160 and the second one is 132x162 and as such offset where their actual usable area is?" could very well be - looking at the ST7735R and ST7735S and the basic ST7735it states the controller is 132x162 (https://www.crystalfontz.com/controllers/ST7735). So where each display starts their usable screen area is a guess I think. This might be interesting from a LCD perspective: https://www.buydisplay.com/default/...-serial-spi-128x128-lcd-display-module-st7735

EDIT: looking at the datasheet a little more:
Code:
Display Resolution 
-132 (RGB) x 162  (GM[2:0]= ”000”, DDRAM: 132 x 18-bits x 162) 
-128 (RGB) x 160  (GM[2:0]= ”011”, DDRAM: 128 x 18-bits x 160)

Lots of variation ...
Sounds like a display calibration app - like for TOUCH boundary map[] - except tied to USB keyboard input. Plop on boxes for locating the boundaries in 4 rotations and then spit out the needed array/table/.begin params in some fashion for setup() to sync the code to the display?
 
not easy trawling through 141 pages of posts.

Yeah, that's why messages 2 - 6 were dedicated for the most important info. As Defragster mentioned, the pinouts are on msg #3.


Also, am I correct in thinking that neither GPT1 or 2 output is available on an external pin?

While not shown on the colorful pinout card, in the table you can see pins 30 & 31 have GPT1_3 and GPT1_2. If you really need to use a GPT timer, those are the place to get the signals.

But you might consider instead using the FlexPWM timers. There are a total of 16 FlexPWM timers (4 timer modules, each with 4 timers) where each timer can create 3 signals (A, B, X).


I'm interested in a substitute for the FTMs of T3x.

For generating waveforms, definitely use the FlexPWM timers.

For internal-only delays or other special timing, maybe look at the "Quad Timer" stuff.


Finally, what is the nominal peripheral/timer clock speed on 1062? Cheers...

150 MHz. Or generally 1/4 of the CPU clock, if you change the CPU speed.

Some peripherals run asynchronously from a network of muxes and clock dividers from the 7 PLLs, or directly from the 24 MHz crystal. Those don't change as you alter the CPU speed.


In any case AFAIK nothing has shipped form PJRC for some weeks that was not a modified to be like the final shipping 1062 T4 product.

Earlier this week we sent all the remaining beta boards. Some may have arrived Wednesday, but I'd imagine most of them will show up today or this weekend. Almost all of those have PCB rev 18, with a white mod wire soldered to bottom side. Two of them have PCB rev 20, which has that wire routed on layer 4 (and some stuff moved from layer 4 to 3 to make room for that extra trace).

FWIW, the final PCB is rev 21, which is really identical to rev 20 other than the panel shape and a couple minor tweaks in the silkscreen. Our PCB vendor is behind schedule, but we did get about 10% of the PCBs last week. They're going into production on Monday. The contract manufacturer wants to do a "slow start" on this one, since it has a fine pitch BGA. Together with 90% of the PCBs still missing, this all means we still have quite a bit of uncertainty about when we'll be able to start selling.

On Wednesday we also get the first batch of printed cards. They look great. Other than very minor cosmetic fixes, like position & size of the color backgrounds under the alternate functions, and a photo of the rev 20 PCB, the pinout cards we're shipping are identical to the image on msg #3.

So at this point, the hardware absolutely is finalized, the very last of the beta hardware has shipped to beta testers, and at least some boards are going into production next week.
 
Yeah, that's why messages 2 - 6 were dedicated for the most important info. As Defragster mentioned, the pinouts are on msg #3.

...
Earlier this week we sent all the remaining beta boards. Some may have arrived Wednesday, but I'd imagine most of them will show up today or this weekend. Almost all of those have PCB rev 18, with a white mod wire soldered to bottom side. Two of them have PCB rev 20, which has that wire routed on layer 4 (and some stuff moved from layer 4 to 3 to make room for that extra trace).

FWIW, the final PCB is rev 21, which is really identical to rev 20 other than the panel shape and a couple minor tweaks in the silkscreen. Our PCB vendor is behind schedule, but we did get about 10% of the PCBs last week. They're going into production on Monday. The contract manufacturer wants to do a "slow start" on this one, since it has a fine pitch BGA. Together with 90% of the PCBs still missing, this all means we still have quite a bit of uncertainty about when we'll be able to start selling.

On Wednesday we also get the first batch of printed cards. They look great. Other than very minor cosmetic fixes, like position & size of the color backgrounds under the alternate functions, and a photo of the rev 20 PCB, the pinout cards we're shipping are identical to the image on msg #3.

So at this point, the hardware absolutely is finalized, the very last of the beta hardware has shipped to beta testers, and at least some boards are going into production next week.

Very cool for the added dozen++ 1062 T4 Boards out to those on the Beta list!

What Rev# had the final SD pad placement ?

Lots of nice helpful text on silkscreen! So many tiny components left room you made good use of. Slow start in building from the first 10% of PCB's not good for schedule - though if usable production confirmed/refined without making extra work/waste it will be good.

@TelephoneBill - opps I read that as looking for GPT input - pin 25 - yes post says output …
 
Rev 18 to 21 (all the boards using the FFC connector pads) all have exactly the same placement.
Cool so those boards represent final layout - except where white wire is inside the SMD underside area.

Is there a plan for TD 1.47 beta 5 release for those getting T4's? Any imminent signs of a new IDE release dropping during the current 1.47 beta?
 
There are a total of 16 FlexPWM timers (4 timer modules, each with 4 timers) where each timer can create 3 signals (A, B, X). For internal-only delays or other special timing, maybe look at the "Quad Timer" stuff.
So many Timers, its a job knowing where to start. I'll experiment with them all and probe the features. Maybe make a writeup later to help T4 newcomers like myself.

I notice that GPT are 32 bits length, whereas the others are all 16. With high speed counting, that could be important. Also, GPT have a choice of clock inputs (not so the others) - if the peripheral clock is 150 MHz, there is another choice called "ipg_clk_highfreq" which is intriguing.

One aspect I have yet to solve with the ref. manual is linking the Quad Timer pin functions with the pin names. Are QT1_0, QT1_2, QT1_1 (pins B0_00, B0_02, B0_01) all compare outputs? Or is there a mixture of input, capture and compare? The ref. manual not helpful calls them TMR1_TIMER0, TMR1_TIMER2, TMR1_TIMER1 on page 309.

I note that PWM pins A, B, X can be configured as outputs or inputs - but can't find words to say the same on Quad.

Gonna miss not having a GPT CAPTURE, but that's life. Maybe one for a future bigger form factor.
 
Gonna miss not having a GPT CAPTURE, but that's life. Maybe one for a future bigger form factor.

I'm pretty sure GPT capture works on T4 (1062), see https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=204630&viewfull=1#post204630
GPT2 capture 1 GPIO_AD_B1_03 pin 15 Serial3 Rx
https://github.com/manitou48/teensy4/blob/master/gpt_capture62.ino

mjs513 has some code that will print out various clock configurations
https://github.com/mjs513/WIP/tree/master/T4 helpers
 
I believe the quadrature encoders are also 32 bits. They connect to the crossbar switch, so you can route any of the XBAR pins to them.
 
I believe the quadrature encoders are also 32 bits. They connect to the crossbar switch, so you can route any of the XBAR pins to them.
Thanks both for assistance and patience with my dumbness. That IOMUX chapter is cavenous. Big change from the T3 world on muxing. Example sketches with plenty comment lines are going to be essential to keep the queries at a manageable level...
 
Thanks both for assistance and patience with my dumbness. That IOMUX chapter is cavenous. Big change from the T3 world on muxing. Example sketches with plenty comment lines are going to be essential to keep the queries at a manageable level...

Just to confuse the issue more I did get an example working for quadrature encoder. So if you want to see how xbar works with quadrature encoder you can check this: https://github.com/mjs513/WIP/tree/master/ENC1_test_xbar1
 
SPI2 and micro SD

Just received my T4B2. Tried the microSD socket with SD.h and it works with several examples.

I see that the microSD socket is connected to both SPI2 and the uSDHC controller.

I decided to test the SPI2 connection to the microSD socket.

I verified microSD pins are connected as described in the #2269 excel sheet using a SparkFun microSD sniffer.

It appears that SPI2 does not connect to the correct pins.

Here is the excel pin connection for SPI2:

Pin SPI
34 MISO
35 MOSI
36 CS
37 SCK

I looked at the SPI library and the above appears to match the code for SPI2.


This is what I expected:

Pin SD SPI

34 DAT1 NC
35 DAT0 MISO
36 CLK SCK
37 CMD MOSI
38 DAT3 CS
39 DAT2 NC

Has the microSD connection to SPI2 been tested?

I also tested SdFat with a card in the Audio Shield and it works.
 
Has the microSD connection to SPI2 been tested?

No, but I'm pretty sure it won't work. NXP didn't assign the SPI signals to the pins in a way that matches the corresponding SDIO pins. For example, SCK2 ends up in pin 37, but would need to be on pin 36. I know this could have been done better, but it's simply the way NXP designed the chip. No amount of wishful thinking or software trickery can re-wire the muxes they put into the silicon.

You can find the pinout info on msg #3.
 
T4B2 and Arduino-Teensy-Codec-lib

I have been working on getting the T4 to work with the Arduino-Teensy-Codec-lib. It uses the SD library so in an attempt to make it work with mcs I had to parallel all of the functions that did any disk access. I got to the point where it would play the the first frame of the song. After a lot of debugging I found that I was getting a 'ERR_MP3_INVALID_HUFFCODES' error code that would stop the file from playing after the first buffer was used. At first I did not get any output at all until I increased the size of 'MP3_SD_BUF_SIZE' from 2048 to 8192. The more I increased the size of the buffer the longer it would play until the first frame was finished then I would bail out with the error code, (-9).

I think it still might have something to do with file read speeds. But I could be wrong. I scrapped that attempt and I am going to try another approach.

Frank B's code is amazingly sophisticated for me and it took me along time to start to understand how it works. Mostly the software interrupt system.
Obviously I don't understand all of it.

Has anybody had this working with the SDHC card?

EDIT:
I meen the BUILTIN_SDCARD.
 
Last edited:
I have been working on getting the T4 to work with the Arduino-Teensy-Codec-lib. It uses the SD library so in an attempt to make it work with mcs I had to parallel all of the functions that did any disk access. I got to the point where it would play the the first frame of the song. After a lot of debugging I found that I was getting a 'ERR_MP3_INVALID_HUFFCODES' error code that would stop the file from playing after the first buffer was used. At first I did not get any output at all until I increased the size of 'MP3_SD_BUF_SIZE' from 2048 to 8192. The more I increased the size of the buffer the longer it would play until the first frame was finished then I would bail out with the error code, (-9).

I think it still might have something to do with file read speeds. But I could be wrong. I scrapped that attempt and I am going to try another approach.

Frank B's code is amazingly sophisticated for me and it took me along time to start to understand how it works. Mostly the software interrupt system.
Obviously I don't understand all of it.

Has anybody had this working with the SDHC card?

If its the same lib that I am thinking about the answer is yes - I got it working with the audio library and SDCard on the audio board. For ref here is the sketch:
Code:
// Requires the prop-shield
// This example code is in the public domain.

#include <string.h>

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>
#include <play_sd_mp3.h>
#include <play_sd_aac.h>
#include <play_sd_flac.h>

// GUItool: begin automatically generated code
AudioPlaySdMp3           playMp3; //xy=154,422
AudioPlaySdWav           playWav; //xy=154,422
AudioPlaySdRaw           playRaw; //xy=154,422
AudioPlaySdAac           playAac; //xy=154,422
AudioPlaySdFlac          playFlac;
AudioMixer4              mixer1;         //xy=323,326
AudioMixer4              mixer2;         //xy=323,326
AudioMixer4              mixer3;

AudioOutputI2S           audioOutput;

AudioConnection          patchCord1(playMp3, 0, mixer1, 0);
AudioConnection          patchCord2(playMp3, 1, mixer1, 1);
AudioConnection          patchCord3(playWav, 0, mixer1, 2);
AudioConnection          patchCord4(playWav, 1, mixer1, 3);
AudioConnection          patchCord5(playAac, 0, mixer2, 0);
AudioConnection          patchCord6(playAac, 1, mixer2, 1);
AudioConnection          patchCord7(playRaw, 0, mixer2, 2);
AudioConnection          patchCord8(playFlac, 0, mixer3, 0);
AudioConnection          patchCord9(playFlac, 1, mixer3, 1);
AudioConnection          patchCord10(mixer1, audioOutput);
AudioConnection          patchCord11(mixer2, audioOutput);
AudioConnection          patchCord12(mixer3, audioOutput);

AudioControlSGTL5000     sgtl5000_1;

// Use these with the Teensy 3.x Audio Shield
#define SDCARD_CS_PIN    10
#define SDCARD_MOSI_PIN  11
#define SDCARD_MISO_PIN  12
#define SDCARD_SCK_PIN   13

float volume = 0.5f;
File root, entry;

void setup() {
 
  AudioMemory(40);
  sgtl5000_1.enable();
  sgtl5000_1.volume(0.5);  
  delay(100);
  
  Serial.println("Initializing SD CARD");
  SPI.setMOSI(SDCARD_MOSI_PIN);
  SPI.setSCK(SDCARD_SCK_PIN);
  SPI.setMISO(SDCARD_MISO_PIN);
  
  if (!(SD.begin(SDCARD_CS_PIN))) {
    // stop here, but print a message repetitively
    while (1) {
      Serial.println("Unable to access the SD card");
      return;
    }
  }
  Serial.println("initialization done.");
  root = SD.open("/");

}

void playFile(const char *filename)
{
  int filetype;

  filetype = 0;
  if (strstr(filename, ".MP3") != NULL) {
      filetype = 1;
  } else if (strstr(filename, ".WAV") != NULL ) {
      filetype = 2;
  } else if (strstr(filename, ".AAC") != NULL ) {
      filetype = 3;
  } else if (strstr(filename, ".RAW") != NULL ) {
      filetype = 4;
  } else if (strstr(filename, ".FLA") != NULL ) {
      filetype = 5;
  } else
      filetype = 0;

  if (filetype > 0) {
    Serial.print("Playing file: ");
    Serial.println(filename);
    
    switch (filetype) {
      case 1 :
        mixer1.gain(0, volume);
        mixer1.gain(1, volume);
        mixer1.gain(2, 0.0f);
        mixer1.gain(3, 0.0f);
        playMp3.play(filename);
        delay(5);
        while (playMp3.isPlaying()) {
        }
        break;
      case 2 :
        mixer1.gain(0, 0.0f);
        mixer1.gain(1, 0.0f);
        mixer1.gain(2, volume);
        mixer1.gain(3, volume);
        playWav.play(filename);
        delay(5);
        while (playWav.isPlaying()) {
        }
        break;
      case 3 :
        mixer2.gain(0, volume);
        mixer2.gain(1, volume);
        mixer2.gain(2, 0.0f);
        playAac.play(filename);
        delay(5);
        while (playAac.isPlaying()) {
        }
        break;
      case 4 :
        mixer2.gain(0, 0.0f);
        mixer2.gain(1, 0.0f);
        mixer2.gain(2, volume);
        playRaw.play(filename);
        delay(5);
        while (playRaw.isPlaying()) {
        }
        break;
      case 5 :
        mixer3.gain(0, volume);
        mixer3.gain(1, volume);
        playFlac.play(filename);
        delay(5);
        while (playFlac.isPlaying()) {
        }
        break;
    }
  }
}

void loop() {
  playAll(root);
}

void playAll(File dir){
  char filename[64];
  char filnam[64];
  
   while(true) {
     entry =  dir.openNextFile();
     if (! entry) {
       // no more files
       // rewind to begining of directory and start over
       dir.rewindDirectory();
       break;
     }
     //Serial.print(entry.name());
     if (entry.isDirectory()) {
       //Serial.println("Directory/");
       //do nothing for now
       Serial.println(entry.name());
       playAll(entry);
     } else {
       // files have sizes, directories do not
       //Serial.print("\t\t");
       //Serial.println(entry.size(), DEC);
       // files have sizes, directories do not
       strcpy(filename, dir.name());
       strcat(filename, "/");
       strcat(filename, strcpy(filnam, entry.name()));
       playFile(filename);
     }
   entry.close();
 }
}
We had tested it early on and FrankB made a few changes to get it work with the T4 so hope you have the latest copy.
 
@mjs513

if its the same lib that I am thinking about the answer is yes - I got it working with the audio library and SDCard on the audio board. For ref here is the sketch:

No. Actually I meant the SDcard slot on the T4B2 breakout board.

Sorry about my bad terminology.
 
Today we mailed pinout cards to all 27 people who have the beta hardware. They're coming by ordinary postal mail, just 2 cards in an envelope.
 
@mjs513



No. Actually I meant the SDcard slot on the T4B2 breakout board.

Sorry about my bad terminology.

No never did get it working. There was a problem with the SD library and its on the msg#6 list for Paul to Check out.
 
Status
Not open for further replies.
Back
Top