PDA

View Full Version : Teensyduino 1.21 Released



Paul
03-15-2015, 11:56 AM
Teensyduino 1.21 has been officially released.

http://www.pjrc.com/teensy/td_download.html

Here are the changes since version 1.20:



Support for Teensy-LC (http://www.pjrc.com/teensy/teensyLC.html)
Support Arduino 1.6.0 and 1.6.1
Keep Arduino Serial Monitor window open during Upload (Arduino 1.0.6, 1.6.0, 1.6.1)
Improve Arduino Serial Monitor efficiency & memory usage (Arduino 1.0.6)
Wire.setClock()
Tools > CPU Speed menu supports speed vs size optimized (Teensy 3.1 & LC)
Update sample Makefile for non-Arduino usage
Simplify usb_desc.h for creating custom USB devices
Libraries added: Adafruit_VS1053, FastCRC, openGLCD, Snooze, TFT_ILI9163C
Libraries updated: Adafruit_CC3000, Adafruit_NeoPixel, Adafruit_SSD1306, Adafruit_ST7735, FastLED, FreqCount, FreqMeasure, ILI9341_t3, IRremote, MsTimer2, OctoWS2811, OneWire, PS2Keyboard, PulsePosition, Time, TimerOne, TimerThree, TinyGPS
Upgrade ARM Toolchain from 4.7.2 to 4.8.4.
Various minor bug fixes



Special thanks to everyone who helped beta test (https://forum.pjrc.com/threads/27689-Teensy-LC-Beta-Testing) and everyone who contributed ideas, feedback, patches and libraries.

linuxgeek
03-15-2015, 05:24 PM
Small suggestion. It's unclear what "optimized" means without reading the version changes here. Could be interpreted as optimized for speed or size. You probably rather not clutter the menu a lot. This might work?:
48 MHz >speed
24 MHz >speed
48 MHz <size
24 MHz <size

jhendrix
03-16-2015, 08:28 PM
Paul,
I did a fresh install of Arduino 1.6.1 with teensyduino 1.21 on top of it.
I can't get any of my teensy++ 2.0 code to compile or any of your teensy example code. (I tried 5 or 6)
I get errors like this

C:\arduino-1.6.1\hardware\teensy\avr\cores\teensy\../usb_flightsim/usb.c:76:24: error: variable 'rawhid_hid_report_desc' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
static uint8_t PROGMEM rawhid_hid_report_desc[] = {

when I fix the const issue, I get lots of other compile errors.

If I change the board to teensy 3.1, everything compiles fine.

-Jeff

PaulStoffregen
03-16-2015, 09:00 PM
when I fix the const issue, I get lots of other compile errors.


I've committed a fix to github (https://github.com/PaulStoffregen/cores/commit/179953284a278c9d6bb3078ab3859ffb4bc5f09e). You can get it there, or just use these 2 files in hardware/teensy/avr/cores/usb_flightsim

jhendrix
03-16-2015, 10:12 PM
With those files, I now get several warnings in other files. (you can reproduce it by making an empty project, set to teensy++ 2 and Flight sim)

I also tried a 3.1 / Serial project with #include <SD.h> and it says it can't find #include <SPI.h>, and I installed all the teensy libraries.

C:\arduino-1.6.1\hardware\teensy\avr\libraries\SD\utility\Sd2 Card.cpp:21:17: fatal error: SPI.h: No such file or directory
#include <SPI.h>

FYI: I tried 1.21 on Arduino 1.0.6 and the teensy++ compiles work.
The #include <SD.h> issues works on teensy++, but I get the same error with teensy 3.1.

PaulStoffregen
03-17-2015, 12:48 AM
Yes, there are currently many harmless warnings. That's common after upgrading the toolchain, as recently happened on both AVR and ARM. It's still the same code we've been using for years, but the compiler become more picky over time.

You might think I and other software authors ought to have a zero tolerance policy for compiler warnings. I certainly do over the very long run.

But in the short term, meaning the next few months until another release, I'd much rather endure warnings that I'm confident are harmless (and user comments about them) than warning-free code based on hastily rewritten and poorly tested changes. Some warnings are quick and easy to fix with very low risk. Many of those got fixed already, or will be addressed soon. But some are much more involved.

PaulStoffregen
03-17-2015, 12:51 AM
C:\arduino-1.6.1\hardware\teensy\avr\libraries\SD\utility\Sd2 Card.cpp:21:17: fatal error: SPI.h: No such file or directory
#include <SPI.h>


Regarding this problem (and all specific problems), you must post the code. See the "forum rule". If it's just one of the examples without any changes, just clearly mentioning which example is fine.

However, you should be aware the Arduino SD library changed from 1.0.x to 1.6.x, to require the SPI library. The new version requires #include <SPI.h> in your sketch. If you're compiling an old program that was written for 1.0.x, you'll need to add that. This isn't specific to Teensy. It's a change in the SD library, which applies to all Arduino boards.

jhendrix
03-17-2015, 05:49 PM
I understand the heartache of upgrading a compiler.
I didn't know if you were aware of the warnings because of the other errors I was seeing in the flight sim code.

Adding #include <SPI.h> in my sketch fixed the SD.h error.
(although I'm still a little confused why adding it to the sketch eliminates the dependency problem for spi.h in the .cpp files)

Thanks
Jeff

defragster
03-17-2015, 05:57 PM
Jeff: The Change in the library to rely on SPI as you note made a dependency on having access to that code base that was not required before. When you added '#include <SPI.h>' the needed reference to that specific code was provided giving the compiler a specification to the needed code to resolve this new dependency.

PaulStoffregen
03-17-2015, 08:16 PM
(although I'm still a little confused why adding it to the sketch eliminates the dependency problem for spi.h in the .cpp files)


The Arduino IDE parses the #include lines in your sketch to configure which libraries are built. The SD library can't tell the Arduino IDE that it needs the SPI library.

This is a silly limitation that's always existed in Arduino. Years ago, I came up with a fix, but David Mellis (then Arduino's technical lead in charge of accepting contributions) changed his mind at the last minute. So it never got accepted. Later, when he realized that to be a mistake, I had started working heavily on Teensy 3.0 and couldn't devote time to the IDE. Since then, the issue has come up many times, usually with nobody willing to do the work. In recent years, the issue has been further clouded by Arduino's move to a new library format with metadata. It's a terrible shame so much indecision over the years on Arduino's part has kept such a simple thing as automatically detecting library dependencies to be added. But that's the situation, if you use a library like SD which uses SPI internally, you have to #include the SPI header in your sketch in the Arduino editor, even if you never use the SPI library directly.

linuxgeek
03-17-2015, 08:38 PM
I think that problem likely hits most every user, sooner or later. For shame.

PaulStoffregen
03-17-2015, 11:43 PM
Maybe it's time for me to finally fix this once and for all.

linuxgeek
03-18-2015, 05:56 AM
I think it's a real problem, cause it makes libraries seem like they don't work. I think there's an expectation that a library is self-contained, and when there's compile errors, it makes the libraries seem broken. And that's bad for the user and the library contributors. I'm surprised that the core Arduino IDE team hasn't addressed it.

Nantonos
03-18-2015, 06:59 AM
The Arduino IDE parses the #include lines in your sketch to configure which libraries are built. The SD library can't tell the Arduino IDE that it needs the SPI library.

This is a silly limitation that's always existed in Arduino. Years ago, I came up with a fix, but David Mellis (then Arduino's technical lead in charge of accepting contributions) changed his mind at the last minute. So it never got accepted.

It seems that there are different people in charge of accepting contributions now; also perhaps a slightly more accepting attitude? May be worth a pull request at some point to try again (probably presented as a brand-new pull rather than bringing up old history).

If that results in more delay or rejection, as a fallback strategy, just make it a Teensy-only change?

PaulStoffregen
03-18-2015, 11:38 AM
Yes Nantonos, that's pretty much my plan.

I also posted a message about it on their mail list. Predictably, that conversation has already wandered off-topic. Arduino is so filled with controversial design choices and trade-offs that even very obviously needed features like this can't possibly be discussed without wandering off topic to all that other junk people want changed.

They have become much more accepting of contributions since Cristian Maglie took over as their lead developer.

But if they don't accept this, or if it gets delayed, I'll just put it into Teensyduino and maintain it along with all the other patches.

KurtE
03-18-2015, 01:40 PM
Yes Nantonos, that's pretty much my plan.

Thanks Paul! I also agree that this is a way overdue feature for Arduino!

Another feature I always think is missing is some ability to for a project to have parameters to pass to the compiler. Things like, maybe in this project I want SoftwareSerial to only use PortX... Or maybe a way to set buffer sizes... I like some others have sort of solved this in some of my libraries, by putting all of the source code in header files, but I really don't like that approach.

I try to read through stuff that is posted on the Arduino Developers list, but often lose interest as many of the subjects and/or solutions. Example the print enhancements. Why not just include printf like you did, instead of adding some new cryptic syntax specific to Arduino... But I am getting off topic ;)

So again thank you! I think your idea to use the pre-processor sounds promising.

MichaelMeissner
03-18-2015, 02:11 PM
The problem with printf is that it is so general, it tends to lead to code bloat. On a teensy 3.1 with 128K of flash, that is not as much of an issue, but on a Lilypad with only 16K it might be more of an issue (let alone the ATtiny85's with 8K, but they usually don't have serial/usb support so it is not as much of an issue).

KurtE
03-18-2015, 02:30 PM
Sorry, I know that print stuff is completely off topic... And I understand about code size... But I don't think I would ever use things like:

Serial.print(3.141592, PRECISION(4) & FIELDSIZE(3));
Serial.print(22, RADIX(5) & FIELDSIZE(8) & ALIGNLEFT);
Serial.print(34, OCT & FIELDSIZE(8) & FORCESIGN & FILLZEROS);
But maybe it's just me.

MichaelMeissner
03-18-2015, 08:31 PM
KurtE at times I would use printf to get things aligned to the right number of columns. At the moment, I tend to do things like:



if (x >= 0 && x < 10)
Serial.print (" ");
else if (x >= -9 && x < 100)
Serial.print (" ");
Serial.print (x);


In general with the current Serial<x>.print functions, you don't pay the code cost for all of the types you don't use, as these functions are typically deleted by the linker since there are no references to them. With *printf however, you get everything, since it has to parse the string at runtime, though whether float/double support is in *printf depends on the installation. With 1.21 of Teensydunio, you have to use an asm to pull in the FP specific version of *printf. With Ardunio, you can't use float/double in *printf in the first place.

PaulStoffregen
03-19-2015, 03:16 AM
I think it's a real problem, cause it makes libraries seem like they don't work.

Well, it took me all day, but I finally got proper library dependency detection working.

Here's the pull request to Arduino.

https://github.com/arduino/Arduino/pull/2792

Even if they don't accept this, I'm definitely going to put it into future Teensyduino versions.

linuxgeek
03-19-2015, 07:42 PM
Awesome work, as usual!

I hope they include it. I've helped many people (for educational youth maker movement stuff) who have run into the dependency problem. Stalls people for weeks, not knowing how to proceed.

mixania
03-20-2015, 04:08 AM
Thank you Paul,
Support for the Arduino 1.6.1 certainly pushed me to finally order the Teensy 3.1. Been loving my Teensy 3.0 for almost 2 years now. I Thank you for your dedication for the project! Can't wait for some new hardcore Teensies.

EDIT: Is there a good guide for taking advantage of the 2,4, 8 & 16 MHz modes the Teensy 3.1 is capable of running on? Thinking of some low power applications there.

neilh20
03-20-2015, 05:51 PM
Awesome, purchased 4 boards when released, and just got my TeensyLCs working from scratch.
New Arduino install on Windows8.1 - I did a quick test of the Analog read with Led Flash (pin 13) and it worked - printing text to the serial monitor and flash the led.
Its always so amazing to see the ease of getting started with a Teensy board - and that takes a lot of work to make it easy.
I'm using the TeensyLC on a new board and put it out through OshPark - and should be getting that back in the next couple of days.
I was wondering is the boot/(Update:Mini54-->KL02 I read somewhere) a low power boot, and anybody done any low power testing yet on the TeensyLC. I know there was some beta testing earlier on, but can't find any follow on for that. thanks.

zachtos
03-20-2015, 10:11 PM
I am unable to use any version of Teensyduino past v1.2 until you are able to figure out why it made multi sound effect playback on the audio library worse. I mentioned it in the testing thread for v.121 and you said it was because I have 500+ sound files on the SD card, and it could be because of how the SD card library works. It also has a slight squeak noise as it opens certain files, but goes away when I reduce the number of files on the card. It performs even worse when you try to open files in rapid succession (100-200ms between open) and is totally unable to be used in the most recent version. This is in a product that we use as well, so I can't update our upcoming product until then.

Thanks,
-zsdicker@gmail.com

PaulStoffregen
03-20-2015, 10:21 PM
I am unable to use any version of Teensyduino past v1.2 until you are able to figure out why it made multi sound effect playback on the audio library worse.

As I recall, when you brought this up before and it came time to actually provide files, the realization that the number of files on the card was most likely causing the problem came up. I removed this from my list of pending issues to investigate.

I can and will investigate, but I really need you to do your homework first. You must provide a test case which you've confirmed works with version 1.20 and fails with 1.21. If it requires 100 or 500 files, we'll find a way. Worst case, we can ship a couple micro SD cards back and forth.

But please do not ask me to pour engineering time into investigating a problem that you haven't carefully verified does not happen with 1.20 and does happen with 1.21 using the EXACT same code and same data. If you have different data you're using with the 1.20 version, please get your files and test in order and make absolutely sure this really is a problem with the change from 1.20 to 1.21 and not something else you've done that's not identical in how you're testing each.

Let me know when you have a solid, confirmed test case.

PaulStoffregen
03-20-2015, 10:25 PM
I was wondering is the boot/(Update:Mini54-->KL02 I read somewhere) a low power boot, and anybody done any low power testing yet on the TeensyLC. I know there was some beta testing earlier on, but can't find any follow on for that. thanks.

Duff's Snooze library was added to 1.21. :)

Look in File > Examples > Snooze > deepsleep > pushbutton_pullup_deepSleep

duff
03-20-2015, 11:40 PM
Duff's Snooze library was added to 1.21. :)

Look in File > Examples > Snooze > deepsleep > pushbutton_pullup_deepSleep

Cool Thanks!

defragster
03-21-2015, 07:44 AM
... watching and saw that m#24 m#25 discussion . . . I wasn't sure if it was the same or better under 1.20 in the end.

zachtos: I'd suppose the content of the other files shouldn't matter so if you could take even 1 sample file and programmatically make the 100('s) of needed unique file named versions it would be easy to reproduce that from a batch/script file. Doing that and seeing the change in perf between 1.20 and 1.2x going forward could then be reproduced from the script and the one source file and no wait for snail mail.

Using the 'code' below in a DOS box as a '.bat' batch file with one file "_.wav" I get 285 copies from a clean directory.

If you could program around this in a sample sketch Paul could repro it with a single copy of "_.wav" on a formatted card.



FOR %%i IN ( 1 2 3 4 5 6 7 8 9 0) DO copy _.wav %%i*.*
rem FOR %%i IN ( A B C D E F G H I J) DO copy *.wav %%i*.*
FOR %%i IN (a b c d e f g h i j k l m n o p q r z t u v w x y z) DO copy ?.wav ?%%i*.*


Notes:
* This assume all files in a single flat directory
* If you have subdirectories I can make update to do that, this isn't elegant but it works
* It will create a clean FAT table with no file fragments on a clean 'disk'
* If this doesn't allow you to repro then the issue may be in the file management over FILE or DIR fragments.
* If you edit the 'rem' off line #2 you end up with 545 copies.
* Start with fewer files by removing any number of the values in one or more sets of parenthesis.
* You can get 10 unique wav files by starting with #.wav and putting 'rem' on the first line.

mxxx
03-21-2015, 10:43 AM
... watching and saw that m#24 m#25 discussion . . . I wasn't sure if it was the same or better under 1.20 in the end.


not very helpful, i know: but anecdotally, re play_sd_wav i think i can confirm there seems to be some deterioration in performance.

there were too many changes recently to say much more. fwiw: i still have 1.0.6 installed with 1.21beta-2, in which case performance is ok. using the same sketch with 1.6.1 and official 1.21 (120MHz, compiled with -O2), there's occasional hick-ups.

KurtE
03-22-2015, 01:37 AM
One thing I noticed today is the spi library updates for Arduino 1.0.6 is not the same as for Arduino 1.6.1. Example SPI1 is not defined in 1.0.6.

zachtos
03-24-2015, 04:05 PM
As I recall, when you brought this up before and it came time to actually provide files, the realization that the number of files on the card was most likely causing the problem came up. I removed this from my list of pending issues to investigate.

I can and will investigate, but I really need you to do your homework first. You must provide a test case which you've confirmed works with version 1.20 and fails with 1.21. If it requires 100 or 500 files, we'll find a way. Worst case, we can ship a couple micro SD cards back and forth.

But please do not ask me to pour engineering time into investigating a problem that you haven't carefully verified does not happen with 1.20 and does happen with 1.21 using the EXACT same code and same data. If you have different data you're using with the 1.20 version, please get your files and test in order and make absolutely sure this really is a problem with the change from 1.20 to 1.21 and not something else you've done that's not identical in how you're testing each.

Let me know when you have a solid, confirmed test case.

OK, I have compiled a test and simple code that proves the bug. I will share the files you can put on an SD card to replicate test:
test setup:
-Teensy 3.1 and audio shield, using amplifier line out left channel to amplifier then to speaker
-one copy of teensyduino 1.2 and arduino 1.06
-one copy of teensyduino 1.21 and arduino 1.61
-class 4 sandisk 4gb SD card (class 10 version made no difference for me)
-copy directory into root of SD card (large number files = 800 raw files)
-run playback interval set at 350ms (adjust volume variable as needed)
-faster you playback files, the worse the squeek/pop between files should get
-also different file numbers will have worse squeek/pop (how far into directory?)
-v1.06 should play a countdown verbally '1, 2, 3, 4'
-v1.61 should try to play same countdown, but skips many numbers randomly '1,3,4... 2,3,1, .. 3,4... 1,2,3...'


*I know bug got worse after version 1.61 arduino without my code changing at all. I can't play multi sounds at all anymore reliably!
*there is a 'squeek/pop' bug that I KNOW is somehow related to the number of files on SD card, it gets worse the lower you set playbackInterval
** if you try the same thing w/ only 4 files in the directory (one, two, three, four), the squeek bug goes away (may need to change file names on card).

Link to files (27mb rar file) (https://app.box.com/s/jfyor8174rhnh4oz8nu7c778arjpirk6)

Please note, I had a similar bug with the old arduino wave shield regarding squeeks/pops with large file numbers. I ended up solving it by using play files by index (example in old WAVE_HC google code libarary). Basically you indexed file names into an array before starting the program, then playback files by the file number/address on card instead. This would be very valuable to us, and I imagine it could be as easy as playByIndex() or something in the audio library, and an index setup command.

PaulStoffregen
03-25-2015, 02:38 PM
Ok, I've put this back on my list of stuff to investigate.

At this moment, I'm wrapping up the SerialFlash library. Then I'm going to look into the Lidar crash. And then a couple documentation tasks. Then probably this... so probably look for it sometime next week.

Donziboy2
04-02-2015, 11:11 AM
Paul is there any advantage to using Arduino 1.6.0 and 1.6.1 over 1.0.6?

PaulStoffregen
04-02-2015, 11:47 AM
Yes. I made more improvements to the serial monitor, which are in the 1.6.1 (and 1.6.2 beta) patches. If you use the serial monitor, especially on Windows, those improvements are very worthwhile. That stuff won't ever be backported to the older versions.

PaulStoffregen
04-02-2015, 11:51 AM
The new library manager in 1.6.2 is going to be pretty nice (already it's getting filled with a lot of libs). If you want only stable stuff, wait for 1.6.3 and the final Teensyduino 1.22 release. 1.6.2 is still a bit rough around the edges, though Teensy isn't depending on the new package system they built. If you're willing to try beta stuff, 1.6.2 should work ok, and you can see where things are going....

zachtos
04-04-2015, 10:53 PM
OK, I have compiled a test and simple code that proves the bug. I will share the files you can put on an SD card to replicate test:
test setup:
-Teensy 3.1 and audio shield, using amplifier line out left channel to amplifier then to speaker
-one copy of teensyduino 1.2 and arduino 1.06
-one copy of teensyduino 1.21 and arduino 1.61
-class 4 sandisk 4gb SD card (class 10 version made no difference for me)
-copy directory into root of SD card (large number files = 800 raw files)
-run playback interval set at 350ms (adjust volume variable as needed)
-faster you playback files, the worse the squeek/pop between files should get
-also different file numbers will have worse squeek/pop (how far into directory?)
-v1.06 should play a countdown verbally '1, 2, 3, 4'
-v1.61 should try to play same countdown, but skips many numbers randomly '1,3,4... 2,3,1, .. 3,4... 1,2,3...'


*I know bug got worse after version 1.61 arduino without my code changing at all. I can't play multi sounds at all anymore reliably!
*there is a 'squeek/pop' bug that I KNOW is somehow related to the number of files on SD card, it gets worse the lower you set playbackInterval
** if you try the same thing w/ only 4 files in the directory (one, two, three, four), the squeek bug goes away (may need to change file names on card).

Link to files (27mb rar file) (https://app.box.com/s/jfyor8174rhnh4oz8nu7c778arjpirk6)

Please note, I had a similar bug with the old arduino wave shield regarding squeeks/pops with large file numbers. I ended up solving it by using play files by index (example in old WAVE_HC google code libarary). Basically you indexed file names into an array before starting the program, then playback files by the file number/address on card instead. This would be very valuable to us, and I imagine it could be as easy as playByIndex() or something in the audio library, and an index setup command.

Let me know when you start investigating this problem. We are stuck at v1.06 until then. I also spent over 40 hours in the last month trying to solve the high file number audio squeak bug, and would be willing to pay for help at this point.

PaulStoffregen
04-05-2015, 12:07 AM
I actually started looking into it last night, but just looking at the code. The SD library files are exactly the same, so whatever happened must be something subtle. I wanted to do a quick code review before releasing 1.22.

This and the Lidar issues are near the top of my list to investigate after 1.22 is released (which I'm doing right now...)

Are you using Visual Micro or some other non-Arduino way of building your code? I'm planning to test using only the Arduino IDE.

zachtos
04-05-2015, 03:23 AM
I actually started looking into it last night, but just looking at the code. The SD library files are exactly the same, so whatever happened must be something subtle. I wanted to do a quick code review before releasing 1.22.

This and the Lidar issues are near the top of my list to investigate after 1.22 is released (which I'm doing right now...)

Are you using Visual Micro or some other non-Arduino way of building your code? I'm planning to test using only the Arduino IDE.

I am strictly using teensyduino and arduino. Easy design with the power of an ARM controller is very appealing for a small company like us. As you well know, I wear many hats as the lone engineer.

defragster
04-05-2015, 07:10 AM
zachtos: I was following a thread that lead to a link that ended here: https://forum.pjrc.com/threads/16758-Teensy-3-MicroSD-guide - from when SDfat got started and folks setting up and benchmarking.

I haven't set up any of this or looked at the samples - but I was wondering if any of the benchmarks referenced might show a difference from standard library examples from the 1.0.6 and 1.6.3 IDE's. Of course they may work perfectly - and you might need to mod them to do multi-file access to demo your situation.

If that gives a difference Paul can use that feedback - if not then it would be interference from another part of your project which would again be good feedback.

Also what happens if you use the 1.0.6 installation with TeensyDuino 1.22? That would point to either the changed libs getting to 1.22 or the IDE as the source.

PaulStoffregen
04-05-2015, 11:31 PM
I am going to get to the bottom of this, and in general really look into SD's efficiency, likely sometime in the coming week.

(this weekend was mostly burned up by a much-needed Linux reinstall on my computer, which I've been putting off for months due to Teensy-LC and then the rapid release of 4 Arduino versions)

The SD code also looks really slow for Teensy-LC, and there seems to be quite a bit of opportunity to improve it for Teensy 3.1 too. Before Arduino 1.6.x, I've always been really cautious about doing too much in these libraries, since I do very little testing on non-Teensy boards. Now that we have 1.6.x with the ability to isolate changes to only Teensy, it's time for me to really put some serious optimization into the normal SD library!

PaulStoffregen
04-09-2015, 05:57 AM
-class 4 sandisk 4gb SD card (class 10 version made no difference for me)


Oh, great, now I'm seeing this after copying all the files to a Sandisk Ultra 16 GB.

The only other SD cards I have here are unlabeled speed "Sandisk 8GB". I suspect they're counterfeits, not genuine Sandisk.

I'm going to try with these 2 cards. If neither reproduces the problem, I'm not sure what to do next....

defragster
04-09-2015, 07:24 AM
Is there only one way to format the cards? Different format type, and the fact that yours went from empty to full with a single linear copy means no fragments and a clean directory list could make a difference.

Do the file lend themselves to a modification of the standard benchmark test to find named list or wild card of all the files and read them with a time per file and overall logged. With a modified benchmark sketch just on file read zachtos could perform that as a baseline. His comparative results would point out the next direction/step.

I assumed I'd see 'benchmark' as a sample - looks like you could combine listfile and dumpfile examples easily enough without editing up a file list. Though you could optionally read the a counting number file between the other files.

defragster
04-09-2015, 08:55 AM
This compiles and will hopefully blink the light as each file reads without error. I didn't run as I have not set up for SD and never used this code before.
4051

Prints summary totals when done. To get individual per file data uncomment line below, it adds some delay() and the USB I/O will intermix with SD access:


// #define PRINT_PER_FILE // Define this and each file prints

Anxious to hear how close it is to working for one of you to post and share to the other to compare.

I should have counted bytes as I read them in DumpFile() to make sure the file size matches the read size.

Doing PER_FILE without delay()'s comparison would show USB impact if any.

PaulStoffregen
04-09-2015, 12:40 PM
I've got the test running now with my 8GB card. I'm able to reproduce the problems, squeeks on 1.0.6 TD 1.20 and skipped numbers and pops on 1.6.3 TD 1.22.

This is looking like a very subtle race condition somewhere, including managing access to the SD card and SPI bus between the main program and audio interrupt. I've found a few ways to affect the problem, but it's going to take some serious digging into the code to figure out exactly where it's going wrong.

I'm on it. This is looking like it's going to be a really tough one. Will post updates here as I learn more....

zachtos
04-09-2015, 04:02 PM
I've got the test running now with my 8GB card. I'm able to reproduce the problems, squeeks on 1.0.6 TD 1.20 and skipped numbers and pops on 1.6.3 TD 1.22.

This is looking like a very subtle race condition somewhere, including managing access to the SD card and SPI bus between the main program and audio interrupt. I've found a few ways to affect the problem, but it's going to take some serious digging into the code to figure out exactly where it's going wrong.

I'm on it. This is looking like it's going to be a really tough one. Will post updates here as I learn more....


Thanks, I appreciate this greatly. Our product will be very professional grade after stamping out this final squeak bug. If not, play files by index may be a work around (open all files at start and store in index array for opening later). I anxiously await a solution.

PaulStoffregen
04-10-2015, 08:46 PM
Just a quick update... I'm actively working on this. It's turning out to be a combination of several subtle interrupt safety issues and also some places disabling interrupts too long.

The good news is looking like the SD and SPI libraries certainly have the raw performance needed. Latency to open a file near the end of the directory is about 50 ms with the card I'm testing.

At the moment I'm digging into parts of the SD library I've never touched before. There seems to be some static data structures somewhere buried in there, which also need proper management for shared access.

stevech
04-11-2015, 12:22 AM
Would the 50mSec latency to open the file be divided among several SPI transactions, each releasing the SPI port for a while?

PaulStoffregen
04-11-2015, 01:29 AM
Yes. Well, it will be with the updates I've been developing today.

It turns out the other major obstacle is the single-sector cache in the SD library. That's where the noises and failure to open files are coming from. This afternoon I've been working with Bill's SdFat code in the utility directory, to add functions to properly track the usage time window for each cached sector. Once that's done, I should be able to expand the cache to multiple sectors, which will allow non-conflicting directory searches and playback, and it should also improve performance, since the single sector cache experiences a lot of cache misses.

For years I've resisted really digging into the SD library code. I just patched the low-level card access. Well, now I'm finally overhauling the entire SD library so it will truly perform properly for these much more demanding uses.

I hope to have a test version posted early next week.

zachtos
04-11-2015, 02:58 AM
Yes. Well, it will be with the updates I've been developing today.

It turns out the other major obstacle is the single-sector cache in the SD library. That's where the noises and failure to open files are coming from. This afternoon I've been working with Bill's SdFat code in the utility directory, to add functions to properly track the usage time window for each cached sector. Once that's done, I should be able to expand the cache to multiple sectors, which will allow non-conflicting directory searches and playback, and it should also improve performance, since the single sector cache experiences a lot of cache misses.

For years I've resisted really digging into the SD library code. I just patched the low-level card access. Well, now I'm finally overhauling the entire SD library so it will truly perform properly for these much more demanding uses.

I hope to have a test version posted early next week.

I anxiously await, while plowing ahead myself on other parts of the project. We just sent our second video to (-a popular American TV show-) for review (second year now). Hopefully we make it on this time! All thanks to the rapid prototyping powers of Teensy and Arduino combined.

stevech
04-11-2015, 03:10 AM
A 50mSec mutex lock on the SPI port would be OK in most instances, but not all.

PaulStoffregen
04-11-2015, 10:27 PM
I've been pretty quiet the last couple days.... better SD caching that's interrupt safe is turning into quite a project!

PaulStoffregen
04-11-2015, 10:32 PM
If anyone's wondering where I've gone... well, I hope to catch up to many conversations on Monday. This weekend I'm working heavily on massive SD library improvement.

defragster
04-12-2015, 09:11 AM
Paul: Any chance you are/will be testing the SD card SPI usage with this really cool color display for SPI sharing with its built in reader? https://www.pjrc.com/store/display_ili9341.html

It is in stock in case you don't have one and I'm sure you could get same day delivery - even on Sunday ;-) and you don't have to go back to work until Monday

stevech
04-12-2015, 04:30 PM
Does the K20 have an SD interface peripheral on-chip (not SPI)? Enabling use of 1, 2, 3, 4 channels (one MOSI, 1-4 MISO) in SD mode, and similar in MMC mode?

PaulStoffregen
04-15-2015, 01:16 PM
Just another quick update... I'm still very actively working on this problem.

Over the last several days, I've ended up rewriting the entire SD+SdFat library. Well. most of it so far, but only reading, not writing to the card. Originally I wanted to just patch Bill's code, and I made a pretty good attempt at that last week. But there were just too many complex paths to analyze, especially in the directory parsing, to resolve all the ranges where pointers still depended on cached data. Bill's put a lot of work into reducing the AVR code size, and most of his code is still pretty readable, but it was never designed with a multi-sector, interrupt aware cache in mind, which needs to be notified when the filesystem is and isn't depending on buffers to remain fixed.

Ultimately, I started fresh. Fortunately, I'm pretty familiar with FAT filesystems, from the old MP3 player days when I wrote simpler filesystem code all in 8051 assembly.

This time around, I created a SDCache object, where the static cached sector buffers have usage counts of the number SDCache objects currently requiring them. I'm using the object destructor to manage when the cache can allow a buffer to be released back into the pool to be reused. By writing all the code fresh, I can structure things with these objects and pointers to allow the cache to properly serve multiple concurrent, interrupt-based and main program users.

This morning I got the new code playing the stress test, with 1, 2, 3, 4 all playing and without any chirps or audible artifacts (at least nothing I can hear within the noise floor on these samples using good over-ear headphones). There's still some bugs to work out, like a memory leak that eventually strikes, and quite a bit of the new code still needs to optimization.

Anyway, the good news is an excellent solution is in sight. Well, with the caveat that at least for quite some time, there will be a choice between the original SD library which can read and write, and this new one that's read-only. Eventually I'll add write support, but that's not going to happen this week.

I hope to have code to share in a day or two. This has been a really tough problem, but the end is finally in sight.

PaulStoffregen
04-15-2015, 01:33 PM
The new library allows playbackInterval to be set to any value, even zero. But below about 100 ms, the sounds don't finish enough of the word to be recognizable ("4" seems to be longer than the other three), before the loop repeats and starts the same object playing again from the beginning, so it all ends up being a big jumble of unintelligible sound.

zachtos
04-15-2015, 02:04 PM
Just another quick update... I'm still very actively working on this problem.

Over the last several days, I've ended up rewriting the entire SD+SdFat library. Well. most of it so far, but only reading, not writing to the card. Originally I wanted to just patch Bill's code, and I made a pretty good attempt at that last week. But there were just too many complex paths to analyze, especially in the directory parsing, to resolve all the ranges where pointers still depended on cached data. Bill's put a lot of work into reducing the AVR code size, and most of his code is still pretty readable, but it was never designed with a multi-sector, interrupt aware cache in mind, which needs to be notified when the filesystem is and isn't depending on buffers to remain fixed.

Ultimately, I started fresh. Fortunately, I'm pretty familiar with FAT filesystems, from the old MP3 player days when I wrote simpler filesystem code all in 8051 assembly.

This time around, I created a SDCache object, where the static cached sector buffers have usage counts of the number SDCache objects currently requiring them. I'm using the object destructor to manage when the cache can allow a buffer to be released back into the pool to be reused. By writing all the code fresh, I can structure things with these objects and pointers to allow the cache to properly serve multiple concurrent, interrupt-based and main program users.

This morning I got the new code playing the stress test, with 1, 2, 3, 4 all playing and without any chirps or audible artifacts (at least nothing I can hear within the noise floor on these samples using good over-ear headphones). There's still some bugs to work out, like a memory leak that eventually strikes, and quite a bit of the new code still needs to optimization.

Anyway, the good news is an excellent solution is in sight. Well, with the caveat that at least for quite some time, there will be a choice between the original SD library which can read and write, and this new one that's read-only. Eventually I'll add write support, but that's not going to happen this week.

I hope to have code to share in a day or two. This has been a really tough problem, but the end is finally in sight.

That is great news. I can't wait to show my product with these fixes, it's going to be awesome! I love the Teensy and Arduino IDE! I will test the new library as soon as you are ready. I know the audible chirp at high file numbers on the SD card was a problem shared by both version, but Does it also fix the issue with v106 to v161 where some of the files were skipped?

PaulStoffregen
04-16-2015, 11:14 AM
Ok, I've committed a pile of new code to github. This is still at a very early stage, but at least in a couple lengthy tests here it was looking really good.

The main thing is the SD library.

https://github.com/PaulStoffregen/SD

You'll need to edit SD_t3.h, line 30 (https://github.com/PaulStoffregen/SD/blob/master/SD_t3.h#L30). By default, the normal SD library is used. You must uncomment that line to compile the new code.

The new SD code has quite a number of limitations. It can't parse pathnames, so you can only open files in the root directory. It can't write to the card. A few of the SD functions, like openNextFile() aren't implemented yet. I've only tested on 2 cards so far, both FAT32 format, so FAT16 (2GB or less) is utterly untested so far. Remember, this is a complete ground-up rewrite of the SD library. Expect some issues.....

But the larger cache and playing more than 1 file at a time while opening others works! Or at least it has on tests I've been doing here.

You'll also need the latest Audio library from github. It was disabling interrupts, as a not-so-great workaround for the SD library problems. This change removes that, so audio can play during the lengthy open while the library has to parse the huge directory with hundreds of files.

https://github.com/PaulStoffregen/Audio/commit/4c6e76e2b4b0888874fc9b60c843bfb9c4248b8a

The other minor thing, which probably doesn't matter (but I've done all my recent testing with it) is this little patch to kinetis.h:

https://github.com/PaulStoffregen/cores/commit/8cd4703817f4e0d143e4686b101c4f34614040bd

I've been doing all my testing on Arduino 1.6.3. In theory, any copy with Teensyduino 1.22 installed should give the same results. Well, except the old versions only run the compiler with code size optimization, so you probably want one of the newer version with speed optimization (in the Tools > CPU Speed menu).

zachtos
04-18-2015, 03:32 AM
Thanks, let me know if you change any more code. I will test on Monday or Tue as soon as I return.

PaulStoffregen
04-18-2015, 06:22 AM
For now, I'm working on the SerialFlash library, and a couple other projects. More changes are very unlikely, until you or others have some feedback... or until I get back to the audo library.

defragster
04-18-2015, 08:06 AM
<SPIFlash.h>? Is there a generally best chip make for size/speed/reliability that you expect to work well - test against the most with best results?

... so little to do . . . so much time . . . < strike that, reverse it >

PaulStoffregen
04-18-2015, 12:27 PM
Until the last few days, I had only tested with the 16 MByte Winbond chip.

The 32+ MByte chips have many annoying incompatibilities. I'm working on adding code in SerialFlash to automatically detect and properly handle the differences. On my desk right now is a 64 and 128 Mbyte Micron chips, and a 16 Mbyte Spansion chip. I have a couple bigger Spansion chips coming from Digikey next week, I believe 32 and 64 Mbyte sizes.

If you want to play with something now that's the most compatible, use the Winbond W25Q128FV.

Eventually, I plan to make all (or almost all) of them "just work".

The one possible gotcha might be the Winbond W25Q256. It apparently has issues with certain write & erase commands in 32 bit addressing mode. I can't find a reputable distributor. I ordered a couple from Aliexpress merchants, but I'm not hopeful those will end up being genuine or even working chips.

stevech
04-19-2015, 01:14 AM
I've used several sizes of Spansion and one of Micron - SPI mode. The only differences I have to deal with are


flash sector sizes - some have the default of some smaller sectors in low memory; you can one-time-program these to use uniform sized sectors if your app prefers that. In my driver, I have a compile-time constant of what chip ID is in use and whether uniform sector sizes are used and a table of sector sizes. So the library is compiled for a particular SPI flash chip and any number of same-sized chips, along with a table of chip selects for each chip if there are more than one.

Page buffer (RAM, on chip) sizes -smaller chips tend to have 256B and larger have 512B.



One could make these run-time choices for a given suite of chip alternatives. But I'm doing compile-time for 1-n of same-type SPI flash chips.

Now I've worked on SDIO and uSD chip driver... that's a bit easier. No chip selects. Fortunately the low level SDIO driver is from the MCU vendor's HAL support. Polling or DMA - because SDIO is a bit more complex that SPI. (not Freescale targets)
Complexity arises if you try to use 4 serial channels. So for now, I'm using just one channel at 24Mbps. The SD_CLK speed is the read/write constraint, assuming the SD chip is not an old/slow one.

PaulStoffregen
04-19-2015, 03:08 AM
Did you use a single or multi-die Micron chip? Did you write the low-level code, or use something provided by a vendor?

stevech
04-19-2015, 04:35 AM
Two dies, one package. For SPI, I did the low level code - low level meaning there's an SPI driver with both polling and DMA options.
I have older code originally for the AVR which uses no driver per se, just direct I/O with the SPI port and crude ppolling.

The code I did provides a block I/O read/write (auto-erase) and seamless addressing for read/write that cross sector and die/chip boundaries, I did. So the API can just deal with address ranges.

For the second project, I did use DMA (that code is in the HAL) so the CPU can do other things or sleep (lower power) during the DMA.

here forward, I think I'll prefer SDIO and either uSD cards or dies. With that HAL driver there's DMA and FATFS as plug and play.
This is all not freescale.

I recently tried out Kinetis Design Studio with the Freescale CMSIS/HAL but it is so far not usable for me, wheres the "other" is easy and comprehensive.

zachtos
04-20-2015, 03:14 PM
Ok, I've committed a pile of new code to github. This is still at a very early stage, but at least in a couple lengthy tests here it was looking really good.

The main thing is the SD library.

https://github.com/PaulStoffregen/SD

You'll need to edit SD_t3.h, line 30 (https://github.com/PaulStoffregen/SD/blob/master/SD_t3.h#L30). By default, the normal SD library is used. You must uncomment that line to compile the new code.

The new SD code has quite a number of limitations. It can't parse pathnames, so you can only open files in the root directory. It can't write to the card. A few of the SD functions, like openNextFile() aren't implemented yet. I've only tested on 2 cards so far, both FAT32 format, so FAT16 (2GB or less) is utterly untested so far. Remember, this is a complete ground-up rewrite of the SD library. Expect some issues.....

But the larger cache and playing more than 1 file at a time while opening others works! Or at least it has on tests I've been doing here.

You'll also need the latest Audio library from github. It was disabling interrupts, as a not-so-great workaround for the SD library problems. This change removes that, so audio can play during the lengthy open while the library has to parse the huge directory with hundreds of files.

https://github.com/PaulStoffregen/Audio/commit/4c6e76e2b4b0888874fc9b60c843bfb9c4248b8a

The other minor thing, which probably doesn't matter (but I've done all my recent testing with it) is this little patch to kinetis.h:

https://github.com/PaulStoffregen/cores/commit/8cd4703817f4e0d143e4686b101c4f34614040bd

I've been doing all my testing on Arduino 1.6.3. In theory, any copy with Teensyduino 1.22 installed should give the same results. Well, except the old versions only run the compiler with code size optimization, so you probably want one of the newer version with speed optimization (in the Tools > CPU Speed menu).

Paul, this is still not working properly for me. I have multiple SD cards (4gb, 1gB sandisk class 4 and a samsung class 10, 16gb), they all still skip numbers at fast speeds.

I think the squeeks/pops are less, but I still get them at fast playbackInterval of 150ms or less. Also it still skips numbers at 500ms or less, which does not work for me. I'm not 100% sure I have the patch installed correct. I did a clean install of Arduino 1.63, teensyduino 1.22, audio library you linked, core update you linked, SD library you linked and I deleted the old libraries/cores. I uncommented the SD_t3.h, line 30. Am I missing a step or did you miss a step for me? I am really seeing no change, so I suspect something is up with directions on one of our sides. I am formatting with SDformatter v1.4 which turns to FAT32 cards, Code I am using:


#include <Audio.h>
#include <Wire.h>
#include <SD.h>
#include <SPI.h>

//////////////////////////////////////////////////////////////////////////
//////////////////////// Audio Setup ///////////////////////////
AudioPlaySdRaw raw4; //channel 4 playback
AudioPlaySdRaw raw3; //channel 4 playback
AudioPlaySdRaw raw2; //channel 4 playback
AudioPlaySdRaw raw1; //channel 4 playback
AudioMixer4 mixer1; //combines up to 4 channels, can play even more if needed by more mixers
AudioOutputI2S i2s; //I2S type playback (opposed to I2C etc)
AudioConnection patchCord1(raw4, 0, mixer1, 3);
AudioConnection patchCord2(raw3, 0, mixer1, 2);
AudioConnection patchCord3(raw2, 0, mixer1, 1);
AudioConnection patchCord4(raw1, 0, mixer1, 0);
AudioConnection patchCord5(mixer1, 0, i2s, 0);
AudioControlSGTL5000 sgtl5000; //audio codec chip
//////////////////////////////////////////////////////////////////////////
const float maxVolume = 0.1;//set speaker volume
const int playbackInterval = 500; //time between files in milliseconds

void setup()
{
AudioMemory(30); //memory usage usually around 6-7, more mixers use more memory
sgtl5000.enable();

mixer1.gain(0, maxVolume); //channel, volume
mixer1.gain(1, maxVolume);
mixer1.gain(2, maxVolume);
mixer1.gain(3, maxVolume);

SPI.setMOSI(7); //move from pin 6 to pin 7
SPI.setSCK(14); //move from pin 13 to pin 14
SD.begin(10); //set SD card cable pin select to pin (#10)
}

void loop()
{
raw1.play("300.RAW");
delay(playbackInterval); //wait to open next file
raw2.play("700.RAW");
delay(playbackInterval); //wait to open next file
raw3.play("600.RAW");
delay(playbackInterval); //wait to open next file
raw4.play("050.RAW");
delay(playbackInterval); //wait to open next file
}

PaulStoffregen
04-20-2015, 03:29 PM
Also it still skips numbers at 500ms or less, which does not work for me. I'm not 100% sure I have the patch installed correct.


It's almost certainly not installed properly. :(

I know there's a lot of separate pieces to get right. Later this week I'll put together a beta installer. That's the way I can help.

zachtos
04-20-2015, 04:48 PM
It's almost certainly not installed properly. :(

I know there's a lot of separate pieces to get right. Later this week I'll put together a beta installer. That's the way I can help.

OK, well I tried installing clean w/o luck. I put the updated audio library, core and SD library into Teensyduino 1.20 and Arduino 1.06 (last version that works for me with multi-sound playback). Lose sound if I uncomment USE_TEENSY3_OPTIMIZED_CODE . Any idea what would cause the SD updated library not to work with that version?

Otherwise, the audio portion of our product is stuck for now.

PaulStoffregen
04-20-2015, 04:53 PM
Any idea what would cause the SD updated library not to work with that version?

Any of the many pieces not installed as intended....



Otherwise, the audio portion of our product is stuck for now.

As I said, I'll put together an installer later this week.

I've published all the raw source code. Packaging it up and testing the installers takes time... time I will put into this, but I can't do it immediately. It will come in a matter of only days.

If you can't get the many pieces put together, which admittedly isn't easy, just wait a little while for me to put in more work to make it easy to install.... and please understand generating the Teensyduino installers that automatically do so much to install thousands of files in exactly the right way so everything "just works" does indeed involve quite a lot of effort on my part.

defragster
04-20-2015, 05:58 PM
... and supporting multiple OS platforms on multiple IDE versions for multiple hardware devices . . . with thousands of related files . . .

zachtos
04-24-2015, 02:13 PM
Any updates on the sd card fix patch installer?

zachtos
04-28-2015, 01:33 AM
Any updates on this? We are willing to make donations to keep wheels of progress spinning...

PaulStoffregen
04-29-2015, 07:00 PM
Any updates on this?

Here it is.

https://forum.pjrc.com/threads/28499-Teensyduino-1-23-Beta-1-Available

After installing, you MUST edit SD_t3.h. The new/experimental SD stuff is disabled by default. Read the comments near the top of that file to find the line to uncomment which enables it.



We are willing to make donations to keep wheels of progress spinning...

All this development is funded by sales of Teensy. Buying more Teensy, or recommending it to others is the way to donate!

A quick YouTube video, even with shakey-cam footage, but with some voice explanation of what it does, showing something awesome you've made with Teensy actually can help quite a lot.

zachtos
04-29-2015, 07:41 PM
Soooo Happy right now, working great, must share with team.

mxxx
05-26-2015, 04:04 PM
The new SD code has quite a number of limitations. It can't parse pathnames, so you can only open files in the root directory. It can't write to the card. A few of the SD functions, like openNextFile() aren't implemented yet.

Paul -- any chance you'll implement the openNextFile() etc stuff any time soon? looking at dir_t3.cpp, it's quite beyond me.

stevech
05-26-2015, 09:19 PM
Am I correct that the K20 used in the T3.1 and LC do not have an SDIO interface (such that uSD cards must use SPI)?

PaulStoffregen
05-27-2015, 01:00 AM
Paul -- any chance you'll implement the openNextFile() etc stuff any time soon? looking at dir_t3.cpp, it's quite beyond me.

Done!

https://github.com/PaulStoffregen/SD/commit/f62f98c92d74c932c8462ef1f0f112f107a8994c

Well, I think it's done, but I've only tested with the listfiles example using one small set of files+dirs on a single SD card.

Please let me know how it works for you? Don't forget to uncomment USE_TEENSY3_OPTIMIZED_CODE...

mxxx
05-27-2015, 11:58 AM
Done!

https://github.com/PaulStoffregen/SD/commit/f62f98c92d74c932c8462ef1f0f112f107a8994c

Well, I think it's done, but I've only tested with the listfiles example using one small set of files+dirs on a single SD card.

Please let me know how it works for you? Don't forget to uncomment USE_TEENSY3_OPTIMIZED_CODE...

oh, neat, thank you! it compiles fine; no access to hardware at the moment but i'll report asap.

PaulStoffregen
05-27-2015, 03:50 PM
I still haven't implemented the path traversal stuff. Will do that soon.

You can open files in subdirs using openNextFile(). But normal SD.open() still only works for the root dir, because it's not parsing pathnames yet.

PaulStoffregen
05-28-2015, 01:03 AM
I've added pathname traversal, so you can now (in theory) use SD.open("/subdir/subdir/filename.txt");

https://github.com/PaulStoffregen/SD/commit/40b37908ac57232f3b99cc6b56a94503c85de375

mxxx
06-10-2015, 06:32 PM
Please let me know how it works for you? Don't forget to uncomment USE_TEENSY3_OPTIMIZED_CODE...

ok, I only got back yesterday, so couldn't try until today -- it almost works for me. i've been testing with play_sd_wav, in which case I get pops every now and again.

i've also edited sd_play_wav:: play() along the lines suggested (added AudioStopUsingSPI()); kinetis.h by now already seems to come with "volatile("CPSID i":::"memory");" (I'm on 1.6.4 / teensy 1.23-beta). if i comment out USE_TEENSY3_OPTIMIZED_CODE again / go back to regular SD, the pops disappear, so I assume the file is ok. not sure what might be the problem. here's my test code (i'm triggering with an external pulse on pin 0; note the SGTL5000 init code snippet is missing, as I'm using a different codec).





#include <Audio.h>
#include <Wire.h>
#include <SD.h>
#include <SPI.h>


#define CS_MEM 6
#define CS_SD 10
#define CLK_L 0 // left clock input

volatile uint8_t LCLK; // left channel clock

void CLK_ISR_L()
{
LCLK = true;
}

AudioPlaySdWav wavL;
//AudioPlaySdWav wavR;
AudioMixer4 mix;
AudioOutputI2S codec;

// Create Audio connections between the components
//
AudioConnection c1(wavL, 0, mix, 0);
AudioConnection c2(wavL, 0, mix, 1);
AudioConnection c3(mix, 0, codec, 0);
AudioConnection c4(mix, 0, codec, 1);

// using pcm5102a
// AudioControlSGTL5000 audioShield;


void setup() {

AudioMemory(15);
pinMode(CS_SD, OUTPUT);
pinMode(CS_MEM, OUTPUT);
digitalWrite(CS_MEM, HIGH);

pinMode(CLK_L, INPUT_PULLUP);

attachInterrupt(CLK_L, CLK_ISR_L, FALLING);

SPI.setMOSI(7);
SPI.setSCK(14);
if (SD.begin(CS_SD)) Serial.println("ok");

}

void loop() {

while(1) {

if (LCLK) {
LCLK = false;
wavL.play("ATARI.WAV");
}
}
}



edit. similar behaviour with play_sd_raw. in this case no pops, but the audio file sounds chopped up, as if playing from somewhere in the middle of the file and then wrapping around; it sounds perfectly normal when I revert to regular SD. as it seems to be working for others, I'm beginning to wonder whether I haven't missed something ? -- kinetis.h, play_sd_raw:: play() -- anything else that might need editing?

PaulStoffregen
06-10-2015, 09:32 PM
Can you send me the files you're playing, like ATARI.WAV? If so, I'll put this on my list of things to test.

mxxx
06-11-2015, 06:37 AM
Can you send me the files you're playing, like ATARI.WAV? If so, I'll put this on my list of things to test.

ok, where do I send it to? i didn't want to post it because of IP/copyright ... it's a/the official atari "corporate tag" from the early 1980s (suzanne ciani, actually); maddening, but i found voice samples are good for testing.