Teensyduino 1.54 Beta #3

Status
Not open for further replies.
@mjs513 - What size card? I am using 8gb one. right now...

But wonder if memory issue by size of card?

Ok did a bit more testing this morning on the T3.2 using a 32GB sd card using the ST7789 240x320 display.

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

Ok did a bit more testing this morning on the T3.2 using a 32GB sd card using the ST7789 240x320 display.

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.

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.
 
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

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.
 
@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.
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)));
 
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.

WMXZ said:
You always can use sd.sdfs.begin(...) to directly accesss the SdFat begin
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.
 
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:
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:
Code:
Initializing SD card...initialization failed!

But works on T3.5 Built in:

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!
Note: I took this SD card from an RPI3 or 4 don't remember which and or if it was for Ubuntu or Raspian...

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:
If 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.
Note looks like a TXB104 they are using
 
@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.
 
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.

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.
 
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 Random ;) What else is new :D

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:

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)

I did a quick and dirty to verify that unused of 25 was correct, plus blink an LED...
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);
}
And my LED is blinking...

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:
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)
To more like:

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)
 
To more like:

Code:
#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.
 
Status
Not open for further replies.
Back
Top