ARM controller with integrated DAC

On 8/16/2010 9:44 AM, Bob wrote:
> Nitro wrote:
>> On Mon, 16 Aug 2010 13:35:44 +0200, Michael Keith wrote:
>>
>>>
>>> Hi everybody,
>>> I am searching for a controller with a fast integrated DAC but haven't
>>> been able to find anything suitable. Google led me to TIs AM3517 but
>>> this is absolute overkill.
>>> I need processing power but not much in terms of interfaces. Something
>>> as simple as an LPC 2103 from NXP (albeit faster) with a DAC would be
>>> perfect.
>>> An ARM controller would be preferred but if necessary we consider
>>> another platform.
>>> I'd be grateful for any hint.
>>> M'
>>
>> You may be able to use a PWM output but it will also drive extra
>> components. I cannot remember an arm with PWM outputs but I am sure I
>> have seen many 8051
>> core processors with a few PWM outputs. This all depends on the specs you
>> need to meet for your dac output.
>>
>>
> elsewhere, OP said 100nS and 5 bits -> 3nS resolution in the PWM. I
> don't know of any parts like that.
> Bob

I think some of the TI C2000 DSPs have motor control PWMs with 
sub-nanosecond resolution.  That's getting more than a little off-topic, 
however.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Michael Keith skrev 2010-08-16 15:51:
> Hi David,
> thanks for your comments.
>> Why do you want an integrated DAC?
> well, as a first idea it seemed like a nice feature.
> Meanwhile I found that the (rather new) LPC1765/66/68 come with a DAC.
>
> Don't laugh - I am a software guy, not an EE and was just tasked to
> evaluate a new idea of my boss. Turns out the DAC in the ARM is too
> slow: It has a maximal conversion rate of 1 �s.
>> What
>> are your requirements for the DAC - channels, resolution, speed, etc.?
> Bad news: We will produce data at the rate of 200 ns (and maybe even
> down to 100 ns).
> (Hopefully) good news: We only need a very low resolution, 5 bit will
> be sufficient (and we need only one channel).
>
> My knowledge of analog conversion is limited to
> - DACs exist and
> - (from very long ago) a faint memory of R-2R-networks.
> Any link to information on how to perform D/A conversion at the rate
> mentioned above would be welcome. I could hand it over to an EE
> colleage to understand the technical details.
>
> Thanks
> M'

You need a DMA controller which can handle a time base
if you do not want to have jitter.
At 100 ns and 5 bit resolution you get 50 megabit per second
transfer rate so you probably want to have a FIFO or you need
to have a way of guaranteeing that the DMA has higher priority
than anything else, and little latency on top.

Doing it serially at 50 Mbit per second will tax most
32 bit flash micros, so a parallell interface would be nice.

The AT91SAM3 has a mode where you can do DMA from internal SRAM to a 
parallel PIO port which might be useful.






-- 
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB

On 08/16/2010 06:51 AM, Michael Keith wrote:
> Hi David,
> thanks for your comments.
>> Why do you want an integrated DAC?
> well, as a first idea it seemed like a nice feature.
> Meanwhile I found that the (rather new) LPC1765/66/68 come with a DAC.
>
> Don't laugh - I am a software guy, not an EE and was just tasked to
> evaluate a new idea of my boss. Turns out the DAC in the ARM is too
> slow: It has a maximal conversion rate of 1 �s.
>> What
>> are your requirements for the DAC - channels, resolution, speed, etc.?
> Bad news: We will produce data at the rate of 200 ns (and maybe even
> down to 100 ns).
> (Hopefully) good news: We only need a very low resolution, 5 bit will
> be sufficient (and we need only one channel).
>
> My knowledge of analog conversion is limited to
> - DACs exist and
> - (from very long ago) a faint memory of R-2R-networks.
> Any link to information on how to perform D/A conversion at the rate
> mentioned above would be welcome. I could hand it over to an EE
> colleage to understand the technical details.

100ns = 10MHz, 10MHz = 5 to 300 clock ticks per repetition, depending on 
how over the top you get with your processor.

5 clock ticks (50MHz processor) is out of the question, unless that's 
all the processor does.

30 clock ticks (300MHz processor) is barely enough time to interrupt, 
fetch some data, pump it out, and resume processing -- and that's with 
no OS getting in the way, which means that you're doing the whole thing 
in an ISR.

300 clock ticks (3GHz processor!!!) means that you could _maybe_ have 
the RTOS involved, or that you could maybe actually do some processing. 
  3GHz is kind of getting out of the realm of "easily embedded", at 
least in my book.

On the other hand, getting a 100ns rep rate out of an FPGA is a snap. 
You'd still need a separate DAC, but I don't think you can get away from 
that.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

On Aug 16, 6:51=A0am, Michael Keith <mjke...@gmx.de> wrote:
> Hi David,
> thanks for your comments.>Why do you want an integrated DAC?
>
> well, as a first idea it seemed like a nice feature.
> Meanwhile I found that the (rather new) LPC1765/66/68 come with a DAC.
>
> Don't laugh - I am a software guy, not an EE and was just tasked to
> evaluate a new idea of my boss. Turns out the DAC in the ARM is too
> slow: It has a maximal conversion rate of 1 =B5s.>

I am not questioning it, but where did you get this number? Just
wondering.

All I can find is that the ADC runs at 13MHz with 200KSPS.  I would
think the DAC can do a little better.

On Aug 16, 8:51=A0am, Michael Keith <mjke...@gmx.de> wrote:
> Hi David,
> thanks for your comments.>Why do you want an integrated DAC?
>
> well, as a first idea it seemed like a nice feature.
> Meanwhile I found that the (rather new) LPC1765/66/68 come with a DAC.
>
> Don't laugh - I am a software guy, not an EE and was just tasked to
> evaluate a new idea of my boss. Turns out the DAC in the ARM is too
> slow: It has a maximal conversion rate of 1 =B5s.> What
> >are your requirements for the DAC - channels, resolution, speed, etc.?
>
> Bad news: We will produce data at the rate of 200 ns (and maybe even
> down to 100 ns).
> (Hopefully) good news: We only need a very low resolution, 5 bit will
> be sufficient (and we need only one channel).
>
> My knowledge of analog conversion is limited to
> - DACs exist and
> - (from very long ago) a faint memory of R-2R-networks.
> Any link to information on how to perform D/A conversion at the rate
> mentioned above would be welcome. I could hand it over to an EE
> colleage to understand the technical details.
>
> Thanks
> M'

You might be able to use a parallel LCD interface or composite video
out DAC on some parts to do what you want.  You would have to see if
there is a way to control the outputs during blank/sync times.

On 8/16/2010 12:23 PM, linnix wrote:
> On Aug 16, 6:51 am, Michael Keith<mjke...@gmx.de>  wrote:
>> Hi David,
>> thanks for your comments.>Why do you want an integrated DAC?
>>
>> well, as a first idea it seemed like a nice feature.
>> Meanwhile I found that the (rather new) LPC1765/66/68 come with a DAC.
>>
>> Don't laugh - I am a software guy, not an EE and was just tasked to
>> evaluate a new idea of my boss. Turns out the DAC in the ARM is too
>> slow: It has a maximal conversion rate of 1 &#4294967295;s.>
>
> I am not questioning it, but where did you get this number? Just
> wondering.
>
> All I can find is that the ADC runs at 13MHz with 200KSPS.  I would
> think the DAC can do a little better.

I've actually got that datasheet up right now, come to mention.  DAC 
maxes out at 1 MSPS; you'd probably need to feed it from the DMA engine 
rather than code in order to keep it running at that rate.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

On Aug 16, 1:00=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
> On 8/16/2010 9:44 AM, Bob wrote:
>
>
>
> > Nitro wrote:
> >> On Mon, 16 Aug 2010 13:35:44 +0200, Michael Keith wrote:
>
> >>> Hi everybody,
> >>> I am searching for a controller with a fast integrated DAC but haven'=
t
> >>> been able to find anything suitable. Google led me to TIs AM3517 but
> >>> this is absolute overkill.
> >>> I need processing power but not much in terms of interfaces. Somethin=
g
> >>> as simple as an LPC 2103 from NXP (albeit faster) with a DAC would be
> >>> perfect.
> >>> An ARM controller would be preferred but if necessary we consider
> >>> another platform.
> >>> I'd be grateful for any hint.
> >>> M'
>
> >> You may be able to use a PWM output but it will also drive extra
> >> components. I cannot remember an arm with PWM outputs but I am sure I
> >> have seen many 8051
> >> core processors with a few PWM outputs. This all depends on the specs =
you
> >> need to meet for your dac output.
>
> > elsewhere, OP said 100nS and 5 bits -> 3nS resolution in the PWM. I
> > don't know of any parts like that.
> > Bob
>
> I think some of the TI C2000 DSPs have motor control PWMs with
> sub-nanosecond resolution. =A0That's getting more than a little off-topic=
,
> however.
>
> --
> Rob Gaddi, Highland Technology
> Email address is currently out of order


The Luminary Micro CM3 parts come with PWM.  Their early parts
actually didn't rank well against the ARM7 parts in terms of power and
speed initially and the PWM was about the only thing they had going
for them.  They were trying to sell them into motor control apps.

As to the rest of the OP's post, it is hard to tell if he knows what
he really needs or not.  He is describing his requirements in pretty
simplistic terms so he may not fully understand the issues or he may
be totally on top of it and just needs some pointers to good parts.  5
bits is certainly not hard.  As someone else pointed out, that could
be done with five outputs and ten resistors.  Normally I wouldn't
recommend using digital outputs for this directly, but he only needs
0.1 V resolution which likely can work ok with digital outputs.

Rick

> You need a DMA controller which can handle a time base
> if you do not want to have jitter.
> At 100 ns and 5 bit resolution you get 50 megabit per second
> transfer rate so you probably want to have a FIFO or you need
> to have a way of guaranteeing that the DMA has higher priority
> than anything else, and little latency on top.
>
> Doing it serially at 50 Mbit per second will tax most
> 32 bit flash micros, so a parallell interface would be nice.
>
> The AT91SAM3 has a mode where you can do DMA from internal SRAM to a
> parallel PIO port which might be useful.
>

The external peripheral interface on the TI Stellaris might also be
useful. It has an internal FIFO as well.

Aaron

http://blog.EmbeddedCoding.com

Many thanks to everybody who responded.

I want to apologize for the delay: Somehow I managed to have my news
reader mark this thread as deleted, which led it to ignore all further
posts. Only when seeing the activity on other threads I had the idea
of deleting (from my reader's memory) this whole group and after
re-subscribing I eventually saw the complete thread.

Rick (Rickman) is "spot on" when he writes
>As to the rest of the OP's post, it is hard to tell if he knows what
>he really needs or not.  He is describing his requirements in pretty
>simplistic terms so he may not fully understand the issues or he may
>be totally on top of it and just needs some pointers to good parts.
"not fully understand" is a kind way to put it.

The idea is to produce short bursts of a duration of appr. 3 - 5 �s
every 100 �s using _pre-defined_ values (this is for testing external
equipment). So I started to look at it from the software side:
- Can we store the data we need in memory? No question, 5 �s will need
only 50 values (if providing data @ 100 ns intervalls).
- Can we provide the data fast enough (a new value every 100 ns)? This
shouldn't be a problem either: DMA is a possibility or we might even
just loop inside an ISR for those 5 �s writng out new values when
needed (the processor won't be doing much else during that time).

Comes the analog part: If the software can provide data every 100 ns
which hardware will turn it into analog values?
Since I'm out of my league in the analog world I turned here and I
must say I am positively surprised: Lots of helpful advice which I
will dump next week onto my co-worker's desk: The analog stuff calls
for an EE.

Again many thanks to all of you. Who knows? Maybe I'll be back some
day with another question "where I don't fully know what I really
need". 
M'

>Comes the analog part: If the software can provide data every 100 ns
>which hardware will turn it into analog values?

You are only looking for 5 bit accuracy, about 3%.
5 resistors on a port could give this to you.

BIT0 81k accurate enough
BIT1 39k accurate enough
BIT2 20k available 1%
BIT3 10k available 1%
BIT4 5k0 2* 10k in parallel

You may need lower values to get the desired frequency response, but there
is a tradeoff with the port drive capability.	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com