FreeRTOS on AT91SAM7S-EK

--- In A..., "Ray" wrote:
>
> Greetings,
> I have been lurking in this group for a few weeks, I'm VERY new to
> the ARM/ SAM7X devices, and I am trying to learn them.
>
> My expertise is with the AVR series, and I couldn't imagine the
> overhead of using an OS.
>
> I am relying on the fact that stupid question aren't against the
> rules :)
>
> What is the advantage of using an OS when you are only running a
> single application?
>
> You compile the app with the OS, its not like there is an executable
> on an SD card that is being run. Of course I'm not talking about any
> device that does run in this fashon, however, from what I've seen
> using SAM7X example code, ethernet code, I can't see the advantage of
> using an OS over an endless loop, state bits, and isr fcns?
>
> Any good args for OS usage are welcomed, I'm probably missing the key
> advantage here.

Hi Ray,

It is always a good thing to snip any parts of a quotation that are
not especially relevant to your reply. That helps keep the messages
shorter for those of us who are getting our email and web access by
dialup. :^)

There are different levels of OS for embedded systems. They range all
the way from simple executives that only handle the switching of
"tasks" to complete systems like ucLinux and VxWorks. So you can pick
the level of OS that your application requires. Even if you are only
running a single app, if the OS includes drivers for the I/O that you
are using, then it can save you a lot of work. But it is all
relative. If you are happy working without an OS and don't feel like
you are missing anything, then it is likely that you don't need an OS.
For me, as soon as it involves more complex I/O like Ethernet, I want
to use an existing OS rather than to try to import driver code into my
app. Start a New Thread

Ray wrote:
> Greetings,
> I have been lurking in this group for a few weeks, I'm VERY new to
> the ARM/ SAM7X devices, and I am trying to learn them.
>
> My expertise is with the AVR series, and I couldn't imagine the
> overhead of using an OS.
>
> I am relying on the fact that stupid question aren't against the
> rules :)
>
> What is the advantage of using an OS when you are only running a
> single application?
>
> You compile the app with the OS, its not like there is an executable
> on an SD card that is being run. Of course I'm not talking about any
> device that does run in this fashon, however, from what I've seen
> using SAM7X example code, ethernet code, I can't see the advantage of
> using an OS over an endless loop, state bits, and isr fcns?
>
> Any good args for OS usage are welcomed, I'm probably missing the key
> advantage here.

An OS is really a framework for process administration, loading and executing
process off a disk, and for sharing system resources between processes.

When you're running a single process, there's no sharing or process
control to be done, so no OS needed.

OTOH, there's the core of an OS that schedules cpu cycles between
threads in a single application. It's this part that can still be
useful in a single application. Start a New Thread

On Wednesday 22 August 2007 17:07:03 Gabriele Brosulo wrote:
> On Wednesday 22 August 2007 13:25:59 FreeRTOS.org Info wrote:
> > So you did not start from a know, working, preconfigured FreeRTOS.org
> > project, like the SAM7X GCC example? This is why they are provided.
>
> Oh yeah! Now it works!! You're right, I was working in the wrong direction,
> using makefile, startup script and friends not written for FreeRTOS..
>
> Now I created a new port for my AT91SAM7S-EK board, that is a subset of the
> lwIP_Demo_Rowley_ARM7 (it just use ParTest to blink the leds). I also added
> to the port a working OpenOCD script useful to flash program rtosdemo.bin
> trough a Olimex Parallel port JTAG dongle interface
> (http://www.olimex.com/dev/index.html).
>
> If it's useful I can post it, so you can add to the FreeRTOS project. I
> think I will upgrade it , because I need to use UART, DBGU, and perhaps
> other peripheral, but I think I will open some other thread berfore :)
>
> Thanks a lot for your help,
>
> g4b0

Just for information,
I added the USB demo to my port! Now I'm working on a UART/DBGU read write.

g4b0 Start a New Thread

Gabrielle,

Could you send your port to me ?

m...@netopen.com.br

Thanks

MArcio
----- Original Message -----
From: Gabriele Brosulo
To: A...
Sent: Thursday, August 23, 2007 5:39 AM
Subject: Re: [AT91SAM] Re: FreeRTOS on AT91SAM7S-EK
On Wednesday 22 August 2007 17:07:03 Gabriele Brosulo wrote:
> On Wednesday 22 August 2007 13:25:59 FreeRTOS.org Info wrote:
> > So you did not start from a know, working, preconfigured FreeRTOS.org
> > project, like the SAM7X GCC example? This is why they are provided.
>
>
>
> Oh yeah! Now it works!! You're right, I was working in the wrong direction,
> using makefile, startup script and friends not written for FreeRTOS..
>
> Now I created a new port for my AT91SAM7S-EK board, that is a subset of the
> lwIP_Demo_Rowley_ARM7 (it just use ParTest to blink the leds). I also added
> to the port a working OpenOCD script useful to flash program rtosdemo.bin
> trough a Olimex Parallel port JTAG dongle interface
> (http://www.olimex.com/dev/index.html).
>
> If it's useful I can post it, so you can add to the FreeRTOS project. I
> think I will upgrade it , because I need to use UART, DBGU, and perhaps
> other peripheral, but I think I will open some other thread berfore :)
>
> Thanks a lot for your help,
>
> g4b0

Just for information,
I added the USB demo to my port! Now I'm working on a UART/DBGU read write.

g4b0 Start a New Thread

> Gabrielle,
>
> Could you send your port to me ?
>
Its not really a port. The GCC SAM7 port was done some years ago. What you
are after is just an adjusted project to run on a different board.

I know I'm being pedantic :o)

Regards,
Richard.

+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.

+ http://www.SafeRTOS.com
An IEC 61508 compliant real time kernel for safety related systems. Start a New Thread

Sorry Richard, I didnt mean to hurt anybody with this simple question!

Cheers

Marcio
----- Original Message -----
From: FreeRTOS.org Info
To: A...
Sent: Thursday, August 23, 2007 3:12 PM
Subject: RE: [AT91SAM] Re: FreeRTOS on AT91SAM7S-EK
> Gabrielle,
>
> Could you send your port to me ?
>

Its not really a port. The GCC SAM7 port was done some years ago. What you
are after is just an adjusted project to run on a different board.

I know I'm being pedantic :o)

Regards,
Richard.

+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.

+ http://www.SafeRTOS.com
An IEC 61508 compliant real time kernel for safety related systems. Start a New Thread

Ray,

When your processor, and your project reaches a certain size, there
are tremendous advantages to using an OS. And an OS doesn't
necessarily have to be a huge and complex thing; many are very small
and simple. Personally, if it involves ethernet or a fairly large
number of simpler peripherals, I would definitely look to an OS.

So here are the advantages I see to using an OS:

1. Someone else has already written and debugged a whole lot of
hardware drivers, startup code, ISR's, etc. You start off, at the
very beginning, with higher-level interfaces to all your peripherals,
and a basic environment that runs, even before you start writing your
custom code.

2. Community! If you have a problem using a peripheral or software
interface with an OS, there are other people using that OS who may
have had the same issue, or who can tell you, just from looking at a
few lines of your code, what you're doing wrong. You may have
discovered a bug in the OS, in which case the actual authors may solve
your problem. (If not, it offers you an opportunity to give back, with
a fix!) Or someone else may discover (and fix) a bug that was going
to bite you in the butt 3 months down the line, and it gets fixed
before you ever have to deal with it.
If you posted your whole custom app and asked for help with some
problem, I doubt any sane person would take the time to go through all
of your code to try to help you figure out what's wrong.

3. Multitasking. It can take surprisingly little overhead, and makes
coding well-structured applications a LOT simpler.

4. Education. Yes, there's a bit of up-front overhead; you have to
learn the OS API, and sometimes you have to dig deep into someone
else's source code to figure out what's wrong. But you also get to
see how someone else structured and solved a lot of the problems that
you would have had to solve if you wrote it all yourself. Working with
an elegant OS API will teach you more in a shorter period of time than
any book or class will! (And you'll learn twice as much working with
your 2nd OS, since you can compare the 2 approaches.)
Of course, you have to put a little thought in; if you use an OS,
don't just blindly code to the examples. If a function call looks
weird (like, "Why does it need this argument" or "Why do I have to
fill in all this stuff in that structure") you can usually figure it
out - and gain a lot of insight on how it works "under the covers"
without actually diving deep into the OS code.

Ultimately, it's really a question of scale; for something really
simple, an OS is overkill. For something really complex, an OS is a
necessity. The boundary seems to keep dropping lower and lower.

--- In A..., "Ray" wrote:
>
> Greetings,
> I have been lurking in this group for a few weeks, I'm VERY new to
> the ARM/ SAM7X devices, and I am trying to learn them.
>
> My expertise is with the AVR series, and I couldn't imagine the
> overhead of using an OS.
>
> I am relying on the fact that stupid question aren't against the
> rules :)
>
> What is the advantage of using an OS when you are only running a
> single application?
>
> You compile the app with the OS, its not like there is an executable
> on an SD card that is being run. Of course I'm not talking about any
> device that does run in this fashon, however, from what I've seen
> using SAM7X example code, ethernet code, I can't see the advantage of
> using an OS over an endless loop, state bits, and isr fcns?
>
> Any good args for OS usage are welcomed, I'm probably missing the key
> advantage here.
>
> Regards,
>
> Ray
> Start a New Thread

On Thursday 23 August 2007 15:00:33 Marcio Campos Lima(Net Open) wrote:
> Gabrielle,
>
> Could you send your port to me ?
>
> m...@netopen.com.br
>
> Thanks
>
> MArcio

OOps.. I send it to your personal email, pheraphs it will be useful for
others..



Hi,
You can download it from here (3,9 Mb):

http://gabo.homelinux.com/code/FreeRTOSV4.4.0_AT91SAM7S-EK_added.tar.bz2

or here (7,2 Mb):

http://gabo.homelinux.com/code/FreeRTOSV4.4.0_AT91SAM7S-EK_added.zip



g4b0 Start a New Thread

--- In A..., Gabriele Brosulo wrote:
>
> On Wednesday 22 August 2007 17:07:03 Gabriele Brosulo wrote:
> > On Wednesday 22 August 2007 13:25:59 FreeRTOS.org Info wrote:
> > > So you did not start from a know, working, preconfigured
FreeRTOS.org
> > > project, like the SAM7X GCC example? This is why they are
provided.
> >
> >
> >
> > Oh yeah! Now it works!! You're right, I was working in the wrong
direction,
> > using makefile, startup script and friends not written for
FreeRTOS..
> >
> > Now I created a new port for my AT91SAM7S-EK board, that is a
subset of the
> > lwIP_Demo_Rowley_ARM7 (it just use ParTest to blink the leds). I
also added
> > to the port a working OpenOCD script useful to flash program
rtosdemo.bin
> > trough a Olimex Parallel port JTAG dongle interface
> > (http://www.olimex.com/dev/index.html).
> >
> > If it's useful I can post it, so you can add to the FreeRTOS
project. I
> > think I will upgrade it , because I need to use UART, DBGU, and
perhaps
> > other peripheral, but I think I will open some other thread
berfore :)
> >
> > Thanks a lot for your help,
> >
> > g4b0
>
> Just for information,
> I added the USB demo to my port! Now I'm working on a UART/DBGU
read write.
>
> g4b0
>

Hi Gabriele, I have a different board and struggling to get the
Freertos running on it. Could you please post you project?

Tudor Start a New Thread

--- In A..., "twgbonehead"
wrote:
>
> Ray,
>
> When your processor, and your project reaches a certain size, there
> are tremendous advantages to using an OS. And an OS doesn't
> necessarily have to be a huge and complex thing; many are very small
> and simple. Personally, if it involves ethernet or a fairly large
> number of simpler peripherals, I would definitely look to an OS.
>
I definitely agree with this point, I'm coming from a world of 4k
words of program space, harvard arch. A very simplistic model
compared to the ARM. I certianly see the advantage when programs
reach several 10k words of code size. Although Ethernet is quite
simple, given an on board MAC. I'm not sure if I can justify using
an OS when all I'm doing is Ethernet, SD storage, a few A2D's,
possibly USB interfacing.
> So here are the advantages I see to using an OS:
>
> 1. Someone else has already written and debugged a whole lot of
> hardware drivers, startup code, ISR's, etc. You start off, at the
> very beginning, with higher-level interfaces to all your
peripherals,
> and a basic environment that runs, even before you start writing
your
> custom code.
Yes this can be an advantage, it can also be a source of software
upgrade bugs. Code reuse has been the catalyst for several software
catastrophes, usually associated with cost cutting, hardware
upgrades, and dare I say, management decisions:)

Again, most of my firmware is less then 4k words/chip. Refactoring,
code review and tweaking for hardware changes has been rather
inexpensive. I'm slowly diving into more robust network interfacing
of our products, I'm sure code size will be exploding soon!

> 3. Multitasking. It can take surprisingly little overhead, and
makes
> coding well-structured applications a LOT simpler.

Yes, as long as you're not requiring hard real-time scheduling. But
then, my applications are not usually overly complex and time
critical at the same time, or in the same chip. I do however need to
set a periodical timer to appx 18-20 uSecs for frequency measurement,
and other small but required i/o states. I usually have no more than
3 ISRs, along with a very short main() fcn

I think the OS based apps prefer a slower interval timer.

> Ultimately, it's really a question of scale; for something really
> simple, an OS is overkill. For something really complex, an OS is a
> necessity. The boundary seems to keep dropping lower and lower.
Excellent information, and there have been several other posts as
well, with some great info and links. I think one of the most
important factor is compiler support for the OS. I'm playing with
ICCARM right now for non OS code, and I have the Eclipse/Nut setup
for OS based work.

Thank You to all who have written in. I think from all the
discussion, the questions for me to ask are how complex is the
application, how real-time is the application. I have a feeling for
one of my future projects, an OS might be needed. For now, I'm still
learning to wiggle pins and LED's :) Start a New Thread