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

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

Is Forth About Tinkering Rather than Design?

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

Contents

  Is Forth About Tinkering Rather than Design? rickman <gnuarm@gmail.com> - 2015-06-02 04:05 -0400
    Is Forth About Tinkering Rather than Design? Mark Wills <markwills1970@gmail.com> - 2015-06-02 09:52 -0700
    Is Forth About Tinkering Rather than Design? Mark Wills <markwills1970@gmail.com> - 2015-06-02 09:55 -0700
      Re: Is Forth About Tinkering Rather than Design? JUERGEN <epldfpga@aol.com> - 2015-06-02 10:09 -0700
    Re: Is Forth About Tinkering Rather than Design? JUERGEN <epldfpga@aol.com> - 2015-06-02 10:01 -0700
    Re: Is Forth About Tinkering Rather than Design? "Elizabeth D. Rather" <erather@forth.com> - 2015-06-02 07:36 -1000
      Re: Is Forth About Tinkering Rather than Design? djc <ciesinger@gmx.net> - 2015-06-05 02:50 -0700
        Re: Is Forth About Tinkering Rather than Design? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-05 11:32 +0000
          Re: Is Forth About Tinkering Rather than Design? djc <ciesinger@gmx.net> - 2015-06-05 05:01 -0700
            Re: Is Forth About Tinkering Rather than Design? rickman <gnuarm@gmail.com> - 2015-06-05 17:04 -0400
          Re: Is Forth About Tinkering Rather than Design? Paul Rubin <no.email@nospam.invalid> - 2015-06-07 23:12 -0700
            Re: Is Forth About Tinkering Rather than Design? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-08 09:48 +0000
        Re: Is Forth About Tinkering Rather than Design? Paul Rubin <no.email@nospam.invalid> - 2015-06-07 20:59 -0700
          Re: Is Forth About Tinkering Rather than Design? djc <ciesinger@gmx.net> - 2015-06-10 05:59 -0700
            Re: Is Forth About Tinkering Rather than Design? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-10 09:05 -0700
              Re: Is Forth About Tinkering Rather than Design? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-10 09:28 -0700
                Re: Is Forth About Tinkering Rather than Design? Paul Rubin <no.email@nospam.invalid> - 2015-06-10 10:51 -0700
                  Re: Is Forth About Tinkering Rather than Design? rickman <gnuarm@gmail.com> - 2015-06-10 14:17 -0400
                    Re: Is Forth About Tinkering Rather than Design? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-10 20:20 +0200
                      Re: Is Forth About Tinkering Rather than Design? rickman <gnuarm@gmail.com> - 2015-06-10 15:03 -0400
                        Re: Is Forth About Tinkering Rather than Design? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-10 22:06 +0200
                          Re: Is Forth About Tinkering Rather than Design? rickman <gnuarm@gmail.com> - 2015-06-10 19:13 -0400
                            Re: Is Forth About Tinkering Rather than Design? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-11 02:59 +0200
                    Re: Is Forth About Tinkering Rather than Design? Paul Rubin <no.email@nospam.invalid> - 2015-06-10 21:41 -0700
                      Re: Is Forth About Tinkering Rather than Design? djc <ciesinger@gmx.net> - 2015-06-11 00:40 -0700
                        Re: Is Forth About Tinkering Rather than Design? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-11 01:24 -0700
                          Re: Is Forth About Tinkering Rather than Design? rickman <gnuarm@gmail.com> - 2015-06-11 05:33 -0400
              Re: Is Forth About Tinkering Rather than Design? Paul Rubin <no.email@nospam.invalid> - 2015-06-10 10:37 -0700
                Re: Is Forth About Tinkering Rather than Design? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-11 00:17 -0700
              Re: Is Forth About Tinkering Rather than Design? stephen@mpeforth.com (Stephen Pelc) - 2015-06-10 18:13 +0000
    Re: Is Forth About Tinkering Rather than Design? Walter Banks <walter@bytecraft.com> - 2015-06-02 14:21 -0400
    Re: Is Forth About Tinkering Rather than Design? Walter Banks <walter@bytecraft.com> - 2015-06-02 14:27 -0400
    Re: Is Forth About Tinkering Rather than Design? Bob <bob@none.com> - 2015-06-02 16:04 -0400
    Re: Is Forth About Tinkering Rather than Design? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-03 05:17 +0000
    Re: Is Forth About Tinkering Rather than Design? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-03 03:07 -0400

Page 1 of 2  [1] 2  Next page →

#39514 — Is Forth About Tinkering Rather than Design?

I was thinking about a timing issue and recalled that Chuck Moore had to 
write code to test his idea that he could use timing loops in the GA144 
to control a video display.  The timing loops didn't work and he had to 
add a crystal oscillator.  I think instead he ended up using a ceramic 
resonator because he couldn't get the crystal to start up reliably. 
Neither of these results were unforeseeable.

I also remember taking my swing at the GA144 and through analysis 
realized the bottleneck in the design would be the memory performance. 
So I tried to analyze a sync DRAM interface only to be limited by the 
timing data provided for the GA144.  When I asked for more detailed 
timing info on the instructions for comms and I/O I was told I didn't 
need that info, I should just build the design code it up and see if it 
works.  When I said that was not the way I work, rather I do analysis 
before I design I was told that was how that person had been doing Forth 
design for 40 years, by building and testing.

To me, when I should be able to do analysis to determine limitations and 
feasibility, it just seems silly to spend time on building and testing 
only to find things don't work.  I know I would never try to use timing 
loops to generate video signals.  I think a simple analysis would show 
the lack of stability.  Timing data is just so basic to the definition 
of a digital device that I can't see any reason to not want to use it to 
save days or weeks of development and testing that might well prove 
fruitless.

Is it typical in the Forth community to code things up rather than to 
think them through?

-- 

Rick

[toc] | [next] | [standalone]

#39518

Both yes and no. I'll often code something up "quick and dirty" and then day to myself "yep that works" then junk it and re-write a proper application from scratch. The first attempt is nothing more than shaking the nuts loose nuts and bolts rattling around in my head into some semblance of order. 

I don't think it's unique to Forth. It's how most softies work. They will look at the real crux of the problem,  the real make-or-break stuff,  convince themselves that they can solve it (with some rough code, perhaps) then set about writing a proper solution. 

You're a hardware guy. I know a few hardware guys. They'll sit with datasheetsfor a few days before breaking out the soldering iron. They'll make some circuits to shake actual facts and figures out of assumptions (how fast is this bus *really*?, what is the *actual* latency when an interrupt comes in?) then they'll throw those b boards away and get down to it. I think it's the same thing, only different ;-)

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

#39519

Another point: is very simple and satisfying to incrementally"grow" forth programs. This might seem like tinkering and I suppose I kind of is. But add long and when you have completed the application you have a sense that the way it had evolved and connects to each other is correct then that's okay. You wouldn't write an autopilot program that way,  but for say,  a software based video controller then why not?

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

#39523

On Tuesday, June 2, 2015 at 5:55:20 PM UTC+1, Mark Wills wrote:
> Another point: is very simple and satisfying to incrementally"grow" forth programs. This might seem like tinkering and I suppose I kind of is. But add long and when you have completed the application you have a sense that the way it had evolved and connects to each other is correct then that's okay. You wouldn't write an autopilot program that way,  but for say,  a software based video controller then why not?

Hi Mark, for once I would kindly disagree. The Forth language allows for incremental and interactive programming so people use it that way. Is there a definition like High End Tinkering? Or Planned Trial and Error? And as you say, there is no real difference between  hardware and software - except for the soldering iron ...

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

#39521

On Tuesday, June 2, 2015 at 9:05:02 AM UTC+1, rickman wrote:
> I was thinking about a timing issue and recalled that Chuck Moore had to 
> write code to test his idea that he could use timing loops in the GA144 
> to control a video display.  The timing loops didn't work and he had to 
> add a crystal oscillator.  I think instead he ended up using a ceramic 
> resonator because he couldn't get the crystal to start up reliably. 
> Neither of these results were unforeseeable.
> 
> I also remember taking my swing at the GA144 and through analysis 
> realized the bottleneck in the design would be the memory performance. 
> So I tried to analyze a sync DRAM interface only to be limited by the 
> timing data provided for the GA144.  When I asked for more detailed 
> timing info on the instructions for comms and I/O I was told I didn't 
> need that info, I should just build the design code it up and see if it 
> works.  When I said that was not the way I work, rather I do analysis 
> before I design I was told that was how that person had been doing Forth 
> design for 40 years, by building and testing.
> 
> To me, when I should be able to do analysis to determine limitations and 
> feasibility, it just seems silly to spend time on building and testing 
> only to find things don't work.  I know I would never try to use timing 
> loops to generate video signals.  I think a simple analysis would show 
> the lack of stability.  Timing data is just so basic to the definition 
> of a digital device that I can't see any reason to not want to use it to 
> save days or weeks of development and testing that might well prove 
> fruitless.
> 
> Is it typical in the Forth community to code things up rather than to 
> think them through?
> 
> -- 
> 
> Rick

Is this a serious post? I cannot believe it.
You can tinker with a supercomputer if you have access.
If it runs Forth or any other language even program in binary you decide if you tinker or do serious work and have to earn money.
Apart from this, tools are to do a job - serious or tinker.
Actually, to answer your questions: any community will have the spread of participants - and some aspects you plan, some you try out as this might be quicker or borderline.

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

#39525

On 6/1/15 10:05 PM, rickman wrote:
> I was thinking about a timing issue and recalled that Chuck Moore had to
> write code to test his idea that he could use timing loops in the GA144
> to control a video display.  The timing loops didn't work and he had to
> add a crystal oscillator.  I think instead he ended up using a ceramic
> resonator because he couldn't get the crystal to start up reliably.
> Neither of these results were unforeseeable.
>
> I also remember taking my swing at the GA144 and through analysis
> realized the bottleneck in the design would be the memory performance.
> So I tried to analyze a sync DRAM interface only to be limited by the
> timing data provided for the GA144.  When I asked for more detailed
> timing info on the instructions for comms and I/O I was told I didn't
> need that info, I should just build the design code it up and see if it
> works.  When I said that was not the way I work, rather I do analysis
> before I design I was told that was how that person had been doing Forth
> design for 40 years, by building and testing.
>
> To me, when I should be able to do analysis to determine limitations and
> feasibility, it just seems silly to spend time on building and testing
> only to find things don't work.  I know I would never try to use timing
> loops to generate video signals.  I think a simple analysis would show
> the lack of stability.  Timing data is just so basic to the definition
> of a digital device that I can't see any reason to not want to use it to
> save days or weeks of development and testing that might well prove
> fruitless.
>
> Is it typical in the Forth community to code things up rather than to
> think them through?
>

There are ways and ways of "thinking things through." Artists think with 
a brush or pencil in hand. Writers often just start writing to let their 
thoughts emerge, and then try to shape the result into something.

In the 70's and 80's it was fashionable to design software programs 
using huge modeling and design tools before writing any code, because it 
took so long to compile programs and they were difficult to change. A 
couple of times FORTH, Inc. was given extensively flow-charted programs 
to code, and every time we were able to come up with radically different 
designs that worked much faster and better.

Forth's interactivity and flexibility make it a great design tool. Many 
people who are constrained to use a "more mainstream" language in 
projects write a first version in Forth, as a proof of concept, because 
it's such a good design tool.

If you're basically a hardware guy, it's natural for you to "think 
things through" with circuit diagrams or a breadboard, but for a person 
like Chuck who "thinks in Forth," it's what works for him.

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]

#39567

Am Dienstag, 2. Juni 2015 19:36:22 UTC+2 schrieb Elizabeth D. Rather:
> On 6/1/15 10:05 PM, rickman wrote:
[snip]
> > Is it typical in the Forth community to code things up rather than to
> > think them through?

1) The community is not uniform in that aspect
2) There is no contradiction between coding and thinking things through

> There are ways and ways of "thinking things through." Artists think with 
> a brush or pencil in hand. Writers often just start writing to let their 
> thoughts emerge, and then try to shape the result into something.

Having artists in my family, I have to compliment you on finding the right words to describe parts of the creative process. Thank you very much!

> In the 70's and 80's it was fashionable to design software programs 
> using huge modeling and design tools before writing any code,

It still is. Look at V-cycle, CMM, SPICE - all these require the model/architecture to exist before coding starts.

> because it 
> took so long to compile programs

Turnaround cycles for embedded systems written in C may still be in the 30-45 minutes range from saving the code, compiling, linking, flashing to starting the debug process.

In addition, there are large and distributed teams working on the code, so there must be something that allows to identify and distribute work packages for the individual team members.

> Forth's interactivity and flexibility make it a great design tool.

Absolute and fully agreed, especially for todays embedded systems with the above turnaround cycles - which are commonplace in some industries.

> Many 
> people who are constrained to use a "more mainstream" language in 
> projects write a first version in Forth, as a proof of concept, because 
> it's such a good design tool.

I did that several times.

There is a SW development methodology called "TDD" (test driven development) where writing SW tests (unit tests, integration tests...) starts well before SW development.
In C, this approach is almost impossible to impose on a team, in Forth coding and testing goes hand in hand naturally.

Daniel

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

#39571

In article <564c1313-344a-486c-a35b-55f09bc3b886@googlegroups.com>,
djc  <ciesinger@gmx.net> wrote:
<snip>
>There is a SW development methodology called "TDD" (test driven
>development) where writing SW tests (unit tests, integration tests...)
>starts well before SW development.

There is something very fishy about this. Software development doesn't
start with tests, it start with breaking a problem in parts and
specify the interaction between parts. On those specifications
you can base tests.

Bottom line I think that test driven development is crucial for
those who can't make specifications, so instead they use tests
sets as specifications. It works, but it may confuse the issue.

What I do is specify (design), implement and test at about the same time.

This works for smallish problems where you can afford to start over.
In large projects a very knowledgable person, an architect ( an real
one, not a job title) needs to split the problem such that the parts
are implementable. If that fails, so does the project.

Note that this requires multidisciplinary skills.



>
>Daniel
-- 
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]

#39574

Am Freitag, 5. Juni 2015 13:32:16 UTC+2 schrieb Albert van der Horst:
> djc   wrote:
> <snip>
> >There is a SW development methodology called "TDD" (test driven
> >development) where writing SW tests (unit tests, integration tests...)
> >starts well before SW development.
> 
> There is something very fishy about this. Software development doesn't
> start with tests

I did not claim that it starts with testing, I claimed that tests are created before coding the SW starts. Wikipedia has an article on TDD.

Requirements (as per requirements engineering) are sentences like
"x shall y"
and they are testable by definition (CMM, SPICE).
The primary source of requirements is the customer in the cases I know.

> What I do is specify (design), implement and test at about the same time.

When I create SW in Forth and/or in a small expert team, I often do this, too.

Daniel

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

#39600

On 6/5/2015 8:01 AM, djc wrote:
> Am Freitag, 5. Juni 2015 13:32:16 UTC+2 schrieb Albert van der Horst:
>> djc   wrote:
>> <snip>
>>> There is a SW development methodology called "TDD" (test driven
>>> development) where writing SW tests (unit tests, integration tests...)
>>> starts well before SW development.
>>
>> There is something very fishy about this. Software development doesn't
>> start with tests
>
> I did not claim that it starts with testing, I claimed that tests are created before coding the SW starts. Wikipedia has an article on TDD.
>
> Requirements (as per requirements engineering) are sentences like
> "x shall y"
> and they are testable by definition (CMM, SPICE).
> The primary source of requirements is the customer in the cases I know.

I had the training for this and it applies to more than software.  The 
idea is that you define the requirements starting with the user 
requirements and breaking those requirements into lower level 
requirements which is essentially the design process.  Once you reach 
the bottom where the implementation of requirements is clear, you start 
defining the tests which will be applied to verify each of the 
requirements at all levels and only then you code to meet those tests. 
By this point the design issues have been hashed pretty thoroughly.

I haven't done a lot of design work under this regimen, so I can't say 
if it is very effective or not.  The company I worked for was learning 
this as a group so it was initially implemented very ineffectively.  But 
then most things that company did were ineffective with lots of 
infighting and little cooperation.  It may have gotten better with time, 
I don't know, I wasn't there for subsequent designs.


>> What I do is specify (design), implement and test at about the same time.
>
> When I create SW in Forth and/or in a small expert team, I often do this, too.

Yeah, for small groups the process can be very informal, or maybe no 
process at all, just people talking.  But for larger groups it is 
important to have a defined methodology unless everyone is an expert and 
just knows how the project will proceed.  I've never seen that happen...

-- 

Rick

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

#39630

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> Bottom line I think that test driven development is crucial for
> those who can't make specifications, so instead they use tests
> sets as specifications. It works, but it may confuse the issue.

The point of TDD is that you can run all the tests every time you change
the program, to make sure (or anyway have higher confidence) that you
didn't inadvertently break something with your change.  There are many
automated test frameworks and deployment tools (search terms:
"continuous integration") built around this idea.  To do the same thing
with a specification would require manually checking the whole program
against the spec after every change.

TDD also helps guide the organization of the code, since you have to
write every part to work under both the real application and under the
test system.  That helps keep the interfaces clean.  Normally a
functional specification wouldn't reach down to such a fine grained
level.

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

#39634

In article <873822vidc.fsf@jester.gateway.sonic.net>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> Bottom line I think that test driven development is crucial for
>> those who can't make specifications, so instead they use tests
>> sets as specifications. It works, but it may confuse the issue.
>
>The point of TDD is that you can run all the tests every time you change
>the program, to make sure (or anyway have higher confidence) that you
>didn't inadvertently break something with your change.  There are many
>automated test frameworks and deployment tools (search terms:
>"continuous integration") built around this idea.  To do the same thing
>with a specification would require manually checking the whole program
>against the spec after every change.
>
>TDD also helps guide the organization of the code, since you have to
>write every part to work under both the real application and under the
>test system.  That helps keep the interfaces clean.  Normally a
>functional specification wouldn't reach down to such a fine grained
>level.

That sounds good. I've worked under such a regime once but it mainly
applied there to driver software.

The closest thing to that description is my own Forth. The source
has a combination of code, test and documentation like so.

worddoc( {STACKS},{CLS},{c_l_s},{ i*x -- },{},
{Clear the data stack},
{{DSP@@}},
{{  1 2 3 CLS DEPTH .},{0} },
enddoc)
_HEADER({CLS},{CLS},{DOCOL})
        DC      SZERO, FETCH
        DC      SPSTO
        DC      SEMIS
_C

In maintenance-development you need a comprehensive
regression test. There typically is none, so I make up my own.
It mostly boiled down to:
"If it can handles one day worth of data, and the result is the
same" then pass. You can't be sure that a 2Gbyte data file
hits all datapaths, but in a sloppy environment it hits probably
more datapaths than have ever been tested by anyone else.
And Bayes says that the chance you've introduced an error is pretty
slim.

You're right that if "test driven development" is used as a
methodology and not a buzz word it is powerful.

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]

#39628

djc <ciesinger@gmx.net> writes:
> Turnaround cycles for embedded systems written in C may still be in
> the 30-45 minutes range from saving the code, compiling, linking,
> flashing to starting the debug process.

Is that for real?  On current systems where people also use Forth, not
some relic from the era where the debug cycle involved waiting for a UV
eprom eraser?  Even on such systems, it was often possible to do most of
the development and testing on a larger machine, then port to the
embedded target.  

These days I don't think it takes more than a few seconds to compile a
reasonable size C program and flash it into an Arduino.

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

#39680

Am Montag, 8. Juni 2015 05:59:39 UTC+2 schrieb Paul Rubin:
> djc writes:
> > Turnaround cycles for embedded systems written in C may still be in
> > the 30-45 minutes range from saving the code, compiling, linking,
> > flashing to starting the debug process.
> 
> Is that for real?  On current systems where people also use Forth, not
> some relic from the era where the debug cycle involved waiting for a UV
> eprom eraser?  

Using a current C environment for complex embedded systems.
* C preprocessor
* C compiler
* C linker
* (erase code/data flash) - optional, calibration is lost here
* flash to target via JTAG (not UV)
- not including calibration of the SW in the target
We talk about several 100k of object code and Megabytes of source code.
I do not say that this is desirable.
  
> These days I don't think it takes more than a few seconds to compile a
> reasonable size C program and flash it into an Arduino.

"Reasonable" is very dependent on the perspective and the targets. For the Arduino, it may be a matter of seconds, but think about MSP56xx and friends and their areas of application...

Daniel

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

#39681

miercuri, 10 iunie 2015, 15:59:35 UTC+3, djc a scris:
> Am Montag, 8. Juni 2015 05:59:39 UTC+2 schrieb Paul Rubin:
> > djc writes:
> > > Turnaround cycles for embedded systems written in C may still be in
> > > the 30-45 minutes range from saving the code, compiling, linking,
> > > flashing to starting the debug process.
> > 
> > Is that for real?  On current systems where people also use Forth, not
> > some relic from the era where the debug cycle involved waiting for a UV
> > eprom eraser?  
> 
> Using a current C environment for complex embedded systems.
> * C preprocessor
> * C compiler
> * C linker
> * (erase code/data flash) - optional, calibration is lost here
> * flash to target via JTAG (not UV)
> - not including calibration of the SW in the target
> We talk about several 100k of object code and Megabytes of source code.
> I do not say that this is desirable.
>   
> > These days I don't think it takes more than a few seconds to compile a
> > reasonable size C program and flash it into an Arduino.
> 
> "Reasonable" is very dependent on the perspective and the targets. For the Arduino, it may be a matter of seconds, but think about MSP56xx and friends and their areas of application...
> 
> Daniel

A Cortex-M4 project, C only:
Compilation: 7 seconds
Flash downloading: 11 seconds (via a serial bootloader at 460800 bps)
binary: 230K (sources 2.9M)

I have a note here: the project is prepared for emBlocks (a codeblocks variant)
which is able to compile all files in about 7 seconds.
The same project Makefile'd compile in more than 20 seconds.
Make is slow, but I don't know why.
The compiler is an 4.7 arm gcc eabi variant

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

#39682

miercuri, 10 iunie 2015, 19:05:54 UTC+3, Raimond Dragomir a scris:
> miercuri, 10 iunie 2015, 15:59:35 UTC+3, djc a scris:
> > Am Montag, 8. Juni 2015 05:59:39 UTC+2 schrieb Paul Rubin:
> > > djc writes:
> > > > Turnaround cycles for embedded systems written in C may still be in
> > > > the 30-45 minutes range from saving the code, compiling, linking,
> > > > flashing to starting the debug process.
> > > 
> > > Is that for real?  On current systems where people also use Forth, not
> > > some relic from the era where the debug cycle involved waiting for a UV
> > > eprom eraser?  
> > 
> > Using a current C environment for complex embedded systems.
> > * C preprocessor
> > * C compiler
> > * C linker
> > * (erase code/data flash) - optional, calibration is lost here
> > * flash to target via JTAG (not UV)
> > - not including calibration of the SW in the target
> > We talk about several 100k of object code and Megabytes of source code.
> > I do not say that this is desirable.
> >   
> > > These days I don't think it takes more than a few seconds to compile a
> > > reasonable size C program and flash it into an Arduino.
> > 
> > "Reasonable" is very dependent on the perspective and the targets. For the Arduino, it may be a matter of seconds, but think about MSP56xx and friends and their areas of application...
> > 
> > Daniel
> 
> A Cortex-M4 project, C only:
> Compilation: 7 seconds
> Flash downloading: 11 seconds (via a serial bootloader at 460800 bps)
> binary: 230K (sources 2.9M)
> 
> I have a note here: the project is prepared for emBlocks (a codeblocks variant)
> which is able to compile all files in about 7 seconds.
> The same project Makefile'd compile in more than 20 seconds.
> Make is slow, but I don't know why.
> The compiler is an 4.7 arm gcc eabi variant

I also have a lot of AVR designs, ranging from 2K to about 30K. I'm using 
their gcc compiler. Compile times can be noticed only if Makefile'd :)
Programming times vary but they are in the range of seconds.
For small projects of 8K or less, compilation and flash downloading are 
about instant, with just two key presses or mouse clicks. Faster than any
REPL...

A funny thing about the above Cortex-M4 that I mentioned is that I'm using
a serial bootloader just for the speed of programming :) 
If I use the 'native' flash programming with a dongle, the programming time
for 230K is more than a minute... For that project I  have done two things 
to improve the speed of the cycle: 
1. Switch from Makefile to emBlocks and 
2. using my bootloader.
The speed improvement is huge, only about 18 seconds compared to more than
2 minutes!

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

#39684

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> > Using a current C environment for complex embedded systems. ...
>> > We talk about several 100k of object code and Megabytes of source code.
>> > I do not say that this is desirable.

Are you saying this is taking 45 minutes?  How is the 45 minutes being
spent?  What kind of computer are you running the compilation on?  A few
MB of source code isn't a lot these days.  I've been fooling a little
with ffmpeg, which has around 30MB of C code in 1800+ files and it takes
around 2.5 minutes to build from scratch on an i7-3770, a fairly fast
machine but not a monster.  Also, normally if you use something like
"make", you won't have to recompile all the source files if you just
make localized changes.

>> > For the Arduino, it may be a matter of seconds, but think about
>> > MSP56xx and friends and their areas of application...

Not sure what an MSP56xx is and wasn't able to quickly figure it out.

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

#39686

On 6/10/2015 1:51 PM, Paul Rubin wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>>>> Using a current C environment for complex embedded systems. ...
>>>> We talk about several 100k of object code and Megabytes of source code.
>>>> I do not say that this is desirable.
>
> Are you saying this is taking 45 minutes?  How is the 45 minutes being
> spent?  What kind of computer are you running the compilation on?  A few
> MB of source code isn't a lot these days.  I've been fooling a little
> with ffmpeg, which has around 30MB of C code in 1800+ files and it takes
> around 2.5 minutes to build from scratch on an i7-3770, a fairly fast
> machine but not a monster.  Also, normally if you use something like
> "make", you won't have to recompile all the source files if you just
> make localized changes.
>
>>>> For the Arduino, it may be a matter of seconds, but think about
>>>> MSP56xx and friends and their areas of application...
>
> Not sure what an MSP56xx is and wasn't able to quickly figure it out.

I think he means DSP56xxx.  The DSP56K line were Motorola's entry into 
the DSP market.  They did things differently from TI and had some 
advantages.  Much like the Intel vs. Motorola designs, the DSP56K family 
was planned rather than just happening, so was architecturally better, 
at least on paper.  But again, in a manner parallel to the Intel vs. 
Motorola competition, TI worked the market better focusing on the one 
big app, cell phones.

I've lost track of cell phones these days.  Do they still mostly contain 
a TI DSP chip along with an ARM?  Or has the DSP become part of a custom 
ASIC?

-- 

Rick

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

#39687

rickman wrote:
> I've lost track of cell phones these days.  Do they still mostly contain
> a TI DSP chip along with an ARM?  Or has the DSP become part of a custom
> ASIC?

The whole thing had become a SoC, with the most important things (including 
GPU and multi-core ARM for the smartphone functionality) all on one chip.  
Broadcom and Samsung are the by far biggest contributors to this market.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#39688

On 6/10/2015 2:20 PM, Bernd Paysan wrote:
> rickman wrote:
>> I've lost track of cell phones these days.  Do they still mostly contain
>> a TI DSP chip along with an ARM?  Or has the DSP become part of a custom
>> ASIC?
>
> The whole thing had become a SoC, with the most important things (including
> GPU and multi-core ARM for the smartphone functionality) all on one chip.
> Broadcom and Samsung are the by far biggest contributors to this market.

Are you saying cell phones do the DSP for the radio on the ARM or that 
the ARM chip includes separate DSP hardware?

-- 

Rick

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web