ATmega/tiny Replacement for AVR32?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

As part of a design job of an audio streaming board for a client, just designed a board based on a AT32UC3A0512.  I'm quite new to AVR and ASF, and the learning curve for the AVR32 is taking more time than expected, so I'm thinking about replacing the UC3 for some 8-bit AVR just to meet the project deadline, while I learn about AVR32 in background.

Just wondering if someone can recommend some ATMega/ATtiny chip that might work here?

 

These are some project specs:

- The board should run a full-duplex audio stream through a RS422 port, driving a local speaker and encoding audio from a microphone.
- Audio format is PCM 44100 Hz, 16 bits.
- External ADC and DAC ICs connected to a single SPI port.
- RS422 port was made as 2 x RS485 driver ICs, both wired to their own UART port, to keep the option to switch to RS485, i.e. using one UART in half-duplex mode.
- The AVR should be fast enough to run some codec or simple filtering, and manage the ADC and DAC, in sync with the sample rate.  Hopefully with PLL.
- Supply: 3.3V-5V

- ADC: AD7680, DAC: MAX5216, RS422 drivers: LTC1685

- Misc I/O; a couple of buttons and LEDs etc.

 

Any thoughts are much appreciated,

Thanks in advance.

while(!solution) {patience--;}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

G0NZ4L0 wrote:

Any thoughts are much appreciated,

 

You'll not do what you want with a 8-bit chip.

 

A quick look at the numbers...

 

44100 x 16 = 705,600 bits per second to and from your serial port. And that without any overhead like start and stop bits.

 

44100 = 22.67us. That's the amount of time between incoming samples you have to do all your processing.

 

44100 x 20 bits (ADC requirement) = your SPI port will need to run at 882,000 bps

 

44100 x 24 bits (DAC requirement) = your SPI port will need to run at 1,058,400 bps

 

...plus there's the issues of needing at least 24-bit wide registers to deal with the filtering.

 

In short, no hope.

 

Your choice of ADC and DAC are interesting. Neither of them jump out as being designed for audio. Audio converters normally have an I2S interface and you couple those to a processor with an I2S port.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you can't live with the ADC and DAC in lets say a xmega32E5 I don't think you can make it.

 

Do you want to send the RAW data or some ADPCM or some other format over the link?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

A quick look at the numbers...

Thanks for the response. Got some similar figures when picked the AVR32.  Actually was getting close with a dsPIC33 (70MIPS, internal ADC) and a "bit bang" serial port in place of the UART, though it was busy most of the time forwarding data between SPI and UART, leaving near zero time to do anything else.

 

Brian Fairchild wrote:

...Neither of them jump out as being designed for audio

Yeah, these ADC and DAC were the first I found supporting 16bit/44KHz, which IMO should be enough for most audio applications.  The choice of SPI over I2S was because SPI has a more flexible clocking than I2S, so I can allocate more time to process the samples.

 

Brian Fairchild wrote:

...I2S interface and you couple those to a processor with an I2S port.

Sounds good if the CPU can keep the clock rate and rely on some external IC to do the processing job, like some I2S codec, etc.  Thanks for the tip!

while(!solution) {patience--;}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

xmega32E5

Xmega are like the next level after ATmega, right? If so, will want to consider it.  Just trying to stay away from AVR32.

 

sparrow2 wrote:

Do you want to send the RAW data or some ADPCM or some other format over the link?

Yes any compression will help.  At first was considering raw PCM just to get something working, then move to 8-bit ADPCM if the AVR can keep up with the sample rate.

Thanks!

while(!solution) {patience--;}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

G0NZ4L0 wrote:

...though it was busy most of the time forwarding data between SPI and UART, leaving near zero time to do anything else.

 

Which is why god gave us the DMA controller.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just trying to stay away from AVR32.

That's the thing I'm wondering about. You could go to dsPic or CortexM4 or whatever but why do you think this is "better" than AVR32 if that CPU has the performance you need?

 

yes the peripherals in "bigger" (usually faster) chips like ARM, dsPIC, AVr32 are more complex than the simple subset in the smaller silicon of AVR8 but you are going to face this complexity barrier whatever chip you move to in order to get the CPU performance you need. So I'd stick at the AVR32 for a while longer - it cannot be THAT bad can it? Though I pity you if you are forced to use ASF to drive it! With these complex peripherals in larger chips there's usually a "simple subset" like an AVR8 peripheral in there hiding under the hood. The only "trick" is sorting the wheat from the chaff to know which 3 of the 20 GPIO registers (or whatever) are the ones you really just use. Often example code (even the dreadful ASF) is an opportunity to see what's actually used (at the register level) and what is "bells and whistles".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

DMA controller.

Sure, though a bit tricky on a s/w emulated port.  Good idea for an UC3 anyway.

while(!solution) {patience--;}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

why do you think this is "better" than AVR32 if that CPU has the performance you need?

Bec the learning curve for AVR32 doesn't fit my project schedule. An ATMega/tiny or dsPIC does. That's it

 

clawson wrote:

So I'd stick at the AVR32 for a while longer

You're right on it.  In fact I'm learning the AVR32 on the side.

 

clawson wrote:

I pity you if you are forced to use ASF to drive it

IMHO, the ASF for AVR32 deserves its own topic in a future "Atmel disasters" thread.  It took 25 lines of code to flash a LED by just writing hex values to registers from the datasheet.  The ASF walked me through 3 header files and 50 lines of defines and macros just to do the same.  Awesome.

 

clawson wrote:

The only "trick" is sorting the wheat from the chaff to know which 3 of the 20 GPIO registers (or whatever) are the ones you really just use.

Yeah, I was able to pull out the PLL, clocks, GPIO and timers that way, just writing hex values as said above.  Looking forward to pull more 'tricks' to make my way out of the hardware,  and finish the rest of the code :)

while(!solution) {patience--;}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the xmega's have DMA, but then again if you don't want a big setup then it could be a problem

At first was considering raw PCM just to get something working

yes that is simple but not easy at that speed.

You have to find out if you want if you want log or lin ADC (sound chip are often log).

 

I would try to play with it on a PC to see what is needed! (perhaps sample with a AVR)

And then I would guess that a xmega32E5 with some good filters will do a ok job.(at least then you can show something in a day or so).

(I have sampled with about 500KHz on a mega16 and if the signal don't have to big a deviation, and don't change the mux the result is ok. )

 

About compression it will depend on how big a delay you can live with.

 

If CPU speed is a problem then split it up to a ADC and send CPU, and a rx that handle DAC, and then double the system for the other direction, 

4 xmega8e5 will cost you about $5 so they don't break the bank.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IMHO, the ASF for AVR32 deserves its own topic in a future "Atmel disasters" thread.  It took 25 lines of code to flash a LED by just writing hex values to registers from the datasheet.  The ASF walked me through 3 header files and 50 lines of defines and macros just to do the same.  Awesome.

Totally agree - ASf is trying to be too much to too many people so it's designed to be so generic that, as you say, flashing an LED takes about 10 layers of code going from the most generic at the outside of the onion layers to the very specific details of SFR register access in the murky depths. But a decent source browsing editor (like AS6 with Visual Assist) should let you dig through the layers. I think it may be the only way to learn about the (simple at the deepest) use of the complex  AVR32 peripherals. Once you know the three registers you actually need to write then throw ASf away and just use SFR1 |= something; SFR2 |= something_else.. or whatever it takes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR336 has an ADPCM decoder implementation for AVR8.  A 16 MHz clock is required to decode an 8 kHz sample rate.  Forget about encoding.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@sparrow2 : Thanks. Good ideas there.  Guess xmega and split processors for the in/out streams are agood option if I didn't find a single-chip solution.

 

@clawson : Absolutely.  Being fair to ASF, it makes sense for 97% of programmers that don't like to deal with datasheets and bitfields, just macros and prototypes with friendly names like "void do_the_stuff(void)" and don't mind a dozen files linked in background, etc.  I'm on the other 3% though.

 

@joeymorin : Just checked the AVR336 datasheet.  Looks like we have a problem solved.  Thanks

 

Thanks to everyone for the help.

 

 

 

while(!solution) {patience--;}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may also want to look at a VS1053B/8053B or similar.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for the late reply.  Good thoughts.  Thanks again!

while(!solution) {patience--;}