Teensyduino 1.23 Beta #1 Available

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
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
 
So far audio bug is eliminated !!! :D

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.
 
Optimize SD library for Teensy 3.x (SD_t3.h, disabled by default)
Click to expand...

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
 
zachtos said:
Did test a 1gb FAT32 card, did not work
Click to expand...

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:
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.
 
stevech said:
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.
Click to expand...

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:
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:
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 :(
 
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.
 
adrianfreed said:
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.
Click to expand...

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