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.

ST ARM versus Atmel ARM?

Discussion in 'Embedded' started by John-Smith, May 18, 2014.

  1. John-Smith

    John-Smith Guest

    This is a bit of a simplistic Q and I am in the early stages of

    My background is a huge amount of assembler on Z80, Z180, Z280, 80x86,
    8031, 8051, AT90S1200, H8/300, etc. Plus a bit of C. No C++.

    Now I am starting on a new product which will need about 1MB of *data*
    storage (factory initialised so can be on chip FLASH) plus some
    floating point maths, and will be done mostly in C.

    I have been using Atmel chips for many years but they seem to run each
    one for only a few years nowadays, and that is my biggest negative on
    Atmel. We were going to do this (and other upcoming projects, mostly
    serial comms) with one of the ATmega128 type of chips but each time I
    look at the range, they seem to have discontinued half of the specific

    Whereas the H8/300 has only just gone on LTB, after some 25 years...
    which leads me to think ST is the way to go as this is a "serious"
    industrial product which will run for at least 10 years. Also, looking
    at what other firms use (e.g. Pico) they seem to be often using the ST
    32F103 or similar which comes in a huge family, from miniscule 6mm x
    6mm chips with 16k FLASH (cost $1 1k+) to 1MB FLASH for about $10.

    The devt kits seem to use GNU compilers and the Eclipse IDE, with IAR
    charging even more for their compilers than they ever used to. IAR
    compilers used to be good but they did contain some really bad details
    e.g. an incredibly slow sscanf() where they were doing multiple
    floating point ops for every single input digit. I spent ages
    optimising that stuff. I think their runtimes were written in generic
    C and that was it. The tool cost is not that important in this case

    I' be very interested in hearing peoples' views on this. I really want
    a 10 year life of the actual device.
    John-Smith, May 18, 2014
    1. Advertisements

  2. Anders.Montonen, May 18, 2014
    1. Advertisements

  3. John-Smith

    Randy Yates Guest


    I can't help you on longevity, but for me the fact TI offers Code
    Composer Studio for free or at least cheap ($800) is a big deal. There
    are several tool vendors that want you to shuck out $3000+ for
    _device-specific_ toolsets. Not happening with this dude.

    I also like very very much that TI's CCS runs under linux and windows.
    Randy Yates, May 19, 2014
  4. John-Smith

    Tauno Voipio Guest

    If your floating point is not in a hurry, the Atmel AT91SAM4SD32
    seems to fit your bill.

    I have experience of Cortex-M processors from three vendors:
    Atmel, ST and TI/Luminary. The peripherals of Luminary are
    very well organized, the Atmel are a bit more disordered,
    and ST are pretty challenging.
    I dropped IAR years ago when I got a sick dongle with a compiler
    upgrade. The version I upgraded from did not have a dongle.

    The free toolchain, GCC, Eclipse and OpenOCD have fit the bill
    on all of the above processors well. The compiler has a bewildering
    number of switches, and it takes some time to find the right
    combination for the task at hand. Reading the generated assembler
    code helps a lot.

    With GCC and Cortex-M, the need for assembler code is minimal.
    Even the startup code can (and should) be written in C. The same
    applies to interrupt handlers. In my applications, there are
    some small embedded assembler functions, mainly in task switcher.
    Tauno Voipio, May 19, 2014
  5. John-Smith

    John-Smith Guest

    The SD card interface is very interesting. We could use a few MB of

    It is damn hard from their website to find which devices do which ADC
    and DAC resolutions!
    In what way are they challenging?

    I have programmed loads of weird hardware, with the Zilog/AMD 85c30
    (SDLC) being probably the weirdest in terms of bizzare behaviour, and
    have seen loads of undocumented stuff to do with the exact instruction
    sequences / bit manipulations required to clear pending interrupts
    etc. One can waste a whole life on crap like that. Is that what you

    My main requirement is driving a 16 bit DAC, at about 100k
    samples/sec. It will probably be an audio DAC and probably I2C rather
    than parallel. But this should "just work" :) I did once bit-bang I2C
    on the H8/300 (for a Texas 12-bit ADC) and it was horrible, and I
    discovered some TI data sheet "artefacts" which they had not known
    about... But these ARM chips all come with I2C interfaces already
    I would never touch a dongled product. I lost the dongles on a $20k
    Xilinx kit (Viewlogic 4 + XACT6) many years ago, but luckily a Russian
    cracked it.
    I had read about the GCC compiler switches but it seems that once this
    is set up, it can be left alone.
    John-Smith, May 19, 2014
  6. John-Smith

    Mikko OH2HVJ Guest

    Usually the uC ADC and DAC range from horrible to bad, so they
    typically do not highlight the specs.
    If audio DAC is good enough, I recommend having a look at
    I2S, which is a synchronous SPI-like interface used for audio.
    I've used this kind of setup (LP1768+DAC) for outputting complex
    calibration signal from MCU flash.
    Mikko OH2HVJ, May 20, 2014
  7. John-Smith

    John-Smith Guest

    They all seem to be 12 bit. I agree that IME the last 2 bits or so are
    fiction, though adding up 100 samples and dividing by 100 seems to
    work :)
    Thanks - will check. Audio should be fine. I don't need full 16 bit
    linearity and certainly not 16-bit temp stability (hard to do anyway).
    John-Smith, May 20, 2014
  8. Op Sun, 18 May 2014 12:18:47 +0200 schreef John-Smith
    The IAR Embedded Workbench also has more features, tools and example
    projects than than it ever used to. If there are many things that you
    don't need, then indeed the cost might be too high.
    I'm curious which target processor and which version that was, but AFAICS
    recent libs don't use floating point math when dealing with integers and
    you can choose between different printf/scanf formatter features.
    Boudewijn Dijkstra, May 20, 2014
  9. John-Smith

    Randy Yates Guest

    That's called oversampling and buys you log_4(M) more bits of
    resolution, where M is the oversampling factor. See section 3


    Randy Yates, May 20, 2014
  10. 2014-05-18 12:18, John-Smith skrev:

    Hi John,
    As a former Atmel FAE, I can give you a little info on the Atmel part.

    As for longevity, the AT91M40800 was released in 1997-8, and is still in
    production.Í„ (Actually this was the AT9140400, but they added
    an additional 4 kB of RAM)
    The ARM devices has had much longer life time than the AVRs.
    This is mostly because Atmel has released pincompatible AVR devices
    with more features, and when those are in production, the older
    devices has been obsoleted. This philosophy has been changed
    a couple of years ago, so expect longer lifetime even on AVRs.

    I would still expect longer lifetime on ARMs still.

    With Atmel, you have the gcc based Atmel Studio, which is free of charge
    and supports both AVR, AVR32 and ARM. This is more like Visual Studio
    than Eclipse. They connect to low cost JTAG-ICE or SAM-ICE which is
    a lower priced version of the Segger J-Link used by IAR.
    The low price is good, but they will only work with Atmel parts,
    and when Atmel releases a new part, you will have to update
    the firmware.

    If you need floating point, then the AVR32 UC3C is quite nice
    due to its internal floating point unit. There are some SAM4's with
    floating point unit as well.

    Both the SAM4s and the AVR32s has I2S support, and each I2S is
    connected to dual buffered DMA both on transmit and receive sides.
    You should have ZERO problem maintaining 100 kbps on I2S.

    Also each serial port is connected to dual buffered DMA controllers
    in each direction, with some nice additions like idle detection.

    You can easily run the serial ports at megabit speed without problems.

    Flash is generally quite expensive while onchip, and an external
    dataflash or SPI flash will be quite small, and much cheaper.
    The SPIs are (surprisingly) supported by dual buffer DMA,
    so you can load data at several MBytes per second in the background.

    An interesting feature of SAM4s and UC3C is the event system.
    This allows peripherals to interact without CPU intervention,
    and has

    Best Regards
    Ulf Samuelsson
    Ulf Samuelsson, May 20, 2014
  11. John-Smith

    Paul Rubin Guest

    Do you mean the AT9140400 was introduced in 1997-8 and quietly replaced
    with a larger part sometime between then and now?
    Yes, I'd have thought "longevity" means you get the exact same part.
    Paul Rubin, May 20, 2014
  12. John-Smith

    John-Smith Guest

    It was their Z80/Z180 compiler.

    In that case we were using sscanf() to parse strings like 123.45 into
    32-bit floats. The code was profiled with a real hardware ICE (those
    were the days!) and we found it was spending ~99% of its time in the
    function, which was doing a float add and a float mult (by 10!) for
    every digit.
    John-Smith, May 20, 2014
  13. John-Smith

    John-Smith Guest

    What about code and fixed data security?

    On chip flash ought to be reasonably good for that. This is not a high
    security application but it would be nice if I could protect the on
    chip stuff from a casual code dump.
    John-Smith, May 20, 2014
  14. 2014-05-20 17:44, Paul Rubin skrev:
    Yes, Same process/package etc so it was more like a revision of the chip.

    Ulf Samuelsson
    Ulf Samuelsson, May 21, 2014
  15. 2014-05-20 22:45, John-Smith skrev:
    On chip flash is of course more secure than off chip flash.
    Then again, the extra security is going to be quite expensive.

    There are micros with AES/3DES crypto engines which can be
    used to encrypt external data.

    Some of those chips have export restriction,
    but the XMEGA does not.

    If you want STM32 witrh M4F (FPU) core, then Digikey only sells maximum
    256 kB versions. Atmel has 512kb/1MB versions.

    Ulf Samuelsson
    Ulf Samuelsson, May 21, 2014
  16. Hi Ulf,

    Trouble with dataflash is that Atmel sold the product line to a company
    whose fab went bust -> instant unobtainium. How do I know this I hear
    you all ask... :(

    I don't think they have any significant advantages over normal modern
    SPI flash anyway, just twice the price and vendor-lockin to a
    non-existent product.
    John Devereux, May 21, 2014
  17. John-Smith

    Paul Rubin Guest

    I think that


    is the part on the STM M4 Discovery board. It has 1M flash, 192k ram,
    and some crypto acceleration and secure boot IIRC.
    Paul Rubin, May 21, 2014
  18. John-Smith

    Randy Yates Guest

    RAM FLASH Clock Temp. Price
    P/N (KB)(KB) MAC PHY Crypto UARTS CAN I2C ADC (MHz) Range (USD)
    http://tinyurl.com/oakwg9t MK60FN1M0VLQ12 256 1024 y y y 6 2 2 4 16-bit 120 -40 to 105 6.69 (10KU)

    Randy Yates, May 21, 2014
  19. Anders.Montonen, May 22, 2014
  20. John-Smith

    John-Smith Guest


    Anyway, I can do all I need with 1MB on chip flash.

    It needs to be secure enough that somebody can't just read it straight
    out. Presumably that must be possible - even the little micros have
    such a mode.
    John-Smith, May 22, 2014
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.