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


Groups > comp.lang.forth > #24179

Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation

From rickman <gnuarm@gmail.com>
Newsgroups comp.lang.forth
Subject Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation
Date 2013-07-05 17:05 -0400
Organization A noiseless patient Spider
Message-ID <kr7c6i$end$1@dont-email.me> (permalink)
References (17 earlier) <7xppuy1ce1.fsf@ruckus.brouhaha.com> <kr49qb$jia$1@dont-email.me> <7x1u7e6xg8.fsf@ruckus.brouhaha.com> <kr4b85$t1o$1@dont-email.me> <7x38ruxh8o.fsf@ruckus.brouhaha.com>

Show all headers | View raw


On 7/4/2013 3:22 PM, Paul Rubin wrote:
> rickman<gnuarm@gmail.com>  writes:
>>> the effect is in principle 4x worse for a 32-bit adder
>> You don't use MCUs like anyone else I know.  You look at the data they
>> provide which is *chip* data.  No one provides power data separately
>> for each logic function on an MCU.  So there is no way to analyze the
>> device in this manner.
>
> MCUs are not made out of magic--they use well-understood design and fab
> processes and the designers know how to estimate these numbers and in
> principle we could do the same.  Without actual numbers we can still
> hopefully agree that it's bloody obvious that if two chips are made with
> the same process and one of them has 4x more circuitry than the other,
> the bigger one is likely to have more total leakage current than the
> smaller one.  That's all I'm saying here.

That is the point, we don't know anything about the processes used for 
the various chips.  Yes, if you want to talk in abstractions then sure, 
I agree.  But what is the point of that?


>>> Lack of code space, lack of ram, awkward instruction set, no compilers.
>> These things (the few that are accurate...
>
> Which of "lack of code space", "lack of ram", "awkward instruction set",
> and "no compilers" are inaccurate?
>
>> most of what you said about the GA144 is wrong) are limitations to you
>> because you have not learned how to use the chip.  That is what I
>> said.  You can't use any device until you learn how.
>
> I look at the sample code that GA has posted, and the pain level
> apparent in that code, and I can only conclude that nobody knows how.

I like to think I know how.  I may not be a master of the GA144, but I 
was able to code a few routines and verified that my ideas likely would 
not work on the GA144, at least not the way I intended.  I also found 
that my concept of using the cores in the same way I use FPGA components 
was not appreciated by the folks at GA and they are not interested in 
supporting that, i.e. they won't release adequate timing data to plan a 
design rather than just expecting the user to try stuff on an eval board 
and time it...

Those were my problems with the company more than the chip or the tools. 
  If you are faulting them for that, then I agree.


>> You have already learned how to use conventional MCUs so you have
>> already climbed up the learning curve.  Now you need to climb the
>> learning curve for this device.
>
> That sounds like a platitude.  Look at that conference paper on the GA
> site, where somebody spent months programming the AES encryption
> function onto something like 100 cores of a GA144.  Or the GA app note
> about MD5, again taking months and spread across dozens of cores.  Both
> those algorithms can easily be coded on a conventional MCU in an
> afternoon.

Ok, AES encryption may not be suitable for the GA144 if it uses 100 out 
of 144 cores.  It is also likely not suitable for the 8 bitter chips you 
have been talking about.  I haven't read all the app notes, but I am 
pretty sure it doesn't take months to learn how to use the GA144.  I 
learned what I know in a few weeks.  I did not get to the point of 
mastering all the tools however.

I will grant you that the company is doing a *lousy* job of promoting 
the device.  I think they are also doing a lousy job of supporting the 
device.  Every question I asked, all of which seemed to be pretty 
obvious questions, had to be answered individually and many had to be 
researched.  I would have thought most of these issue would have been 
addressed in the docmentation.  Clearly their ideas of design are 
different from mine.  That still does not make the chip or the tools 
difficult to use.


>> The GA144 is not inherently difficult to use for simple tasks.  In
>> fact, I find it much easier to use than most MCUs where you often have
>> to figure out how to use a single CPU to do multiple asynchronous
>> tasks, interrupts, multi-threading, etc... not simple stuff to the
>> uninitiated.
>
> Let's take a fairly simple conceptual exercise and say you want to make
> a typical, slightly fancy digital wrist watch.  Ignore the notorious
> hardware issues of clocking the GA144 with a crystal,

Uh, I don't think you will have much luck getting any MCU without an 
internal oscillator to run from a crystal.  So you will need an 
oscillator instead.  If you are going to discount the device based on an 
app which requires functions it doesn't have then why not ask it to 
shoot a payload to the moon?


> and assume you
> have a precise 1000 hz timer toggling an input pin, and enough i/o pins
> for all the LCD segments.  So you have to count these timer events, and
> drive an LCD display showing the current time (hours/minutes/seconds),
> day of the week, and calendar day.  You have to support a pushbutton UI
> allowing setting the time and date, and you have to calculate the
> weekday from the day/month/year, which requires taking leap years into
> account.  You want stopwatch and alarm functions, but we'll skip unusual
> features like the sunrise/sunset time or moon phase.  I have a $5 watch
> that does all this stuff, so it's not outlandish.
>
> How would you envision the GA144 code for this being organized?  On a
> conventional MCU it's all very straightforward coding.  You might want
> to use interrupts, or you could do a single threaded polling loop.

Why would you want to do polling or use interrupts in a conventional 
MCU?  They all work at much lower power if you put them in stop state 
and let the 1000 Hz input wake them and run from an internal imprecise, 
but low power oscillator.  This feature they have in common with the 
GA144.


> MCU's usually have built-in counter/timers so you can let the hardware
> divide the 1000 hz down to 1 hz for display update.  The only catch is
> that there's enough functions that you might need a KB or so of code.
> On an MCU that's no big deal.  On the GA144 it means having to split the
> code across many different cores, and deal with routing communications
> around between the cores, etc.  Plus you have to program in a very low
> level Forth subset.  MCU's usually have C compilers, or (this being clf)
> full featured ANS Forth which we can consider to be about equivalent.

See, you *don't* understand the GA144.  Splitting the code across cores 
is not a *requirement*, it is a *feature*!!!  This makes the code simple 
in the same way it is simple in an FPGA.  Imagine doing this in an FPGA. 
  You would have an input counter dividing by 1000 to produce a seconds 
pulse followed by the seconds counter, the minutes counter..., in fact 
early watches were done just this way and I'm not sure they aren't still 
done this way.  So you might assign the input counter to a single CPU in 
the GA144.  It wakes on the positive transition of the 1 kHz input, 
handles the counter and (if it doesn't deal with the time itself) sends 
an a one Hz tick to the next node.  This input timing node calculates 
the seconds, minutes and hours while taking into account (possibly) the 
leap second and outputs to another node which calculates the day, week, 
month and year.  None of these are complex tasks and would fit easily in 
the available node memory.  The aggregate time is passed on to the alarm 
node which deals with handling alarm operation and the display node with 
handles formatting the data for the LCD.  There may be another node to 
control the display timing since an LCD is driven by ~30 Hz AC, but that 
can likely be done by the same node, it needs a timing signal from the 
first node that is dividing by 1000.  The input timing node just has to 
provide the ~30 Hz output as well as a 1 Hz output.  Another node is the 
"UI" which controls the two, three or four push buttons and sends 
messages to all of these nodes to set the current time.

How could you possibly make this into something complex?  Ah, you are 
used to using a single, sequential processor with all of it's 
complexities like needing interrupts and multiple tasks.

If I had the time I would code this up for you, but I'm busy with work 
for a few more weeks.


> It's pretty clear that if you make any realistic plan in your head about
> how you'd develop the code for the two approaches, the coding hassle is
> just much, much lower with the MCU.

Or it is obvious that coding this app (and many others) is a snap on a 
multi-core chip like the GA144.

Look, I understand where you are coming from.  I have a different 
perspective because I do FPGA work which always deals with multiple 
processing elements.  This means I already have the development model in 
my head.  You need to give up what you have learned about sequential 
processing and think in terms of modularization and data flow.  Its not 
harder, it's just different.  In fact, I think it is much easier because 
the synchronization is built in.  That can be a bear in sequential 
processing.

-- 

Rick

Back to comp.lang.forth | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-24 11:02 +0200
  Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-24 05:54 -0700
    Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-25 10:51 +0200
      Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-25 02:29 -0700
        Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-25 14:06 +0200
          Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-25 10:34 -0700
            Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-26 11:03 +0200
              Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-26 22:18 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-27 12:09 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-06-27 11:15 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-27 09:55 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-06-27 15:02 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation visualforth@rocketmail.com - 2013-06-30 21:43 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-01 12:09 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-01 16:44 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-01 18:14 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-02 10:36 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Mark Wills <markrobertwills@yahoo.co.uk> - 2013-07-02 03:12 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-02 10:17 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-02 16:35 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-02 16:33 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-03 00:51 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-03 10:38 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-04 09:26 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 10:08 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-04 13:07 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 10:34 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-04 13:31 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 12:22 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 12:27 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-05 17:05 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-05 15:09 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-05 19:21 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-05 17:49 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-06 00:38 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-05 22:39 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-06 10:56 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-06 20:35 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-07 10:44 +0000
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-07 12:48 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-07 01:20 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-08 11:49 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-08 09:55 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Roberto Waltman <usenet@rwaltman.com> - 2013-07-06 12:48 -0400
          Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-08 14:47 +0200
            Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-08 09:37 -0700
            Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-07-09 11:32 +0000
              Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-09 14:27 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Bill Richards <billrich@gmx.com> - 2013-07-09 13:41 +0000
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-09 09:23 -0500
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-10 02:27 +0000
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Bill Richards <billrich@gmx.com> - 2013-07-10 07:34 +0000
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-10 03:18 -0500
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-10 01:43 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Brad Eckert <hwfwguy@gmail.com> - 2013-07-16 08:31 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-10 03:02 -0500
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-07-09 15:14 +0000
      Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation visualforth@rocketmail.com - 2013-07-15 12:27 -0700
        Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-16 11:52 +0200

csiph-web