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.

[paulie]

EXACTLY, like me speaking in a mirror. LOL.

Thanks for the hint on the Yiu book. I just downloaded the PDF and it's absolutely the best deal for these chips so far. Definitely definitive.

[Yansi]

And do no not miss one  - there are maybe four such books I think. There is also one dedicated for Cortex M0 only and one revised edition, which added Cortex M4.

[paulie]

After playing with over two dozen different ARM chips recently I must admit to not being that excited by F0 or F4. IMO better to leave those for "ghetto" discussion. Only STM32f103c8t6 has impressed me among all the ARMs. More features and performance per buck than any other chip (including AVR and PIC). Also easiest to obtain and most popular ARM in the world therefor lots of support.

The only other device of interest to me lately is the STM8 series because it's literally the lowest cost MCU with even vaguely similar capabilities. Actually lowest cost PERIOD! Also very common and easy to buy.

The dynamic duo.

[Yansi]

For me the price of STM32 does not matter much for obvious reasons. 103C8 is too small for many my applications, in the name of pin count. I am bulding some experimental BLDC controller board now, and there is almost fully assigned 64pin package. And that is not  the biggest wiring project at all.  I also play a little with logic gate arrays and when it comes to connecting big memories (to PLDs or ARMs) or TFT screens, 100pin package is nothing and sometimes 144pin is also small.
Said thing is, one can't have sufficient time to play with all these amazing gizmos... so the progress at diy side is slow and low. I haven't made anything much interesting, for the last half year. Only many unfinished work lies on the desk. Hope next year will be much better.

I promise, when I'll have something interesting, I'll share. Maybe the motor controller board, or some stuff around electrophorescent display, which I am working on exactly now. (Routing adaptor board for 32L152 discovery board).

[westfw]

More features and performance per buck than any other chip (including AVR and PIC). Also easiest to obtain and most popular ARM in the world therefor lots of support.

Transient qualities?   For instance, the F1xx chip are NOT supported by ST's recent "STCube" initialization code generator.  And TI pretty much dumped their whole CM3 line.  Perhaps there is something fundamentally broken about CM3 that is causing manufacturers to move on to other things.

[Yansi]

Will be, end of year. Not broken, but old series, noone bothers. There is quite good StdPeriph library to be used. Cube sucks, sucks like a bitch, unusable to any serious work (motor control, low power). To be exact - HAL libraries sucks. Good only for some basic pin toggling arduino style. The config tool has good concept and would be very nice to have such tool for StdPeriph libraries.  Unhappily, StdPeriph is no longer supported on new series of STM32 MCUs. That really pisses off a lot of people. (possibility of continuing StdPeriph still considered, chances low).

Let's go to bed now, 4:21 AM here 

[westfw]

The new HAL replaced SPL?  I hadn't realized that; what I've used so far looked like Cube WAS generating calls to SPL, or that the HAL they were talking about included SPL...

(Of course, I've said elsewhere that I think the SPL is pretty bad, too...)

[paulie]

Will be, end of year.

Are you saying ST will discontinue production of STM32F103? If this is the case I'm going to drop all this ARM crap right now and crawl back to 8 bit world. They can leave somebody else twisting in the wind. At least Microchip PIC16x54 and ATMEL m8 and t2313 still available 20 years after intro.

What about STM8S003?

[Yansi]

nono, that was for the F1 Cube. I think end of the yr is the date for F1_Cube publishing.
F103 is not to be discontinued in any near future.

That ST8 sucker - I dont know, if anything is about to be changed. So, the answer is - everything normal :-)

[paulie]

WHEW! I keep thinking these chips are too good to be true and waiting for the other shoe to drop.

I could care less about product support or Cube/SPL/HAL (Sorry Dave, I'm afraid I can't do asm). You and the other Human Centipedes can crawl around on hands and knees and worry about that stuff. Real Men build $1 demo boards and create their own include files from datasheets.

Back to regularly scheduled program.