High end vs low end platforms

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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í?



Re: High end vs low end platforms
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: High end vs low end platforms

Quoted text here. Click to load it

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.



Re: High end vs low end platforms
Quoted text here. Click to load it

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, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: High end vs low end platforms

Quoted text here. Click to load it

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



Re: High end vs low end platforms

Quoted text here. Click to load it

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.
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline