Forum Rule: Always post complete source code & details to reproduce any issue!
Page 146 of 175 FirstFirst ... 46 96 136 144 145 146 147 148 156 ... LastLast
Results 3,626 to 3,650 of 4361

Thread: Teensy 4.0 First Beta Test

  1. #3626
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,171
    Thanks Frank. That works with the demo wavfileplayer but not with my code so I have some digging to do.

    Pete

  2. #3627
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,397
    Quote Originally Posted by Jean-Marc View Post
    I Is there a way to use usdfs with build-in sd interface?
    uSDFS is basically based on FatFS which provides a lower-level API and is written in plain C.
    Adsing a SD-style API is possible, but is it needed?

  3. #3628
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,357
    Quote Originally Posted by KurtE View Post
    Hi @MichaelMeissner - Are you trying T4 using something like breadboard or using Paul's breakout? With Paul's breakout getting some of those specific pins as many of the signals are not routed to the socket you plug the Audio board into... But I think all of those are brought out...
    CS - A8 - ??? Not sure?
    DC - A1 - You can use the RX pin on the Serial3 connection
    Reset A0 - You can use the TX pin on Serial 3 connection
    SCLK does route to pin marked SCK on Audio connection
    MOSI 11 routes to MOSI (different location but labeled)

    Since I have not yet done the PR: I added your suggestion for #ifndef SPICLOCK

    Pushed it up...

    Note: I hacked my copy yesterday and the display appeared to work at 25mhz SPI speed. Although Spec almost looks like it should work at 4mhz?
    Yes, after testing the pins, I settled on CS=10, DC=15, RESET=18, MOSI=11 (but using pin #7 on the board, due to sound card using alt. MOSI), and SCLK=13 (but using pin #14). The two simple demo programs worked.

  4. #3629
    Quote Originally Posted by wwatson View Post
    Yes there is a way to use the built in SDHC card slot with uSDFS. If you look in the examples directory of uSDFS you will find several examples that give you the option to mount SPI, SDHC, USB or all three. Check out lines 5-13 of 'uSDFS_test.ino' for example:
    Code:
    #define TEST_DRV 2
    //
    #if TEST_DRV == 0
      const char *Dev = "0:/";  // SPI
    #elif TEST_DRV == 1
      const char *Dev = "1:/";  // SDHC
    #elif TEST_DRV == 2
      const char *Dev = "2:/";  // USB
    #endif
    If you define 'TEST_DRV' as 1 uSDFS will mount and change to the built in SDHC card slot. If you check further down the example you will see where 'Dev' is used in those operations.
    I have used all three at the same time successfully when copying files.

    I hope I understood your question correctly.

    Will checkout your Github site. Sounds real interesting.

    EDIT:
    I have been wanting to try out your emulators for a long time now. Just lost site of it

    In 'teensysync.ino' I see you are using Sdfat and uSDFS together. You might try using uSDFS for both:
    Code:
      if((rc = f_mount (&fatfs, SDpath, 1))) { 
        emu_printf("f_mount() for USB MSC  failed");
      }
    Code:
      if((rc = f_mount (&fatfs1, USBpath, 1))) { 
        emu_printf("f_mount() for USB MSC  failed");
      }
    USBpath = "2:/" and SDpath = "1:/".

    Of course all I/O ref's to SDFat would have to change to FatFS I/O op's.
    Not sure if SDFat and uSDFS play well together.
    Thanks, I had noticed that you could also use uSDFS with the SD card but when I tried it was not working. May be it is because of my card. I use to format it Fat on the Mac. I will try again when I am back from holiday. USDFS is a better choice anyhow, also it handles long name so I will move all emulators code to it. I used SDFat on the T3.6 in the past, it is because I used initially the SPI SD of the ILI display that I had moved to SD. If uSDFS does it all and work also on the T3.6, I will use it, it is a nice piece. Good work!

  5. #3630
    If someone wants to try the emulators on the T4, use teensyMCUME on https://github.com/Jean-MarcHarvengt
    Pinout file is included. For more details, use the doc in espMCUME. At the exception of teensyvectrex, the rest works on the t4b2

  6. #3631
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,059
    Paul: I've been (begrudgingly) using TeensyLoader instead of TyCommander for upload. It has been working well enough - maybe because it has been easy enough to just Button push the right device for upload. Though TyComm(ander) for multi SerMon is my only other terminal program when viewing multiple Teensy's - which is typical.

    Programming a T4B2 today I turned it off long enough it seems for the IDE to autoswitch to a T_3.5 that happened to be plugged in? So when I turned the T4 back on and hit IDE upload I got the 'Wrong MCU' kraap from TLoader and powering down the T_3.5 was the easy way to get back to work.

    Not sure if I did anything to inspire that - other than turning off the T4?

    <edit>: perhaps since IDE/TeensyPorts knows the Teensy device list - if it could see the selected Teensy didn't match the Type/Boards - maybe it could pop up a selection dialog or something better?

  7. #3632
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,270
    @KurtE
    SSD1351: So far just one:https://smile.amazon.com/gp/product/B01HHPOD44/


    And @mjs513 ...
    Talking about the OLED. I hacked up the uncannyEyes and have it working with the st7735 library in 16 bit color mode...
    And have it sort of working for just one eye. Don't see any way without mods to do some of the sendCommands... Could maybe add to his library...

    But With this hacked up version, it is now updating the eye at about 55 frames per second
    Did receive my 1351 yesterday afternoon but as you know was distracted with getting that other display working with the T4. So finally hooked it up and ran the simpletest and indexcolors sketches and didn't see any problems. Ran out of the box. The only thing I modified in indexcolors was to add a delay(200) when it went through the colors - otherwise it just flashed the screen so fast couldn't see what was happening.

    I also gave your hacked up version of UncannyEyes a try and that worked out of the box as well - again only tested one screen as you said. Too bad two eyes for the 1351 will take a bit of hacking to get it work. You know me - never did mind to add to the libraries

  8. #3633
    Senior Member
    Join Date
    Aug 2017
    Posts
    146
    Quote Originally Posted by Jean-Marc View Post
    Thanks, I had noticed that you could also use uSDFS with the SD card but when I tried it was not working. May be it is because of my card. I use to format it Fat on the Mac. I will try again when I am back from holiday. USDFS is a better choice anyhow, also it handles long name so I will move all emulators code to it. I used SDFat on the T3.6 in the past, it is because I used initially the SPI SD of the ILI display that I had moved to SD. If uSDFS does it all and work also on the T3.6, I will use it, it is a nice piece. Good work!
    The credit for uSDFS goes to @WMXZ. I agree it is a great piece of work. Very easy to understand and use.

  9. #3634
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,690
    Quote Originally Posted by mjs513 View Post
    @KurtE
    Did receive my 1351 yesterday afternoon but as you know was distracted with getting that other display working with the T4. So finally hooked it up and ran the simpletest and indexcolors sketches and didn't see any problems. Ran out of the box. The only thing I modified in indexcolors was to add a delay(200) when it went through the colors - otherwise it just flashed the screen so fast couldn't see what was happening.

    I also gave your hacked up version of UncannyEyes a try and that worked out of the box as well - again only tested one screen as you said. Too bad two eyes for the 1351 will take a bit of hacking to get it work. You know me - never did mind to add to the libraries
    Yep - OK, I think things are far working well enough with the library so I did to a Pull Request: https://github.com/kirberich/teensy_ssd1351/pull/1
    Now to mark up message on first page.

    I was/am tempted to order 2nd one to try out two eyes, but figure I have enough distractions (for now)

  10. #3635
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,357
    Quote Originally Posted by KurtE View Post
    Yep - OK, I think things are far working well enough with the library so I did to a Pull Request: https://github.com/kirberich/teensy_ssd1351/pull/1
    Now to mark up message on first page.

    I was/am tempted to order 2nd one to try out two eyes, but figure I have enough distractions (for now)
    Now, that I'm slowly learning bits and pieces of the Teensy 4.0, and that we don't seem to have accelerated support for more than one CS, I'm wondering for the uncanny eyes, whether we would have separate CS pins. I.e. we would use pin 10 as the 'CS' pin for the SPI calls, but we would connect up two other pins, one to each of the displays CS pin, and manually set that other two pin when we are switching eyes. Obviously we would have to what for the I/O to drain out before doing this switch.

    Or just use two different SPI buses.

    I haven't yet looked at modifications to uncanny eyes for Teensy 4.0.

    I'm getting kind of tired of the standard Arduino libraries assuming you only have one i2c port and one SPI port, and the standard calls only use that port. I realize why it is, but it would be nice if the base code were updated to know that more than one bus is possible.

  11. #3636
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,357

    Cool Updated google table comparing Teensy 3.0, 3.1/3.2, 3.5, 3.6, and 4.0 processors

    I have gone through the pinout card, and I have added the basic's for the Teensy 4.0 to my large google document comparing the pinouts of the Teeny 3.0, 3.1/3.2, 3.5, 3.6, LC, and now 4.0. I still need to fill in the overall summary for the Teensy 4.0:



    Let me know of ways to improve the document.

  12. #3637
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,690
    @MichaelMeissner - Yes with the T4, the CS pins are very different than T3.x, which for many of our drivers like the ili9341_t3 library, the main speedup is the ability to keep the queue active while the DC state changes. That is when you draw a pixel, there is data output sort of like:
    <DC LOW>0x2a<DC HIGH>X 16 bits, X 16 bits<DC LOW>0x2b<DC HIGH>Y 16 bits, Y 16 bits<DC LOW>0x2c<DC HIGH>color 16 bits
    Note: most of the time CS is asserted at the start of this and unasserted at the end of this. Most of the time even with hardware CS we wait until completion before doing the end transaction...

    So using two different non hardware pins for CS for uncannyEyes probably does not hurt much...

    And I am totally with you on wishing most libraries would support (somehow different SPI busses). Which is one of the differences between ili9341_t3 library and ili9341_t3n... Where I added support for multiple SPI busses, at the time to test the T3.6 during beta... Put all of the stuff into SPIN library to make it easier. But then most of that I was able to pull back into SPI library. Note: With ili9341_t3n I put in support for not having CS on hardware CS as on T3.6 SPI1 only had one CS pin...

    Note with my update to st7735_t3 library to support T4, I put in back door support for different SPI busses. How I did it in this case was to see if the pins passed in
    That is in the commonInit I do:
    Code:
    	if (SPI.pinIsMOSI(_sid) && SPI.pinIsSCK(_sclk) && SPI.pinIsChipSelect(_rs)) {
     		<Setup for SPI>
        #if  defined(__MK64FX512__) || defined(__MK66FX1M0__)
    	} else if (SPI1.pinIsMOSI(_sid) && SPI1.pinIsSCK(_sclk) && SPI1.pinIsChipSelect(_rs)) {
    	       <Setup for SPI1>
     	} else if (SPI2.pinIsMOSI(_sid) && SPI2.pinIsSCK(_sclk) && SPI2.pinIsChipSelect(_rs)) {
    	       <Setup for SPI2>
    	} else {
    	       <Setup for bitbang>
    }
    In the T4 part I don't require hardware pin chip select...

    In the earlier versions of ili9341_t3n, I instead had you pass in which SPIN object (SPI wrapper) to use, but internally now, that is optional as I do like above.

  13. #3638
    Senior Member
    Join Date
    Mar 2015
    Location
    UK
    Posts
    301

    GPT Timer Interrupt Behaviour

    Interesting experience whilst experimenting with GPT1 and GPT2 today. Using the 150 MHz clock, I wrote a simple test to use GPT1 Compare1 to generate an interrupt every second. In the ISR, I reset the specific Status Register bit OF1 as the first job inside the ISR, followed by a blink of the LED. It worked fine. Same behaviour with GPT2 using Compare1.

    But when I tried to do the same for Compare2, or Compare3 - still resetting the specific associated Status Register bit (OF2 or OF3) inside the ISR - then both would fail for GPT1 or GPT2. Even unplugging the T4 USB to get a hard reset still failed on restarting T4.

    After puzzling this over for a while, I tried writing a '1' to all three OF1,OF2,OF3 at once in the Status Register (even though I was only enabling one interrupt at a time). To my surprise, this now worked with Compare2 and with Compare3. So I now write '3F' to the Status Register in the ISR to reset all the potential interrupts, even though only one interrupt is enabled at any one time.

    I presume that writing to the SR is the correct way to reset the flags inside the ISR? But it was curious that writing to specific bits worked with Compare1 but not the other two. This is probably something to do with the fact they are all "ORed" together for the NVIC table.

  14. #3639
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,235
    Quote Originally Posted by WMXZ View Post
    updated GitHub
    Only to make sure, what I have here is
    running uSDFS_test on T4b2 with
    - TEST_DRV=0 and uSD card in AudioCard: works fine
    ? uSDFS SPI problems with uSD on audio shield T4B2R

    I fetched the latest uSDFS and MSC from github and am running 1.8.8 1.47-beta4 on T4B2R. I modified uSDFS example to just do directory listing. Listing works with on-board uSD and listing works on USB thumbdrive, but fails for uSD on audio shield on T4B2R breakout.
    Code:
    Test uSDFS
    0:/
    Mount: Failed with rc=FR_DISK_ERR.
    SD lib's listfiles works on audio shield uSD on T4B2R.

    EDIT: also tested on T3.6 (ye ol acrylic K66 beta). on-board SDHC uSD worked and USB thumb drive worked, but uSD on audio shield failed as on T4. Also SdFat_Beta works with T4 audio shield uSD (SPI).
    Last edited by manitou; 07-12-2019 at 08:19 PM.

  15. #3640
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,235
    Quote Originally Posted by TelephoneBill View Post
    Interesting experience whilst experimenting with GPT1 and GPT2 today. Using the 150 MHz clock, I wrote a simple test to use GPT1 Compare1 to generate an interrupt every second. In the ISR, I reset the specific Status Register bit OF1 as the first job inside the ISR, followed by a blink of the LED. It worked fine. Same behaviour with GPT2 using Compare1.

    But when I tried to do the same for Compare2, or Compare3 - still resetting the specific associated Status Register bit (OF2 or OF3) inside the ISR - then both would fail for GPT1 or GPT2. Even unplugging the T4 USB to get a hard reset still failed on restarting T4.

    After puzzling this over for a while, I tried writing a '1' to all three OF1,OF2,OF3 at once in the Status Register (even though I was only enabling one interrupt at a time). To my surprise, this now worked with Compare2 and with Compare3. So I now write '3F' to the Status Register in the ISR to reset all the potential interrupts, even though only one interrupt is enabled at any one time.

    I presume that writing to the SR is the correct way to reset the flags inside the ISR? But it was curious that writing to specific bits worked with Compare1 but not the other two. This is probably something to do with the fact they are all "ORed" together for the NVIC table.
    T4 ISR's are finicky, are you using asm volatile ("dsb") in your ISR? (or spinning til flag is cleared)

    https://github.com/manitou48/teensy4...er/gpt_isr.ino
    Last edited by manitou; 07-11-2019 at 06:46 PM.

  16. #3641
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by el_supremo View Post
    Thanks Frank. That works with the demo wavfileplayer but not with my code so I have some digging to do.

    Pete
    Pete, the new code is supposed to work the same way (just translated to the new hardware). If you find the reason, I'd be interested to know why it didn't work! Maybe we need to pay more attention when doing that (changing sample-freq) on T4?

  17. #3642
    Senior Member
    Join Date
    Mar 2015
    Location
    UK
    Posts
    301
    I have not used "DSB", but will give it a try. Thanks for your reference - useful to see how someone else does it.

    I think the Compare1, 2 and 3 are completely independant of each other in their actions. If so, have you tried using either Compare2 or Compare3 on their own? I would be interested to hear your results. My experience earlier is getting even more complicated, for using Compare2 or Compare3 on their own has not worked out quite as I expected. I did a bit more work after the post and realised I'm getting weird results. Maybe "DSB" can resolve things. Will see...

  18. #3643
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,059
    Startup Hooks with code as noted in post #3576 edited into startup.c

    Made a Pull Request for startup change of p#3576: github.com/PaulStoffregen/cores/pull/385

    Discovered that the EarlyHook can do pinMode and digitalWrite[Fast] under 1,300 MicroSeconds after the Teensy 4 clock starts.
    Code:
    Compile Time:: T:\tCode\T4\ShowTime\ShowTime.ino Jul 11 2019 09:48:14
    
    Start setup():: E_HOOK us>>1295 [ii3#>>1] E_hook millis is 1
    Start setup():: L_HOOK us>>45341 [ii2#>>5] L_hook millis is 45
    Start setup():: @us>>300001 [static ii ms>>300] setup millis is 300
    @micros>>687016 [ms>>687] Time is Thu Jul 11 11:58:21 2019
    
    @micros>>10963612 [ms>>10963] Time is Thu Jul 11 11:58:21 2019
    This is the code in the sketch - uses some global variables that are set to record time and use in the _hooks and then printed when Serial comes online:
    Code:
    #include <time.h>
    time_t tt;
    uint32_t  jj, kk, ii = millis();
    uint32_t  jj2, kk2, ii2 = 1;
    uint32_t  jj3, kk3, ii3 = 2;
    elapsedMillis ems = 0;
    
    #ifdef __cplusplus
    extern "C" {
    #endif
    PROGMEM void startup_early_hook(void) {
    	pinMode( LED_BUILTIN, OUTPUT);
    	digitalWriteFast( LED_BUILTIN, HIGH );
    	delayMicroseconds(10);
    	delayNanoseconds(10);
    	jj3 = micros();
    	kk3 = millis();
    	ii3--; // prints 1 in setup
    }
    
    PROGMEM void startup_late_hook(void) {
    	jj2 = micros();
    	kk2 = millis();
    	delay( 100 );
    	while (millis() < 280) {
    		if ( ems > 40 ) {
    			ems = 0;
    			ii2++;
    			digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN ) );
    		}
    	}
    }
    #ifdef __cplusplus
    } // extern "C"
    #endif
    
    void setup() {
    	jj = micros();
    	kk = millis();
    	while (millis() < 300) {
    		if ( ems > 20 ) {
    			ems = 0;
    			digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN ) );
    		}
    	}
    	Serial.begin(115200);
    	while (!Serial && millis() < 4000 );
    	Serial.println("Compile Time:: " __FILE__ " " __DATE__ " " __TIME__);
    	tt = rtc_get();
    	Serial.printf("\nStart setup():: E_HOOK us>>%u [ii3#>>%u] E_hook millis is %u", jj3, ii3, kk3);
    	Serial.printf("\nStart setup():: L_HOOK us>>%u [ii2#>>%u] L_hook millis is %u", jj2, ii2, kk2);
    	Serial.printf("\nStart setup():: @us>>%u [static ii ms>>%u] setup millis is %u", jj, ii, kk);
    	Serial.printf("\n@micros>>%u [ms>>%u] Time is %s\n", micros(), millis(), ctime(&tt));
    }
    
    void loop() {
    	tt = rtc_get();
    	while ( tt + 10 >= rtc_get() ) jj = micros();
    	Serial.printf("@micros>>%u [ms>>%u] Time is %s", jj, millis(), ctime(&tt));
    }
    Last edited by defragster; 07-11-2019 at 09:46 PM.

  19. #3644
    Senior Member
    Join Date
    Mar 2015
    Location
    UK
    Posts
    301
    Quote Originally Posted by TelephoneBill View Post
    ...I did a bit more work after the post and realised I'm getting weird results...
    @Manitou - Tried "DSB" and it made no difference. If I can summarize, using GPT2 it looks like this... If you only enable Compare2 using "GPT2_IR = 0x00000002;" then it ONLY WORKS (the ISR) if you put a value in the Compare1 value register e.g. "GPT2_OCR1 = 0x08F0D180;". Note that this is the WRONG register - it should be "GPT2_OCR2 = 0x08F0D180;" - but if OCR1 is zero, and something in OCR2 then it FAILS.

    Same is true of Compare3. If you use "GPT2_IR = 0x00000004;" it too only works if something is in OCR1. It cares NOT what is in OCR3. That cannot be correct?

    I'm using GPT2 because eventually, I want to toggle an output pin and GPT2 looks to be the only way on GPT's to get an output. What I'm aiming for is a edge on the Compare3 output to AD_B1_07 (Teensy Pin 16) to trigger a scope channel and then put a "digitalWriteFast" in an ISR to measure the ISR latency. I read somewhere that this can be as low as 20 nanoSecs.

  20. #3645
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,171
    @Frank B:
    I have a test WAV file that is sampled at 12kHz. I've modified the example WavFilePlayer to add setI2SFreq and then play the wav files like this:
    Code:
      setI2SFreq(12000);
      playFile("000001.WAV");  // filenames are always uppercase 8.3 format
      delay(500);
      setI2SFreq(44100);
      playFile("SDTEST1.WAV");  // filenames are always uppercase 8.3 format
      delay(500);
    Works perfectly. However, I then added some other WAV files for it to play which are sampled at various rates including 8kHz, 11025Hz, 12kHz and 44.1kHz and that doesn't work as well. I'm currently digging into play_sd_wav.cpp to try to sort it out.

    Pete

  21. #3646
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,357
    I realize this is premature until the T4 is actually announced, but does anybody have plans to make a carrier to access the bottom pins? Something like this board from FrankB?


    Or the Talldog boards?


    I would also hope that a board similar to the board used by the beta hardware is available for those people that want to use the audio shield with the Teensy 4, but that board is kind of on the big side.

  22. #3647
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,059
    Quote Originally Posted by MichaelMeissner View Post
    I realize this is premature until the T4 is actually announced, but does anybody have plans to make a carrier to access the bottom pins? Something like this board from FrankB?


    Or the Talldog boards?


    I would also hope that a board similar to the board used by the beta hardware is available for those people that want to use the audio shield with the Teensy 4, but that board is kind of on the big side.
    I've been wondering about a board like the first for the end I/O where it has to stop short of the bottom SMD parts - which that style from FrankB does.

    Also for the other end a USB HOST adapter like this :: https://oshpark.com/shared_projects/C8EaHAAq
    It would need female USB on bottom and 'USB control chip' and 5V and GND pins picked up.
    Suspect the SDIO line pitch too fine to get castellation to work. Might be cool to put double set of holes for female USB to mount to point either way underneath.

    The Beta Board was cool - except for not having a pin row parallel to all side pins to give ready access to them.

  23. #3648
    Senior Member
    Join Date
    Aug 2017
    Posts
    146
    @WMXZ, @Jean-Marc

    Just realized I was testing SPI in uSDFS with T3.2 and T3.6. Never did try with the T4. After trying to play a wave file with uSDFS and the audio board it did not work. My bad!
    And as WMXZ stated:
    uSDFS is basically based on FatFS which provides a lower-level API and is written in plain C.
    Adsing a SD-style API is possible, but is it needed?

  24. #3649
    Quote Originally Posted by wwatson View Post
    @WMXZ, @Jean-Marc

    Just realized I was testing SPI in uSDFS with T3.2 and T3.6. Never did try with the T4. After trying to play a wave file with uSDFS and the audio board it did not work. My bad!
    And as WMXZ stated:
    @manitou,@wmxz,
    Is there a way to specify the CS when using uSDFS in SPI mode (audio board or when using the SD of the ili9341 display) iso the Sdio build-in pins? A bit like SD lib does?

  25. #3650
    Senior Member
    Join Date
    May 2016
    Posts
    226
    @MichaelMeissner: I asked Daniel Gilbert (TallDog on Tindie) about his plans for a T4 breakout board similar to his DIP-64 and Standard t3.6 breakouts on Tindie. Here's his response yesterday:

    "Iíll definitely have a Teensy 4.0 breakout if it needs one, which I think it will. Unfortunately Paulís already distributed all the betas, and I canít seem to find any pictures of the pin layout yet. Thereís a preliminary pinout card, but it doesnít show the pin/pad locations."

    I'm a big fan of his DIP-64 T3.6 board.

    I just want to say that I'm hugely disappointed when I look at the pinout/form-factor of the T4. My apps need the processing power of the T4, but also need lots of digital pins for front panel communication etc. I'm thinking ahead, and it's going to be a major PITA if I have to redesign everything to use I2C to talk to a sub-processor that handles the encoders etc. That was the reason for asking Daniel about his plans...

    @Paul: Maybe you could work with Daniel to facilitate the production of a convenient breakout board?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •