el_supremo
Well-known member
Thanks Frank. That works with the demo wavfileplayer but not with my code so I have some digging to do.
Pete
Pete
I Is there a way to use usdfs with build-in sd interface?
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 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.
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.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
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!
@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)
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>
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
Test uSDFS
0:/
Mount: Failed with rc=FR_DISK_ERR.
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.
Thanks Frank. That works with the demo wavfileplayer but not with my code so I have some digging to do.
Pete
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
#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));
}
...I did a bit more work after the post and realised I'm getting weird results...
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);
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.
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?
@manitou,@wmxz,@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: