1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

arm7 core with fast monolithic 12-bit ADC

Discussion in 'Embedded' started by Jon Kirwan, Feb 11, 2009.

  1. Jon Kirwan

    Jon Kirwan Guest

    I'm just getting into a project which "prefers" the ARM7 for business
    reasons, not technical ones. I do _not_ have experience writing for
    the ARM7 beyond some modest playing around, but will muddle through
    that part when the time comes.

    I'm looking for an ARM7TDMI core (or upward compatible) that includes
    a monolithic (unless someone goes through all the trouble of
    wire-bonding in packaging for reasonable prices) 12-bit minimum width,
    1.5MHz minimum rate ADC (10.5-bit or so realizable at 2MHz with 1-2V
    signals is fine.) Pipelined sampling and conversion stages is okay to
    get the speed, as only one signal needs to be measured. Flash
    programming of code, 1000-5000 pc qtys. Other features are far less
    important, but RAM should be at least 2k (4k would be safer) and flash
    should be at least 32k-64k (128k would probably be massive overkill.)
    I/O required is probably less then 20 I/O pins (12, I'm counting right
    now, outside the ADC input.) So a 44-pin package is well more than I
    need.

    There is a core algorithm involved that processes the data, but to be
    honest I don't need a blazingly fast cpu here -- the core parts that
    require very fast speed will be written in assembly. I won't be using
    floating point, except for a few custom routines I'll write. A fully
    combinatorial barrel shifter with the ability to find the leading bit
    and record the number of shifts required is a plus, though. I already
    know that division is an issue for the ARM7 (software), but that is
    okay as I keep division to a minimum, using wider 'registers' and
    multiplicative sums and tracking divisors, holding the division parts
    till the very end.

    I've seen a few cases with fancy debug trace buffers available over
    JTAG and that would be "high cotton" if I could find that, together
    with the ADC. But it really isn't necessary.

    The main thing I'm looking for a fast, decent 12-bit or better ADC
    inside an ARM7TDMI (or upward compatible) cpu. The 1.5MHz minimum
    requirement is a bit of a stretch, perhaps. But it is important and
    I'm currently using an external ADC for this (which easily reach much
    higher than this and with decent bits.) Pushing towards 2-3MHz would
    be pure ecstasy.

    Right now I'm just trying to compile a list for examination. So even
    things that are close (1MHz, for example) would be okay to include.
    I'll talk it over, later, to see what we may have to accept.

    The other option is to use a non-ARM7TDMI compatible cpu, if that is
    the only way to get there (for example, Atmel's XMEGA.) I'm hoping
    there are some options in the ARM7 field, though.

    Thanks very much in advance for any suggestions to add to the list.

    Jon
     
    1. Advertising

  2. "Jon Kirwan" <> wrote in message news:eek:...

    > There is a core algorithm involved that processes the data, but to be
    > honest I don't need a blazingly fast cpu here -- the core parts that
    > require very fast speed will be written in assembly. I won't be using
    > floating point, except for a few custom routines I'll write. A fully
    > combinatorial barrel shifter with the ability to find the leading bit
    > and record the number of shifts required is a plus, though. I already
    > know that division is an issue for the ARM7 (software), but that is
    > okay as I keep division to a minimum, using wider 'registers' and
    > multiplicative sums and tracking divisors, holding the division parts
    > till the very end.


    If clz and division are important then you might want to consider Cortex-M3
    instead, for example the LM3S628 (8x 1MHz adc, 50MHz, 32KB flash,
    8KB SRAM, 48 LQFP).

    Wilco
     
    1. Advertising

  3. -jg

    -jg Guest

    Jon Kirwan wrote:

    > I'm just getting into a project which "prefers" the ARM7 for business
    > reasons, not technical ones. I do _not_ have experience writing for
    > the ARM7 beyond some modest playing around, but will muddle through
    > that part when the time comes.
    >
    > I'm looking for an ARM7TDMI core (or upward compatible) that includes
    > a monolithic (unless someone goes through all the trouble of
    > wire-bonding in packaging for reasonable prices) 12-bit minimum width,
    > 1.5MHz minimum rate ADC (10.5-bit or so realizable at 2MHz with 1-2V
    > signals is fine.)
    > Right now I'm just trying to compile a list for examination. So even
    > things that are close (1MHz, for example) would be okay to include.
    > I'll talk it over, later, to see what we may have to accept.


    12 bits and Multi MHz is a stretch,
    Analog devices have 12 bits and 1MHz, in ARM7.

    NXP have Cortex cores at 1MHz / 12 bits, and Atmel AT91SAM3
    seems to have slipped - I think that was 12 bits/ 1MSPS too
    ..
    Documents suggesting Q3/Q4 08 SAM3 samples, have not been correct,
    and their newest ARM family guide, skips the SAM3 entirely

    > The other option is to use a non-ARM7TDMI compatible cpu, if that is
    > the only way to get there (for example, Atmel's XMEGA.) I'm hoping
    > there are some options in the ARM7 field, though.


    XMega is a little short on ADC speed ?.

    >
    > Thanks very much in advance for any suggestions to add to the list.


    If you already have an ADC chip, why not morph slightly, and
    make that a TI Picolo : $3 for 12 bit ADC 325ns conversion, high
    precision
    timers, (and a free DSP), and then any-old-arm can do the rest. ?

    -jg
     
  4. Jon Kirwan

    Jon Kirwan Guest

    On Wed, 11 Feb 2009 22:32:36 -0000, "Wilco Dijkstra"
    <> wrote:

    >"Jon Kirwan" <> wrote in message news:eek:...
    >
    >> There is a core algorithm involved that processes the data, but to be
    >> honest I don't need a blazingly fast cpu here -- the core parts that
    >> require very fast speed will be written in assembly. I won't be using
    >> floating point, except for a few custom routines I'll write. A fully
    >> combinatorial barrel shifter with the ability to find the leading bit
    >> and record the number of shifts required is a plus, though. I already
    >> know that division is an issue for the ARM7 (software), but that is
    >> okay as I keep division to a minimum, using wider 'registers' and
    >> multiplicative sums and tracking divisors, holding the division parts
    >> till the very end.

    >
    >If clz and division are important then you might want to consider Cortex-M3
    >instead, for example the LM3S628 (8x 1MHz adc, 50MHz, 32KB flash,
    >8KB SRAM, 48 LQFP).


    Actually, division is less important. I've got those operations down
    to a bare minimum and can tolerate some execution time. I'm still
    hoping for something more than 1MHz on a monolithic ADC, which will
    put a small kink into the idea of moving away from an outboard ADC.
    I'm a bit unhappy at 1Mhz. It might be livable, but the extra bit of
    speed would be worth going after. If you don't know of one, then I
    guess there may be nothing staring me in the face that I've missed on
    a quick search this morning. But don't get me wrong. I'm not opposed
    to an M3. I'm just waffling about the ADC speed.

    Jon
     
  5. Jon Kirwan

    Jon Kirwan Guest

    On Wed, 11 Feb 2009 15:59:53 -0800 (PST), -jg
    <> wrote:

    >Jon Kirwan wrote:
    >
    >> I'm just getting into a project which "prefers" the ARM7 for business
    >> reasons, not technical ones. I do _not_ have experience writing for
    >> the ARM7 beyond some modest playing around, but will muddle through
    >> that part when the time comes.
    >>
    >> I'm looking for an ARM7TDMI core (or upward compatible) that includes
    >> a monolithic (unless someone goes through all the trouble of
    >> wire-bonding in packaging for reasonable prices) 12-bit minimum width,
    >> 1.5MHz minimum rate ADC (10.5-bit or so realizable at 2MHz with 1-2V
    >> signals is fine.)
    >> Right now I'm just trying to compile a list for examination. So even
    >> things that are close (1MHz, for example) would be okay to include.
    >> I'll talk it over, later, to see what we may have to accept.

    >
    >12 bits and Multi MHz is a stretch,


    Yes, I'm kind of thinking so, too.

    >Analog devices have 12 bits and 1MHz, in ARM7.


    Yes, I had only this morning before posting noted the ADuC7022 from
    Analog.

    >NXP have Cortex cores at 1MHz / 12 bits, and Atmel AT91SAM3
    >seems to have slipped - I think that was 12 bits/ 1MSPS too
    >.


    I think I saw an LPC175x series with 12-bit. But no information on
    when it will be sampling. Apparently, not now anyway. On the XMEGA
    with 2MHz 12-bit pipelined ADC, Digikey told me yesterday that it was
    at least sometime April before they'd see any there to ship. Maybe
    longer. Which just may... may... be okay.

    >Documents suggesting Q3/Q4 08 SAM3 samples, have not been correct,
    >and their newest ARM family guide, skips the SAM3 entirely


    Thanks.

    >> The other option is to use a non-ARM7TDMI compatible cpu, if that is
    >> the only way to get there (for example, Atmel's XMEGA.) I'm hoping
    >> there are some options in the ARM7 field, though.

    >
    >XMega is a little short on ADC speed ?.


    Well, supposedly I saw an ATxmega16A4 (up to 128A4) variety with 2MHz
    and 12bit, nicely pipelined for my needs. So in one-off conversions,
    it is too slow. But free-running it looks good and would suit the
    application (well, I haven't checked through the specifications in any
    detail, so there might be something there that would kill the idea.)

    >> Thanks very much in advance for any suggestions to add to the list.

    >
    >If you already have an ADC chip, why not morph slightly, and
    >make that a TI Picolo : $3 for 12 bit ADC 325ns conversion, high
    >precision
    >timers, (and a free DSP), and then any-old-arm can do the rest. ?


    I hadn't even thought to look at that one. It kind of defeats the
    idea using two big chips -- I'm looking to reduce the chip and
    supplier count, not increase it. But if there is, say, 12-14 I/Os
    there and if I can set up RS232 on it then I might not need anything
    else. The 64kb flash and 12kb ram seems okay. This application used
    to run on an ADSP21xx, so I'm perfectly comfortable with DSPs for
    this. I just didn't like my earlier experiences with the TI C30/C40
    clan. If this is another roll of one of those cores, I'm not going to
    be happy unless they've learned a lot more about their own chips,
    enough that they can explain an observed cycle count running out of
    cache. They couldn't tell me why a 7 cycle count loop in cache took
    11 cycles, years back. We spent weeks on the phone with their
    technical folks pouring carefully over various ways of forced
    interlock waits and never got anywhere.

    Thanks for the thought. I'll take a closer look.

    Jon
     
  6. Jon Kirwan

    Jon Kirwan Guest

    On Wed, 11 Feb 2009 15:59:53 -0800 (PST), -jg
    <> wrote:

    ><snip>
    >TI Picolo : $3 for 12 bit ADC 325ns conversion
    ><snip>


    I'm seeing towards $4. But then I won't really know until an order is
    placed. Can you say anything about the tool chains you've experienced
    for this device? Cost, support reponsiveness, etc. Alternative
    development tools you looked at but didn't actually wind up trying
    out?

    Jon
     
  7. -jg

    -jg Guest

    >
    > I'm seeing towards $4.  But then I won't really know until an order is
    > placed.  Can you say anything about the tool chains you've experienced
    > for this device?  Cost, support reponsiveness, etc.  Alternative
    > development tools you looked at but didn't actually wind up trying
    > out?


    Not on this family yet, but I did like the look of the Peripheral mix,
    so it is on our radar for future use...
    ..
    Very fast ADC, and high resolution timers.

    TI are pushing some low-cost stuff
    Experimenter Kit w/ControlCARD I see in stock at Newark for ~$82,
    Piccolo controlSTICK is a USB stick, for $40.50

    so that would be an easy way to quickly try the latest tools ?.

    -jg
     
  8. Jon Kirwan

    Jon Kirwan Guest

    On Wed, 11 Feb 2009 23:20:12 -0800 (PST), -jg
    <> wrote:

    >> I'm seeing towards $4.  But then I won't really know until an order is
    >> placed.  Can you say anything about the tool chains you've experienced
    >> for this device?  Cost, support reponsiveness, etc.  Alternative
    >> development tools you looked at but didn't actually wind up trying
    >> out?

    >
    >Not on this family yet, but I did like the look of the Peripheral mix,
    >so it is on our radar for future use...
    >.
    >Very fast ADC, and high resolution timers.


    Yeah. I'm impressed.

    >TI are pushing some low-cost stuff
    >Experimenter Kit w/ControlCARD I see in stock at Newark for ~$82,
    >Piccolo controlSTICK is a USB stick, for $40.50
    >
    >so that would be an easy way to quickly try the latest tools ?.


    I suppose so. I'm a little disappointed looking at Eclipse
    development tool costs for active development (not trial stuff.)
    That's kind of off my radar range, if I decide to go that way. Which
    means I need to dig a little deeper about tools. But yes, the device
    appears attractive to me and I definitely appreciate the pointer. I
    think I'd heard the name dropped here once or twice, but never took
    notice before. But my head is turned now. So I'll put a little
    effort into looking further.

    Jon
     
  9. arzo

    arzo Guest

    On Feb 12, 3:10 am, Jon Kirwan <> wrote:
    > I'm just getting into a project which "prefers" the ARM7 for business
    > reasons, not technical ones.  I do _not_ have experience writing for
    > the ARM7 beyond some modest playing around, but will muddle through
    > that part when the time comes.
    >
    > I'm looking for an ARM7TDMI core (or upward compatible) that includes
    > a monolithic (unless someone goes through all the trouble of
    > wire-bonding in packaging for reasonable prices) 12-bit minimum width,
    > 1.5MHz minimum rate ADC (10.5-bit or so realizable at 2MHz with 1-2V
    > signals is fine.)  Pipelined sampling and conversion stages is okay to
    > get the speed, as only one signal needs to be measured.  Flash
    > programming of code, 1000-5000 pc qtys.  Other features are far less
    > important, but RAM should be at least 2k (4k would be safer) and flash
    > should be at least 32k-64k (128k would probably be massive overkill.)
    > I/O required is probably less then 20 I/O pins (12, I'm counting right
    > now, outside the ADC input.)  So a 44-pin package is well more than I
    > need.
    >
    > There is a core algorithm involved that processes the data, but to be
    > honest I don't need a blazingly fast cpu here -- the core parts that
    > require very fast speed will be written in assembly.  I won't be using
    > floating point, except for a few custom routines I'll write.  A fully
    > combinatorial barrel shifter with the ability to find the leading bit
    > and record the number of shifts required is a plus, though.  I already
    > know that division is an issue for the ARM7 (software), but that is
    > okay as I keep division to a minimum, using wider 'registers' and
    > multiplicative sums and tracking divisors, holding the division parts
    > till the very end.
    >
    > I've seen a few cases with fancy debug trace buffers available over
    > JTAG and that would be "high cotton" if I could find that, together
    > with the ADC.  But it really isn't necessary.
    >
    > The main thing I'm looking for a fast, decent 12-bit or better ADC
    > inside an ARM7TDMI (or upward compatible) cpu.  The 1.5MHz minimum
    > requirement is a bit of a stretch, perhaps.  But it is important and
    > I'm currently using an external ADC for this (which easily reach much
    > higher than this and with decent bits.)  Pushing towards 2-3MHz would
    > be pure ecstasy.
    >
    > Right now I'm just trying to compile a list for examination.  So even
    > things that are close (1MHz, for example) would be okay to include.
    > I'll talk it over, later, to see what we may have to accept.
    >
    > The other option is to use a non-ARM7TDMI compatible cpu, if that is
    > the only way to get there (for example, Atmel's XMEGA.)  I'm hoping
    > there are some options in the ARM7 field, though.
    >
    > Thanks very much in advance for any suggestions to add to the list.
    >
    > Jon


    these website i found on net are very informative.
    plz check all the links and enjoy your self.

    http://picinf.blogspot.com/ http://microcontroller51.blogspot.com/
    http://makeonlinemoneyinf.blogspot.com/
    regardz
     
  10. arzo

    arzo Guest

    On Feb 12, 3:10 am, Jon Kirwan <> wrote:
    > I'm just getting into a project which "prefers" the ARM7 for business
    > reasons, not technical ones.  I do _not_ have experience writing for
    > the ARM7 beyond some modest playing around, but will muddle through
    > that part when the time comes.
    >
    > I'm looking for an ARM7TDMI core (or upward compatible) that includes
    > a monolithic (unless someone goes through all the trouble of
    > wire-bonding in packaging for reasonable prices) 12-bit minimum width,
    > 1.5MHz minimum rate ADC (10.5-bit or so realizable at 2MHz with 1-2V
    > signals is fine.)  Pipelined sampling and conversion stages is okay to
    > get the speed, as only one signal needs to be measured.  Flash
    > programming of code, 1000-5000 pc qtys.  Other features are far less
    > important, but RAM should be at least 2k (4k would be safer) and flash
    > should be at least 32k-64k (128k would probably be massive overkill.)
    > I/O required is probably less then 20 I/O pins (12, I'm counting right
    > now, outside the ADC input.)  So a 44-pin package is well more than I
    > need.
    >
    > There is a core algorithm involved that processes the data, but to be
    > honest I don't need a blazingly fast cpu here -- the core parts that
    > require very fast speed will be written in assembly.  I won't be using
    > floating point, except for a few custom routines I'll write.  A fully
    > combinatorial barrel shifter with the ability to find the leading bit
    > and record the number of shifts required is a plus, though.  I already
    > know that division is an issue for the ARM7 (software), but that is
    > okay as I keep division to a minimum, using wider 'registers' and
    > multiplicative sums and tracking divisors, holding the division parts
    > till the very end.
    >
    > I've seen a few cases with fancy debug trace buffers available over
    > JTAG and that would be "high cotton" if I could find that, together
    > with the ADC.  But it really isn't necessary.
    >
    > The main thing I'm looking for a fast, decent 12-bit or better ADC
    > inside an ARM7TDMI (or upward compatible) cpu.  The 1.5MHz minimum
    > requirement is a bit of a stretch, perhaps.  But it is important and
    > I'm currently using an external ADC for this (which easily reach much
    > higher than this and with decent bits.)  Pushing towards 2-3MHz would
    > be pure ecstasy.
    >
    > Right now I'm just trying to compile a list for examination.  So even
    > things that are close (1MHz, for example) would be okay to include.
    > I'll talk it over, later, to see what we may have to accept.
    >
    > The other option is to use a non-ARM7TDMI compatible cpu, if that is
    > the only way to get there (for example, Atmel's XMEGA.)  I'm hoping
    > there are some options in the ARM7 field, though.
    >
    > Thanks very much in advance for any suggestions to add to the list.
    >
    > Jon

    these website i found on net are very informative.
    plz check all the links and enjoy your self.

    http://picinf.blogspot.com/ http://microcontroller51.blogspot.com/
    http://makeonlinemoneyinf.blogspot.com/
    regardz
     
  11. korenje

    korenje Guest

    On Feb 12, 9:46 am, Jon Kirwan <> wrote:
    > On Wed, 11 Feb 2009 23:20:12 -0800 (PST), -jg
    >
    > <> wrote:
    > >> I'm seeing towards $4.  But then I won't really know until an order is
    > >> placed.  Can you say anything about the tool chains you've experienced
    > >> for this device?  Cost, support reponsiveness, etc.  Alternative
    > >> development tools you looked at but didn't actually wind up trying
    > >> out?

    >
    > >Not on this family yet, but I did like the look of the Peripheral mix,
    > >so it is on our radar for future use...
    > >.
    > >Very fast ADC, and high resolution timers.

    >
    > Yeah.  I'm impressed.
    >
    > >TI are pushing some low-cost stuff
    > >Experimenter Kit w/ControlCARD I see in stock at Newark for ~$82,
    > >Piccolo controlSTICK is a USB stick, for $40.50

    >
    > >so that would be an easy way to quickly try the latest tools ?.

    >
    > I suppose so.  I'm a little disappointed looking at Eclipse
    > development tool costs for active development (not trial stuff.)
    > That's kind of off my radar range, if I decide to go that way.  Which
    > means I need to dig a little deeper about tools.  But yes, the device
    > appears attractive to me and I definitely appreciate the pointer.  I
    > think I'd heard the name dropped here once or twice, but never took
    > notice before.  But my head is turned now.  So I'll put a little
    > effort into looking further.
    >
    > Jon


    Be vary, that F28xx (including the picolo family) internal ADC does
    not deliver the promised 12 bits. Event the TI acknowledge this and
    state thet the ENOB is around 10 bits (that was for the first members
    of the family the F2812). For more info on this take a look at
    comp.dsp and comp.arch.embedded archives and TI forum
    https://community.ti.com/forums/t/3165.aspx

    The TI improves the ADC module each generation, but I can not tell you
    how the picolo series ADC behaves

    Regards, Mitja
     
  12. Jon Kirwan

    Jon Kirwan Guest

    On Thu, 12 Feb 2009 02:30:25 -0800 (PST), korenje
    <> wrote:

    ><snip of my interest in the piccolo>


    >Be vary, that F28xx (including the picolo family) internal ADC does
    >not deliver the promised 12 bits. Event the TI acknowledge this and
    >state thet the ENOB is around 10 bits (that was for the first members
    >of the family the F2812). For more info on this take a look at
    >comp.dsp and comp.arch.embedded archives and TI forum
    >https://community.ti.com/forums/t/3165.aspx
    >
    >The TI improves the ADC module each generation, but I can not tell you
    >how the picolo series ADC behaves


    This doesn't surprise me that much. It's hard for me to imagine
    getting 12 bits on something monolithic with a micro. I mentioned in
    my original post (perhaps you didn't see it) that 10.5 bits would be
    enough. I use integration, so if the noise is essentially gaussian I
    may be able to deal with this, satisfactorily. If not, could be an
    issue. I'll read up and thanks for the pointers!

    Jon
     
  13. Didi

    Didi Guest

    On Feb 12, 7:05 pm, Jon Kirwan <> wrote:
    > On Thu, 12 Feb 2009 02:30:25 -0800 (PST), korenje
    > .....
    > >Be vary, that F28xx (including the picolo family) internal ADC does
    > >not deliver the promised 12 bits. Event the TI acknowledge this and
    > >state thet the ENOB is around 10 bits (that was for the first members
    > >of the family the F2812).

    > .... that 10.5 bits would be
    > enough. I use integration, so if the noise is essentially gaussian I
    > may be able to deal with this, satisfactorily.  If not, could be an
    > issue.  I'll read up and thanks for the pointers!


    Gaussian noise is the least likely issue they have. Most if not all
    of the 12 bit ADCs I have seen on MCUs are in reality more like 10
    bits,
    INL is just that bad (DNL is 12-bittish, they have no missing codes
    after all).
    Please keep us posted if you find a true 12bit/1MSPS ADC on MCU, this
    would be something worth seeing.

    Dimiter

    ------------------------------------------------------
    Dimiter Popoff Transgalactic Instruments

    http://www.tgi-sci.com
    ------------------------------------------------------
    http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

    Original message: http://groups.google.com/group/comp.arch.embedded/msg/25a210fc78417310?dmode=source
     
  14. Jon Kirwan

    Jon Kirwan Guest

    On Thu, 12 Feb 2009 02:30:25 -0800 (PST), korenje
    <> wrote:

    ><snip>
    >The TI improves the ADC module each generation, but I can not tell you
    >how the picolo series ADC behaves


    I took a quick look. The gain error is +- 10 bits. But in this
    application, the algorithms are intentionally designed to perform
    compuations that remove gain as a factor. So long as the signal is in
    the conversion window, the gain is pretty much irrelevant (cancels out
    as a factor in the equations); so long as it doesn't vary over time
    during the snapshot, I'm fine. And I'm not looking at sine waves.

    I don't find a specification of internal noise -- magnitude, shape,
    etc. Nothing. There is some talk in the manual about SINAD and ENOB,
    but no data on input referred noise at various source voltages or S-N
    or distortion (the SINAD figure.) I've been using converters with
    about 11.3 ENOB in the past (about 70dB SINAD), but could live with
    10.5 (about 65dB SINAD), I think.

    Do you know of any discussions that attempt to bound this figure for
    the Piccolo 2802x?

    Jon
     
  15. Aleš Svetek

    Aleš Svetek Guest

    -jg wrote:
    > Jon Kirwan wrote:
    >
    >> I'm just getting into a project which "prefers" the ARM7 for business
    >> reasons, not technical ones. I do _not_ have experience writing for
    >> the ARM7 beyond some modest playing around, but will muddle through
    >> that part when the time comes.
    >>
    >> I'm looking for an ARM7TDMI core (or upward compatible) that includes
    >> a monolithic (unless someone goes through all the trouble of
    >> wire-bonding in packaging for reasonable prices) 12-bit minimum width,
    >> 1.5MHz minimum rate ADC (10.5-bit or so realizable at 2MHz with 1-2V
    >> signals is fine.)
    >> Right now I'm just trying to compile a list for examination. So even
    >> things that are close (1MHz, for example) would be okay to include.
    >> I'll talk it over, later, to see what we may have to accept.

    >
    > 12 bits and Multi MHz is a stretch,
    > Analog devices have 12 bits and 1MHz, in ARM7.
    >
    > NXP have Cortex cores at 1MHz / 12 bits, and Atmel AT91SAM3
    > seems to have slipped - I think that was 12 bits/ 1MSPS too
    > ..
    > Documents suggesting Q3/Q4 08 SAM3 samples, have not been correct,
    > and their newest ARM family guide, skips the SAM3 entirely



    You can also take a look at ST's STM32 family.
    It it CM3 with very interesting mix of peripherals.
    It also has multichannel 12-bit ADC @ 1MHz.
    (No 1.5MHz or more sampling rate tough, for what you are looking for.)

    ~ Aleš
     
  16. Jon Kirwan

    Jon Kirwan Guest

    On Thu, 12 Feb 2009 09:31:46 -0800 (PST), Didi <> wrote:

    >On Feb 12, 7:05 pm, Jon Kirwan <> wrote:
    >> On Thu, 12 Feb 2009 02:30:25 -0800 (PST), korenje
    >> .....
    >> >Be vary, that F28xx (including the picolo family) internal ADC does
    >> >not deliver the promised 12 bits. Event the TI acknowledge this and
    >> >state thet the ENOB is around 10 bits (that was for the first members
    >> >of the family the F2812).

    >> .... that 10.5 bits would be
    >> enough. I use integration, so if the noise is essentially gaussian I
    >> may be able to deal with this, satisfactorily.  If not, could be an
    >> issue.  I'll read up and thanks for the pointers!

    >
    >Gaussian noise is the least likely issue they have. Most if not all
    >of the 12 bit ADCs I have seen on MCUs are in reality more like 10
    >bits, INL is just that bad (DNL is 12-bittish, they have no missing
    >codes after all).


    I see a specification on the data sheet (one of the very few things
    they actually talk about regarding the ADC) of DNL +- 1 bit, INL +- 2
    bits. Did you look at the datasheet? (Not that it should be
    believed, but I'm just wondering where you came up with the
    "12-bittish" for this device.)

    >Please keep us posted if you find a true 12bit/1MSPS ADC on MCU, this
    >would be something worth seeing.


    If I'm lucky enough to find something interesting, I will. The XMEGA
    specification is entirely TBD. So there is absolutely no information
    on it, btw.

    Jon
     
  17. rickman

    rickman Guest

    On Feb 12, 5:30 am, korenje <> wrote:
    > On Feb 12, 9:46 am, Jon Kirwan <> wrote:
    >
    >
    >
    > > On Wed, 11 Feb 2009 23:20:12 -0800 (PST), -jg

    >
    > > <> wrote:
    > > >> I'm seeing towards $4. But then I won't really know until an order is
    > > >> placed. Can you say anything about the tool chains you've experienced
    > > >> for this device? Cost, support reponsiveness, etc. Alternative
    > > >> development tools you looked at but didn't actually wind up trying
    > > >> out?

    >
    > > >Not on this family yet, but I did like the look of the Peripheral mix,
    > > >so it is on our radar for future use...
    > > >.
    > > >Very fast ADC, and high resolution timers.

    >
    > > Yeah. I'm impressed.

    >
    > > >TI are pushing some low-cost stuff
    > > >Experimenter Kit w/ControlCARD I see in stock at Newark for ~$82,
    > > >Piccolo controlSTICK is a USB stick, for $40.50

    >
    > > >so that would be an easy way to quickly try the latest tools ?.

    >
    > > I suppose so. I'm a little disappointed looking at Eclipse
    > > development tool costs for active development (not trial stuff.)
    > > That's kind of off my radar range, if I decide to go that way. Which
    > > means I need to dig a little deeper about tools. But yes, the device
    > > appears attractive to me and I definitely appreciate the pointer. I
    > > think I'd heard the name dropped here once or twice, but never took
    > > notice before. But my head is turned now. So I'll put a little
    > > effort into looking further.

    >
    > > Jon

    >
    > Be vary, that F28xx (including the picolo family) internal ADC does
    > not deliver the promised 12 bits. Event the TI acknowledge this and
    > state thet the ENOB is around 10 bits (that was for the first members
    > of the family the F2812). For more info on this take a look at
    > comp.dsp and comp.arch.embedded archives and TI forumhttps://community.ti.com/forums/t/3165.aspx
    >
    > The TI improves the ADC module each generation, but I can not tell you
    > how the picolo series ADC behaves


    There are actually few ADC that give you the same number of effective
    bits as resolution. Any noise at all causes a loss of effective bits
    and every part has noise, even separate ADC chips. It is just a
    question of how many bit survive the journey through the chip. 10
    ENoB is not at all bad for a low cost 12 bit ADC, especially in an
    MCU. If you need much better than that, you are unlikely to find it
    without using a higher bit resolution device. But as others have
    said, uncorrelated noise can be averaged out... *if* it is
    uncorrelated. It is common for the noise to be related to the clock.
    After all, the same master clock is driving the MCU and the ADC.

    Rick
     
  18. Jon Kirwan <> writes:

    > I'm just getting into a project which "prefers" the ARM7 for business
    > reasons, not technical ones. I do _not_ have experience writing for
    > the ARM7 beyond some modest playing around, but will muddle through
    > that part when the time comes.
    >
    > I'm looking for an ARM7TDMI core (or upward compatible) that includes
    > a monolithic (unless someone goes through all the trouble of
    > wire-bonding in packaging for reasonable prices) 12-bit minimum width,
    > 1.5MHz minimum rate ADC (10.5-bit or so realizable at 2MHz with 1-2V
    > signals is fine.) Pipelined sampling and conversion stages is okay to
    > get the speed, as only one signal needs to be measured. Flash
    > programming of code, 1000-5000 pc qtys. Other features are far less
    > important, but RAM should be at least 2k (4k would be safer) and flash
    > should be at least 32k-64k (128k would probably be massive overkill.)
    > I/O required is probably less then 20 I/O pins (12, I'm counting right
    > now, outside the ADC input.) So a 44-pin package is well more than I
    > need.
    >
    > There is a core algorithm involved that processes the data, but to be
    > honest I don't need a blazingly fast cpu here -- the core parts that
    > require very fast speed will be written in assembly. I won't be using
    > floating point, except for a few custom routines I'll write. A fully
    > combinatorial barrel shifter with the ability to find the leading bit
    > and record the number of shifts required is a plus, though. I already
    > know that division is an issue for the ARM7 (software), but that is
    > okay as I keep division to a minimum, using wider 'registers' and
    > multiplicative sums and tracking divisors, holding the division parts
    > till the very end.
    >
    > I've seen a few cases with fancy debug trace buffers available over
    > JTAG and that would be "high cotton" if I could find that, together
    > with the ADC. But it really isn't necessary.
    >
    > The main thing I'm looking for a fast, decent 12-bit or better ADC
    > inside an ARM7TDMI (or upward compatible) cpu. The 1.5MHz minimum
    > requirement is a bit of a stretch, perhaps. But it is important and
    > I'm currently using an external ADC for this (which easily reach much
    > higher than this and with decent bits.) Pushing towards 2-3MHz would
    > be pure ecstasy.
    >
    > Right now I'm just trying to compile a list for examination. So even
    > things that are close (1MHz, for example) would be okay to include.
    > I'll talk it over, later, to see what we may have to accept.



    The ADUC7k family has a 12 bit, 1MHz ADC (as you probably know). It
    seems pretty good for an "embedded" ADC. As one might expect from an
    ADC manufacturer. It does in fact work at 2MHz if you set the clock
    divider bits appropriately, but to what extent that violates the spec
    I don't know. (I tried it just for fun once, and seemed to work
    fine!).

    > The other option is to use a non-ARM7TDMI compatible cpu, if that is
    > the only way to get there (for example, Atmel's XMEGA.) I'm hoping
    > there are some options in the ARM7 field, though.
    >
    > Thanks very much in advance for any suggestions to add to the list.
    >
    > Jon


    --

    John Devereux
     
  19. Didi

    Didi Guest

    On Feb 12, 8:19 pm, Jon Kirwan <> wrote:
    > On Thu, 12 Feb 2009 09:31:46 -0800 (PST), Didi <> wrote:
    > >On Feb 12, 7:05 pm, Jon Kirwan <> wrote:
    > >> On Thu, 12 Feb 2009 02:30:25 -0800 (PST), korenje
    > >> .....
    > >> >Be vary, that F28xx (including the picolo family) internal ADC does
    > >> >not deliver the promised 12 bits. Event the TI acknowledge this and
    > >> >state thet the ENOB is around 10 bits (that was for the first members
    > >> >of the family the F2812).
    > >> .... that 10.5 bits would be
    > >> enough. I use integration, so if the noise is essentially gaussian I
    > >> may be able to deal with this, satisfactorily.  If not, could be an
    > >> issue.  I'll read up and thanks for the pointers!

    >
    > >Gaussian noise is the least likely issue they have.  Most if not all
    > >of the 12 bit ADCs I have seen on MCUs are in reality more like 10
    > >bits, INL is just that bad (DNL is 12-bittish, they have no missing
    > >codes after all).

    >
    > I see a specification on the data sheet (one of the very few things
    > they actually talk about regarding the ADC) of DNL +- 1 bit, INL +- 2
    > bits.  Did you look at the datasheet?  (Not that it should be
    > believed, but I'm just wondering where you came up with the
    > "12-bittish" for this device.)


    No, this is just my general experience with ADCs speaking. I have
    looked through a fair number of MCU ADCs, and I do not remember
    having seen one like the one you describe, that's all.

    If they specify INL as +/- 2 *bits*, not LSBs, this might be
    reason to raise some suspicion. It may mean the 2 lowest bits
    are meaningless, which will match my observation on MCU ADCs
    lately. IIRC I saw one - I think on some Microchip part I was
    reviewing for someone - which was true 12 bit or sort of, but
    was much much slower (double integrating IIRC).

    I have been spoilt by ADI when it comes to ADCs, I guess,
    but I know only their standalone ones (their specs are
    really trustworthy).

    Dimiter

    ------------------------------------------------------
    Dimiter Popoff Transgalactic Instruments

    http://www.tgi-sci.com
    ------------------------------------------------------
    http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

    Original message: http://groups.google.com/group/comp.arch.embedded/msg/d46c90be2743ff2b?dmode=source
     
  20. Jon Kirwan

    Jon Kirwan Guest

    On Thu, 12 Feb 2009 10:19:14 -0800 (PST), rickman <>
    wrote:

    >On Feb 12, 5:30 am, korenje <> wrote:
    >> On Feb 12, 9:46 am, Jon Kirwan <> wrote:
    >>
    >>
    >>
    >> > On Wed, 11 Feb 2009 23:20:12 -0800 (PST), -jg

    >>
    >> > <> wrote:
    >> > >> I'm seeing towards $4. But then I won't really know until an order is
    >> > >> placed. Can you say anything about the tool chains you've experienced
    >> > >> for this device? Cost, support reponsiveness, etc. Alternative
    >> > >> development tools you looked at but didn't actually wind up trying
    >> > >> out?

    >>
    >> > >Not on this family yet, but I did like the look of the Peripheral mix,
    >> > >so it is on our radar for future use...
    >> > >.
    >> > >Very fast ADC, and high resolution timers.

    >>
    >> > Yeah. I'm impressed.

    >>
    >> > >TI are pushing some low-cost stuff
    >> > >Experimenter Kit w/ControlCARD I see in stock at Newark for ~$82,
    >> > >Piccolo controlSTICK is a USB stick, for $40.50

    >>
    >> > >so that would be an easy way to quickly try the latest tools ?.

    >>
    >> > I suppose so. I'm a little disappointed looking at Eclipse
    >> > development tool costs for active development (not trial stuff.)
    >> > That's kind of off my radar range, if I decide to go that way. Which
    >> > means I need to dig a little deeper about tools. But yes, the device
    >> > appears attractive to me and I definitely appreciate the pointer. I
    >> > think I'd heard the name dropped here once or twice, but never took
    >> > notice before. But my head is turned now. So I'll put a little
    >> > effort into looking further.

    >>
    >> > Jon

    >>
    >> Be vary, that F28xx (including the picolo family) internal ADC does
    >> not deliver the promised 12 bits. Event the TI acknowledge this and
    >> state thet the ENOB is around 10 bits (that was for the first members
    >> of the family the F2812). For more info on this take a look at
    >> comp.dsp and comp.arch.embedded archives and TI forumhttps://community.ti.com/forums/t/3165.aspx
    >>
    >> The TI improves the ADC module each generation, but I can not tell you
    >> how the picolo series ADC behaves

    >
    >There are actually few ADC that give you the same number of effective
    >bits as resolution.


    I never imagined differently. Resolution is almost a waste to care
    about. The only thing it does is provide a __suggestion__ about the
    care they took in designing it.

    >Any noise at all causes a loss of effective bits
    >and every part has noise, even separate ADC chips.


    I know.

    >It is just a
    >question of how many bit survive the journey through the chip. 10
    >ENoB is not at all bad for a low cost 12 bit ADC, especially in an
    >MCU.


    I know that isn't bad. In fact, as I mentioned earlier, my
    expectations are only for about 10.5 bits ENOB, 65dB SINAD. I'm not
    expecting the impossible here. Just something that isn't garbage.

    >If you need much better than that, you are unlikely to find it
    >without using a higher bit resolution device.


    Which, obviously, would mean "slower" when talking about monolithic
    designs with the microcontroller. It's the combination of speed and
    ENOB that I'm looking for in a monolithic design and frankly I think
    it isn't entirely out of the ballpark. It's a doable, not unreasoned
    goal I'm looking for.

    >But as others have said, uncorrelated noise can be averaged out...


    Obviously. Gaussian distribution (integral of Poisson) is the
    assumption that goes into the very idea.

    >*if* it is uncorrelated.


    Of course. Correlated noise violates the assumption.

    >It is common for the noise to be related to the clock.


    Indeed.

    >After all, the same master clock is driving the MCU and the ADC.


    I know.

    I might expect this kind of lecture had I asked for something crazy. I
    didn't. Perhaps someone else learned something, though.

    Jon
     
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Doug
    Replies:
    12
    Views:
    504
    J. Clarke
    Aug 16, 2005
  2. Alfie
    Replies:
    3
    Views:
    299
    John Devereux
    Mar 3, 2004
  3. Tilmann Reh
    Replies:
    23
    Views:
    1,136
    Peter Dickerson
    May 18, 2007
  4. ARM7 16 bit LR move

    , Oct 29, 2008, in forum: Embedded
    Replies:
    1
    Views:
    221
    Wilco Dijkstra
    Oct 29, 2008
  5. Benjamin Couillard

    Monolithic DC/DC converters

    Benjamin Couillard, Oct 7, 2011, in forum: Embedded
    Replies:
    20
    Views:
    777
Loading...

Share This Page