Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 14 of 14

Thread: Teensyduino 1.23 Beta #1 Available

  1. #1
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    390

    Teensyduino 1.23 Beta #1 Available

    Here is a first beta test for Teensyduino 1.23:


    Edit: old beta test linkes removed. Full non-beta release is here:
    http://www.pjrc.com/teensy/td_download.html



    Please give this a try and report any bugs. Try to include a sample program that reproduces the problem!

    These are the changes since Teensyduino 1.22:


    • Improve Wire library, handle Lidar Lite issues
    • Add SerialFlash library
    • Optimize SD library for Teensy 3.x (SD_t3.h, disabled by default)
    • Default Systick interrupt to priority level 32
    • Fix 24 MHz speed on Teensy 3.1
    • Fix RawHID on Teensy 2.0 with newer Arduino version
    • Update Time library
    • Update i2c_t3 library, adds support for Teensy-LC

  2. #2
    Senior Member
    Join Date
    Aug 2014
    Posts
    143
    So far audio bug is eliminated !!!

    No more pops, squeeks or missed audio sound playback when in multi sound playback mode (RAW format).

    Did test a 1gb FAT32 card, did not work, but 4gB sandisk FAT32 cards OK (800+ audio files on card).

    Need to do heavy stress testing this week, but we can finally upgrade to newest Teensyduino and Arduino IDE!

    Thank you so much! We hope we make it on TV this year, and get to show the true power of Teensy. It's a great step up from Arduino, perfect for very small company like us.

  3. #3
    Senior Member
    Join Date
    Feb 2013
    Posts
    563
    Optimize SD library for Teensy 3.x (SD_t3.h, disabled by default)
    i've just tried, and now i get: undefined reference to `File::name()' ; the code compiles fine when i leave define USE_TEENSY3_OPTIMIZED_CODE commented out.

    basically that bit of code is just trying to get the filename:


    Code:
        
        File dir;
        File entry;
      
        dir = SD.open(DIRECTORY);
        
        while(fcnt < MAXFILES) {
             entry = dir.openNextFile();
             if (!entry || fcnt >= MAXFILES) break;    
             int s = entry.size();   
             if ( (s & 0xff) > 0) s |= 0xff;
             filename[fcnt] = entry.name(); // --> filenames
             Serial.printf("%s\t\t\t%d bytes\r\n", filename[fcnt].c_str(), s);
             fsize += s;   
             entry.close();  
             fcnt++;
         }
    any hints? i guess i must be me missing something ...

    thanks

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,958
    Quote Originally Posted by zachtos View Post
    Did test a 1gb FAT32 card, did not work
    Any chance you could send that card to me?

    This new version is disabled by default, mainly because it doesn't support writing and some other features, but also because it's been tested with only a few cards.
    Last edited by PaulStoffregen; 04-29-2015 at 10:59 PM.

  5. #5
    Senior Member
    Join Date
    Aug 2014
    Posts
    143
    I think he said open.next is not support right now

  6. #6
    Senior Member
    Join Date
    Feb 2013
    Posts
    563
    Quote Originally Posted by zachtos View Post
    I think he said open.next is not support right now
    ah, i see. so that can't work. i thought this was something else now.
    Last edited by mxxx; 04-29-2015 at 11:29 PM.

  7. #7
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    I think the SD and uSD cards of 2GB and less are "type 1" cards (old and MMC) seem incompatible with software that assumes a 512B block size. Type 2 cards all seem to use 512B blocks, and it may be that type 2's are "HC" or higher, and usually or always larger than 2GB (e.g., 4GB and up).

    Interesting find today: reading a type 2 card, SDIO interface @ 24MHz clock, (a) after a multi-block read completes, it takes 500uSec to get the next read to start. So reading a single 512 byte block with the single-block-read command uses 170uSec to read the data and wastes 500uSec for this inter-command delay. Don't know how to deal with this well, when the RAM buffer size in the MCU is rather small, e.g., 8KB or so. PCs and tablets probably have really big buffers.

    I also noted that the (SanDisk) card I tested with draws power (stays awake at about 30mA) for 4 seconds after the last read. Autonomously, it goes back to 0.4mA sleeping current after seconds of inactivity.

  8. #8
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,220
    Quote Originally Posted by stevech View Post
    Interesting find today: reading a type 2 card, SDIO interface @ 24MHz clock, (a) after a multi-block read completes, it takes 500uSec to get the next read to start. So reading a single 512 byte block with the single-block-read command uses 170uSec to read the data and wastes 500uSec for this inter-command delay.
    Yes, i noticed the same effect when i did some experiments with "DIY" 4-BIT access; with some cards it was worse, nearly 1ms. The fastest block-addressing was with my oldest card, a 512MB chinese no-name: 300us.
    Then I did some benchmarks with my PC and got the same result. So I'm pretty sure it's really a problem with the cards, not with my code. At this point I lost interest.
    There's a little chance that there is a undocumented way to make it faster, but in this case my PC does not know this way too :-)
    Last edited by Frank B; 04-30-2015 at 02:22 PM.

  9. #9
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    thanks Frank. I'm currently using a single-serial (D0) interface with SDIO - kind of like SPI - but the SDIO commands have their own independent serial link. A test with reading 8KB in one command to the card yielded no inter-block delay (like 500uSec) until all 8KB is sent. So looping that 8KB read, with the 500uSec dead-air between 8KB blocks, and one serial line, I saw 2.2MBytes/sec sustained. Ideally it'd be 3MB/s with one line and 24MHz clock. (The driver code does use a hardware FIFO).

    On PCs and tablets and big files, they probably always read into a buffer much larger than 8KB. I can afford in this app to use a 40KB+ buffer - since I have that as globally time-shared in a single-threaded architecture.
    I did start out with a 512B buffer - now I know this is too slow. I did the 512B buffer because I didn't want the user app to have to align its buffer on a quad-word boundary - which is a requirement for DMA.

    I have just a few cards - need more. They vary considerably.
    Indeed, wear-leveling isn't mandated by the standards as I read, but most reputable vendors provide it on chip. Beware too-cheap cards. It can't be done in the PC/tablet, I think, because the uSD cards are removable and there's no assurance where it would go next. Done on-chip, the erasure history is kept on chip, non-volatile.
    Last edited by stevech; 04-30-2015 at 09:11 PM.

  10. #10
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    The OSC library is going to receive an update soon to also support the Teensy LC amongst other things.

  11. #11
    Junior Member
    Join Date
    Jan 2014
    Posts
    10
    Hi Paul, thanks for this new release.

    Could you take a look at this :

    Code:
    void OctoWS2811::isr(void)
    {
    	Serial1.print("."); <=========
    	//Serial1.println(dma3.CFG->DCR, HEX);
    	//Serial1.print(dma3.CFG->DSR_BCR > 24, HEX);
    	dma3.clearInterrupt();
    	//Serial1.print("*");
    	update_completed_at = micros();
    	update_in_progress = 0;
    }
    It looks like you forgot to remove some debug

  12. #12
    Senior Member
    Join Date
    Mar 2013
    Posts
    132
    yes, I have updated the OSC library and done some preliminary testing on Teensy LC. I will try to complete the testing in time for the next teensyduino release.

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,958
    Quote Originally Posted by Alkorin View Post
    It looks like you forgot to remove some debug
    Yup, already fixed on github, and will be in 1.23-beta2... coming later today.

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,958
    Quote Originally Posted by adrianfreed View Post
    yes, I have updated the OSC library and done some preliminary testing on Teensy LC. I will try to complete the testing in time for the next teensyduino release.
    I took the liberty to grab the latest from your github, for 1.23-beta2, which I intend to publish today.

    I want to finalize 1.23 by Monday.... so there's still time to make updates, but only a matter of days.

Posting Permissions

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