Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 70 of 70

Thread: Teensyduino 1.54 Beta #3

  1. #51
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,352
    Quote Originally Posted by KurtE View Post
    @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.

  2. #52
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,746
    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

  3. #53
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,352
    @KurtE

    Quote Originally Posted by mjs513 View Post
    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.

  4. #54
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,352
    Quote Originally Posted by PaulStoffregen View Post
    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.

  5. #55
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,065
    Quote Originally Posted by mjs513 View Post
    Paul - think you may need to make the clock speed part of the sd.begin call instead of making it a fixed value.
    You always can use sd.sdfs.begin(...) to directly accesss the SdFat begin

  6. #56
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,479
    Quote Originally Posted by mjs513 View Post
    @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)));

  7. #57
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,352
    Quote Originally Posted by KurtE View Post
    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.

    Quote Originally Posted by WMXZ
    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.

  8. #58
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,065
    Quote Originally Posted by mjs513 View Post
    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.

  9. #59
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,746
    Ok, 16 MHz sounds fine a safe default.

    https://github.com/PaulStoffregen/SD...d8fd50079f5171

  10. #60
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,352
    Quote Originally Posted by PaulStoffregen View Post
    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.

  11. #61
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,479
    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

  12. #62
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,352
    @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

  13. #63
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,746
    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.

  14. #64
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,479
    Quote Originally Posted by PaulStoffregen View Post
    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.

  15. #65
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,746
    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.

  16. #66
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,479
    Quote Originally Posted by PaulStoffregen View Post
    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.

  17. #67
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,479
    And Now for something completely Random What 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:

    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)

  18. #68
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,746
    Quote Originally Posted by KurtE View Post
    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.

  19. #69
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,479
    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...

  20. #70
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,746
    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

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