Teensy Audio Shield Serial Ram - chip compatibility question

Status
Not open for further replies.

dimitre

Well-known member
Before answering, it's important to understand the external memory doesn't function as general purpose memory. It doesn't work that way. This isn't the same as getting more memory by changing from Teensy 3.2 to Teensy 3.6.

Both of these chips can work, but for very different purposes.

Currently, the only object which supports serial flash is this:

https://www.pjrc.com/teensy/gui/?info=AudioPlaySerialflashRaw

Likewise, if you add the serial RAM, this is currently the only object which can use it:

https://www.pjrc.com/teensy/gui/?info=AudioEffectDelayExternal

In the future I'm planning to add more pre-recorded playing options for the flash chip. The RAM might get a live sample-then-play object someday. But in general, if you want more memory for anything else, Teensy 3.6 is the most you can get.
 
Hey Paul, thanks for the detailed answer. In fact I've ordered both a serial ram and a flash solution and will see which is better.
I'm altering some modules like AudioPlaySdRaw to be able to access different points of the file randomly (which microsd complains a little bit because of the nonsequential speed)

Probably Flash will be easier for me because of the similarity of working with SD. card
But I would love to be able to write down a RAW audio directly to AUDIO_MEMORY_23LC1024, and play it back from any point, shuffle pieces, maybe reverse speed and so on.

In other hand I'll be playing with my Teensy 3.5 and audio next week too.
Cheers
 
Chip is working great, it has actually 16Mb of space!
I've ported all the code I was using from SD_t3.h to SerialFlash, working great, thanks for the similar functions.

I've experiencing erratic behavior from time to time, sometimes SerialFlash takes almost one minute to start working properly,
I've been reading SerialFlash readme and I suppose it has to do with file rewriting when erasing.
Any ideas on that?

Thank you
 
Last edited:
Looking good
IMG_8596.jpg
 
Thanks Frank, one question: is it mandatory to overwrite 0xFF in an entire erased file when using Flash to be able to write again? I'm a newbie in that subject.
If it is mandatory maybe I should begin using some Serial Ram chips to get instant results, as it was a digital guitar effect.
Thank you
 
FLASH is such that 1's can be written to 0's to change their value. So starting at 0xFF means they can take on any value. Formatting put's all bytes to 0xFF. Once a ZERO is 'written' only a format can undo it.
 
Thank you defragster! hope this thread help others too.

About SRAM chip, I've research a little bit and it seems the one recommended in Teensy Audio Adaptor Board is the best you can get (23LC1024).
At least I can't find any with more than 1Mbit, Sop-8.
Do you think there are chips with more memory out there?
Thanks
 
Hey Frank thanks, it is an amazing project and I'll be ordering one to test soon.
Just to update things here, I've overcome the overwrite problem by creating a new file on each record, and start erasing the previous file after recording the new one.
This way Teensy will only be busy overwriting when playing back files, it is working great with two simultaneous tracks now.
Maybe I can even use the SD card this way.

For some reason as soon as I plug the synthesizer in Line In, even without sound the built in LED starts to fade a little bit, as seen in this video:
Have anybody else noticed it? is this a matter of concern? (I'm aiming at using in a live performance in near future)

Thank you!
 
Sorry, answering my last question, pin 13 is part of the communication, so it is natural the LED is blinking.
Other question, when not turned on (plugged on usb), the line out from teensy audio produces a noise, is there any way to avoid it?
Thanks
 
Thank you all! Just sharing the actual state of the project:
Actually building some pedals to activate with foot, and a midi out port to sync BPM with a drum machine
 
The terms NAND and NOR, which technically describe logic functions, are normally used in the context of memory to describe Flash, not RAM.

So basically, I don't understand your question. Maybe you could be more specific? Actual part numbers with links to their datasheets would be best. Some explanation of what you want to actually accomplish would also go a long way towards helping us to help you.
 
Last edited:
W25M02GV has not been tested. I do not know if it will work.

Any idea where I can buy this chip? Digikey has it listed, but no stock and full reel minimum quantity.
 
I'm wondering if they newer SRAM chips are compatible with Teensy Audio

VTI7064MSME
https://datasheet.lcsc.com/szlcsc/Vilsion-Tech-VTI7064MSME_C139966.pdf

LY68L6400SLIT
https://datasheet.lcsc.com/szlcsc/Lyontek-Inc-LY68L6400SLIT_C261881.pdf

both with 64Mbit Serial SRAM (or Pseudo SRAM)
if yes this memory could be a serious addon for the Teensy Audio

Will it work? Yes and no.

#1) They require a bit of startup work. You must hold SCLK low and CS# high during power on sequence, then issues a couple custom commands to reset the device. Not a big deal but you don't do this on conventional SRAM parts.

#2) These are conventional DRAMs wrapped in a SPI interface. Since DRAMs cells decay over time, they need to be periodically refreshed, this refresh blocks regular operations, and this refresh is needed quite frequently. Both those parts use the rising edge of CS# to trigger the refresh operation. If you leave CS# low too long during a burst the memory will not refresh and will start to corrupt it's contents.

So how long can you burst for? One of those parts has max CS# low for 8 us, the other is 4 us. At 8 us, a 20 MHz clock is 50 ns. This means you can only burst for 8000/50 = 160 SCLK cycles. It takes 32 clocks to start a command plus 8 bits per byte after that. So your bursts are limited to about 16 bytes of data. If you're cool with that, you're good.

So, if you tend to issue one write or read per SPI.beginTransaction()/SPI.endTransaction you won't notice. But that is also a VERY slow inefficient way to use SPI. If you transfer more than one byte, you must be very careful not to exceed the max transfer time. You must also account for any idle time the processor puts between calls to SPI.transfer(). If you are using the SPI DMA capabilties, you must limited your burst size accordingly.

Practically speaking, for high-performance audio applications, you really want to use DMA to burst audio blocks to and from the memory and you probably want to do this for an entire audio block which is 256 bytes for the standard 128 samples. So you need to be triggering a lot of DMA transfers just to copy a single block of audio.

So yeah, they should work with some pretty big caveats.
 
Another rather expensive alternative is the CY15B104Q: 4-Mbit (512 K × 8) Serial (SPI) F-RAM. It's in a slightly different 8 pin package and haven't checked the actual pinout, but will give you 4 times the length as the 1M part.
 
There's actually a new 4Mbit SPI now so no need for FRAM if that's enough capacity. Check out ISSI IS62WVS5128
 
Status
Not open for further replies.
Back
Top