Ok did a bit more testing this morning on the T3.2 using a 32GB sd card using the ST7789 240x320 display.Originally Posted by KurtE
Tried 2 different external readers and the internal reader and all three cases failed. Can't find any of my small cards so will have to punt on this.
EDIT: Got it finally working but had to change the clock speed from 24Mhz to 16Mhz in the library.
Paul - think you may need to make the clock speed part of the sd.begin call instead of making it a fixed value.
I'm currently working on 3 serial monitor bugs....
1: Printing a very long line forces horizontal scroll
2: Copy to clipboard gives double spaced lines
3: Memory leak on MacOS with repeated reopening of window
@KurtE
Just a quick update. Retested ILI9341 and ILI9488 (with tri-state buffer chip on MISO line) at 16Mhz clock with a 32Gb SD card on a T3.2. SUCCESS - both are working at the lower clock speed. Running the JPEG Slideshow sketch without an issue.
As a test I inserted the 512Gb card and its working with the clock at 16Mhz.
Great and good luck - besides issue 2 noticed issue 1 as well which was a bit annoying but didn't remember if it did it before or not so never reported it. Sorry.
You always can use sd.sdfs.begin(...) to directly accesss the SdFat begin
Maybe I will have to play again. I found I had an Sparkfun external SD reader and could not get it to do anything with T3.2... Did not try with anything else yet.
I think it is this one: https://www.sparkfun.com/products/13743
But for example it failed to init... I just retried it with 16 still failing, but need to double check what state I left the wiring in...
I assume you changed the line: return sdfs.begin(SdSpiConfig(csPin, SHARED_SPI, SD_SCK_MHZ(16)));
Yep thats what I did. You could also do what @WMXZ suggested and use SD.sdfs.begin(SdSpiConfig(csPin, SHARED_SPI, SD_SCK_MHZ(16))) directly in place of
SD.begin(ChipSelect).
For reference I have the breakout from Adafruit https://www.adafruit.com/product/254 that I have been using, also the one been using the Teensy backpack SD Card reader from @brtaylor.
Yep I agree. Just thought if you include it in the SD.begin function it would be more consistent even though its not currently in the SD lib so you wouldn't have to mix and match. 24Mhz seems to work fine for T3.5 and above.
Originally, I thought that too and started a PR, but then realized that this is becoming too difficult (SDClass, FS, etc) and Paul commented on PR saying that sdfs is public exactly for that purpose. PR is closed now.
Last edited by WMXZ; 11-03-2020 at 02:44 PM.
Ok, 16 MHz sounds fine a safe default.
https://github.com/PaulStoffregen/SD...d8fd50079f5171
Sounds good - just double checked it with the TeensyBackpack SD card reader with the ILI9488 and its working at 16Mhz as well. So at least that's with 2 different card readers.
I think my Sparkfun one might be DOA... Never had any luck with it.
Actually I just redid it again and it worked, with: two different cards: an old Kingston 16GB and a Sandisk Ultra 32gb.
But a Samsung32 EVO Select fails on the external Sparkfun unit:
But works on T3.5 Built in:Code:Initializing SD card...initialization failed!
Note: I took this SD card from an RPI3 or 4 don't remember which and or if it was for Ubuntu or Raspian...Code:Initializing SD card...initialization done. overlays/ adau7002-simple.dtbo 1587 README 113431 act-led.dtbo 569 adau1977-adc.dtbo 1027 akkordion-iqdacplus.dtbo 1387 ads1015.dtbo 2425 ads1115.dtbo 2425 ads7846.dtbo 2402 adv7282m.dtbo 1952 adv728x-m.dtbo 2436 audioinjector-addons.dtbo 1866 anyspi.dtbo 3895 allo-boss-dac-pcm512x-audio.dtbo 1473 allo-digione.dtbo 1208 allo-katana-dac-audio.dtbo 1659 allo-piano-dac-pcm512x-audio.dtbo 1011 allo-piano-dac-plus-pcm512x-audio.dtbo 1585 ... fixup4db.dat 9192 fixup4x.dat 9192 fixup_cd.dat 2656 fixup_db.dat 9817 fixup_x.dat 9819 kernel.img 5142912 kernel7.img 5424376 kernel7l.img 5757200 kernel8.img 13521408 start.elf 2883204 start4.elf 2784800 start4cd.elf 784316 start4db.elf 4593508 start4x.elf 3546468 start_cd.elf 690884 start_db.elf 4859912 start_x.elf 3797384 System Volume Information/ WPSettings.dat 12 IndexerVolumeGuid 76 done!
But if someone else has an RPI image you might try it as well...
EDIT: Just as an FYI - Looking at the Sparkfun page for this unit, it mentions:
Note looks like a TXB104 they are usingIf your processor is capable of it, this board supports the use of even the fastest UHS µSD cards. We only tested to 25MHz, but it should be good to two to four times that. Today most Arduino type µControllers are only capable of SPI_HALF_SPEED (6Mbps). Consider this board if you want a little future proofing or have a faster setup. The Arduino SD library is capable of SPI_FULL_SPEED (25Mbps).
The SparkFun Shifting µSD is also a bit unique from its competitors in that it is bi-directional - it level translates all of its outputs back to the level of the hardware it's connected to.
@KurtE
The 32gb card I am using has a Rpi4 Ubuntu image on it and seems to work. The EVO version of the SDCards seem to have a problem - think Paul was having the same issue with Lexar? EVO card.
Looks like the level shifter for the Adafruit board is a CD74HC4050. Not sure what the difference
After much more fiddling, it's looking like the only way to get rid of the serial monitor double spacing on copy to clipboard is to filter away the carriage return chars before they get into the FifoDocument data storage. While Sun tried to design a highly flexible API between the Document class and JTextComponent, it's becoming pretty clear there's code buried deep in Java that expects the internal storage to the unix style newlines.
It's pretty clear there are multiple platform specific translations going on behind the scenes. The really frustrating part is how poorly this behavior is documented in all the Java docs.
I'm going to put this into the teensy_ports helper program, since this is much more efficient to do in C than Java.
What a pain with both '\r','\n' in there. On Windows using .print('\n') instead of .println() works well/as intended for SerMon's.After much more fiddling, it's looking like the only way to get rid of the serial monitor double spacing on copy to clipboard is to filter away the carriage return chars before they get into the FifoDocument data storage. While Sun tried to design a highly flexible API between the Document class and JTextComponent, it's becoming pretty clear there's code buried deep in Java that expects the internal storage to the unix style newlines.
It's pretty clear there are multiple platform specific translations going on behind the scenes. The really frustrating part is how poorly this behavior is documented in all the Java docs.
I'm going to put this into the teensy_ports helper program, since this is much more efficient to do in C than Java.
Does Mac or Linux require "\r\n" both be present? If required println() can't just be made '\n' - though changing that would be ... a Change ... for both UART and USB usage.
Changing the behavior of the Arduino Print class is not an option! While convenient for this particular serial monitor issue, that sort of change could break countless programs which depend on the Print class for writing to files on SD cards and other media, for transmitting data over Ethernet, for hardware serial protocols and so many more applications. It would probably even break using non-Arduino terminal emulators like Coolterm on Windows & Macintosh and seyon on Linux.
Good answer, indeed not valid to change, thanks. - asked before and still wondering since KurtE brought up last year(s). So fix would have to be through resultant IDE Copy/Paste data xfer.
And Now for something completely RandomWhat else is new
A few days ago when answering another question, I was suprised that we did not have a T4.x GPIO structure defined in imxrt.h....
So I did a quick and dirty:
I did a quick and dirty to verify that unused of 25 was correct, plus blink an LED...Code:typedef struct { volatile uint32_t DR; // 00 volatile uint32_t GDIR; // 04 volatile uint32_t PSR; // 08 volatile uint32_t ICR1; // 0C volatile uint32_t ICR2; // 10 volatile uint32_t IMR; // 14 volatile uint32_t ICR; // 18 volatile uint32_t EDGE_SEL; // 1C uint32_t UNUSED[25]; // 20 - 83 volatile uint32_t DR_SET; // 84 volatile uint32_t DR_CLEAR; // 88 volatile uint32_t DR_TOGGLE; // 8C } IMXRT_GPIO_t; #define IMXRT_GPIO1S (*(IMXRT_GPIO_t *)0x401B8000) #define IMXRT_GPIO2S (*(IMXRT_GPIO_t *)0x401BC000) #define IMXRT_GPIO3S (*(IMXRT_GPIO_t *)0x401C0000) #define IMXRT_GPIO4S (*(IMXRT_GPIO_t *)0x401C4000) #define IMXRT_GPIO5S (*(IMXRT_GPIO_t *)0x400C0000) #define IMXRT_GPIO6S (*(IMXRT_GPIO_t *)0x42000000) #define IMXRT_GPIO7S (*(IMXRT_GPIO_t *)0x42004000) #define IMXRT_GPIO8S (*(IMXRT_GPIO_t *)0x42008000) #define IMXRT_GPIO9S (*(IMXRT_GPIO_t *)0x4200C000)
And my LED is blinking...Code:void setup() { while (!Serial); Serial.begin(115200); delay(2); IMXRT_GPIO_t *pgpio = nullptr; Serial.println((uint32_t)(&(pgpio->DR_SET)), HEX); pinMode(13, OUTPUT); } void loop() { IMXRT_GPIO7S.DR_TOGGLE = (1<<3); delay(250); }
Question is, is this something we should do a PR for?
And if So, Should I also go through and change the defines like this:
To more like:Code:#define GPIO2_DR (IMXRT_GPIO2.offset000) #define GPIO2_GDIR (IMXRT_GPIO2.offset004) #define GPIO2_PSR (IMXRT_GPIO2.offset008) #define GPIO2_ICR1 (IMXRT_GPIO2.offset00C) #define GPIO2_ICR2 (IMXRT_GPIO2.offset010) #define GPIO2_IMR (IMXRT_GPIO2.offset014) #define GPIO2_ISR (IMXRT_GPIO2.offset018) #define GPIO2_EDGE_SEL (IMXRT_GPIO2.offset01C) #define GPIO2_DR_SET (IMXRT_GPIO2.offset084) #define GPIO2_DR_CLEAR (IMXRT_GPIO2.offset088) #define GPIO2_DR_TOGGLE (IMXRT_GPIO2.offset08C)
Code:#define DR (IMXRT_GPIO1.DR) #define GPIO1_DR (IMXRT_GPIO1.DR) #define GPIO1_GDIR (IMXRT_GPIO1.GDIR) #define GPIO1_PSR (IMXRT_GPIO1.PSR) #define GPIO1_ICR1 (IMXRT_GPIO1.ICR1) #define GPIO1_ICR2 (IMXRT_GPIO1.ICR2) #define GPIO1_IMR (IMXRT_GPIO1.IMR) #define GPIO1_ISR (IMXRT_GPIO1.ISR) #define GPIO1_EDGE_SEL (IMXRT_GPIO1.EDGE_SEL) #define GPIO1_DR_SET (IMXRT_GPIO1.DR_SET) #define GPIO1_DR_CLEAR (IMXRT_GPIO1.DR_CLEAR) #define GPIO1_DR_TOGGLE (IMXRT_GPIO1.DR_TOGGLE)
Yes, like that (not using a new name "IMXRT_GPIO1S"). Maybe someday all the peripherals will get this treatment. I created everything with those offset defines a couple years ago to save time (just making the first imxrt.h took several days) and make double checking against the reference manual easier.
Send a PR if you'd like to see this in beta4. This stuff is pretty much at the very bottom of my priority list, but I'll merge it if you send it.
Sent in PR. No high priority, but again wondered, and so did... Had to change interrupt.c as well as it had #define statements for some of the register names, like DR, PSR...
I already packaging up beta4 and I'm editing the changelog now while waiting on Raspberry Pi build and Apple notarization. Unless something goes really wrong with testing tonight or tomorrow, that PR will get merged into beta5.
Posting Permissions
Reply With Quote