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 1 of 2  [1] 2  Next page →

#39206 — 7 lessons for embedded developers from ESC Boston 2015

I just read "7 lessons for embedded developers from ESC Boston 2015", and there it says:

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. 

What about Forth?

The other lessons are:
Lesson #2 - The importance of low power 
Lesson #3 - Securing embedded systems 
Lesson #4 - One language isn't enough 
Lesson #5 - Plethora of protocols 
Lesson #6 - Track optimization efforts 
Lesson #7 - Rapid prototyping 

Six (or more) of these 7 Lessons can be covered by Forth.
Another chance to be taken or to be missed?

Source: 
http://www.edn.com/electronics-blogs/embedded-basics/4439406/7-Lessons-for-embedded-developers-from-ESC-Boston-2015

[toc] | [next] | [standalone]

#39207

On 5/19/15 12:44 PM, visualforth@rocketmail.com wrote:
> I just read "7 lessons for embedded developers from ESC Boston 2015", and there it says:
>
> 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.
>
> What about Forth?
>
> The other lessons are:
> Lesson #2 - The importance of low power
> Lesson #3 - Securing embedded systems
> Lesson #4 - One language isn't enough
> Lesson #5 - Plethora of protocols
> Lesson #6 - Track optimization efforts
> Lesson #7 - Rapid prototyping
>
> Six (or more) of these 7 Lessons can be covered by Forth.
> Another chance to be taken or to be missed?
>
> Source:
> http://www.edn.com/electronics-blogs/embedded-basics/4439406/7-Lessons-for-embedded-developers-from-ESC-Boston-2015
>

Dunno about #4, unless you count a Forth assembler, but SwiftX (and its 
predecessors) all included an extremely small, fast RTOS, as well as the 
other issues.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#39212

On Tuesday, May 19, 2015 at 8:55:21 PM UTC-4, Elizabeth D. Rather wrote:
> On 5/19/15 12:44 PM, visualforth@rocketmail.com wrote:
> > I just read "7 lessons for embedded developers from ESC Boston 2015", and there it says:
> >
> > 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.
> >
> > What about Forth?
> >
> > The other lessons are:
> > Lesson #2 - The importance of low power
> > Lesson #3 - Securing embedded systems
> > Lesson #4 - One language isn't enough
> > Lesson #5 - Plethora of protocols
> > Lesson #6 - Track optimization efforts
> > Lesson #7 - Rapid prototyping
> >
> > Six (or more) of these 7 Lessons can be covered by Forth.
> > Another chance to be taken or to be missed?
> >
> > Source:
> > http://www.edn.com/electronics-blogs/embedded-basics/4439406/7-Lessons-for-embedded-developers-from-ESC-Boston-2015
> >
> 
> Dunno about #4, unless you count a Forth assembler, but SwiftX (and its 
> predecessors) all included an extremely small, fast RTOS, as well as the 
> other issues.
> 
> Cheers,
> Elizabeth
> 
> -- 
> ==================================================
> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> FORTH Inc.                         +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045
> http://www.forth.com
> 
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

There we are! Forth will be the solution!

But who will promote this solution which will be the best of all?

What about some Press-Releases announcing a Forth IoT-RTOS?

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

#39208

On Tuesday, 19 May 2015 23:44:44 UTC+1, visua...@rocketmail.com  wrote:
> I just read "7 lessons for embedded developers from ESC Boston 2015", and there it says:
> 
> 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. 
> 
> What about Forth?
> 
> The other lessons are:
> Lesson #2 - The importance of low power 
> Lesson #3 - Securing embedded systems 
> Lesson #4 - One language isn't enough 
> Lesson #5 - Plethora of protocols 
> Lesson #6 - Track optimization efforts 
> Lesson #7 - Rapid prototyping 
> 
> Six (or more) of these 7 Lessons can be covered by Forth.
> Another chance to be taken or to be missed?
> 
> Source: 
> http://www.edn.com/electronics-blogs/embedded-basics/4439406/7-Lessons-for-embedded-developers-from-ESC-Boston-2015

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.

The others I'm kind of "meh" about. One language isn't enough? Well,
they haven't tried Forth, then, have they? :-)

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

#39209

Am Mittwoch, 20. Mai 2015 09:29:53 UTC+2 schrieb Mark Wills:
> On Tuesday, 19 May 2015 23:44:44 UTC+1, visua...@rocketmail.com  wrote:
> > I just read "7 lessons for embedded developers 

> > Lesson #4 - One language isn't enough 

> The others I'm kind of "meh" about. One language isn't enough? Well,
> they haven't tried Forth, then, have they? :-)

Think about using an internal DSL (domain specific language written in Forth) and/or high level interfacing formats like XML, ASN.1, google protobuf etc. as "languages", then item 4 has some truth even for a pure Forth only system.

Daniel 

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

#39559

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.

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

#39561

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. And I don't know any
language with direct/internal/designed support for an RTOS. Forth is in fact
far behind, exactly like C. There are other languages with some builtin
features, but not rel-time focused but multi-tasking (cooperative). Forth has
classical cooperative multitasking implementations which are not built-in 
in the language in any way though.

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

#39562

On 6/5/2015 2:31 AM, 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. And I don't know any
> language with direct/internal/designed support for an RTOS. Forth is in fact
> far behind, exactly like C. There are other languages with some builtin
> features, but not rel-time focused but multi-tasking (cooperative). Forth has
> classical cooperative multitasking implementations which are not built-in
> in the language in any way though.

I don't know this is strictly true.  I believe there are some forths out 
there that incorporate an RTOS or at least multitasking/multiuser and 
not necessarily cooperative.  I don't recall any names, but I recall 
this being discussed.

But even so, that is beyond the domain of forth, it is an extension that 
seems to fit fairly nicely with it though.

-- 

Rick

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

#39569

On Fri, 05 Jun 2015 03:15:54 -0400, rickman <gnuarm@gmail.com> wrote:

>I don't know this is strictly true.  I believe there are some forths out 
>there that incorporate an RTOS or at least multitasking/multiuser and 
>not necessarily cooperative.  I don't recall any names, but I recall 
>this being discussed.

What stops a cooperative scheduler from being (hard) real time?

Im my experience, two things. Program bugs and assumptions leading
to program bugs. In both cases, a simple cooperative scheduler with
a timeout interrupt is good enough.

Since bare-metal Forths do not have buried code, the distinction
between tools such as the multitasker and the application code
is only one of name, not of availability. Whether these tools
form an RTOS or not is simply a question of whether there is a
consistent and documented API over a range of processors and/or
implementations.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#39583

vineri, 5 iunie 2015, 13:48:15 UTC+3, Stephen Pelc a scris:
> On Fri, 05 Jun 2015 03:15:54 -0400, rickman <gnuarm@gmail.com> wrote:
> 
> >I don't know this is strictly true.  I believe there are some forths out 
> >there that incorporate an RTOS or at least multitasking/multiuser and 
> >not necessarily cooperative.  I don't recall any names, but I recall 
> >this being discussed.
> 
> What stops a cooperative scheduler from being (hard) real time?
> 
It's just crazy even to try to reach hard real time requirements with
a cooperative rtos. Even a 10Hz task (100ms sharp, or ok take it with 
a +100us jitter). Unless your system has almost nothing to do and waits
for the 100ms to schedule the "hard" real time task...

> Im my experience, two things. Program bugs and assumptions leading
> to program bugs. In both cases, a simple cooperative scheduler with
> a timeout interrupt is good enough.
> 
Good enough is another thing. The interrupt can meet the hard real time
requirement. I'm using such systems for almost twenty years. Hard realtime
only with interrupts. Anything else is soft real-time with cooperative
tasks.

> Since bare-metal Forths do not have buried code, the distinction
> between tools such as the multitasker and the application code
> is only one of name, not of availability. Whether these tools
> form an RTOS or not is simply a question of whether there is a
> consistent and documented API over a range of processors and/or
> implementations.
> 
> Stephen
> 
> -- 
> Stephen Pelc, stephenXXX@mpeforth.com
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web: http://www.mpeforth.com - free VFX Forth downloads

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

#39585

On Fri, 5 Jun 2015 07:55:51 -0700 (PDT), Raimond Dragomir
<raimond.dragomir@gmail.com> wrote:

>It's just crazy even to try to reach hard real time requirements with
>a cooperative rtos. Even a 10Hz task (100ms sharp, or ok take it with 
>a +100us jitter). Unless your system has almost nothing to do and waits
>for the 100ms to schedule the "hard" real time task...

You say this without evidence or numbers. Both MPE and Forth Inc.
have had plenty of experience with hard-real-time systems over the
last 30+ years. MPE has never had to use anything other than a 
cooperative scheduler.

In your world, 100us may be tight, but in my world on current
hardware, I would be ashamed if a task switch took even 1us.

Yes, of course we value well-written interrupts. These days, 
even those are written in high-level Forth; the compiler
looks after code generation.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#39587

vineri, 5 iunie 2015, 18:54:32 UTC+3, Stephen Pelc a scris:
> On Fri, 5 Jun 2015 07:55:51 -0700 (PDT), Raimond Dragomir
> <raimond.dragomir@gmail.com> wrote:
> 
> >It's just crazy even to try to reach hard real time requirements with
> >a cooperative rtos. Even a 10Hz task (100ms sharp, or ok take it with 
> >a +100us jitter). Unless your system has almost nothing to do and waits
> >for the 100ms to schedule the "hard" real time task...
> 
> You say this without evidence or numbers. Both MPE and Forth Inc.
> have had plenty of experience with hard-real-time systems over the
> last 30+ years. MPE has never had to use anything other than a 
> cooperative scheduler.

And you provided the evidence or numbers?

> 
> In your world, 100us may be tight, but in my world on current
> hardware, I would be ashamed if a task switch took even 1us.
> 
In my world I have task switching in less than 1us too. Yet, in many
typical applications from my world I cannot create a task that meets
100us jitter even in a 100ms period (probably in any period at all). 
These things are not related. If you have only 10 tasks and all tasks
have execution paths of more than 10us... even instant ideal task switching 
of 0ns cannot save you.

> Yes, of course we value well-written interrupts. These days, 
> even those are written in high-level Forth; the compiler
> looks after code generation.
> 
That's nice indeed.
I'm only dissapointed that you are trying to convince me that you can meet
hard real time requirements with a cooperative multitasking. 
Yes you can meet them in very specific situations, but you can meet them
with superloops too, without any rtos. 


> Stephen
> 
> -- 
> Stephen Pelc, stephenXXX@mpeforth.com
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web: http://www.mpeforth.com - free VFX Forth downloads

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

#39596

On 6/5/15 6:32 AM, Raimond Dragomir wrote:
> vineri, 5 iunie 2015, 18:54:32 UTC+3, Stephen Pelc a scris:
>> On Fri, 5 Jun 2015 07:55:51 -0700 (PDT), Raimond Dragomir
>> <raimond.dragomir@gmail.com> wrote:
>>
>>> It's just crazy even to try to reach hard real time requirements with
>>> a cooperative rtos. Even a 10Hz task (100ms sharp, or ok take it with
>>> a +100us jitter). Unless your system has almost nothing to do and waits
>>> for the 100ms to schedule the "hard" real time task...
>>
>> You say this without evidence or numbers. Both MPE and Forth Inc.
>> have had plenty of experience with hard-real-time systems over the
>> last 30+ years. MPE has never had to use anything other than a
>> cooperative scheduler.
>
> And you provided the evidence or numbers?
>
>>
>> In your world, 100us may be tight, but in my world on current
>> hardware, I would be ashamed if a task switch took even 1us.
>>
> In my world I have task switching in less than 1us too. Yet, in many
> typical applications from my world I cannot create a task that meets
> 100us jitter even in a 100ms period (probably in any period at all).
> These things are not related. If you have only 10 tasks and all tasks
> have execution paths of more than 10us... even instant ideal task switching
> of 0ns cannot save you.

On today's processors and real-time applications, it's relatively rare 
to encounter long execution paths with no I/O (which entails a PAUSE). 
Howevr, it is very easy to profile task latencies, and insert a PAUSE if 
necessary.

>> Yes, of course we value well-written interrupts. These days,
>> even those are written in high-level Forth; the compiler
>> looks after code generation.
>>
> That's nice indeed.
> I'm only dissapointed that you are trying to convince me that you can meet
> hard real time requirements with a cooperative multitasking.
> Yes you can meet them in very specific situations, but you can meet them
> with superloops too, without any rtos.

A RTOS with cooperative multitasking is far simpler to code, test, and 
manage than a complex "superloop".

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#39612

On Friday, June 5, 2015 at 9:32:27 AM UTC-7, Raimond Dragomir wrote:
> vineri, 5 iunie 2015, 18:54:32 UTC+3, Stephen Pelc a scris:
> > On Fri, 5 Jun 2015 07:55:51 -0700 (PDT), Raimond Dragomir
> > <raimond.dragomir@gmail.com> wrote:
> > 
> > >It's just crazy even to try to reach hard real time requirements with
> > >a cooperative rtos. Even a 10Hz task (100ms sharp, or ok take it with 
> > >a +100us jitter). Unless your system has almost nothing to do and waits
> > >for the 100ms to schedule the "hard" real time task...
> > 
> > You say this without evidence or numbers. Both MPE and Forth Inc.
> > have had plenty of experience with hard-real-time systems over the
> > last 30+ years. MPE has never had to use anything other than a 
> > cooperative scheduler.
> 
> And you provided the evidence or numbers?

lol

> > In your world, 100us may be tight, but in my world on current
> > hardware, I would be ashamed if a task switch took even 1us.

Stephen is just trying to get your goat --- implying that "your world" is novice-level and pedestrian, unlike his elite world...

> In my world I have task switching in less than 1us too. Yet, in many
> typical applications from my world I cannot create a task that meets
> 100us jitter even in a 100ms period (probably in any period at all). 
> These things are not related. If you have only 10 tasks and all tasks
> have execution paths of more than 10us... even instant ideal task switching 
> of 0ns cannot save you.

Neither of you are doing this the way that I'm familiar with, so apparently there are many worlds...

At Testra they used dual processors. There was a MiniForth and an 8032 on the board, with the MiniForth doing the hard real-time (the stepper motors) and the 8032 doing the soft real-time (communicating with the desktop-computer via a serial-line and feeding data to the MiniForth). The 8032 had 64MB of RAM (not a typo; that is 64MB not 64KB) so it could hold multiple large files of data.

This seems like a good system to me. I would rather have two small processors (8-bit and 16-bit in this case) rather than one big processor (32-bit). The whole system seems more tractable this way. If one processor is doing everything, you could have a lot of timing clashes and never be sure that the system is working correctly and no data is getting lost --- I don't like the idea of multi-tasking because there are too many parameters to consider, and no matter how much you test the system you may yet miss some weird collision of circumstances that will result in the system over-loading --- but if your customer is running the system every-day all-day then the customer will eventually experience the weirdness, resulting in an angry phone call to you.

With the MiniForth system, the 8032 was necessary anyway because the MiniForth couldn't boot itself up --- it needed the 8032 to get it started --- I came up with the term "pony processor" which is reference to "pony engine" which is a small gas-engine used to start up big diesel-engines.

It would have over-complicated the MiniForth to provide a means to address 64MB of memory. Also, the MiniForth didn't have a UART built-in, and the 8032 did. The Lattice isp1048 PLD was packed solid getting the MiniForth to run on it --- adding extra features such as a gigantic memory or a UART was not realistic --- it was easier to out-source this stuff to a separate processor.
 
> > Yes, of course we value well-written interrupts. These days, 
> > even those are written in high-level Forth; the compiler
> > looks after code generation.
> > 
> That's nice indeed.
> I'm only dissapointed that you are trying to convince me that you can meet
> hard real time requirements with a cooperative multitasking. 
> Yes you can meet them in very specific situations, but you can meet them
> with superloops too, without any rtos. 

I've never heard the term "super-loop" before. I know what a "paced loop" is --- is this the same thing?

A paced loop is tied to a heart-beat timer, usually at 10ms or 20ms. Everything combined must take less time than this. If anything takes too long, it should be broken up into chunks that are done one after the other on subsequent passes through the loop, so no pass through the loop takes more than this allowed amount of time.

A paced-loop is a pretty simple system, but it can be used effectively in soft real-time applications and it is not difficult to implement. I have a book that describes this for 6805 assembly-language --- Motorola used to sell that book 25 years ago to help novices get going with the 6805.

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

#39614

duminică, 7 iunie 2015, 02:28:12 UTC+3, hughag...@gmail.com a scris:
> On Friday, June 5, 2015 at 9:32:27 AM UTC-7, Raimond Dragomir wrote:
> > vineri, 5 iunie 2015, 18:54:32 UTC+3, Stephen Pelc a scris:
> > > On Fri, 5 Jun 2015 07:55:51 -0700 (PDT), Raimond Dragomir
> > > <raimond.dragomir@gmail.com> wrote:
> > > 
> > > >It's just crazy even to try to reach hard real time requirements with
> > > >a cooperative rtos. Even a 10Hz task (100ms sharp, or ok take it with 
> > > >a +100us jitter). Unless your system has almost nothing to do and waits
> > > >for the 100ms to schedule the "hard" real time task...
> > > 
> > > You say this without evidence or numbers. Both MPE and Forth Inc.
> > > have had plenty of experience with hard-real-time systems over the
> > > last 30+ years. MPE has never had to use anything other than a 
> > > cooperative scheduler.
> > 
> > And you provided the evidence or numbers?
> 
> lol
> 
> > > In your world, 100us may be tight, but in my world on current
> > > hardware, I would be ashamed if a task switch took even 1us.
> 
> Stephen is just trying to get your goat --- implying that "your world" is novice-level and pedestrian, unlike his elite world...
> 
> > In my world I have task switching in less than 1us too. Yet, in many
> > typical applications from my world I cannot create a task that meets
> > 100us jitter even in a 100ms period (probably in any period at all). 
> > These things are not related. If you have only 10 tasks and all tasks
> > have execution paths of more than 10us... even instant ideal task switching 
> > of 0ns cannot save you.
> 
> Neither of you are doing this the way that I'm familiar with, so apparently there are many worlds...
> 
> At Testra they used dual processors. There was a MiniForth and an 8032 on the board, with the MiniForth doing the hard real-time (the stepper motors) and the 8032 doing the soft real-time (communicating with the desktop-computer via a serial-line and feeding data to the MiniForth). The 8032 had 64MB of RAM (not a typo; that is 64MB not 64KB) so it could hold multiple large files of data.
> 
> This seems like a good system to me. I would rather have two small processors (8-bit and 16-bit in this case) rather than one big processor (32-bit). The whole system seems more tractable this way. If one processor is doing everything, you could have a lot of timing clashes and never be sure that the system is working correctly and no data is getting lost --- I don't like the idea of multi-tasking because there are too many parameters to consider, and no matter how much you test the system you may yet miss some weird collision of circumstances that will result in the system over-loading --- but if your customer is running the system every-day all-day then the customer will eventually experience the weirdness, resulting in an angry phone call to you.
> 
> With the MiniForth system, the 8032 was necessary anyway because the MiniForth couldn't boot itself up --- it needed the 8032 to get it started --- I came up with the term "pony processor" which is reference to "pony engine" which is a small gas-engine used to start up big diesel-engines.
> 
> It would have over-complicated the MiniForth to provide a means to address 64MB of memory. Also, the MiniForth didn't have a UART built-in, and the 8032 did. The Lattice isp1048 PLD was packed solid getting the MiniForth to run on it --- adding extra features such as a gigantic memory or a UART was not realistic --- it was easier to out-source this stuff to a separate processor.
>  
> > > Yes, of course we value well-written interrupts. These days, 
> > > even those are written in high-level Forth; the compiler
> > > looks after code generation.
> > > 
> > That's nice indeed.
> > I'm only dissapointed that you are trying to convince me that you can meet
> > hard real time requirements with a cooperative multitasking. 
> > Yes you can meet them in very specific situations, but you can meet them
> > with superloops too, without any rtos. 
> 
> I've never heard the term "super-loop" before. I know what a "paced loop" is --- is this the same thing?
> 
> A paced loop is tied to a heart-beat timer, usually at 10ms or 20ms. Everything combined must take less time than this. If anything takes too long, it should be broken up into chunks that are done one after the other on subsequent passes through the loop, so no pass through the loop takes more than this allowed amount of time.
> 
> A paced-loop is a pretty simple system, but it can be used effectively in soft real-time applications and it is not difficult to implement. I have a book that describes this for 6805 assembly-language --- Motorola used to sell that book 25 years ago to help novices get going with the 6805.

A superloop is a simple loop in fact, it's "super" because it is (may be)
very ... big. It's not timed, you call every task in this loop as fast as
you can, just one after the other. Al timings are done with a global
counter variable incremented in an interrupt and the tasks are responsible
to calculate their timing from that counter.

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

#39664

On Sunday, June 7, 2015 at 12:00:13 AM UTC-4, Raimond Dragomir wrote:
> duminică, 7 iunie 2015, 02:28:12 UTC+3, hughag...@gmail.com a scris:
> > On Friday, June 5, 2015 at 9:32:27 AM UTC-7, Raimond Dragomir wrote:
> > > vineri, 5 iunie 2015, 18:54:32 UTC+3, Stephen Pelc a scris:
> > > > On Fri, 5 Jun 2015 07:55:51 -0700 (PDT), Raimond Dragomir
> > > > wrote:
> > > > 
> > > > >It's just crazy even to try to reach hard real time requirements with
> > > > >a cooperative rtos. Even a 10Hz task (100ms sharp, or ok take it with 
> > > > >a +100us jitter). Unless your system has almost nothing to do and waits
> > > > >for the 100ms to schedule the "hard" real time task...
> > > > 
> > > > You say this without evidence or numbers. Both MPE and Forth Inc.
> > > > have had plenty of experience with hard-real-time systems over the
> > > > last 30+ years. MPE has never had to use anything other than a 
> > > > cooperative scheduler.
> > > 
> > > And you provided the evidence or numbers?
> > 
> > lol
> > 
> > > > In your world, 100us may be tight, but in my world on current
> > > > hardware, I would be ashamed if a task switch took even 1us.
> > 
> > Stephen is just trying to get your goat --- implying that "your world" is novice-level and pedestrian, unlike his elite world...
> > 
> > > In my world I have task switching in less than 1us too. Yet, in many
> > > typical applications from my world I cannot create a task that meets
> > > 100us jitter even in a 100ms period (probably in any period at all). 
> > > These things are not related. If you have only 10 tasks and all tasks
> > > have execution paths of more than 10us... even instant ideal task switching 
> > > of 0ns cannot save you.
> > 
> > Neither of you are doing this the way that I'm familiar with, so apparently there are many worlds...
> > 
> > At Testra they used dual processors. There was a MiniForth and an 8032 on the board, with the MiniForth doing the hard real-time (the stepper motors) and the 8032 doing the soft real-time (communicating with the desktop-computer via a serial-line and feeding data to the MiniForth). The 8032 had 64MB of RAM (not a typo; that is 64MB not 64KB) so it could hold multiple large files of data.
> > 
> > This seems like a good system to me. I would rather have two small processors (8-bit and 16-bit in this case) rather than one big processor (32-bit). The whole system seems more tractable this way. If one processor is doing everything, you could have a lot of timing clashes and never be sure that the system is working correctly and no data is getting lost --- I don't like the idea of multi-tasking because there are too many parameters to consider, and no matter how much you test the system you may yet miss some weird collision of circumstances that will result in the system over-loading --- but if your customer is running the system every-day all-day then the customer will eventually experience the weirdness, resulting in an angry phone call to you.
> > 
> > With the MiniForth system, the 8032 was necessary anyway because the MiniForth couldn't boot itself up --- it needed the 8032 to get it started --- I came up with the term "pony processor" which is reference to "pony engine" which is a small gas-engine used to start up big diesel-engines.
> > 
> > It would have over-complicated the MiniForth to provide a means to address 64MB of memory. Also, the MiniForth didn't have a UART built-in, and the 8032 did. The Lattice isp1048 PLD was packed solid getting the MiniForth to run on it --- adding extra features such as a gigantic memory or a UART was not realistic --- it was easier to out-source this stuff to a separate processor.
> >  
> > > > Yes, of course we value well-written interrupts. These days, 
> > > > even those are written in high-level Forth; the compiler
> > > > looks after code generation.
> > > > 
> > > That's nice indeed.
> > > I'm only dissapointed that you are trying to convince me that you can meet
> > > hard real time requirements with a cooperative multitasking. 
> > > Yes you can meet them in very specific situations, but you can meet them
> > > with superloops too, without any rtos. 
> > 
> > I've never heard the term "super-loop" before. I know what a "paced loop" is --- is this the same thing?
> > 
> > A paced loop is tied to a heart-beat timer, usually at 10ms or 20ms. Everything combined must take less time than this. If anything takes too long, it should be broken up into chunks that are done one after the other on subsequent passes through the loop, so no pass through the loop takes more than this allowed amount of time.
> > 
> > A paced-loop is a pretty simple system, but it can be used effectively in soft real-time applications and it is not difficult to implement. I have a book that describes this for 6805 assembly-language --- Motorola used to sell that book 25 years ago to help novices get going with the 6805.
> 
> A superloop is a simple loop in fact, it's "super" because it is (may be)
> very ... big. It's not timed, you call every task in this loop as fast as
> you can, just one after the other. Al timings are done with a global
> counter variable incremented in an interrupt and the tasks are responsible
> to calculate their timing from that counter.

Isn't that called "Round Robin"?

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

#39666

> Isn't that called "Round Robin"?

You may call it whatever you like. I suspect that the OS vendors needed to
call this kind of system somehow and came with different names. I know about
'superloop'. In fact it's a kind of programs that don't have any os at all.
These programs must have a main forever loop in which all things are to be
done. Arduino even have this named: loop() :-)

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

#39625

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> In my world I have task switching in less than 1us too. Yet, in many
> typical applications from my world I cannot create a task that meets
> 100us jitter even in a 100ms period (probably in any period at all). 
> These things are not related. If you have only 10 tasks and all tasks
> have execution paths of more than 10us... even instant ideal task
> switching of 0ns cannot save you.

If there's only one task with a realtime deadline, the task scheduler
can know about it.  So if you can make sure the other tasks never run
more than 1ms without a pause, then the scheduler can check at every
pause whether there's more than 1ms remaining before the deadline.  If
yes, it runs the next task as usual.  If not, it runs the realtime task,
which waits til the deadline and then does its thing.

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

#39594

On 6/5/15 4:55 AM, Raimond Dragomir wrote:
> vineri, 5 iunie 2015, 13:48:15 UTC+3, Stephen Pelc a scris:
>> On Fri, 05 Jun 2015 03:15:54 -0400, rickman <gnuarm@gmail.com> wrote:
>>
>>> I don't know this is strictly true.  I believe there are some forths out
>>> there that incorporate an RTOS or at least multitasking/multiuser and
>>> not necessarily cooperative.  I don't recall any names, but I recall
>>> this being discussed.
>>
>> What stops a cooperative scheduler from being (hard) real time?
>>
> It's just crazy even to try to reach hard real time requirements with
> a cooperative rtos. Even a 10Hz task (100ms sharp, or ok take it with
> a +100us jitter). Unless your system has almost nothing to do and waits
> for the 100ms to schedule the "hard" real time task...

Certainly you need interrupts to do hard real-time. But there's no 
inconsistency between having a simple cooperative scheduler and 
interrupts not only from a clock but also the devices you're controlling.

>> Im my experience, two things. Program bugs and assumptions leading
>> to program bugs. In both cases, a simple cooperative scheduler with
>> a timeout interrupt is good enough.
>>
> Good enough is another thing. The interrupt can meet the hard real time
> requirement. I'm using such systems for almost twenty years. Hard realtime
> only with interrupts. Anything else is soft real-time with cooperative
> tasks.

The rule in FORTH, Inc. multitaskers is that a task that initiates I/O 
then sleeps until the I/O is complete. Whether completion is signaled by 
an interrupt or polling (1 or 2 instructions per poll, and the task is 
back to sleep again, so not very intrusive), that means in practice most 
tasks are asleep most of the time. In the rare case where there is some 
very intensive CPU-intensive activity (e.g. a big sort of stuff all in 
memory) it's very easy to insert a PAUSE in convenient spots in the process.

>> Since bare-metal Forths do not have buried code, the distinction
>> between tools such as the multitasker and the application code
>> is only one of name, not of availability. Whether these tools
>> form an RTOS or not is simply a question of whether there is a
>> consistent and documented API over a range of processors and/or
>> implementations.
>>
>> Stephen

Agreed.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#39593

On 6/4/15 9:15 PM, rickman wrote:
> On 6/5/2015 2:31 AM, 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. And I don't know any
>> language with direct/internal/designed support for an RTOS. Forth is
>> in fact
>> far behind, exactly like C. There are other languages with some builtin
>> features, but not rel-time focused but multi-tasking (cooperative).
>> Forth has classical cooperative multitasking implementations which are
>> not built-in in the language in any way though.
>
> I don't know this is strictly true.  I believe there are some forths out
> there that incorporate an RTOS or at least multitasking/multiuser and
> not necessarily cooperative.  I don't recall any names, but I recall
> this being discussed.
>
> But even so, that is beyond the domain of forth, it is an extension that
> seems to fit fairly nicely with it though.

Forth as a language is certainly not an RTOS, but it is certainly true 
that some implementations (including not only SwiftX mentioned above but 
all systems produced by FORTH, Inc. since 1973) have included a 
multitasker and RTOS, and have been used in native mode (no host OS) in 
many high-performance real-time applications.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web