Green Arrays DevBoards!

forth

    Next

  • 1. +DEFER
    Don't know if this is re-inventing the wheel but I haven't seen a version of this before ... For those who have implemented DEFER IS , here's a way to add new behaviours to an existing deferred word. This definition of +DEFER should work with implementations of DEFER that have a single XT in the body (which AFAIK is most of them). I've tested it on Win32Forth. However Gforth 050 seems overly protective and won't allow the compilation of ' ; ' - no matter what I tried. \ Add xt to an existing DEFERed word : +DEFER ( xt -- ) :NONAME SWAP COMPILE, ' >BODY DUP @ COMPILE, POSTPONE ; ! ; DEFER TEST : T1 ." Test1 " ; ' T1 IS TEST : T2 ." Test2 " ; ' T2 +DEFER TEST : T3 ." Test3 " ; ' T3 +DEFER TEST TEST Finally, - with this scheme the most recently added behaviour is the one that is executed first. - +DEFER is not state-smart and can't be used inside a definition. Ed
  • 2. Strange (?) GUI question
    I really like the way Forth (and Lisp) allow me to design top-down, but implement from the bottom up, constantly testing along the way. There doesn't seem to be any way to do this with a GUI, at least not that I've found. All GUIs seem to be very much top-down design and implementation, possibly because of their strong roots in C and C-like languages. Has any work been done anywhere that reverses this? Something that will let me design a button and test it, before adding it and it's cousins to a panel to test, and eventually building the window frame last of all? Without all the scaffolding that GTK+ and its cousins require. Would this even be possible, and if it is possible, would it even be desirable? Any thoughts? Thanks, Larry
  • 3. GUI question (and more)
    The following is a list of all the progress made to-date towards GUI and OOP standards for Forth (please correct me if I've gotten it wrong):

Green Arrays DevBoards!

Postby Mux » Thu, 21 Oct 2010 13:48:59 GMT

 http://www.**--****.com/ 

Little pricey though...

Re: Green Arrays DevBoards!

Postby rickman » Thu, 21 Oct 2010 17:02:43 GMT



The board as described appears rather minimal, but I don't consider
$400 pricey.  Eval boards are typically several hundred dollars.  It
is the very tiny, very limited EZ type kits that are under $50...
well, given the minimal functionality of this eval board, maybe $400
is a bit high.  It is interesting that it only has EIA-232
interfaces... no USB, no Ethernet, no analog, no nothing other than
three "minimal" serial ports.

The idea of an eval board is to allow an engineer to evaluate the
product in an application context.  With nothing but power and serial
ports, this is not much of an application context.  Maybe they plan to
expand the base board with I/O daughter cards.

Rick

Re: Green Arrays DevBoards!

Postby David Kuehling » Thu, 21 Oct 2010 19:57:54 GMT

>>>>> "Mux" == Mux  < XXXX@XXXXX.COM > writes:


And not even available for at least half a year:

  "[..] and we expect to have chips available in quantity during the
   second quarter of 2011"

Also the listed price may not apply:

  "The discounted prices shown below apply to the first 25 orders
   received."

Could be a nice alternative to an FPGA development board.  However, as
long as /full/ programming documentation (such as ROM contents) is not
available, it won't be less proprietary than an FPGA.  

And I certainly won't want to program such a device in colorForth using
yet another proprietary IDE, when a portable cross-compiler with more
normal Forth syntax could be written within a few days.

I'm not per se against using a new language like colorForth.  But I like
to have tools properly modularized and interoperable.  Can I interface
colorForth code to subversion?  I guess not.  Can I edit code in my
editor of choice?  I can't.  Can I control compilation using the tools I
know (like GNU make?).  No.

I've had to work with quite a lot of annoying vendor-tools.  Looks like
colorForth/arrayForth takes non-interoperability to a new level.

</rant>

The GA144 chips still let me hope that their extreme simplicity allows
full programming without vendor-tools.  Something that's pretty much
impossible with current FPGAs.

David
-- 
GnuPG public key:  http://www.**--****.com/ ~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40

Re: Green Arrays DevBoards!

Postby Dennis » Thu, 21 Oct 2010 23:19:26 GMT



While I can't argue with your last point, the 1st is simply not true.
Subversion can handle binary files fine.  It just can't do diffs
between versions, and personally, I find that objectionable.

I also agree with your 2nd point, and as I find time, I have been
trying to deal with that with a project that you can find at
 http://www.**--****.com/ 
This does not, and will not remove the proprietary nature of the code,
but it does, at least, expose the source to a little more
interoperability.

DaR

Re: Green Arrays DevBoards!

Postby foxchip » Thu, 21 Oct 2010 23:43:01 GMT



Maybe you stopped reading after the second sentance
of the announcement and preliminary documentation
on the EVB-001.

I read that it will have a 40-pin external memory
interface, external SRAM, an SPI flash interface,
external SPI flash, an ANSI Forth in flash, Serdes
connection, Specific I/O connections, Analog terminations,
and prototyping area.  The preliminary documentation
doesn't say much but the page does not say that the board
has nothing but power and serial ports.

Best Wishes

Re: Green Arrays DevBoards!

Postby Mux » Thu, 21 Oct 2010 23:55:56 GMT





For what's included, I still say it's pricey :-) Like you said, most
FPGA dev-boards in that price range are loaded with SRAM, DRAM, FLASH,
ethernet, etc. A picture's worth a thousand words though... How about
it, GA? :-)

Re: Green Arrays DevBoards!

Postby John Passaniti » Fri, 22 Oct 2010 02:41:08 GMT



I'm curious if anyone has a "colorblind" syntax that ColorForth source
can be converted to (and back).  I'm not talking about a one-way
conversion (such as to HTML).  I fully expect that any syntax one
comes up with is going to be more verbose and possibly visually
annoying than ColorForth, but having such a syntax (and tool) would be
a big step towards letting people use existing tools they are familiar
and comfortable with.  And for those who have some color blindness or
those who view ColorForth source code as "angry fruit salad", it's an
option that opens development up to more people.

In particular, it would enable using version control systems with
meaningful diffing between versions and it would enable sharing code
easier-- it could be posted in forums and in email.


Re: Green Arrays DevBoards!

Postby Josh Grams » Fri, 22 Oct 2010 07:36:20 GMT





I don't know if there is a tool available -- colorforthers rarely seem
to bother with those sorts of conveniences, and I can't find the code
that I wrote.

But there is a trivial transform between color and punctuation.  Off the
top of my head:

red word = ": word"
green-yellow transition = "["
yellow-green transition = "] literal"
cyan word = "postpone word" (or "` word" in the HelForth tradition)
white words = "( words )" or "\ words"
magenta word = "variable word"

ANS Forth it ain't, but it's perfectly readable.

I'm probably forgetting a couple of wrinkles, but once you're familiar
with the ColorForth source format it's pretty straightforward.

--Josh

Re: Green Arrays DevBoards!

Postby rickman » Fri, 22 Oct 2010 10:47:35 GMT





Yes, I read the document, but none of the items you list are external
interfaces.  I would assume the CPU has some means of booting code and
that some sort of boot code would be supplied.  I have not found
"prototyping areas" to be of much use since I stopped using 0.1" DIP
package parts.  I have to say, I don't know what "analog termination"
implies and "specific I/O connections" means nothing to me unless the
I/O type is defined.

So my impression of the board stands.  It is for playing with the
chip, not evaluating it in the context of an application unless that
application is EIA-232 intensive.  This is exactly what TI and other
companies intend with their low end kits such as the $4.30 MSP430
kit.  If Green Array follows that approach at some point they will
offer it for either $144 or $1.44.

Regards,

Rick

Re: Green Arrays DevBoards!

Postby Albert van der Horst » Fri, 22 Oct 2010 10:50:20 GMT

n article < XXXX@XXXXX.COM >,
John Passaniti < XXXX@XXXXX.COM > wrote:

I have been working on the parallel sieve with Leon Konings
and we use Git to store a html version of the total system, but this
is a one way street. We can use it to run diffs, though.
So we have to store the .cf file as well, because that is the source.
It can only be edited by the colorforth editor while running
colorforth/Okad.

Now what I did a long time ago.
I have assembled and reassembled colorforth. That is including screens.
That is two-way.

It uses my ciforth prefixes.
So <red>jan <green>piet <green>pies <green>;
becomes
:jan ]piet ]pies ];

``,'' : commaed in. (copout)
``:'' : a red colorword. (define)
``]'' : a green colorword. (compile)
``['' : a yellow colorword. (execute)
``^'' : a cyan colorword. (postpone)
``?'' : a violet colorword. (variable)
``('' : a white colorword. (comment)
``+'' extends the previous word. (extend)
``#'' : a yellow decimal number.
``$'' : a yellow hex number.
``[#'' : a green decimal number.
``]$'' : a green hex number.
``%$'' : a brown hex number.

Note that prefixed words are effectively opcodes, and generate
binary content in the edit screen section (section in the sense
of assembler like .data .txt )

So what you do is take a couple of screens like this, stuffed
in an ascii file,
=======================================================

( SCREEN) #36 400 * DUP SECTION SCR36 EDIT-TIME
( 0000,9000 ) (Edit
( 0000,90B8 ) :td ]toggle
( 0000,90C0 ) :d ]#16
( 0000,90C8 ) :wrap [cu ]@ ]+
( 0000,90D8 ) #16 #24 [* ]dup
( 0000,90E8 ) ]u+ ]/mod ]drop [cu
( 0000,90F8 ) ]! ];
( 0000,9100 ) :tu ]toggle
( 0000,9108 ) :u ]#134217712 ]wrap ];
( 0000,9118 ) :tr ]toggle
( 0000,9120 ) :r ]#1 ]wrap ];
( 0000,9130 ) :tl ]toggle
( 0000,9138 ) :l ]#134217727 ]wrap ];
( 0000,9148 ) :nul ];
( 0000,9150 ) :h ]pad ]nul ]nul
( 0000,9160 ) ]accept ]nul ]tl ]tu
( 0000,9170 ) ]td ]tr ]l ]u
( 0000,9180 ) ]d ]r ]-ic ]nul
( 0000,9190 ) ]nul ]+ic ]nul ]nul
( 0000,91A0 ) ]nul ]nul ]nul ]nul
( 0000,91B0 ) ]nul ]nul ]nul ]nul
( 0000,91C0 ) ]nul ]nul $2500 [,
( 0000,91D0 ) $110160C [dup [, [,
( 0000,91E0 ) %$2B000023 [, #0
( 0000,91F0 ) [, #0 [, #0
( 0000,9200 ) [,

-----------------------------------
and assemble it.

I plan to reorganise such that within the project that the above
becomes source.

Note that it can be rewritten
from
---------------------------
( 0000,9018 ) :-ic [ic ]@ ]#134217727
( 0000,9028 ) ]+ ]#0 ]max [ic
( 0000,9038 ) ]! ];
( 0000,9040 ) :bit [cu ]@ ]2/
( 0000,9050 ) ]2/ ]2/ ]2/ ]2*
( 0000,9060 ) ]loc ]+ ]$10000 [cu
( 0000,9070 ) ]@ ]$F ]and ]#1
( 0000,9080 ) ]+ ]for ]2/ ]next
( 0000,9090 ) ]*byte ];
( 0000,9098 ) :toggle ]bit ]over ]@w
( 0000,90A8 ) ]or ]swap ]!w ];

to
---------------------------

\ Yellow decimal numbe

Re: Green Arrays DevBoards!

Postby Albert van der Horst » Fri, 22 Oct 2010 11:24:22 GMT

In article < XXXX@XXXXX.COM >,




<SNIP>

                                 ^^^^
That must be                     doesn't






Re: Green Arrays DevBoards!

Postby Dennis » Fri, 22 Oct 2010 23:04:24 GMT







The project that I mentioned earlier at
 http://www.**--****.com/ 
does the "colorblind" translation to pure ASCII.  The colorForth
portion is (almost) full round trip, but I have not completed the
machine code translation back to executable format yet.

Your mapping is close to what we started with originally, but it has
expanded over time.

Yellow words get [ ... ]
Blue, grey and unknown get { ... }, which probably aren't fully round
trip yet.

There's also the various number formats to deal with and variable did
not quite map to what magenta do, so we used :#

It is perfectly readable, although significantly more noisy.

DaR

Re: Green Arrays DevBoards!

Postby Mux » Sat, 23 Oct 2010 01:40:00 GMT

Soooo, anyone up for starting some sort of pool to bring the cost
down?

-Mux

Re: Green Arrays DevBoards!

Postby John Passaniti » Sat, 23 Oct 2010 02:20:51 GMT


> application unless that application is EIA-232 intensive. 

I don't think the limited I/O of the GA144-1.20 evaluation board is a
big deal.  I've got an $150 (Digikey pricing) XMOS XC-2 evaluation
board on my desk that has not much more-- just a USB port used for
programming and an Ethernet jack.  But what is key is that it also
brings out (nearly) every pin from the XS1-G4 and has a small proto
area.  In our case, the proto area is too small and we made a separate
board for codecs and connectors and other whatnot.  That's reasonable
because to evaluate the XS1-G4 for our applications, we need to
interface to our hardware; I wouldn't expect an evaluation board to
have the specific set of interfaces we use in our industry.

The GA144-1.20 evaluation board preliminary datasheet says the board
will have a prototyping area.  And as long as all the relevant signals
of the GA144 are brought out, that's all I would care about.  It isn't
clear to me what "Minimal RS232 Xcvr" means.  I would hope that it was
little more than a line driver chip and glue because I want to see the
GA144s implement serial communications in software.

What might be a cute idea is to make the GA144-1.20 evaluation board
have the same form-factor as Arduino "shields".  That ecosystem has a
huge variety of I/O boards and being electrically compatible with that
would mean engineers evaluating the GA144 could find most any I/O that
they liked.

I do think the price is a bit high, but my guess is that they don't
expect to be making many of these boards and probably haven't bothered
to cost-optimize them.

Re: Green Arrays DevBoards!

Postby Albert van der Horst » Sat, 23 Oct 2010 20:45:35 GMT

In article < XXXX@XXXXX.COM >,



<SNIP>


If it is anything like the Seaforth 232 it will be bit-banging
and a level convertor.

<SNIP>

Groetjes Albert


Similar Threads:

1.Green Arrays DevBoards!

2.More Thoughts on Green Arrays

I had a conversation about the Green Arrays chips in an FPGA
discussion group where I said the devices should be thought of as
processor arrays with the emphasis on array rather than processor.
The point is that no one thinks about a LUT in an FPGA in terms of
keeping it "busy" or utilizing every gate, etc.  They know that there
are lots of LUTs and FFs and they are cheap, so there is no need to
optimize every gate.

Another poster was very concerned about the sorts of issues you have
when you are multitasking on typical processors, like preventing
deadlocks.  I can't remember ever worrying about deadlocks when
designing logic although I'm sure it is possible.  But I couldn't
explain how they are avoided when designing hardware.

In fact, that is how I see the Green Array devices as programmable
hardware, not software engines.  But I'm not sure I fully understand
how to use all the features in this way. Consider the memory
interface.  It uses three processors to control memory and has to be
accessible from many nodes in the chip.  I suppose one will be the
primary node to handle access requests.  I suppose some of the other
nodes would need to pass messages around and act as multiplexors.

The one thing I am having trouble getting around is the tiny 64 word
memories.  I can accept a small stack and I can see where minimal data
memory is needed, but I am stuck thinking about how to use a node for
processing and also use it for passing data between the other nodes.

Do the tools have a simulator so that code can be tested before the
hardware is available?  That is another way I see these as being
similar to hardware, I will feel a lot more comfortable using a
simulator that lets me "see" what is going on in the chip.  How else
will you be able to debug 144 processors?

Rick

3.[OT] ADC in green array chips

I read with interest all the advantages of the ADC
conversion in the Green Array Chip and suspected that it
would be one of Chuck Moore's patents until
I discovered it mentionned in a wikipedia article.

Anyway, I understand that we read out a wrapping 18 bit counter,
and the difference in count represents an avarage voltage.
So far so good, but the points in time were the counter is read
out must be very precise, I understand that a 0.1% jitter would
reduce the resolution to 10 bits.

So how is this accomplished in a chip without a clock?

Groetjes Albert

4.Green Arrays CPU Chips

I have been looking a bit at the GA chips and they seem to have at
least one particular selling point, the power consumption vs. the
processing capability.  I want to explore that a bit. There is a while
paper about this comparing the GA chips to the MSP430.  The MS430 is a
good benchmark for a low power MCU, but the GA chips are not MCUs.
They need external Flash and may need external RAM.  In that sense it
is an odd comparison.  I can't see any MSP430 chips being displaced in
a new design by a GA chip, not even the GA4.

They currently show two devices on the web site, at GA144 and a GA4
with 144 and 4 processors respectively.  The GA4 has only 10 I/O, two
analog and 8 digital.  I don't have any apps suitable for such a chip,
especially considering that there is no on chip flash memory and very
little RAM.  The GA144 chip has 62 digital I/O I think... I count 16
power pins (+c, +i, +a) and 10 analog leaving 62 out of the 88.  I
can't quite figure out how they get "25 digital I/O lines".  They say
the two 18 bit ports can be used for "other purposes", I have to
assume that means I/O port bits.  However, it appears that the two
buses come from one CPU each.  So if you want to do fast I/O on them
this may be a limiting factor.  In my designs I typically only have a
few I/Os that need to be fast and the rest are static control
signals.  Since this comes in a 10 mm QFN package, it would allow
space for a serial boot Flash (but I'm not sure about a RAM chip) in a
footprint comparable to the FPGA I use in many of my designs.  I'm not
crazy about the 0.4 mm pitch.  That is only 16 mils and may be a bit
difficult for low cost assembly.

I wonder about the low power pin count.  I expect the 16 power pins
are half ground and half power.  That's not many pins and could lead
to ground bounce.  I expect the async nature of the chip clock may
help mitigate this issue.

Rick

5.ADC in green array chips

Maybe the question should be how is a PLL clock of a ring oscillator
synchronized to a temperature compensated voltage reference?

6. GA144 Devboard Pool?

7. Green book Q

8. Hamilton Beach Eclectrics 500-Watt 48-Ounce Blender (Apple Green)



Return to forth

 

Who is online

Users browsing this forum: No registered users and 96 guest