Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #39206 > unrolled thread

7 lessons for embedded developers from ESC Boston 2015

Back to article view | Back to comp.lang.forth

Contents

  7 lessons for embedded developers from ESC Boston 2015 visualforth@rocketmail.com - 2015-05-19 15:44 -0700
    Re: 7 lessons for embedded developers from ESC Boston 2015 "Elizabeth D. Rather" <erather@forth.com> - 2015-05-19 14:55 -1000
      Re: 7 lessons for embedded developers from ESC Boston 2015 visualforth@rocketmail.com - 2015-05-20 10:04 -0700
    Re: 7 lessons for embedded developers from ESC Boston 2015 Mark Wills <markwills1970@gmail.com> - 2015-05-20 00:29 -0700
      Re: 7 lessons for embedded developers from ESC Boston 2015 djc <ciesinger@gmx.net> - 2015-05-20 03:47 -0700
      Re: 7 lessons for embedded developers from ESC Boston 2015 hughaguilar96@gmail.com - 2015-06-04 21:02 -0700
        Re: 7 lessons for embedded developers from ESC Boston 2015 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-04 23:31 -0700
          Re: 7 lessons for embedded developers from ESC Boston 2015 rickman <gnuarm@gmail.com> - 2015-06-05 03:15 -0400
            Re: 7 lessons for embedded developers from ESC Boston 2015 stephen@mpeforth.com (Stephen Pelc) - 2015-06-05 10:48 +0000
              Re: 7 lessons for embedded developers from ESC Boston 2015 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-05 07:55 -0700
                Re: 7 lessons for embedded developers from ESC Boston 2015 stephen@mpeforth.com (Stephen Pelc) - 2015-06-05 15:54 +0000
                  Re: 7 lessons for embedded developers from ESC Boston 2015 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-05 09:32 -0700
                    Re: 7 lessons for embedded developers from ESC Boston 2015 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-05 07:46 -1000
                    Re: 7 lessons for embedded developers from ESC Boston 2015 hughaguilar96@gmail.com - 2015-06-06 16:28 -0700
                      Re: 7 lessons for embedded developers from ESC Boston 2015 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-06 21:00 -0700
                        Re: 7 lessons for embedded developers from ESC Boston 2015 visualforth@rocketmail.com - 2015-06-09 10:04 -0700
                          Re: 7 lessons for embedded developers from ESC Boston 2015 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-09 10:58 -0700
                    Re: 7 lessons for embedded developers from ESC Boston 2015 Paul Rubin <no.email@nospam.invalid> - 2015-06-07 20:40 -0700
                Re: 7 lessons for embedded developers from ESC Boston 2015 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-05 07:40 -1000
            Re: 7 lessons for embedded developers from ESC Boston 2015 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-05 07:31 -1000
          Re: 7 lessons for embedded developers from ESC Boston 2015 Mark Wills <markwills1970@gmail.com> - 2015-06-05 05:35 -0700
            Re: 7 lessons for embedded developers from ESC Boston 2015 foxaudioresearch@gmail.com - 2015-06-05 06:05 -0700
              Re: 7 lessons for embedded developers from ESC Boston 2015 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-05 07:43 -0700
                Re: 7 lessons for embedded developers from ESC Boston 2015 rickman <gnuarm@gmail.com> - 2015-06-05 14:47 -0400
                Re: 7 lessons for embedded developers from ESC Boston 2015 albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-06 09:28 +0000
              Re: 7 lessons for embedded developers from ESC Boston 2015 Mark Wills <markwills1970@gmail.com> - 2015-06-05 10:43 -0700
                Re: 7 lessons for embedded developers from ESC Boston 2015 Paul Rubin <no.email@nospam.invalid> - 2015-06-07 20:03 -0700

Page 2 of 2 — ← Prev page 1 [2]

#39578

On Friday, 5 June 2015 07:31:26 UTC+1, Raimond Dragomir  wrote:
> vineri, 5 iunie 2015, 07:02:18 UTC+3, hughag...@gmail.com a scris:
> > On Wednesday, May 20, 2015 at 12:29:53 AM UTC-7, Mark Wills wrote:
> > > On Tuesday, 19 May 2015 23:44:44 UTC+1, visua...@rocketmail.com  wrote:
> > > > Lesson #1 - Connected devices need at least an RTOS 
> > > > When developing an embedded system the temptation exists to forgo an RTOS and develop everything from scratch in a bare-metal fashion. For Internet connected devices excluding an RTOS looks to be a foolhardy endeavor. The features provided in an RTOS provide developers with significant features such as task scheduling, stack maintenance, and hooks into TCP/IP stacks along with many other features that are just too time-consuming to develop from scratch. For a connected device at least an RTOS should be used to help ease the development and security burden. 
> > > 
> > > I agree with #1. Why go to the trouble of doing things like a TCP/IP stack
> > > and all the de-bugging etc that would be required to put into it?
> > > 
> > > Thing is: With Forth, Forth *is* the RTOS. With something like VFX or
> > > SwiftX you *do* get TCP/IP and task switching, and memory management.
> > > 
> > > If you want them.
> > 
> > Forth isn't an RTOS any more than C is an RTOS --- in both cases it is necessary to write an RTOS in the language taking recourse in non-standard programming (assembly-language) --- also, in both cases the result is usually not preemptive, so it is not an RTOS.
> 
> Good point. I'm tired to read such hypes about forth. In fact an RTOS is
> a REAL-TIME operating system - it's not a language. 

But Forth isn't *just* a language either. It's an entire REPL environment.
Unless you're using a cross compiler. Forth is a mini-os. We may call it
a programming language, but we really shouldn't. It's a self contained
environment. In my Forth system I can obtain disk directories, edit blocks,
list them etc. That's not the function of a programming language. It's the
underlying OS (albeit very simple).

WRT RTOS, I don't agree. In VFX I can launch a task in a single line of code.
That task can use semaphores, mutexes, the whole shootery. All provided
by VFX. No such analogue exists in C. That's because Forth is a *system*
and C is a language.

[toc] | [prev] | [next] | [standalone]

#39580

I think we have to therefore say that VFX is an RTOS or at least a System, and SwiftForth for embedded devices is such a System, as is any other suitably extended Forth implementation but standard Forth is just a language.

I also have to agree with Stephen on coopertative task switchers.  I have found for small systems very few things need to be preemptive and if one does, hook it to an interrupt.  The atomic nature of the Fortth cooperative switcher and the amazingly fast context switching time means for a specific application you can get better scheduling results with the Forth switcher and far less surprises in the field.  It is counterintuitive, but it just works.

And by the way, there is always one less task running... The preemptive switcher task is not needed.

BF

[toc] | [prev] | [next] | [standalone]

#39582

vineri, 5 iunie 2015, 16:05:15 UTC+3, foxaudio...@gmail.com a scris:
> I think we have to therefore say that VFX is an RTOS or at least a System, and SwiftForth for embedded devices is such a System, as is any other suitably extended Forth implementation but standard Forth is just a language.
> 
> I also have to agree with Stephen on coopertative task switchers.  I have found for small systems very few things need to be preemptive and if one does, hook it to an interrupt.  The atomic nature of the Fortth cooperative switcher and the amazingly fast context switching time means for a specific application you can get better scheduling results with the Forth switcher and far less surprises in the field.  It is counterintuitive, but it just works.
> 
> And by the way, there is always one less task running... The preemptive switcher task is not needed.
> 
> BF

I'm against preemtive systems too. To me it seems a crazy idea to make the 
entire application preemptive like interrupts. Very hard to manage, you end 
up programming the rtos (semaphores, flags, critical sections etc.) instead
of programming your application. But probably the rtos vendors want exactly
this, to hook you up to their product.

I'm using a cooperative os, both in C and in forth. It is almost the same
only that the forth one needs two stacks to manage. It's fast indeed, but
this is the merit of the cooperative type and the merit of coded in assembly
(even for the C one). Neither C nor Forth helps my os in any way.

BTW, the less task running is not quite true... the preemptive idle task can 
just put the system to sleep when there's nothing to do. The cooperative one
is supposed to not have the idle task, but it should loop forever searching
for the next task ready to run... then, this loop is similar to idle task...
Of course, when no task is ready, it puts the system to sleep too.

[toc] | [prev] | [next] | [standalone]

#39598

On 6/5/2015 10:43 AM, Raimond Dragomir wrote:
> vineri, 5 iunie 2015, 16:05:15 UTC+3, foxaudio...@gmail.com a scris:
>> I think we have to therefore say that VFX is an RTOS or at least a System, and SwiftForth for embedded devices is such a System, as is any other suitably extended Forth implementation but standard Forth is just a language.
>>
>> I also have to agree with Stephen on coopertative task switchers.  I have found for small systems very few things need to be preemptive and if one does, hook it to an interrupt.  The atomic nature of the Fortth cooperative switcher and the amazingly fast context switching time means for a specific application you can get better scheduling results with the Forth switcher and far less surprises in the field.  It is counterintuitive, but it just works.
>>
>> And by the way, there is always one less task running... The preemptive switcher task is not needed.
>>
>> BF
>
> I'm against preemtive systems too. To me it seems a crazy idea to make the
> entire application preemptive like interrupts. Very hard to manage, you end
> up programming the rtos (semaphores, flags, critical sections etc.) instead
> of programming your application. But probably the rtos vendors want exactly
> this, to hook you up to their product.
>
> I'm using a cooperative os, both in C and in forth. It is almost the same
> only that the forth one needs two stacks to manage. It's fast indeed, but
> this is the merit of the cooperative type and the merit of coded in assembly
> (even for the C one). Neither C nor Forth helps my os in any way.

I've seen the other side of that coin.  Formerly programming for Windows 
3.1 one of our programmers had a task that was doing a long calculation, 
hard to break into pieces.  He continually found portions of the calcs 
that would take longer than expected due to data dependencies. 
Preemptive would have been so much simpler for him.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#39605

In article <d2354ab8-3f0d-4741-95a9-b98fa8d13b5d@googlegroups.com>,
Raimond Dragomir  <raimond.dragomir@gmail.com> wrote:
>vineri, 5 iunie 2015, 16:05:15 UTC+3, foxaudio...@gmail.com a scris:
>> I think we have to therefore say that VFX is an RTOS or at least a
>System, and SwiftForth for embedded devices is such a System, as is any
>other suitably extended Forth implementation but standard Forth is just
>a language.

Hardware driven interrupts are a form of preemption that is sometimes
necessary. You can have priorities in interrupts and sometimes that
is pretty essential. I've done this optical delay line software for
the ESO-telescopes in Paranal. There is too much going on on too different
time-scales (uS - sec) that cooperative scheduling only would've made
amess.
This was under a RTOS from Windriver.

I know that you can get far with cooperative scheduling. My manx program
(plays music on mechanical instruments) includes parts that would normaly
be done in driver software. I tested its timing once on a 90 Mhz Linux,
and the notes where played were within a mS of the intended time.
Still that program contains two lists of xt that could be considered
high and low priority tasks, or background tasks and drivers.
Timer interrupts are emulated by a busy wait until the scheduled time.
Using Linux OS timing facilities one can restrict the duration of
those busy waits to about a mS which I consider acceptable.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#39595

I would agree with that. Co-operative multi-tasking systems have
an important advantage. They are atomic by their very nature. 
That means that you don't have to lock resources. 

In a cooperative system I can do:

port@ >float fbuffer f! pause

A somewhat tortured example but you get the point. In a pre-emptive system I cannot guarantee that another task is not trying to read from fbuffer while I'm trying to write to it. I have to put a lock around it. 

port@ >float fbuffer lock f! unlock

Lock just suspends the task switching mechanism. 

*NOT* doing this in pre-emptive systems can lead to some truly evil bugs. I've been there! So cooperative is better in that respect. But of course there are trade-offs.

And yes I agree.  You cut put VFX or SwiftX on an embedded board and as far as I'm concerned that's a RTOS. Just. If that system offers facilities such as memory allocation/de-allocation, garbage collection, communication stacks etc then it's definitely an OS. If it has fast lightweight task switching then it's a RTOS.

[toc] | [prev] | [next] | [standalone]

#39624

Mark Wills <markwills1970@gmail.com> writes:
> port@ >float fbuffer f! pause
> A somewhat tortured example but you get the point. In a pre-emptive
> system I cannot guarantee that another task is not trying to read from
> fbuffer while I'm trying to write to it. I have to put a lock around it.

Preferable is to not allow any other tasks to directly access fbuffer
for either reading or writing, but make it owned by the task that reads
the port.  Other tasks needing the data can only get it through message
passing from the port reading task.  It's pretty easy to program in this
style and it gets rid of most of those hazards.  It incurs some overhead
compared to shared memory, but for most i/o concurrency uses it's not a
problem.

Andrew Haley also has implemented transactional memory in Forth, which
is another approach.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web