High end vs low end platforms

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??

Reply to
Bruce Varley
Loading thread data ...

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

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.

Reply to
Bruce Varley

There are three mainstream open source RTOS options which come to mind:

RTEMS

formatting link
ECOS
formatting link
FreeRTOS
formatting link

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
Reply to
Simon Clubley

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.
 Click to see the full signature
Reply to
Tim Wescott

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

Reply to
Bruce Varley

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.