@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?
You edit sd_config.h in uSDFS/utility
@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?
@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?
@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."
SD DAT1, x=361.22, y=487.80
SD DAT0, x=361.22, y=448.43
SD GND, x=361.22, y=409.06
SD CLK, x=361.22, y=369.69
SD 3.3V, x=361.22, y=330.32
SD CMD, x=361.22, y=290.95
SD DAT3, x=361.22, y=251.58
SD DAT2, x=361.22, y=212.21
Pin 24: x=1182, y=550
Pin 25, x=1018, y=550
Pin 26: x=1182, y=450
Pin 27, x=1018, y=450
Pin 28: x=1182, y=350
Pin 29, x=1018, y=350
Pin 30: x=1182, y=250
Pin 31, x=1018, y=250
Pin 32: x=1182, y=150
Pin 33, x=1018, y=150
USB2 D+, x=72, y=305
USB2 D-, x=72, y=395
SD DAT1, x=340, y=527.17
SD DAT0, x=340, y=483.86
SD GND, x=340, y=440.55
SD CLK, x=340, y=394.24
SD 3.3V, x=340, y=353.94
SD CMD, x=340, y=310.63
SD DAT3, x=340, y=267.32
SD DAT2, x=340, y=224.02
@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:
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.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);
Pete
Paul mentioned a future version with more pins - not sure if (and when) it comes.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.
Maybe I'll make something like this. But I'm not sure how to handle the SD slot.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?
In file included from C:\Arduino\hardware\teensy\avr\cores\teensy4/core_pins.h:32,
from C:\Arduino\hardware\teensy\avr\cores\teensy4/wiring.h:38,
from C:\Arduino\hardware\teensy\avr\cores\teensy4/WProgram.h:45,
from c:\temp\arduino_build_474724\pch\Arduino.h:6:
C:\Arduino\hardware\teensy\avr\libraries[COLOR=#ff0000][B]\SPI/SPI.h[/B][/COLOR]: In member function 'void SPIClass::usingInterrupt(uint8_t)':
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4967:33: [COLOR=#ff0000]error[/COLOR]: expression '((IMXRT_REGISTER32_t*)1075544064)->IMXRT_REGISTER32_t::offset000' has side-effects
#define GPIO1_DR (IMXRT_GPIO1.offset000)
~~~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\[COLOR=#ff0000][B]SPI/SPI.h[/B][/COLOR]:1148:20: note: in expansion of macro 'GPIO1_DR'
case (uint32_t)&GPIO1_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4966:24: [COLOR=#ff0000]error[/COLOR]: 'reinterpret_cast<IMXRT_REGISTER32_t*>(1075544064)' is not a constant expression
#define IMXRT_GPIO1 (*(IMXRT_REGISTER32_t *)0x401B8000)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4967:21: note: in expansion of macro 'IMXRT_GPIO1'
#define GPIO1_DR (IMXRT_GPIO1.offset000)
^~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1148:20: note: in expansion of macro 'GPIO1_DR'
case (uint32_t)&GPIO1_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4967:42: [COLOR=#ff0000]error[/COLOR]: conversion from pointer type 'volatile uint32_t*' {aka 'volatile long unsigned int*'} to arithmetic type 'uint32_t' {aka 'long unsigned int'} in a constant expression
#define GPIO1_DR (IMXRT_GPIO1.offset000)
^
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1148:20: note: in expansion of macro 'GPIO1_DR'
case (uint32_t)&GPIO1_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4979:33: [COLOR=#ff0000]error[/COLOR]: expression '((IMXRT_REGISTER32_t*)1075560448)->IMXRT_REGISTER32_t::offset000' has side-effects
#define GPIO2_DR (IMXRT_GPIO2.offset000)
~~~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1152:20: note: in expansion of macro 'GPIO2_DR'
case (uint32_t)&GPIO2_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4978:24: [COLOR=#ff0000]error[/COLOR]: 'reinterpret_cast<IMXRT_REGISTER32_t*>(1075560448)' is not a constant expression
#define IMXRT_GPIO2 (*(IMXRT_REGISTER32_t *)0x401BC000)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4979:21: note: in expansion of macro 'IMXRT_GPIO2'
#define GPIO2_DR (IMXRT_GPIO2.offset000)
^~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1152:20: note: in expansion of macro 'GPIO2_DR'
case (uint32_t)&GPIO2_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4979:42: [COLOR=#ff0000]error[/COLOR]: conversion from pointer type 'volatile uint32_t*' {aka 'volatile long unsigned int*'} to arithmetic type 'uint32_t' {aka 'long unsigned int'} in a constant expression
#define GPIO2_DR (IMXRT_GPIO2.offset000)
^
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1152:20: note: in expansion of macro 'GPIO2_DR'
case (uint32_t)&GPIO2_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4991:33: error: expression '((IMXRT_REGISTER32_t*)1075576832)->IMXRT_REGISTER32_t::offset000' has side-effects
#define GPIO3_DR (IMXRT_GPIO3.offset000)
~~~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1156:20: note: in expansion of macro 'GPIO3_DR'
case (uint32_t)&GPIO3_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4990:24: error: 'reinterpret_cast<IMXRT_REGISTER32_t*>(1075576832)' is not a constant expression
#define IMXRT_GPIO3 (*(IMXRT_REGISTER32_t *)0x401C0000)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4991:21: note: in expansion of macro 'IMXRT_GPIO3'
#define GPIO3_DR (IMXRT_GPIO3.offset000)
^~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1156:20: note: in expansion of macro 'GPIO3_DR'
case (uint32_t)&GPIO3_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4991:42: error: conversion from pointer type 'volatile uint32_t*' {aka 'volatile long unsigned int*'} to arithmetic type 'uint32_t' {aka 'long unsigned int'} in a constant expression
#define GPIO3_DR (IMXRT_GPIO3.offset000)
^
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1156:20: note: in expansion of macro 'GPIO3_DR'
case (uint32_t)&GPIO3_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:5003:33: error: expression '((IMXRT_REGISTER32_t*)1075593216)->IMXRT_REGISTER32_t::offset000' has side-effects
#define GPIO4_DR (IMXRT_GPIO4.offset000)
~~~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1160:20: note: in expansion of macro 'GPIO4_DR'
case (uint32_t)&GPIO4_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:5002:24: error: 'reinterpret_cast<IMXRT_REGISTER32_t*>(1075593216)' is not a constant expression
#define IMXRT_GPIO4 (*(IMXRT_REGISTER32_t *)0x401C4000)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:5003:21: note: in expansion of macro 'IMXRT_GPIO4'
#define GPIO4_DR (IMXRT_GPIO4.offset000)
^~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1160:20: note: in expansion of macro 'GPIO4_DR'
case (uint32_t)&GPIO4_DR:
^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:5003:42: error: conversion from pointer type 'volatile uint32_t*' {aka 'volatile long unsigned int*'} to arithmetic type 'uint32_t' {aka 'long unsigned int'} in a constant expression
#define GPIO4_DR (IMXRT_GPIO4.offset000)
^
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1160:20: note: in expansion of macro 'GPIO4_DR'
case (uint32_t)&GPIO4_DR:
^~~~~~~~
No I'm not, although I sure wish I wasI'm not sure if you are on the beta list...
maybe T4 is locked up with run away interrupts, try holding program button for 15 s to erase flashI have suspicions tonight that my experiments with turning on 150 MHz for GPT timers may have damaged the chip internally. Until I can clarify this further, please will all beta users refrain from trying this for themselves.
The evidence that something ODD has happened is the behaviour of the GPT timers - things that used to work fine, now do not seem to be so fine. It may take me some while to pin the situation down.
The posts relevant here are #3554, #3557, #3578, #3579, #3582, #3583, #3586, #3591, #3611, #3638, #3642, #3644.
Specifically do not try the code in #3611 !!
Thanks for your patience. I shall report again in due course.
Good added info - still need to decipher and decode/read SRC_SRSR for debug_tt.
If it does trigger one of those _isr()'s that would be the way to get a _callback. If it were set to a _weak default the user could include custom code for resolution.
Thanks for typo false alarm check - I was willing to ignore it until seeing there were three _0, _1, and _2 variations in the header.
I am playing around with simple breakout board, to play with doing Robotics. With this I don't need complex sounds or the like, usually just some form of multiple beeps or the like. Things like, you pressed a button to control it and maybe signal with mode you are in. Or battery is getting low...
I am wondering if with T4, probably best off going back to what I was doing before, which is to connect up speaker/buzzer sometimes directly to IO pin, but usually when putting on a board, I would use a transistor, diode, ...
Later I started using a small amplifier chip off of the DAC pin(s). Or wonder if it makes sense to use some other I2S device and some form of AMP?
Just wondering which way I want to go.
@defragster - went back into my original standalone sketch: https://github.com/mjs513/WIP/tree/master/TempMonitorStuff/T4-TEMPMON. You can see how I did the Callbacks if the ISR is tripped for HIGH and panic temps. Also the panic temp is set that high that the chip would go into meltdown - you can always test I presume if you run the chip at "Ludicrous Speed"
I have pulled that original sample and thought about changing the PANIC temp to something near normal temp to see it work, was going to ask how and how much you tested. Played some before moving on - I was dong it in conjunction with the STARTUP_HOOKS and stopped to do the Pull request because that part was working right and seemed useful to be able to get in early and use time that would be wasted in those while(waits).
Wanted to be sure I understood enough to catch interrupt and such without having to actually make time to read the manual. I suppose I could edit the Startup.c code to pull the included TempMon_Init() and call out to a LIB test version where I saw you passed in the TEMP values.
I am playing around with simple breakout board, to play with doing Robotics. With this I don't need complex sounds or the like, usually just some form of multiple beeps or the like. Things like, you pressed a button to control it and maybe signal with mode you are in. Or battery is getting low...
I am wondering if with T4, probably best off going back to what I was doing before, which is to connect up speaker/buzzer sometimes directly to IO pin, but usually when putting on a board, I would use a transistor, diode, ...
Later I started using a small amplifier chip off of the DAC pin(s). Or wonder if it makes sense to use some other I2S device and some form of AMP?
Just wondering which way I want to go.
Well tested it pretty good to make sure things tripped when they were suppose to in that test sketch. Just for the fun of it I also lowered the panic temp and tested to see if it really reset using a panic temp near normal run time temps. And before you ask yes it did keep resetting until I put the temps back to way I had it. Never got around to try looking at the SRC bits - punted on that one.
@defragster - Essenstially that's it - the system automatic triggers reset when panic temp is exceeded - it will keep resetting unless you do something to lower the temp. Believe so on the init and tempmon start.
uint32_t WIPstartup_reset_SRSR = SRC_SRSR; // WIP
…\hardware\teensy\avr\cores\teensy4\imxrt.h about line 7650:
// 52.7: page 2969
#define IMXRT_SRC (*(IMXRT_REGISTER32_t *)0x400F8000)
// ...
#define SRC_SRSR (IMXRT_SRC.offset008)