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 2 of 2 — ← Prev page 1 [2]

#39690

rickman wrote:

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

Everything except power management (needs big, cheap power transistors), 
memory, touch screen controller, and camera sensor is on the SoC.  The 
mobile part today is called something like "LTE modem" or so ;-).

Companies without that know-how like Apple apparently still buy a standalone 
mobile part (LTE modem), which contains an ARM, DSP, antenna driver and 
amplifier.

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

#39691

On 6/10/2015 4:06 PM, Bernd Paysan wrote:
> rickman wrote:
>
>> 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?
>
> Everything except power management (needs big, cheap power transistors),
> memory, touch screen controller, and camera sensor is on the SoC.  The
> mobile part today is called something like "LTE modem" or so ;-).
>
> Companies without that know-how like Apple apparently still buy a standalone
> mobile part (LTE modem), which contains an ARM, DSP, antenna driver and
> amplifier.

Any idea which DSP these two types of devices use?  There had been a 
metric ton of software for the TI fixed point chips.  I remember seeing 
a number of start-ups hawking their custom DSP designs which could have 
been rolled into such SoCs, but I never followed them enough to know 
which ones were chosen.  I can only imagine that TI would have been 
happy to be in the IP business selling software compatible DSP IP to SoC 
makers as well.

So who won that race?

-- 

Rick

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

#39692

rickman wrote:

> On 6/10/2015 4:06 PM, Bernd Paysan wrote:
> Any idea which DSP these two types of devices use?  There had been a
> metric ton of software for the TI fixed point chips.  I remember seeing
> a number of start-ups hawking their custom DSP designs which could have
> been rolled into such SoCs, but I never followed them enough to know
> which ones were chosen.  I can only imagine that TI would have been
> happy to be in the IP business selling software compatible DSP IP to SoC
> makers as well.

Apparently a company called CEVA sells IP cores with LTE modem DSPs:

https://www.semiwiki.com/forum/content/4499-qualcomm-lte-modem-competitors-samsung-intel-mediatek-spreadtrum-leadcore%85-simply-ceva.html

I don't think Ti is still in there, but the other big names mentioned there 
do make their own LTE modems.

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

#39693

rickman <gnuarm@gmail.com> writes:
>> 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.

Oh ok, that makes sense.  The 56k series was cool in the 1990's but I
think they're not used much any more, so it sounds like djc might be
using some very old development setups.  45 minutes to compile/link a
program that size is ridiculous these days.  Plus as mentioned, normally
there would be lots of modules with separate compilation.

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

#39695

Am Donnerstag, 11. Juni 2015 06:41:27 UTC+2 schrieb Paul Rubin:
> rickman writes:
> >> 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.
> 
> Oh ok, that makes sense.  The 56k series was cool in the 1990's but I
> think they're not used much any more, so it sounds like djc might be
> using some very old development setups.  45 minutes to compile/link a
> program that size is ridiculous these days.

Lots of guesswork, huh?
MSP != DSP and no, it is neither a mobile phone CPU nor a signal processor.
The compilers were current and the hosts were mid-level office laptops, not top end. Make -j was used, the time relates to the full build, like make depend make boot, make application, link and flash.

And - need I say it again: I do not claim is good to work like that.

Daniel

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

#39696

joi, 11 iunie 2015, 10:40:36 UTC+3, djc a scris:
> Am Donnerstag, 11. Juni 2015 06:41:27 UTC+2 schrieb Paul Rubin:
> > rickman writes:
> > >> 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.
> > 
> > Oh ok, that makes sense.  The 56k series was cool in the 1990's but I
> > think they're not used much any more, so it sounds like djc might be
> > using some very old development setups.  45 minutes to compile/link a
> > program that size is ridiculous these days.
> 
> Lots of guesswork, huh?
> MSP != DSP and no, it is neither a mobile phone CPU nor a signal processor.
> The compilers were current and the hosts were mid-level office laptops, not top end. Make -j was used, the time relates to the full build, like make depend make boot, make application, link and flash.
> 
> And - need I say it again: I do not claim is good to work like that.
> 
> Daniel

So, it's probably a MPC56xx, isn't it?

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

#39697

On 6/11/2015 4:24 AM, Raimond Dragomir wrote:
> joi, 11 iunie 2015, 10:40:36 UTC+3, djc a scris:
>> Am Donnerstag, 11. Juni 2015 06:41:27 UTC+2 schrieb Paul Rubin:
>>> rickman writes:
>>>>> 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.
>>>
>>> Oh ok, that makes sense.  The 56k series was cool in the 1990's but I
>>> think they're not used much any more, so it sounds like djc might be
>>> using some very old development setups.  45 minutes to compile/link a
>>> program that size is ridiculous these days.
>>
>> Lots of guesswork, huh?
>> MSP != DSP and no, it is neither a mobile phone CPU nor a signal processor.
>> The compilers were current and the hosts were mid-level office laptops, not top end. Make -j was used, the time relates to the full build, like make depend make boot, make application, link and flash.
>>
>> And - need I say it again: I do not claim is good to work like that.
>>
>> Daniel
>
> So, it's probably a MPC56xx, isn't it?

Ah, found it...

"The Qorivva MPC56xx family of 32-bit MCUs built on Power Architecture 
technology is designed for engine management, body control, gateway, 
safety, chassis and driver ..."

-- 

Rick

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

#39683

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> 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.

What is the host cpu?  Are you using make -j ?  I get around a 3-4x
speedup from make -j 8 on a i7-3770 (quad core with hyperthreading).

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

#39694

miercuri, 10 iunie 2015, 20:37:22 UTC+3, Paul Rubin a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> > 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.
> 
> What is the host cpu?  Are you using make -j ?  I get around a 3-4x
> speedup from make -j 8 on a i7-3770 (quad core with hyperthreading).

This worked, thank you. Compiling speed with Makefile is greatly improved.

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

#39685

On Wed, 10 Jun 2015 09:05:52 -0700 (PDT), Raimond Dragomir
<raimond.dragomir@gmail.com> wrote:

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

MPE cross compiler generating about 180 kb with Forth interpreter, FAT
file system, PowerNet ...

Section         Type      Used    Start       DP       BP      End
Page
CCMRAM          UDATA        0 10000000 10000000 1000ED00 1000FFFF
PROGU           UDATA     C354 20001000 2000D354 2001F400 2001FFFF
PROGD           IDATA      3DC 20000000 200003DC 20001000 20000FFF
STM32F4EVALPN   CDATA    2B800  8000000  802B800  8080000  807FFFF

Compilation time was 0.168 seconds.

Flash programming with a Segger JLink is a couple of seconds at most
and is performed automagically after a successful compile.

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]

#39526

On 02/06/2015 4:05 AM, rickman wrote:
>
> 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?
>

I spent a lot of time in the 90's in Asian software development shops 
and learned a lot about software design by watching a different 
approach. They did two things that changed how I wrote software.

1) They relied heavily on self contained modules with very clear 
interfaces to them so they could be swapped out and replaced with other 
code. This was important because the very fixed clean software interface 
reduces the number of series terms in the overall application reliability.

2) They had software budgets for each module. Ram, Rom and execution 
time. In general they quit tinkering when the budget was met, and often 
the budget came from an implementation prototype. Rather that draconian 
negotiations of the software budget, they were often developed by the 
same person who would be responsible for the final implementation.

The budget and complete application map predicted, part specs that could 
be used for an application. Not surprisingly they were able to design in 
parts with less capability than competative approaches.

Overall design and implementation time generally a little than most 
alternative approaches. Lots of group meetings early on but few during 
the implementation phase which tended to be shorter. Implementation 
language was not a big factor.

w..

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

#39527

On 02/06/2015 4:05 AM, rickman wrote:
 >
 > 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?
 >

I spent a lot of time in the 90's in Asian software development shops 
and learned a lot about software design by watching a different 
approach. They did two things that changed how I wrote software.

1) They relied heavily on self contained modules with very clear 
interfaces to them so they could be swapped out and replaced with other 
code. This was important because the very fixed clean software interface 
reduces the number of series terms in the overall application reliability.

2) They had software budgets for each module. Ram, Rom and execution 
time. In general they quit tinkering when the budget was met, and often 
the budget came from an implementation prototype. Rather than  draconian 
negotiations for a software software budget, they were often developed 
by the same person who would ultimately be responsible for the final 
implementation.

The budget and complete application map predicted, part specs that could 
be used for an application. Not surprisingly they were able to design in 
parts with less capability than competitive approaches.

Overall design and implementation time generally a little less than most 
alternative approaches. Lots of group meetings early on but few during 
the implementation phase which tended to be shorter. Implementation 
language was not a big factor.

w..

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

#39528

On 06/02/2015 04:05 AM, rickman wrote:
> I was thinking about a timing issue and 
<snip>
> 
> Is it typical in the Forth community to code things up rather than to
> think them through?
> 
A difference is the attitude toward the documentation.  For example, I
know a guy who buys a replacement car battery based on the length of the
warranty.  He figures the price divided by the months of warranty.  That
is one way.  I do it differently.  I use a mechanic I trust and I bring
him all my car repair business.  If he has enough customers he remains
available to me when I need a complicated repair.  Then his judgement,
skill, and experience become important.

If the spec sheet for a part has all the data needed and all of the
parts perform correctly and the rigorous attention to detail is
sufficient then technology can be applied without risk.  Interactive
Forth and Basic make it easier than Fortran or C++ to tinker with a new
part to allow the use of judgement, skill, and experience to evaluate
whether it is feasable or appropriate to use that part for that purpose.

Which is more significant, the tube of 20 parts in hand or the
specification?  Both are important.  All parts should meet their specs,
but often some detail isn't specified but it matters for the application
at hand.  Testing of the tricky corner cases is necessary.

When my car engine cranks slowly but then starts I am warned that I
might need to replace the battery soon.  When I turn the key and the
battery goes bang it maximizes inconvenience.  I don't get to where I
want to go and I have an acid cleanup.  The failure mode of the last
battery I bought wasn't specified at the time of purchase.  I can hope
that it won't go bang.  I know that it is a different brand than the one
that did go bang.  If it does go bang I will be disappointed but not
surprised.
--
Bob

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

#39535

rickman <gnuarm@gmail.com> writes:
>Is it typical in the Forth community to code things up rather than to 
>think them through?

I don't think that the Forth community is a community when it comes to
such questions.  However, Forth is better for tinkering than some
other languages.  IMO there are occasions for tinkering and occasions
for thinking things through.  Of course, there are terms like
"prototyping" that are used instead of "tinkering" that have less of a
negative connotation.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39537

On Tue, 02 Jun 2015 04:05:02 -0400, rickman <gnuarm@gmail.com> wrote:

What did you say about personal manifesto's? ...

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

Now, you  *seem*  to be embellishing your stories, like Hugh ...
Previously, you stated this about the timing info:

"I was not able to get that info as it is proprietary."

-by rickman, "GA144 in a Serious Low Power Project (SLPP)" thread,
comp.lang.forth, Jan 7, 2013, msg-id: kc7q3g$e45$2@dont-email.me

Was this a different situation of timing info?

If so, just how many people in the world don't
want to give you timing info?

> [...] doing Forth design for 40 years, by building and testing.

This works, but a skilled programmer generally has an idea of
what to implement, and sufficient experience in solving similar
problems to chose a path which is likely to succeed.  Other
techniques like build-and-test, or shot-gun, or re-write,
or debug-it, or wing-it, or cut-n-paste, must be used too
because some people are brighter and others less so, and
there are always unforeseeable interactions.  Also, the less
able the person or perhaps less well paid, the more they'll
rely on simpler techniques, because they're easier and slower.
Agree?

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

Reality simply doesn't match theory due to assumptions and
simplifications or only does so rarely.  Digital circuits
should be much more precise in general than analog.

At some point, the code must be tested.  So, you might as
well test incrementally.  Even if you're designing something
and not just winging it, testing as you go is easier and a
bit more thorough.  You can work with the code in an
intermediate form that may allow more access and ability
to test than in the final form.  Even so, you should still
produce a comprehensive final test to test the design after
completion.  However, there will always be some things that
simply can't be tested in the final form.

> I know I would never try to use timing loops to generate
> video signals.

Why not?

Much the same thing is done in electronic circuits.
Isn't it?  I.e., imprecise methods, but good enough.
E.g., 14.318Mhz or 3.58Mhz divided down by counters
or a digital delay line to generate sync signals or
color-burst ring oscillator, or PLL, or RC timing,
etc.

> I think a simple analysis would show the lack of stability.

The obsolete NTSC televisions are very forgiving.  Very few
of the early 8-bit computers generated correct horizontal or
vertical sync and they worked on almost every television.

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

Some chips simply aren't to spec because they're cheap,
or are thrown off by poor tolerance production parts.

E.g., a company I worked for designed audio circuits
using high-end video op-amps and 1% tolerance resistors,
but then they bought the cheapest audio versions of
the op-amp they could find for production and used 10%
resistors.  The production op-amps had a high failure
rate, but they were unbelievably cheap.  The resistors'
possibly poor tolerance had been accounted for by the
electrical engineers for most situations but not all,
i.e., two in parallel, _both_ with wide tolerances ...

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

Was this a comment on someone here in particular?

You have to start somewhere to solve a problem.
If you don't already have an understanding of what
to solve, you'll likely have to learn something or
code something up first to attempt to obtain an
understanding of the issue(s).


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?

[toc] | [prev] | [standalone]

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

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

csiph-web