additional 8bit SRAM (parallel/serial)

[old gregg]

Hi,

I'm playing around with the idea of a 8bit audio sampler. I wish to have the sampling rate at 44khz.

I need (for obvious reasons) an external SRAM to write data in it and read from it.  What would the most efficient in terms of speed/space ?

parallel seems to be the quicker but requires tons of pin and is mostly huge. The serial version takes less space but needs to shift the 16bits adress, the instruction and the data (the same goes for the reading).

the micro will be clocked at 20mhz (atmega 328 as a starting point).

Do you have any kind of experiences with that serial/parallel data management ?

If the project really kicks in, I might go for a higher resolution (could be a nice project for a bigger uc as ARM).

[rob77]

i would suggest to start with ARM right away... do some math and you'll realize why

[cloudscapes]

I've built many samplers/loopers! usually I'd use one of microchip's serial SRAMs.

I think 44khz is pretty optimistic on an atmega. it just might be barely possible with pure ASM and parallel memory, but difficult. I'd say since you're already aiming for lo-fi (8bit), just stick with 11-22khz. 8bit & 44khz is a weird combo. you'll need overly aggressive filtering for the 8bit headroom, which will probably smother a third of your higher khz anyway

here's a sampler I did with an atmega328 + serial ram + serial adc. with the serial stuff, I think I benchmarked it at around 15khz. I wasn't using proper filtering either, so it sounds VERY crunchy. I was overclocking it at 12mhz to be able to keep the micro powered at 3.3v, since at the time, there was no 5v serial sram.


know the WTPA sampler? this should have a lot of good info, since it's roughly the same hardware:
http://blog.narrat1ve.com/

I've since moved onto 32bit micros for sampling, and I do NOT regret it. 96khz is a breeze. even without using I2S or other sound interfaces.

[westfw]

I need (for obvious reasons)

It's not obvious to me.

atmega 328

Oh.  WHY?!
Why don't you just pick a different microprocessor with more memory?  There are cheap ARM development boards with 128k or more of RAM *and* audio DACs.  Do you want to work on an audio sampler, or do you want to be mired in implementing your own RAM infrastructure?

[cloudscapes]

to be fair, samplers are perfectly doable on at atmega328. he just needs to dial down the samplerate quite a bit.

[old gregg]

I was pretty optimistic with the sampling rate indeed.

It's not obvious to me.

the atmega is only 2K SRAM. It  Seems very small for such application even with a 4K or 8K sampling rate. I'd like to move toward the ARM structure and such but I need to read more about this structure and the tool chain.

Do you want to work on an audio sampler, or do you want to be mired in implementing your own RAM infrastructure?

Well at the start it was to do something with what I've on hands.A silly sampler for my own amusement. but I could move to something more interesting if needed. The challenge could be interesting but I'm more into having something which work good than spending hours on a hardly doable thing.

The atmega 328 thing seems doable but very lofi indeed.

cloudscapes, actually I've known your work for years. I read your blog several time !

you did what I want to do.  A sampler with variable speed reading and start/stop pot to read only a portion of the sound.

[Scrts]

On the other hand, large atmegas have parallel memory interface.

[Yansi]

Exactly, no need to stick with crappy M328, go for bigger MCU just suitable for this kind of application. ARM might be here to big to swallow, but you can use at least atmega with memory interface. Or, raise your level to xmega series.  DMA and other sorts of things might get handy.
But please, do not try us saying you need and arduino bootloader with all its crap toolchain. No! That arduino stuff is a waste of processing time. For some realtime sound work, arduino is a no go!

Serial SRAMs are not suitable, because how you said - need to shift in 16 (or more!) address bits, and data and some overhead stuff. SPI can go only maximally I think 20Mhz (when 20Mhz system clock), that would result in slower data access rates, than using software-driven standard parallel SRAM. With practicly-tactical connecting the SRAM to the MCU, there is only few clock cycles needed to make a byte transfer. (using inline assembly code, of course)

Look, what a simple M32 or M644 can do at 20Mhz.
http://elektronika.kvalitne.cz/ATMEL/S3Mplayer/S3Mplayer_eng.html

Note: Some time ago, I was playing around with interfacing DRAM to AVR. DRAMs are everywhere (dumpsters full of them) and  when requiring very high storage capacity with not much hig data transfer rates, they are ideal. I have written a few version of DRAM library for AVR (C and inline ASM, bone-dry optimized). I found a way how to interface 64MByte of DRAM (using standard 72pin SIMM module), with refresh taking away only less than 15% of computing power at 16MHz (using CBR burst refresh). The data rates were between 300-450kBytes/s. Unfortunately, I have no free time to finish it (make a prototyping board and finetune the software).  Yes, it is a stepback when we have cheap ARMs with (also synchronous dynamic) memory controllers, but someone just could find usage for this. I only have wanted to play with DRAMs on AVR :-)

[senso]

The atmega2560 used in the Arduino supports external ram and you can map directly 32K of ram with a couple settings in the compiler, more than that and you need bank switching and roll your own memory read and write code.

There is even "shields" with 256K of SRAM and code available to play around.

You might be more hard pressed from the ADC side, since the atmega adc can only run at 15.3Khz(less because at 16Mhz the prescaler will force the ADC clock to be 128Khz if I'm not mistaken) while maintaining the 10 bits resolution, you can obviously run the ADC faster at the expense of resolution,  run it at 500Khz and left align the adc data to ditch the lower to bits that will be more or less noise at those speeds.

[westfw]

It's not obvious to me.

the atmega is only 2K SRAM.

I guess I underquoted.  It's obvious that you need more than 2k RAM.  It's NOT obvious that you need an EXTERNAL RAM.

[Rasz]

do yourself a favour, but a teensy, forget about arduidiotino

[cloudscapes]

As much as I'd also recommend a 32bit micro for good quality audio, I still think sampling on an 8bit mega can be a good learning experience!

example, I learned to use timers to sample pots every tens of milliseconds instead of all the time, at audio rates  learning to do it on a teensy, it would have the horsepower to sample pots at audio rates, but you might not learn good practices.

if someone's fine with 11khz audio quality, and aren't looking to actually ship a product, then I think audio on 8bit micros can be fun

[old gregg]

I didn't mention arduino, I'm not using one. I'm on the proper C avr stuff.

the question was about the 328p because it is what I have in my stock but the question is open for other µC as well. I'm not stick with that actual µC. I'm willing to go for something with higher powers. The question was focus to the SRAM interface.

I guess I underquoted.  It's obvious that you need more than 2k RAM.  It's NOT obvious that you need an EXTERNAL RAM.

I can do all the work into a built-in chip it could be great. I started to look for ARM or STM32 stuff, at first glance it seems to have a lot of stuff available I need to do a bit of reading and search.

I didn't teensy, I'll go check this out.

[Rasz]

I suggested teensy because all the work is already done
http://www.pjrc.com/teensy/td_libs_Audio.html

all you need is audio codec and you are good to go
http://www.pjrc.com/store/teensy3_audio.html

code is already written, programs can be generated using wysiwyg GUI
http://www.pjrc.com/teensy/gui/

yes, you can hack that 8bit micro, spending nights coding assembler routines, or you can just concentrate on your audio project

[Yansi]

Disagree. I think, it's more like  this:

A) Just use some crappy overpriced idiotino-like shields, solder two pieces together, puke there some crappy lib and be cool
B) Make the whole thing yourself, learn things as you build all of the bricks together

which do you like the most?

A -> it is better to buy complete sampler from some renowned manufacturer, so you can just concentrate on your audio and produce some sound
B -> is better for actually learn something. A pile of nonworking stuff made yourself is also experience. It shows you, what isn't the way how to do it. And also, I don't actually see, why not make the whole thing yourself, just why to buy some idiotshields.

gregg said, he wanted to learn STM32. He's got all my support.

[old gregg]

actually I've no use for a sampler per se, I just find that project interesting. I want to build one for understanding and making something with all the parts I collected.

I used Arduino for a very short time, I didn't like it because everything's done for you in libraries/shileds. So I quickly moved to AVR (as my initial idea was). I've nothing against Arduino, just not my thing.

Anyway, this project seems to be a good canditate to try some ARM stuff that I've never met so far. I've to browse through the enormous amount of dev board and documentation though.

[Yansi]

Before you make a decision about architecture, how good are you in programming?  ARMs are definitely not the best for learning how to code basics in C. They are really beasts sometimes, require deeper knowledge of what is going on - especially when using pointers (and you will use them quite a lot) and keywords like static, volatile, const, etc. ARMs alone are complex enough, I wouldn't recommend learning C on them.
How much practice on MCUs or logic do you have?

[old gregg]

I've took a look at the STM32 datasheet, seems to be quite a beast !

I don't know how to qualify my C knowledge. I've done few stuff with AVR micro (and computer programming with small programs which help calculations) and I'm currently working (for time to time) on a midi converter (using a USART communication). I've knowledge of static, const., bool and C concepts.

I've started to learn a bit of C++ and this object oriented thing but it seems to be not really the language to use for µC. I know people does it very well but I like to keep things close to the actual "hardware".

[dannyf]

I like to keep things close to the actual "hardware".

The closest would be code with binary directly.

A more girly approach is to use assembly.

C is pretty lame in that respect.

[Rasz]

I like to keep things close to the actual "hardware".

The closest would be code with binary directly.

A more girly approach is to use assembly.

C is pretty lame in that respect.

C was meh 20 years ago, was ok 10 ago, and today you got people coming up from the woodwork with object oriented/functional programming embedded ideas

[Yansi]

Keep the topic please,  Cpplikers away. I know from work, how troubly can be fixing one's buggy Cpp program. It is a crystalic hell on MCUs. 

old  gregg: On what series did you look?  ST has a whole bunch of series of ARM micros.  But it almost doesn't matter, which one will you pick first to learn them. STM32 micros are very well designed, and there are a lot similarities between all MCUs in all series. Unlike for example atmel or microchip, where each type of MCU is absolutely different with peripherals. That sucks like a bitch. On STM32 for example, when you have there Timer 1, you know for sure, that it is advanced control timer for motor control. For sure, yes, sometimes the micros differ, ADC converters are revised or used better, that pissful I2C periphral was changed on some series, and so...  But there is a plenty of tidines, which really helps jumping between series and types. So if you learn one type from one serie, then you almost can use them all without a problem.

I would recommend to pick F0-DISCOVERY (STM32F051) which is easy to learn the basics and then maybe something from F1 series... Just what would you like the most.  The point is, that with any discovery (or nucleo) board comes full featuring SWD debugger, which can be used easily to download or debug any other STM32 off the discovery board, without any limitations. You can use the discovery board itself as a programmer. Just open two jumpers and take the signals from a header.
That was the easy part. The harder part is, which toolchain to use. I am used to Keil MDK-ARM or IAR from work.  They are both very expensive software, but I really like Keil. Keil also comes as free version limited by 32kBytes code side. That size might be just enought for small projects, but not for any serious work. You can download Keil uVision 5 from Keil's website and try that.  Why to start on non-free tool like Keil?  Because it simply works. You install that and everything works fine. Unlike some free tools, which always only adds some problems for beginners. In our country, we say "házet klacky pod nohy", which means something like "to throw branches under your legs". 

Or, does anybody know about a free ARM toolchain which would compete with Keil uVision? I'd like to know, if such thing exists. I only use Keil/IAR at work or the 32K limited Keil at home, would be nice to have a comparable and free toolchain. 
(I admit I didn't search for any, just want to hear your recommendation)
Thanx

[paulie]

I suspect the 2 dozen or so toolchains built around gcc will give keil a run for the money. Technically, in terms of bang-for-the-buck, by definition INFINITELY superior to any commercial product.

And dannyf is right about asm heads being girls compared to those who hand code in binary or hex. But those who restrict themselves to hll like c can only really be... well... BABY girls. lol.

Of course those who embrace all the above are what can only be described as "superior beings". Generally outside any such puny attempts at gender classification. Usually beyond the comprehension of mere mortals.

[Yansi]

i suspect the 2 dozen or so toolchains built around gcc will give keil a run for the money.

I seriously doubt about that, after my previous experience with some free tools. But I am open to new ideas.

And also everyone who talks about coding in hex, is girl himself, if he cannot do that. I am completely fine with ARM (or any other) assembly language. Really no need to code in binary or hex.  So paulie, girl or can you code ARM in assembly?   O0

[paulie]

LOL. If you check out this thread you might discover who you are really talking to:

https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/

Not only the first person to ever post an ARM asm blinky in the history of the internet but also the first to actually not just link but attach to a forum like this a full set of ARM tools. Also to this day lay claim to the smallest and most efficient LED toggle program (6 bytes). Have I ever mentioned any of these before? Maybe I'm just too humble. LOL.

In the first half hour I found that by trying different operands and changing the instructions themselves it was possible to get a handle on the ARM opcode bit fields. This was before actually downloading the ARM.org bit mapping spec. At this point I could write a DIY assembler from scratch with one arm tied behind my back. BTW I also noticed how easy that was compared to chips like AVR where they break up and scatter argument bits all over the place.

So yeah... if you read even the first couple pages of that thread you'll find that I'm the original asm fanboy. In spite of all the scoffing from C girls here who quake at the thought of having to actually get a handle on what's going on under the hood.

Hmmmm....Ii really should revive that thread but nothing new in the line of LDO regulators or other off topics to bump it. Anyway enough links from other web sites to keep it in the news. Lots of background activity but not much for the girls here to chat about.

[Yansi]

Hehe, and also you dont know, who am I. Only some young sucker working in STmicro, supporting EMEA customers @ STM32. So, I really do not know much about STM32.     Still a lot ahead to learn, one simply can't know everything. But let's say, very easy to get any info about STM32 internall stuff, for me.
And also no, I did not learn ARMs through some crappy online tutorials (I hate those). Only Yiu's Definitive guide and a lot of hours reading manuals and asking skilled personel dumb questions. 
By the way, the book is really a Helper, for the beginning.

And I appreciate, that you also like to know the most possible about architecture(s). I really hate people saying, that learning assembly and low level stuff is a waste of time.  But, learning opcodes is a little bit overkill I think... I would understand learning opcodes for maybe Z80 enthusiasts, not for such complex architecture (unless you are a ARM chip designer).
Not many people have the understanding for learning such things.
So keep the good work.