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.

High end vs low end platforms

Discussion in 'Embedded' started by Bruce Varley, Mar 14, 2012.

  1. Bruce Varley

    Bruce Varley Guest

    This is a serious enquiry, sorry if it comes across as a bit of a rant.

    I’ve done two projects over the last 6 months, both with a similar target
    end result, a real time device for processing MIDI messages from musical
    equipment. The first implementation used an HCS12, it took just over a month
    to stage the hardware, and to prototype and complete the software from the
    ground up. That included a basic RTOS with multilevel IRQ processing, a
    rudimentary file system and transfer through a serial connection, and
    interfacing with a couple of on-bus and SPI devices. The final system came
    together with only the usual minor bugs, rapidly stabilised and has been
    performing faultlessly.

    For the second implementation I decided to use an embedded Linux device
    with a file system on flash, because it provided proper file support and a
    heap more RAM for holding large sequencing arrays. In 3 months, all I have
    is a bricked platform, high blood pressure and snippets of trial software
    that don’t work. The huge masses of system documentation, much of it cryptic
    to my eyes, have made gaining any sort of understanding a real struggle.
    Simple test snippets behaved in unexpected ways due to obscure complexities
    within the SBC. Even the system vendor support was unable to give clear
    answers on some aspects of the I/O that were important to me. There were
    questions on latency that were never clarified, that could have torpedoed
    the entire exercise if they’d emerged as issues.

    Aside from the obvious observation, which I can’t disagree with, that I’m a
    boy taking on a mans job, I’d be interested in any observations on the
    following:

    What are the determining factors that people use in deciding whether to use
    a naked (in a software sense) SBC or one with a sophisticated OS onboard?

    Do people get to a point where it’s easier to do any embedded job with a
    platform with a sophisticated OS? Or does the overhead always need to be
    factored into choice of platform?

    Are todays high-end SBCs maybe just a transitional stage on the way to
    something that’s more ‘plugnplay’?
     
    Bruce Varley, Mar 14, 2012
    #1
    1. Advertisements

  2. You don't seem to have considered a third option. Use a open source RTOS
    and write a BSP for it so that it will run on your hardware.
    I use a RTOS when I need to run multiple tasks or need to do routine
    support operations like file systems. On smaller projects, both ARM and
    AVR, I just write code to run on the bare metal.

    I should point out that I am speaking as a hobbyist here, so the time
    versus cost tradeoffs in deciding to write a full BSP are different for
    me. OTOH, you seem to have sunk a large amount of time into your Linux
    based solution already.

    Simon.
     
    Simon Clubley, Mar 14, 2012
    #2
    1. Advertisements

  3. Bruce Varley

    Bruce Varley Guest

    Thanks for the comments Simon. This is a hobby thing too, so absence of
    frustration is high on the wish list. And, no, I haven't committed myself to
    the Linux solution, I'd be more than happy to abandon it right at this
    moment. Would you (or anyone else) care to suggest a good, not-too-expensive
    open source RTOS for ARM, plus associated C/C++ environment, that sounds
    exactly what I'm after.
     
    Bruce Varley, Mar 14, 2012
    #3
  4. There are three mainstream open source RTOS options which come to mind:

    RTEMS http://www.rtems.com/
    ECOS http://ecos.sourceware.org/
    FreeRTOS http://www.freertos.org/

    I only have experience with RTEMS. (I use it because it has Ada support
    built in).

    I have a few words of advice before you go down this path, regardless
    of which option you might choose.

    Writing a BSP requires a specific skillset and experience with various
    low level concepts. It also requires (if you are doing this as a hobbyist)
    a mindset which enjoys getting involved in studying and understanding a
    large range of very low level details about the target platform which
    you are writing the BSP for.

    I absolutely love getting involved at that level of detail and consider
    writing a new BSP or device driver as just part of the fun of this
    hobby. (Yes, I am been serious; I enjoy OS level coding).

    However, you may have a different viewpoint, so I would strongly recommend
    you look at the existing BSPs and RTOS documentation first for whatever
    RTOS options you are interested in to see what is involved in bringing up
    a new BSP and see if it's something you want to get involved in.

    You should also see which of the RTOS options are most closely matched
    in terms of your general functionality requirements (for example, your
    flash file system requirement) in order to minimise the amount of general
    functionality you need to add to the RTOS code base.

    However, you may get lucky and find your target platform is already
    supported in at least one RTOS, or there's a close match which you
    can use as a starting point. Which SBC are you using for your Linux
    platform ?

    Simon.
     
    Simon Clubley, Mar 14, 2012
    #4
  5. Bruce Varley

    Tim Wescott Guest

    You get a feel for the amount of work (and processor power) required for
    a "big box" OS, and for the degree of fit between what you're trying and
    the problem at hand. Then you decide if the features that you're getting
    with the "big box" OS are worth the time & trouble (in the commercial
    world read "expense and uncertainty") and you make a go/no-go decision.

    And, sometimes you do as you have done; you start down a path and find
    out that it's a Very Bad Idea, then you back away.

    If you're using a PC-class SBC, I don't think you're going to get away
    from finding obscure details that muck you up -- folks have been making
    PCs for long enough, and they're complex enough, that they've made it
    into the class of things that "everyone just knows how to use" -- which
    means that no one bothers to document them in detail any more, which, in
    turn, means that at best you'll find some well-written book out there
    that details most of the stuff you need to know and maybe even is still
    up-to-date enough to be useful a year after it is published.

    If it's just more RAM and lots of flash that you need, you might want to
    look at one of the ARM Cortex M3 parts (yes, I'm in love with those
    things). You can get them with tons-o-memory, SD memory cards are
    reputed to be easy to interface anything and there are freeware DOS
    filesystems out there specifically for SD memory cards, so that kinda
    solves both of your stated problems, without requiring you to go the full-
    blown SBC route.

    --
    My liberal friends think I'm a conservative kook.
    My conservative friends think I'm a liberal kook.
    Why am I not happy that they have found common ground?

    Tim Wescott, Communications, Control, Circuits & Software
    http://www.wescottdesign.com
     
    Tim Wescott, Mar 14, 2012
    #5
  6. Bruce Varley

    Jerry Gardner

    Joined:
    Mar 5, 2012
    Messages:
    5
    Likes Received:
    0


    I would suggest keeping things as simple as possible and not using something like Linux, which generally includes everything, including the kitchen sink.

    Start with a basic RTOS and add needed features on top of it, such as a simple file system. It's generally much easier to get that to work than if you start with a monster such as Linux and try to shoe horn it into your environment.

    For an ARM development environment, you won't find one better than Rowley CrossWorks for ARM. They have a "personal" license for hobbyists that's only $150. The IDE is one of the best I've ever used and supports just about all ARM variants. If you don't already have a J-TAG unit, take a look at the Segger J-LINK EDU. This is the non-commercial version of the J-LINK and is only about $60.
     
    Jerry Gardner, Mar 15, 2012
    #6
  7. Bruce Varley

    Bruce Varley Guest

    Thanks for the comments, Simon. The Linux system I chose is unlikely to be a
    good platform, it interfaces its I/O through an FPGA, there is certain to be
    tons of vendor-specific I/O side software/firmware involved that would
    seriously complicate any deviation from the supplied OS. I will check with
    the vendor, nonetheless.

    Regarding system internals detail, I have plenty of energy, enthusiasm and
    time for that sort of thing these days. In my earlier days, I used to write
    quite sophisticated things in asm, just for fun, and very recently I've just
    finished my first serious FPGA project. The path that you've put me onto
    looks like just the thing. Cheers
     
    Bruce Varley, Mar 18, 2012
    #7
    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.