Program Chip directly via Internet - ATTINY – Tiny 13 and Tiny2313 –- Sparrow

[JUERGEN]

Programming a chip via a tablet, mobile or PC – just using the earphone connector?
It looked like a quite unusual solution – but interesting. Useful – not sure, but good enough to get started.
All of the tools are somewhere on the web. For now, Editor, Assembler and C-Compiler
– so why not a Forth Cross Compiler as well?
Minimalist yes.
The link to the eBook: https://www.amazon.co.uk/Cheepit-Sparrow-Programming-Mobile-Phone-ebook/dp/B074G54KRR/ref=asap_bc?ie=UTF8
The link to some free documentation, there further down: http://www.ak-modul-bus.de/cgi-bin/iboshop.cgi?showd20!0,694364494580736,Sparrow
Related to Tiny Systems: http://tiny.systems/categorie/cheepit/

Write your small application online, and program the chip directly via the audio socket.
And it works, tried it.
8 pins and 1k Flash is not much and few IO pins, so the next step would be the 20 pin 2313, and double the Flash, using the same programming regime.
There is MikroForth for 2313 in German and English, at https://wiki.forth-ev.de/doku.php/attiny

Which other Forth compilers or cross compilers are out there now that could be used for such an application?
I found Byteforth, but have issues with the links.

But there must be more …

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> Write your small application online, and program the chip directly via
> the audio socket.

That's a cute idea but I think the Adafruit Express boards have it
almost all the way figured out. Use a chip with a USB device port, with
a firmware stack that simulates a USB hub with both a simulated flash
drive (on-chip or on-board flash) and a simulated serial port connected
to the simulated hub. Then you plug it into your PC, use your favorite
PC text editor to write code and store it as files on the device, and
interact with it through a terminal program. I just ordered one of
these boards: https://www.adafruit.com/product/3501

It implements the simulated flash drive, but does serial on separate
pins.

[minf...@arcor.de]

There is a lot more. F.ex.
https://www.postscapes.com/internet-of-things-hardware/

[Paul Rubin]

minf...@arcor.de writes:
>> Which other Forth compilers or cross compilers are out there now

> There is a lot more. F.ex.
> https://www.postscapes.com/internet-of-things-hardware/

I see tons of hardware there but nothing about Forth.

[JUERGEN]

Thanks Paul, this is now on the radar anyway for later - as basis for Forth, and hopefully included in A Start With Forth Part2 ... Sparrow is an interesting idea, I did the translations, tried a few of the downloadable apps - the minimalist approach, as no USB as all of the other options.

[JUERGEN]

Wow, somebody did quite a collection there. But most of them are Dev-Boards, and I am looking more at Application boards, as the app has to run on something and should not block the DevBoard.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> Thanks Paul, this is now on the radar anyway for later - as basis for
> Forth, and hopefully included in A Start With Forth Part2 ... Sparrow
> is an interesting idea, I did the translations, tried a few of the
> downloadable apps - the minimalist approach, as no USB as all of the
> other options.

It's cute but if the idea is to communicate with a smartphone, you might
as well use Bluetooth like the BBC MicroBit.

Meanwhile, a day after I ordered the M0 Gemma, Adafruit launched an M0
Trinket (similar board with more pins and leds, at $8.95 US):
https://www.adafruit.com/product/3500

Meanwhile, they offer a giant 555 timer made entirely of discrete parts:

https://www.adafruit.com/product/1526

and a "555 timer circuit playground plushie":

https://www.adafruit.com/product/1022

But no actual 555 chips! I need to make a pulsating buzzer (never mind
why) and I ordered some vibration discs (like in cell phones) from them,
but no 555's to do the pulsing. So I'm going to use a 32 bit
microprocessor programmed in Python. What a world.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> Wow, somebody did quite a collection there. But most of them are
> Dev-Boards, and I am looking more at Application boards, as the app
> has to run on something and should not block the DevBoard.

I still don't understand what you're trying to do? Why two boards?

[minf...@arcor.de]

Em, the "usual" industry way is to prototype with a dev board, and give
the result to an app board manufacturer. The app device is mostly much
smaller and with a customized chip.

[rickman]

I couldn't read the web pages you linked as I don't read German (or is it
Dutch?). Have you looked at Mecrisp? There is a new version in development
that does cross support for the MSP430. Other targets shouldn't be too hard.

--

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

[Albert van der Horst]

In article <42c65de5-2020-42dc...@googlegroups.com>,
JUERGEN <epld...@aol.com> wrote:
>Programming a chip via a tablet, mobile or PC =E2=80=93 just using the earp=
>hone connector?
>It looked like a quite unusual solution =E2=80=93 but interesting. Useful =
>=E2=80=93 not sure, but good enough to get started.
>All of the tools are somewhere on the web. For now, Editor, Assembler and C=
>-Compiler=20
>=E2=80=93 so why not a Forth Cross Compiler as well?
>Minimalist yes.
>The link to the eBook: https://www.amazon.co.uk/Cheepit-Sparrow-Programmin=
>g-Mobile-Phone-ebook/dp/B074G54KRR/ref=3Dasap_bc?ie=3DUTF8
>The link to some free documentation, there further down: http://www.ak-mo=

>dul-bus.de/cgi-bin/iboshop.cgi?showd20!0,694364494580736,Sparrow
>Related to Tiny Systems: http://tiny.systems/categorie/cheepit/
>

>Write your small application online, and program the chip directly via the =
>audio socket.
>And it works, tried it.=20
>8 pins and 1k Flash is not much and few IO pins, so the next step would be =

>the 20 pin 2313, and double the Flash, using the same programming regime.

>There is MikroForth for 2313 in German and English, at https://wiki.forth=
>-ev.de/doku.php/attiny

I see a lot of answers that propose to use a different development system,
drawing all kind of extra requirements, usb, bluetooth wifi etc.
They don't seem to understand the implication of this.

I can have msp430 launchpad under control with a single bit on my
boat ancre system.
It is true that I had to buy a plug in card with a genuine parallel port.
You need only one bit, but you must totally control that bit!
Then you can program a board, communicate with it et. (Okay if you don't
want to press reset on the board maybe an extra line or two).

The exciting thing is to be able to do same thing on a tablet
with a Forth, and the ear phone that is the only peripheral available.


>
>Which other Forth compilers or cross compilers are out there now that could=

> be used for such an application?

>I found Byteforth, but have issues with the links.=20
>
>But there must be more =E2=80=A6
>
--
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

[JUERGEN]

I actually initiated the port of Mecrisp to the microbit at the time, sent Matthias a microbit, and he did a brilliant job.
The result from last year you can find at
https://www.forth-ev.de/article.php/20161015170308483
and
https://wiki.forth-ev.de/doku.php/en:projects:microbit:start
ALL IN ENGLISH.
And in most of the other links it is partially in English - there are still other languages around ...is why I ask the community here.
I own at least 25 430 boards, you can see the Xmas tree from last year https://www.facebook.com/juergen.pintaske.3/videos/g.1470449089921787/10211886240457125/?type=2 made by most of them. And see them in light further down.

I am trying to find out what has been done already for the Tiny13 and the Tiny2313, the chips below the Arduino, where it would be AMForth.And somewhere on github. for example.

[JUERGEN]

Just see it as a game or killing time or a learning experience when on the train.
Might be the wrong target audience here, but my reason was to ask the ones who might know Forth solutions for such a project, unfortunately no solutions suggested yet, but I am still keeping my fingers crossed.

It is not targeted at being a better ST ARM M4 or more.
I do have other options, but this is not the point here.
The target chip of interest here is either the ATTINY13a or the 2313 - this is the question - and any other options are not of interest in this context and should be dealt with in another thread..

[JUERGEN]

Do you use your devsystem in the target application?
What do you do if you need 2 or more application systems then?

[minf...@arcor.de]

This suggests an older Arduino Uno?

[JUERGEN]

Unfortunately no Arduinos here as the Programming Technique is different.
As stated before 13 or 2313.

[Cecil Bayona]

No Arduino has a ATTINY13 or a 2313 device as those chips are too tiny
to support the Arduino platform. The ATTINY13 has 1KB of FLASH memory,
the ATTINY 2313 has 2KB of FLASH not even big enough to have the Arduino
Boot loader installed.

Unfortunately I missed the early part of this thread, I delete messages
as my mail program tends to choke on too many emails. So I'm not 100%
sure what the original solution desired was.

--
Cecil - k5nwa

[rickman]

The original post is included in yours, so what did you miss? I don't think
Juergen is looking for any particular solution rather than just wanting to
know what is out there. He has some very minimal chips and wants to know
what means there is to program them without using a special connection. I
guess he missed all the USB programmable boards or doesn't like them because
they require an extra chip for the interface.

[JUERGEN]

Sorry Rick,
I have the STMs, probably 10 USBtoTTLs, LP1114 is running Forth as well, MSP430 you can see the MicroBox project at
https://wiki.forth-ev.de/doku.php/en:projects:microbox:start
Including the IP solution on an FPGA with USB Interface.

I phrase it again:
I S
T H E R E
A
C R O S S C O M P I L I N G F O R T H
F O R
T H E S E
C H I P S

[minf...@arcor.de]

W H I L E Y O U ' R E A T I T : W E W A N T F O R T R A N T O O !!

[JUERGEN]

Forth and Fortran are so old / settled - there must be a few Fortrans written in Forth and with all of the TUV approvals - might be buried so a lot of digging ...

[minf...@arcor.de]

You might read the classic Aho/Sethi/Ullmann compiler book (dragon book)
for leisure. It is full of anecdotes about the first FORTRAN compilers
dealing with its grammar complexities.

And then came Forth as a small and simple 1-pass compiler....
No lispy VM, no WAM, no parser-generators or ASTs...

Of course this was against all TÜV regulations. :-)

[Cecil Bayona]

On 8/25/2017 3:53 PM, minf...@arcor.de wrote:

>>>>> Cecil Bayona wrote on 8/25/2017 11:13 AM:
>>>>>> On 8/25/2017 8:27 AM, minf...@arcor.de wrote:

>>>>>> No Arduino has a ATTINY13 or a 2313 device as those chips are too tiny to
>>>>>> support the Arduino platform. The ATTINY13 has 1KB of FLASH memory, the
>>>>>> ATTINY 2313 has 2KB of FLASH not even big enough to have the Arduino Boot
>>>>>> loader installed.
>>>>>>
>>>>>> Unfortunately I missed the early part of this thread, I delete messages as
>>>>>> my mail program tends to choke on too many emails. So I'm not 100% sure what
>>>>>> the original solution desired was.
>>>>>
>>>>> The original post is included in yours, so what did you miss? I don't think
>>>>> Juergen is looking for any particular solution rather than just wanting to
>>>>> know what is out there. He has some very minimal chips and wants to know
>>>>> what means there is to program them without using a special connection. I
>>>>> guess he missed all the USB programmable boards or doesn't like them because
>>>>> they require an extra chip for the interface.
>>>>>
>

I did not know which was the original Post and since I delete post that
are not of interest at that time I had no clue which was the original post.

In any case all I know is generic solutions, my preferred solution would
be to have a cross compiler tethered to the target board through a
serial port.

But since I have not used AVR Forth compilers very much I'm not aware
what is out there available, I don't recall seeing a tethered cross
compiler for the AVR family other than SwiftX, and MPE versions but then
I have not paid attention, for the AVR I use Assembler, Arduino, or
Pascal platforms to program those devices. There are a free version of
SwiftX cross compiler but it takes too much RAM, The MPE AVR version is
not free but in any case it takes too much FLASH, so neither of these
will work.

I did try it out the SwiftX AVR version a few years ago and it worked
well but I used it on the larger chips in the AVR family.

--
Cecil - k5nwa

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> Do you use your devsystem in the target application?
> What do you do if you need 2 or more application systems then?

I'm a little confused: if I want a separate dev system I'd use a laptop
rather than a dev board if I could. Part of the attraction of Forth is
to run the dev system directly on the target, though cross compilers are
useful of course. I'm not sure why the Tiny13 and 2313 are that
interesting since the ATTiny85 is much more popular for small hobby
boards. It has 8k of flash and 0.5k of ram, which is marginal for a
resident Forth but could be ok as a cross compiler target.

These days I can't think of a reason to use AVR instead of ARM in
non-production quantities, except for possible special hardware
requirements that might come up.

[Lars Brinkhoff]

Cecil Bayona writes:
> There are a free version of SwiftX cross compiler but it takes too
> much RAM, The MPE AVR version is not free but in any case it takes too
> much FLASH, so neither of these will work.

How much RAM and flash?

I have something in the works that supports a subset of the standard
CORE wordset. It needs less than 1K flash.

[Paul Rubin]

Lars Brinkhoff <lars...@nocrew.org> writes:
> Cecil Bayona writes:
>> SwiftX cross compiler... takes too much RAM, The MPE AVR
>> version... takes too much FLASH, so neither of these will work.

> How much RAM and flash?

And does that mean ram or flash on the machine where the compiler is?
If that's the case just use a bigger one? Or does it mean flash on the
target, i.e. there is some kind of largish interpreter or library that
has to be resident there?

> I have something in the works that supports a subset of the standard
> CORE wordset. It needs less than 1K flash.

You mean on the target? If you're writing a compiler, why not generate
machine code, or write a very simple VM for better code density? That
should use very little flash, not counting the translated user code.

And, why even care about the AVR? I lost interest in it a few days ago
when I noticed the Adafruit M0 Gemma (and now the Trinket). There are
even cheaper ARM boards around but these felt like they put the nail in
the coffin.

If you *do* care about the AVR, why the Tiny13? The Tiny85 has far more
resources in the same small packages while being almost as cheap. The
Tiny10 (with even less resources than the 13) might have some attraction
because of its 6-pin package, if you're not up for hand soldering WLCSP
parts.

[Cecil Bayona]

> 5K of Flash and a little bit under 1K of RAM but that includes
multitasking and other feature that may not be needed, and that compiler
has a feature that removes unused code so one could end up with a pretty
small core. The ATTINY2313 might be a better option since there is also
a ATTINY4313 with 4K of FLASH that has the same pin out but all these
devices are really deficient in the RAM arena.

--
Cecil - k5nwa

[Cecil Bayona]

On 8/26/2017 12:52 AM, Paul Rubin wrote:
> Lars Brinkhoff <lars...@nocrew.org> writes:
>> Cecil Bayona writes:
>>> SwiftX cross compiler... takes too much RAM, The MPE AVR
>>> version... takes too much FLASH, so neither of these will work.
>> How much RAM and flash?
>
> And does that mean ram or flash on the machine where the compiler is?
> If that's the case just use a bigger one? Or does it mean flash on the
> target, i.e. there is some kind of largish interpreter or library that
> has to be resident there?

The SwiftX compiler can have a resident compiler for around 5K of FLASH
but it can also have a stripped down core to just run the application
which can be quite smaller. The actual optimizing compiler resides on a
PC and downloads to the target application CPU either a resident Forth
compiler or a stripped down application. It does have size limits but it
doesn't apply for this application.

>
>> I have something in the works that supports a subset of the standard
>> CORE wordset. It needs less than 1K flash.
>
> You mean on the target? If you're writing a compiler, why not generate
> machine code, or write a very simple VM for better code density? That
> should use very little flash, not counting the translated user code.
>
> And, why even care about the AVR? I lost interest in it a few days ago
> when I noticed the Adafruit M0 Gemma (and now the Trinket). There are
> even cheaper ARM boards around but these felt like they put the nail in
> the coffin.

I came to the same conclusion and stopped using AVR CPUs and use either
ARM or MSP430 for most projects, but I'm keeping an eye on the dsPIC family.

>
> If you *do* care about the AVR, why the Tiny13? The Tiny85 has far more
> resources in the same small packages while being almost as cheap. The
> Tiny10 (with even less resources than the 13) might have some attraction
> because of its 6-pin package, if you're not up for hand soldering WLCSP
> parts.
>

The ATTINY85 with 8K of FLASH was actually cheaper for a while than the
ATTINY13 but now the volume is not as high so the prices have gone up.

--
Cecil - k5nwa

[Lars Brinkhoff]

Paul Rubin wrote:
> Lars Brinkhoff wrote:

>> Cecil Bayona wrote:
>>> SwiftX cross compiler... takes too much RAM, The MPE AVR
>>> version... takes too much FLASH, so neither of these will work.
>> How much RAM and flash?
> And does that mean ram or flash on the machine where the compiler is?
> If that's the case just use a bigger one? Or does it mean flash on
> the target, i.e. there is some kind of largish interpreter or library
> that has to be resident there?

On the target. I'm assuming a cross compiler host will not be resource
constrained.

>> I have something in the works that supports a subset of the standard
>> CORE wordset. It needs less than 1K flash.
> You mean on the target?

Yes.

> If you're writing a compiler, why not generate machine code, or write
> a very simple VM for better code density? That should use very little
> flash, not counting the translated user code.

I do generate machine code. Did you think otherwise?

The reason there is a requirement on flash size, is that the generated
code makes calls to a run-time kernel. To conserve space, I don't
inline code which is larger than a CALL instruction.

> And, why even care about the AVR?

I don't particularly. I'm just writing a compiler because it's fun.

Presumably some people do want to use these very low-end devices. I
think they should be able to use Forth if they like.

[JUERGEN]

Thank you very much for the suggestions.
If you work for a company there is a target spec for a project - and then you do the work. You might want to convince the team to use a better processor - but a no is a no.
Not much different here:
The system based on Tiny 13 exists. I have a few.
The web-based Infrastucture exists.
Editor, Assembler C exist - all out there
Forth???? - I try to get it added - is there anything out there already?
It seems that one of the articles in A Start With Forth is at least a starting solution https://www.amazon.co.uk/Start-Forth-2017-Bits-Bites-ebook/dp/B073NMX1XP/ref=sr_1_13?s=books&ie=UTF8&qid=1499278235&sr=1-13 - the 3 word Forth Interface. Actually I had the Sparrow as well in mind when I included it.
But there must be something better. Today is the monthly Forth meeting - are there any people that have the knowledge about an existing better solution or discuss a possible solution?

[JUERGEN]

On Saturday, August 26, 2017 at 7:23:25 AM UTC+1, Cecil - k5nwa wrote:

I had asked Leon, if there is an option to use Swiftforth in this context, as there is some AVR on their website, and he mentioned as well the 5 k minimum on-chip.
There is a solution with even on-chip Forth for the 2313 from a Japanese source. I tried to contact her/him, but no answert yet.
http://middleriver.chagasi.com/electronics/tforth.html
I wonder if anybody here tried this yet, but still no solution for the ATTINY13a and Sparrow.

[Lars Brinkhoff]

Paul Rubin wrote:
> And, why even care about the AVR? I lost interest in it a few days ago
> when I noticed the Adafruit M0 Gemma (and now the Trinket).

Are the Cortex-M parts easy to hook up? AVR is supposedly very easy to
get up and running. Only a few pins to connect, I hear.

What about power requirements? Are there Cortex-M devices that can
match 8-bit and 16-bit devices?

[JUERGEN]

Lars, if you have a surface mount production line, the choice is wide.
If not, you have only 2 options:
DevKit, Small Application Board, Adafruit or similar
or you go the route of Dual in Line Chips. The the choice is limited.
AVRs, 430G2553, or as ARM LP1114 to my knowledge.
I assume the TI MSP430G2553 is the lowest power option then.

[Lars Brinkhoff]

JUERGEN writes:
> or you go the route of Dual in Line Chips. The the choice is limited.
> AVRs, 430G2553, or as ARM LP1114 to my knowledge.
> I assume the TI MSP430G2553 is the lowest power option then.

I did check that, and it seems some Cortex-M flavour is available in a
DIP package.

[Cecil Bayona]

I used to use AVR devices because they were available in DIP packages so
it was easy to breadboard something quickly, with a built oscillator you
could build a CPU with the device and a couple of filter caps, the ARMs
not so, I have to buy ready made boards as breaboarding with SMD devices
is a lot more complex, but ARM boards can be had for a couple of dollars.

As far as I know there is a small M0 part available in DIP form, I have
never used a M0 part, M3 at the smallest and usually an M4 is what I
prefer to use for quick breadboarding, so I use ARM boards.

I now will use a PIC18 or a dsPIC instead of AVR devices, plenty of
those are available in DIP format and I use Pascal or C to program the
thing but mostly I stick to ARM boards. I don't know of any cross Forth
compiler for PICS and dsPICS which is what I would prefer to use, but
I'm fairly comfortable with Pascal I don't breadboard very much anymore
with anything other than ARM boards, so no big hurry to find the software.

--
Cecil - k5nwa

[Lars Brinkhoff]

Cecil Bayona wrote:
> I don't know of any cross Forth compiler for PICS and dsPICS which is
> what I would prefer to use

There's a picforth for PIC16.

[Cecil Bayona]

I'm aware of it but it's hosted on Linux and my main OS is Windows, and
the lowest PIC is would use is the PIC18, one has to place a limit
otherwise one is overwhelmed with too many choices. The PICs I have in
my stock are PIC18, PIC24, and dsPICs with the last two as my choice if
possible.

My cup of Windows BS is fast filling up and one day I might start
switching my PCs to Mint Linux, but that day is not today, several of my
top end CPUs have dual OS with Linux Mint LTS installed, at this point I
would say 95% of my software will run in Mint, but it's that last 5%
that makes it hard, I spent a lot of money on Adobe Photo Processing
software to throw it away. In Mint I been playing with VirtualBox and
that is working well so Microsoft better watch themselves their future
is not that secure at my house.

--
Cecil - k5nwa

[Cecil Bayona]

AVRs are low power, inexpensive, and easy to use and program, and there
is a wide choice of DIP versions.

PICs are low powered, and has the largest available line of DIP devices
available of all the IC makers, including some high end PIC24, and dsPIC
devices that are inexpensive. The PIC24 and dsPIC devices have a decent
instruction set for use with Assembler, Forth, or other high level
languages.

MSP430 are low powered and easy to use, and wonderful to program in
Assembler, Forth, or other high level languages.

In the US a small ARM3 board with 128K to 512K of FLASH can be had for a
couple of dollars from China. For less than $11 for a more local source
you can get an M4 CPU with 1MB of FLASH. I'm not sure of the market in
Europe most likely it will cost more. So for me it's hardly worth the
expense of buying a chip and build something from scratch.

If I were to build something for reselling I would most likely use a
ready made ARM board for development and when things are working design
an ARM board, it might be CPU overkill but the price is right. Also
something else in favor of an ARM is that massive CPU power and lots of
FLASH makes development a little easier, and there is plenty of room for
future upgrades to the product.

The problem is that there are too many good devices to use but one can't
use them all as the learning needed is massive so I came to the
conclusion that I had to keep the choices down, I picked ARM and MSP430
but your choice might be different.

--
Cecil - k5nwa

[rickman]

I wonder what it would take to emulate an MSP430 on a GA144? GA did a paper
comparison between power use of an MSP430 and the F18A in the GA144. They
did pick one of the older MSP devices so the GA144 looked pretty good. I
wonder if it has to execute MSP430 opcodes if it still comes out on top?

It would be an interesting task to partition and program.

[rickman]

Cecil Bayona wrote on 8/26/2017 10:56 AM:
> On 8/26/2017 4:37 AM, Lars Brinkhoff wrote:
>> Paul Rubin wrote:
>>> And, why even care about the AVR? I lost interest in it a few days ago
>>> when I noticed the Adafruit M0 Gemma (and now the Trinket).
>>
>> Are the Cortex-M parts easy to hook up? AVR is supposedly very easy to
>> get up and running. Only a few pins to connect, I hear.
>>
>> What about power requirements? Are there Cortex-M devices that can
>> match 8-bit and 16-bit devices?

Cortex M0 devices are intended to be low cost and low power. I don't know
details of what the smaller chips can do, but I believe the CM0 ARMs are in
the same ballpark for power.

> I used to use AVR devices because they were available in DIP packages so it
> was easy to breadboard something quickly, with a built oscillator you could
> build a CPU with the device and a couple of filter caps, the ARMs not so, I
> have to buy ready made boards as breaboarding with SMD devices is a lot more
> complex, but ARM boards can be had for a couple of dollars.
>
> As far as I know there is a small M0 part available in DIP form, I have
> never used a M0 part, M3 at the smallest and usually an M4 is what I prefer
> to use for quick breadboarding, so I use ARM boards.

Google is your friend. I found an 8 pin LPC810 and a 28 pin LPC1114 at
Mouser and Digikey as well. Google also has mention of a 40 pin DIP device,
but that didn't show at the distis.

[JUERGEN]

I found this comparison App Note actually not very useful, as it was not tied to any useful application.
It looks more like a test chip.
I just wonder why nobody has done at least GA1 in FPGA. Then RAM and Flash are free to adapt, and connecting multiples is done for many ARMs now.
Who has seen a real application running on GA144 yet?
Just listen to James Bowman at about 1h30. GA144 is better for C than for Forth.
https://www.youtube.com/watch?v=inlwcTCEXRk&feature=em-lss

[JUERGEN]

MPE Forth Lite is running on my LP1114 in 28 Pin DIL.

for 8Pin ARM http://blog.nano-age.co.uk/2014/07/lpc810-little-8-pin-dip-arm-mcu.html
this then needs an eForth at least, as there are only 4k Flash or a cross compiler.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> If you work for a company there is a target spec for a project - and
> then you do the work.

There a part missing: you do they work, and they pay you ;-). It sounds
like an Attiny13 Forth is something nobody wanted enough to either do it
themselves or pay someone else.

> The system based on Tiny 13 exists. I have a few.

Tiny85 is really a more popular and realistic target.

> - the 3 word Forth Interface.

Do you mean Frank Sergeant's 3-instruction Forth? It's cute but it's
basically an asm-language boot loading stub.

Two approaches to Forth on the tiny13:

1) compile native code

2) run an address interpreter or bytecode vm on the tiny13 and download
threaded or byte code to it.

I don't know of any Forth to AVR native code compiler so #1 would be a
big project.

#2 would be another tethered Forth. I don't know of any out there
but maybe it could be adapted from Amforth or something like that.

If your idea is still to have an easy to use Forth for teaching embedded
programming, it's probably best to start with a more powerful and
standardized board. BBC MicroBit, Arduino, that sort of thing. I don't
understand why you think the Tiny 13 is worth anyone's effort. Who even
has a Tiny 13 board except you?

[Paul Rubin]

Lars Brinkhoff <lars...@nocrew.org> writes:
>> Or does it mean flash on the target, i.e. there is some kind of
>> largish interpreter or library that has to be resident there?
>
> On the target. I'm assuming a cross compiler host will not be resource
> constrained.

Oh cool, that's the part that wasn't clear. Yes if it's a cross
compiler, that obviously gets rid of size constraints for the compiler,
and even the 1k flash on the target sounds like a lot.

> Presumably some people do want to use these very low-end devices. I
> think they should be able to use Forth if they like.

Nice!

[Paul Rubin]

Lars Brinkhoff <lars...@nocrew.org> writes:
> Are the Cortex-M parts easy to hook up? AVR is supposedly very easy to
> get up and running. Only a few pins to connect, I hear.

Well, those cheap small boards are available. I dunno about starting
from a bare chip.

> What about power requirements? Are there Cortex-M devices that can
> match 8-bit and 16-bit devices?

Yes, the AVR is actually something of a power hog. The 430 might be
competitive with the M0.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> On Saturday, August 26, 2017 at 11:29:12 PM UTC+1, rickman wrote:
>> I wonder what it would take to emulate an MSP430 on a GA144?

That would be unrealistic imo. You'd need a bunch of GA nodes just run
the 430 instruction set, you'd need a node for the 16 byte-addressible
registers, you'd have to get at the bytes by shifting, you'd need
off-chip program flash, etc.

> I just wonder why nobody has done at least GA1 in FPGA.

That's called a B16 ;-).

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> I found an 8 pin LPC810 and a 28 pin LPC1114 at Mouser and Digikey as
> well. Google also has mention of a 40 pin DIP device, but that didn't
> show at the distis.

If you can deal with a largish DIP package, check the Teensy 3.x
development boards at pjrc.com

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> I guess he missed all the USB programmable boards or doesn't like them
> because they require an extra chip for the interface.

There are lots of ATTiny85 boards that communicate by USB using software
bit banging. This is probably the best known:

http://digistump.com/products/1

[JUERGEN]

On Saturday, August 26, 2017 at 11:29:12 PM UTC+1, rickman wrote:

I would prefer it the other way around. Have the 430 chip emulate a GA1,
this should just take a page or 2 of Forth?
And then add additional GAs as the application requires, and throw a free multitasker in - still a 20 pin DIL ...
Or if not enough memory, there are sufficient ARM boards around, I like the ST board range.
And if this 430 runs out of memory - well I have 25x 430 boards waiting for an application.

[JUERGEN]

Agreed, but it seems nobody here has tested it in an FPGA - neither of the 2 versions, at least not said anything about it.

[JUERGEN]

Paul, there are more than just one project:
- I assume you have seen my microbit Mecrisp tread and now updated with Calliope.
- This one here is lower level, and if there is no Forth option, then nothing changes really - the rest is there already.
- I just have to wait and SIMPL and Lars as options.
And just to highlight it again: Two options for this project:
13a or
2313 - nothing else.
Why not? Only those two can be programmed directly with the implemented environment via the the web.
And for 2313 there is a Forth option already. https://wiki.forth-ev.de/doku.php/attiny
See manual at http://www.ak-modul-bus.de/cgi-bin/iboshop.cgi?showd20!0,694364494580736,Sparrow

I think actually two. There is a Japanese option.

[JUERGEN]

Sorry Paul, the Headline Has Not Changed:
Program Chip directly via Internet - ATTINY – Tiny 13 and Tiny2313 –- Sparrow

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> Program Chip directly via Internet - ATTINY – Tiny 13 and Tiny2313 –-
> Sparrow

I don't see anything impeding making a similar software modem for the
tiny85 or other chips. That's probably easier than writing a Forth for
the tiny13. Don't forget most phones also have bluetooth, which brings
back the Microbit.

I'm still having trouble with the idea that someone who doesn't want to
use a PC will want to program an embedded dev board, but whatev.

[rickman]

Paul Rubin wrote on 8/27/2017 5:12 PM:
> JUERGEN <epld...@aol.com> writes:
>> On Saturday, August 26, 2017 at 11:29:12 PM UTC+1, rickman wrote:
>>> I wonder what it would take to emulate an MSP430 on a GA144?
>
> That would be unrealistic imo. You'd need a bunch of GA nodes just run
> the 430 instruction set, you'd need a node for the 16 byte-addressible
> registers, you'd have to get at the bytes by shifting, you'd need
> off-chip program flash, etc.

What is unrealistic about that? You just explained a lot of what needs to
be done. Sounds very realistic to me.

[rickman]

> I would prefer it the other way around. Have the 430 chip emulate a GA1,
> this should just take a page or 2 of Forth?

Not any real reason to do that when the GA144 is only $15 and the MSP430
would run the GA144 code probably 100 to 1000 times slower. The GA144 is
emulated on a PC by way of the simulator, so why use an MSP430???

> And then add additional GAs as the application requires, and throw a free multitasker in - still a 20 pin DIL ...

You mean emulate the GA144's many fast processors in a single slow MSP430
processor? I see absolutely no utility in that. If you want to emulate the
GA144 use a PC. The program is already written and works and will run at an
adequate speed with a real UI.

> Or if not enough memory, there are sufficient ARM boards around, I like the ST board range.
> And if this 430 runs out of memory - well I have 25x 430 boards waiting for an application.

Go for it. Let us know how it works out.

[rickman]

I'm not the one looking for DIP MCUs. I have no reason to use them. I'm
happy with boards like the TI launchpads.

[rickman]

It all depends on the application. There are applications where the bulk of
the power is used during wait times when the CPU is doing nothing. Then the
power down or power save current dominates. It's not always about the power
used when the CPU is running flat out.

[rickman]

JUERGEN wrote on 8/27/2017 8:52 AM:
>
> I found this comparison App Note actually not very useful, as it was not tied to any useful application.
> It looks more like a test chip.

Not sure what you mean by "it". Are you saying the GA144 looks like a test
chip? What does that mean???

> I just wonder why nobody has done at least GA1 in FPGA. Then RAM and Flash are free to adapt, and connecting multiples is done for many ARMs now.

I asked GA if they had any heartburn if I did an HDL F18A CPU and they said
they couldn't stop me, but I could not use their software to program it.
Not much point is designing a CPU without tools and I didn't feel like
designing my own toolset.

> Who has seen a real application running on GA144 yet?

Not me. When I asked for detailed timing data on some of the I/O
capabilities I was told it was too much work to produce the data and they
thought I probably was trying to reverse engineer their designs.

> Just listen to James Bowman at about 1h30. GA144 is better for C than for Forth.
> https://www.youtube.com/watch?v=inlwcTCEXRk&feature=em-lss

I don't think that's what he said, but I didn't catch the context. He said,
"With all of its hopping around it's not actually completely suitable for
Forth". He was point to some code and I don't know he was talking about the
GA144 rather than that particular code. It would require listening to a lot
more of the presentation.

[JUERGEN]

Just listen to James's presentation again. How true such a judgement is I cannot say, but he is probably the one closest to the chip.

It seems the GA144 is not fully speced - as you confirm - so it is a tst chip - and still testing now.
My background is at RCA, Hitachi, and others,; if a chip is not fully speced - how can a reliable application be done by a customer.

It seems this chip is in the deepfreeze and I fear it will stay there unfortunately.

If I look at Forth, one man developing it , and many have done theit own implementations - success
If you look at F18A and it's successors - mainly one man behind it as well. Brilliant idea, much ahead of its time when invented. Now there are manyARMs.
Not fully specified - so a test chip to check a new technology.

Not use their software? if you bought it you can use it, if it is free as well - I do not see the point and have no similar comparison in the industry.

[JUERGEN]

If money was driving me, I would not have done the Forth Bookshelf https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM.
The chip price is not the real cost - you need a board with RAM to have a running system - but this is not the point.

I want to see if possible what the GA1 wound be written in Forth. Then it could run under any, the VFXTESYAPP.exe if free for download and part of the A Start With Forth https://wiki.forth-ev.de/doku.php/en:projects:a-start-with-forth:start0

And if available it can run on VFX 430 LITE, part of the same ebook = and I have my GA1 - speed I do not care - learning how it works is the interest - and being able to see all of the registers if I want.
Basically a TestChip on a Test Bench - nothing commercial behind it.
You mentioned the issue with using your potential chip with GA Software the way I want it is completely independent.

And it might take a couple of years if I do it myself,
and probably an afternoon if Bernd does it over a coffee,
probably just small mods to the b16 ...

[JUERGEN]

It seems you have not looked at the background:
there is no modem, there is no software in the chip.
Stick the 3 pin connector into the tablet, a little bit of hardware and a virgin chip, see http://www.ak-modul-bus.de/cat/documentation/Sparrow_Manual_English_v6_Partial_A5.pdf
as said before
page 4 shows the hardware - this is the interesting bit - at least for me - absolute minimum - not even a bootloader.
If you want to go down to a bare chip and start there - I have seen nothing similar yet. Is it important, actually for me it is fun.
Bluetooth, USBtoTTL - been there done that - got the T-Shirt, actually have now my own Forth T-Shirt with the Forth Bookshelf on it ...
Actually just go to another thread of mine - microbit and now Calliope as well.
Or read the microbit book I translated https://www.amazon.co.uk/BBC-Micro-Tests-Tricks-Secrets/dp/1541200721/ref=asap_bc?ie=UTF8

[JUERGEN]

If you are having trouble - I feel really sorry for you.
This product exists and can be bought and used now.
Nobody is impeding anybody to do what they like and write new software.

I started this thread to ask for help and advice.
Not to hear about different mouse traps ...

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> It seems you have not looked at the background:
> there is no modem, there is no software in the chip.

By modem I just mean that audio signals are demodulated into data. In
your link it looks like they do it with a comparator feeding into a
digital pin, which is a crude approach that uses an extra part, but I
guess it can work.

> page 4 shows the hardware - this is the interesting bit - at least for
> me - absolute minimum - not even a bootloader.

Hmm, you mean they get a bit stream out of the comparator that's able to
do the low level programming to flash the tiny13? That is pretty cute.
I wonder how many phones can control the output waveform enough for
that.

Still I gotta think it's easier to use an Atmega-like approach where
there's a protected boot loader programmed through a messier process,
but that's quite hard to clobber by accident.

[Albert van der Horst]

In article <a6f056af-e478-453e...@googlegroups.com>,
JUERGEN <epld...@aol.com> wrote:
<SNIP>
>It seems you have not looked at the background:=20
>there is no modem, there is no software in the chip.=20
>Stick the 3 pin connector into the tablet, a little bit of hardware and a v=
>irgin chip, see http://www.ak-modul-bus.de/cat/documentation/Sparrow_Manual=
>_English_v6_Partial_A5.pdf=20
>as said before
>page 4 shows the hardware - this is the interesting bit - at least for me -=

> absolute minimum - not even a bootloader.

At first I was impressed, but now I see the hardware.
That is quite complicated. Now you need a circuit that is large
as the microcontroller itself.

The following is really minimal.
I've made a contraption to program a virgin MSP430 (say a launchpad
with a botched boot loaded and a destroyed suv chip) from
a parallel port on a pc-chip. The cable you must make yourself.
Modify a printer cable by soldering 4 single dip headers to the
end of a printer cable. Insert 100 ohm resistors for protection.
Or just solder 4 wires to the print via a resistor.
(That includes power for the MSP430.)

The software is complicated, but who cares? In particular it must do a
9600 baud timing, and a first timing that is based on measuring what
the chip returns. You need a fast pc, preferably multi core.
The project was really fun, until I discovered that TI changes
the spec's willy nilly for new versions of the MSP430.

One needs a real parallel port, something via USB will not do, obviously.


<SNIP>

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

[JUERGEN]

There is the Low-Cost-Version in the eBook with just 2 resistors or two capacitors to get started. But not as reliable and device dependent - explained in length.
https://www.amazon.co.uk/Cheepit-Sparrow-Programming-Mobile-Phone-ebook/dp/B074G54KRR/ref=asap_bc?ie=UTF8

There are probably other and better solutions
- but this one is the only one for now that I can buy with such an interface and the online tools provided.

Yes, I prefer a local PC solution as well
- but this is NOT the target for this project - here Mobile or Tablet.

[Albert van der Horst]

In article <bb89521c-2fed-45ba...@googlegroups.com>,

Can't find it, in the whole pdf.

>
>There are probably other and better solutions
>- but this one is the only one for now that I can buy with such an interface and the online tools provided.
>
>Yes, I prefer a local PC solution as well
>- but this is NOT the target for this project - here Mobile or Tablet.

I don't say the pc solution is prefereable.
The ideal solution to mass program msp430 is probably a Launcpad
dedicated to it.
Bit banging is an option when all else fails.

[JUERGEN]

This is in the eBook only as stated
- not in the PDF, Product Description English or German,
but I can send you a circuit diagram, just send an email to Jue...@exemark.com
Or hope you can access it at https://www.facebook.com/photo.php?fbid=10214476650575759&set=gm.1768239720142721&type=3 , just placed the circuit diagram there which is included with a lot more explanations on how to get from such a minimum to the final board in https://www.amazon.co.uk/Cheepit-Sparrow-Programming-Mobile-Phone-ebook/dp/B074G54KRR/ref=asap_bc?ie=UTF8

I know this is not the most interesting solution,
but if you are child in South Africa or else and only have access to a mobile phone or a tablet as seems to be the case
- the options are limited and this would work anywhere in the world
- fits very well with my STEM Ambassador Activity hat on.

If you have access to all of the resources - completely different scenario and a TI MSP430 Launchpad or an ARM board is probably the way to go.
Then RPI and Arduino plus many other boards are on the table again.

[rickman]

Not sure what you are getting at.

> It seems the GA144 is not fully speced - as you confirm - so it is a tst chip - and still testing now.

But then no chip is "fully" specified. I was working with an Atmel ARM MCU
and realized they didn't provide full info on the requirements for the
crystal to be used. They sent me info in the form of a table with data at
four frequencies with no indication on pro-rating the values for other
frequencies. There are *many* examples of similar issues with other chips.

> My background is at RCA, Hitachi, and others,; if a chip is not fully speced - how can a reliable application be done by a customer.

They muddle through. It is a common problem that the engineer does not have
100% accurate or complete information on either the requirements or the
devices.

> It seems this chip is in the deepfreeze and I fear it will stay there unfortunately.

That is more about the architectural limitations than any issue with
specification. 64 words of RAM is difficult to work with.

> If I look at Forth, one man developing it , and many have done theit own implementations - success
> If you look at F18A and it's successors - mainly one man behind it as well. Brilliant idea, much ahead of its time when invented. Now there are manyARMs.

I don't know about "ahead of its time". It uses a very different approach
to CPU design where features that are built into hardware in large CPUs are
part of the software in the GA144 or entirely absent. I'd be willing to bet
if you count all the dedicated processing capability in an x86 there are
many more processors than just 144. They are just not all totally
independent. But they have much higher speed communications.

> Not fully specified - so a test chip to check a new technology.
>
> Not use their software? if you bought it you can use it, if it is free as well - I do not see the point and have no similar comparison in the industry.

They don't sell the software, it is free for use with their chips. FPGA
software is this way. You can produce a bitstream using their software
without charge, but you can only use the bitstream to program their chips.
A company that would make ASIC chips from Altera bistreams was run out of
business that way.

[rickman]

That is the reason why bit banging a port is obsolete, it's too hard to find
a PC port. Instead most use a USB interface chip that can both provide a
JTAG interface and serial port. The JTAG interface allows an MCU to be cold
programmed and the serial port allows debugging of the user program. Or
some just use the serial port and a ROM bootloader that can't be bricked.
The serial port control lines are used to reset the MCU being programmed.
This is cheap enough that the USB chip is often included on the target board.

[rickman]

Of course it is possible to write an F18A simmulator in Forth, it has
already been done as I indicated. There is an simulator as part of the
GA144 tools. What else do you need?

> And if available it can run on VFX 430 LITE, part of the same ebook = and I have my GA1 - speed I do not care - learning how it works is the interest - and being able to see all of the registers if I want.
> Basically a TestChip on a Test Bench - nothing commercial behind it.
> You mentioned the issue with using your potential chip with GA Software the way I want it is completely independent.

I don't see what advantage your idea would have in any sense. You will need
to write your own development tools as GA won't give permission to use
theirs on your MSP430 I expect.

If you want to see the F18A registers you just need to use the simulator GA
provides. I think there might be another simulator written by someone else
as well.

> And it might take a couple of years if I do it myself,
> and probably an afternoon if Bernd does it over a coffee,
> probably just small mods to the b16 ...

??? The B16 is an entirely different design and does not have a simulator
that I am aware of. It is an HDL design that can be run in an FPGA or built
into an ASIC. It would not be at all hard to code an F18A in HDL. Maybe
I'll work on that later and see if I can do a first pass. The comms is the
only tricky part as it is *very* complex and making a design that duplicates
the timing might be difficult, but maybe not too hard. The GA144 is a bit
of work as it has some dozen different types of F18A with different I/Os. I
guess that can be a separate module bolted onto the CPU.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> I know this is not the most interesting solution,
> but if you are child in South Africa or else and only have access to a
> mobile phone or a tablet as seems to be the case

That is a weird scenario. The child probably needs vaccinations,
nutrition, and sanitary living conditions much more than anything to do
with computers. Anyway, what the heck do they want with a
microcontroller board of any sort, if they have a tablet, or better yet
a laptop? They can program the tablet/laptop directly.

Also, most phones and tablets these days support USB OTG. So a teeny
little cable adapter will let them run many of the regular cheap dev
boards.

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>>>> I wonder what it would take to emulate an MSP430 on a GA144?

>> That would be unrealistic imo. You'd need a bunch of GA nodes...

> What is unrealistic about that? You just explained a lot of what
> needs to be done. Sounds very realistic to me.

Oh ok, I thought the emulation idea was to get the supposedly better
power efficiency of the GA. But you'll definitely dissipate that and
then some, if you take factors of 100 or more in emulation overheard.

If you do want to go that route, simplest might be to write your MSP
emulator in Polyforth, which runs on a VM that's burnt into ROM on a few
of the GA nodes for the purpose. I never figured out the instruction
set and it doesn't seem documented, but the source code (written in
the obscure Colorforth style you'd expect) is in one of the GA downloads.

[rickman]

Paul Rubin wrote on 8/31/2017 12:21 AM:
> rickman <gnu...@gmail.com> writes:
>>>>> I wonder what it would take to emulate an MSP430 on a GA144?
>>> That would be unrealistic imo. You'd need a bunch of GA nodes...
>> What is unrealistic about that? You just explained a lot of what
>> needs to be done. Sounds very realistic to me.
>
> Oh ok, I thought the emulation idea was to get the supposedly better
> power efficiency of the GA. But you'll definitely dissipate that and
> then some, if you take factors of 100 or more in emulation overheard.

Yeah, 100x loss of efficiency would be pretty bad. I'm not even sure how
you might produce such a bad emulation. I guess every instruction you
define might include a spin loop to waste time and power.

> If you do want to go that route, simplest might be to write your MSP
> emulator in Polyforth, which runs on a VM that's burnt into ROM on a few
> of the GA nodes for the purpose. I never figured out the instruction
> set and it doesn't seem documented, but the source code (written in
> the obscure Colorforth style you'd expect) is in one of the GA downloads.

No, I don't think running a Forth program in Polyforth would get as bad as
100x loss of efficiency. You need to try harder.

[Albert van der Horst]

If is much worse than that. It is impossible to make a working
equivalent that goes beyond a demonstration of the MSP320
instruction set. Even if it were possible nobody in his right mind
would even attempt.

On its own the MSP430 can be programmed to be extremely low power,
easily beating the GA144 in practical applications.

From
http://home.hccnet.nl/anij/nof/noforth.html
you can find the Hedgehog and from there you arrive at
the following site with numerous application notes for noforth
running on the MSP430

At
https://noforth.bitbucket.io/site/egel%20for%20launchpad.html#e05x
Willem Ouwerkerk starts his low power applications.
Those applications, far below 1 uA , already are under the self
discharge of normal batteries.

A typical example is a RC5 infrared receiver, example number 53.
If you want to make something equivalent on a GA144 you need at least
to hook up a 32 Khz crystal. Wake up! Despite rumors that the GA144
could synchronize with a crystal, after all those years there is
still no application note.

>--
>
>Rick C
>

Groetje Albert

[rickman]

A single MSP430 idling will beat the GA144 with all 144 processors idling (<
1 uW vs 13 uW typ). If the app is not dominated by the idling current I
don't think the processing capability per watt is nearly as high in the
MSP430.

> From
> http://home.hccnet.nl/anij/nof/noforth.html
> you can find the Hedgehog and from there you arrive at
> the following site with numerous application notes for noforth
> running on the MSP430
>
> At
> https://noforth.bitbucket.io/site/egel%20for%20launchpad.html#e05x
> Willem Ouwerkerk starts his low power applications.
> Those applications, far below 1 uA , already are under the self
> discharge of normal batteries.

Yes, these apps have the processor doing *very* little, *very* seldom. So
the power is dominated by the static current when the processor is doing
nothing. The GA144 is not a good fit for apps that require so little
processing capability. In other apps where the power used with processing
actually registers on the battery, the GA144 can hold its own... provided
CPUs aren't used with timing loops sucking down 7 mW.

> A typical example is a RC5 infrared receiver, example number 53.
> If you want to make something equivalent on a GA144 you need at least
> to hook up a 32 Khz crystal. Wake up! Despite rumors that the GA144
> could synchronize with a crystal, after all those years there is
> still no application note.

F18A oscillators are not a good idea for low power. At very least they
require a lot of power to get the crystal oscillating and stabilized.
That's not good if the design requires the device to power down frequently.

I believe there are examples of working oscillators with the GA144 though.
It was the 10 MHz oscillator that Chuck didn't get working. Hitting the
right point of pinging a 10 MHz oscillator with a timing loop is a bit
tricky when the timing varies so much with temperature. I'm pretty sure
someone has a 32 kHz oscillator working. I think part of Chuck's problem
was wanting to do it with a minimum of pins and parts.

I believe an RC5 receiver would be a pretty easy task on a GA144 or even a
GA4 as long as a clock signal is provided. Otherwise the oscillator node
would be needed.

[Albert van der Horst]

In article <oo9deh$qvj$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>Albert van der Horst wrote on 8/31/2017 5:26 AM:
>> In article <oo868m$sgh$2...@dont-email.me>, rickman <gnu...@gmail.com> wrote:

<SNIP>

>> From
>> http://home.hccnet.nl/anij/nof/noforth.html
>> you can find the Hedgehog and from there you arrive at
>> the following site with numerous application notes for noforth
>> running on the MSP430
>>
>> At
>> https://noforth.bitbucket.io/site/egel%20for%20launchpad.html#e05x
>> Willem Ouwerkerk starts his low power applications.
>> Those applications, far below 1 uA , already are under the self
>> discharge of normal batteries.
>
>Yes, these apps have the processor doing *very* little, *very* seldom. So
>the power is dominated by the static current when the processor is doing
>nothing. The GA144 is not a good fit for apps that require so little
>processing capability. In other apps where the power used with processing
>actually registers on the battery, the GA144 can hold its own... provided
>CPUs aren't used with timing loops sucking down 7 mW.

This contradicts that the GA144 could emulate Willems circuit.

>
>
>> A typical example is a RC5 infrared receiver, example number 53.
>> If you want to make something equivalent on a GA144 you need at least
>> to hook up a 32 Khz crystal. Wake up! Despite rumors that the GA144
>> could synchronize with a crystal, after all those years there is
>> still no application note.
>
>F18A oscillators are not a good idea for low power. At very least they
>require a lot of power to get the crystal oscillating and stabilized.
>That's not good if the design requires the device to power down frequently.
>
>I believe there are examples of working oscillators with the GA144 though.
>It was the 10 MHz oscillator that Chuck didn't get working. Hitting the
>right point of pinging a 10 MHz oscillator with a timing loop is a bit
>tricky when the timing varies so much with temperature. I'm pretty sure
>someone has a 32 kHz oscillator working. I think part of Chuck's problem
>was wanting to do it with a minimum of pins and parts.

That's what I said, rumors.

There is a scrap of paper insided:
"They say that a two handed sword misses".

<SNIP>

>
>--
>
>Rick C

[rickman]

Albert van der Horst wrote on 8/31/2017 12:46 PM:
> In article <oo9deh$qvj$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>> Albert van der Horst wrote on 8/31/2017 5:26 AM:
>>> In article <oo868m$sgh$2...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
> <SNIP>
>>> From
>>> http://home.hccnet.nl/anij/nof/noforth.html
>>> you can find the Hedgehog and from there you arrive at
>>> the following site with numerous application notes for noforth
>>> running on the MSP430
>>>
>>> At
>>> https://noforth.bitbucket.io/site/egel%20for%20launchpad.html#e05x
>>> Willem Ouwerkerk starts his low power applications.
>>> Those applications, far below 1 uA , already are under the self
>>> discharge of normal batteries.
>>
>> Yes, these apps have the processor doing *very* little, *very* seldom. So
>> the power is dominated by the static current when the processor is doing
>> nothing. The GA144 is not a good fit for apps that require so little
>> processing capability. In other apps where the power used with processing
>> actually registers on the battery, the GA144 can hold its own... provided
>> CPUs aren't used with timing loops sucking down 7 mW.
>
> This contradicts that the GA144 could emulate Willems circuit.

Where did anyone say that it could emulate Willems circuit?

>>> A typical example is a RC5 infrared receiver, example number 53.
>>> If you want to make something equivalent on a GA144 you need at least
>>> to hook up a 32 Khz crystal. Wake up! Despite rumors that the GA144
>>> could synchronize with a crystal, after all those years there is
>>> still no application note.
>>
>> F18A oscillators are not a good idea for low power. At very least they
>> require a lot of power to get the crystal oscillating and stabilized.
>> That's not good if the design requires the device to power down frequently.
>>
>> I believe there are examples of working oscillators with the GA144 though.
>> It was the 10 MHz oscillator that Chuck didn't get working. Hitting the
>> right point of pinging a 10 MHz oscillator with a timing loop is a bit
>> tricky when the timing varies so much with temperature. I'm pretty sure
>> someone has a 32 kHz oscillator working. I think part of Chuck's problem
>> was wanting to do it with a minimum of pins and parts.
>
> That's what I said, rumors.

Ok, whatever. I can't see anything that would preclude a 32 kHz oscillator
with the GA144. If I ever get back to working with the device I will make
it my priority to design a crystal oscillator. I just couldn't get past all
the many kludges that had to be learned to actually download code to the
GA144. You had to memorize screen numbers of what was where with multiple
authors and multiple applications. I'd rather switch from my flip phone to
a smart phone!

[Jan Coombs]

On Sun, 27 Aug 2017 05:52:36 -0700 (PDT)
JUERGEN <epld...@aol.com> wrote:

> Just listen to James Bowman
> at about 1h30. GA144 is better for C than for Forth.

My impression from the talk [1], was that the Forth capable
processor that James built out of 4-6 GA144 nodes _may_ be
better as a C target than a Forth target.

Jan Coombs
--
[1] "A Novel Execution Model for GA144"
Michael Schuldt, Mark Flamer, James Bowman
found at ~00:45 to 01:30 in
https://www.youtube.com/watch?v=inlwcTCEXRk&feature=em-lss

[JUERGEN]

Thanks Jan, but I do not understand where the amiguities could be. James says what he says there at about 1h30. If it is correct is a different matter - and I keep out of this. But indepentent of this, I have not seen a fully defined or coded application in GA144 yet from GA, so others can can emulate the same functionality and THEN will be able to compare speed, size, cost, power consumption or else.
It is just unfortunate that after so many years now this is still not available - it seems the interest of the design community is not high enough.

[rickman]

JUERGEN wrote on 9/3/2017 10:54 AM:
> On Sunday, September 3, 2017 at 12:01:30 PM UTC+1, Jan Coombs wrote:
>> On Sun, 27 Aug 2017 05:52:36 -0700 (PDT)
>> JUERGEN <epld...@aol.com> wrote:
>>
>>> Just listen to James Bowman
>>> at about 1h30. GA144 is better for C than for Forth.
>>
>> My impression from the talk [1], was that the Forth capable
>> processor that James built out of 4-6 GA144 nodes _may_ be
>> better as a C target than a Forth target.
>>
>> Jan Coombs
>> --
>> [1] "A Novel Execution Model for GA144"
>> Michael Schuldt, Mark Flamer, James Bowman
>> found at ~00:45 to 01:30 in
>> https://www.youtube.com/watch?v=inlwcTCEXRk&feature=em-lss
>
> Thanks Jan, but I do not understand where the amiguities could be. James says what he says there at about 1h30. If it is correct is a different matter - and I keep out of this. But indepentent of this, I have not seen a fully defined or coded application in GA144 yet from GA, so others can can emulate the same functionality and THEN will be able to compare speed, size, cost, power consumption or else.

Not sure what those qualifications entail, but GA has provided code for
several algorithms and even a 10 Mbps Ethernet interface. What were you
looking for that these don't provide? Do none of these rise to the level of
"application"?

> It is just unfortunate that after so many years now this is still not available - it seems the interest of the design community is not high enough.
>

Clearly the GA144 lacks a lot. I think the issue is the chip, not the
design community. At one time I was impressed by the strong points of the
chip. But they can't make up for the tremendous weaknesses.

I didn't listen to all of JB's presentation. Unfortunately the volume
fluctuations make it very hard for me to listen to what he is saying. I was
listening to the flash memory format and just couldn't stay with it after
that. Maybe my brain cells are hardening. I used to be able to just absorb
it all during a lecture.

[Paul Rubin]

Jan Coombs <jenfhaom...@murmic.plus.com> writes:
> My impression from the talk [1], was that the Forth capable processor
> that James built out of 4-6 GA144 nodes _may_ be better as a C target
> than a Forth target.

I'd still think it's best to use the ROM code built into some of the
GA144 nodes for the purpose of running Polyforth. There's very limited
RAM in any of the nodes, so if you have to use it for code, that makes
the task harder, the program slower because it has to route stuff around
more nodes, etc. While if you can use the ROM code, that frees up ram
on those nodes for the VM, probably better even if it doesn't do quite
what you want.

At this point though, regrettably, the GA144 doesn't seem to be a viable
product. There doesn't seem much point in figuring out how to program
it to emulate other parts, etc.

[JUERGEN]

It seems that there are serious limitations. Which supports my guess that this is more a test chip than a product. The related applications and customers did not come along, so the real product is still waiting to be designed.
As far a I understood, there is an alternate tool chain James and aliter did.
As such, my idea still stands or even more now. Get an emulation on a real processor and people can start playing with RAM and ROM sizes. Slower? does it matter?
Unfortunately, even if parts of the GA144 beat the world - a slower version with more RAM might help to design an application. A fast ARM might be a good option - or the VHDL/FPGA route.

[Albert van der Horst]

In article <88215814-5be1-43af...@googlegroups.com>,

JUERGEN <epld...@aol.com> wrote:
>On Monday, September 4, 2017 at 6:10:05 AM UTC+1, Paul Rubin wrote:
>> Jan Coombs <jenfhaom...@murmic.plus.com> writes:
>> > My impression from the talk [1], was that the Forth capable processor
>> > that James built out of 4-6 GA144 nodes _may_ be better as a C target
>> > than a Forth target.
>>
>> I'd still think it's best to use the ROM code built into some of the
>> GA144 nodes for the purpose of running Polyforth. There's very limited
>> RAM in any of the nodes, so if you have to use it for code, that makes
>> the task harder, the program slower because it has to route stuff around
>> more nodes, etc. While if you can use the ROM code, that frees up ram
>> on those nodes for the VM, probably better even if it doesn't do quite
>> what you want.

If they are serious with running Forth on the GA144 they should hook
up a 1 Gbyte dynamic ram and make it a decent 32 bit Forth, with the
two halves of the word running in parallel on two nodes.
Programming this RAS/CAS stuff directly could be great fun.

>>
>> At this point though, regrettably, the GA144 doesn't seem to be a viable
>> product. There doesn't seem much point in figuring out how to program
>> it to emulate other parts, etc.
>
>It seems that there are serious limitations. Which supports my guess that this is more a test chip than a product. The related applications and customers did not come along, so the real product is still waiting to be designed.
>As far a I understood, there is an alternate tool chain James and aliter did.
>As such, my idea still stands or even more now. Get an emulation on a real processor and people can start playing with RAM and ROM sizes. Slower? does it matter?

Learn how to limit line length. Also you should be aware that there is a
simulation for arrayForth called arrayFactor. You can get everything,
including source via arrayfactor.org.

My parallel prime number counter (parpi) has run on that emulator,
counting all the primes under 100,000. You will not be able to
repeat that because it needed a patched version of colorforth from
GreenArrays or some such.

<SNIP>

Groetjes Albert

[Mark Wills]

Less nodes. More memory.

Would have been a better place to start.

It was minimalism taken too far.

[Jan Coombs]

On Sun, 3 Sep 2017 07:54:00 -0700 (PDT)
JUERGEN <epld...@aol.com> wrote:

In the talk [1] James mentions that polyFORTH runs about 200
times slower on the GA144 than native code [3]. It needs 18 -
24 GA144 nodes, although six are just used as wires on the demo
board. [2]

He then describes a "Novel Execution Model" [1], which is 40x
faster than polyFORTH for fully inlined nested loops. [3]

> ... I do not understand where the amiguities

> could be. James says what he says there at about 1h30. If it
> is correct is a different matter - and I keep out of this.

He is talking about running C on the "Novel Execution Model"
described in the talk [3 - last note]. This compiled C would
still run code at least 5 times slower than than native code on
a single GA144 node, and have other restrictions.


Thanks for pushing me to listen again. I also want to slurp
Forth code phrases from a serial flash, and use a cache to
avoid re-loading loop bodies.


Jan Combs

--

[1] "A Novel Execution Model for GA144"
Michael Schuldt, Mark Flamer, James Bowman
found at ~00:45 to 01:30 in
https://www.youtube.com/watch?v=inlwcTCEXRk&feature=em-lss

[2] Pg 8 of "G144A12 polyFORTH"
http://www.greenarraychips.com/home/documents/greg/DB006-120923-PF-G144A12.pdf

[3] Notes from James' talk:

found at ~00:45 to 01:30 in
https://www.youtube.com/watch?v=inlwcTCEXRk&feature=em-lss

0:45:29 "A Novel Execution Model for GA144"

"Michael Schuldt, Mark Flamer, James Bowman"

0:51:50 [starts here]

0:55:57 'PolyForth hit is 200x slower than native'

1:10:00 100k instructions per second

1:13:06 'return oriented programming'

1:20:?? start of code run demos

1:24.33 50 for 1000 for 1000 for next next next
takes 1s (inlined), PolyForth 40s

1:25.28 1000 for 1000 for 0 drop next next
takes 65ms (inlined), PolyForth 3s

1:26:31 10 for 1000 for 0 7 mod drop next next
takes 2s+? (calls mod)

1:29:00 [just after applause] "Oh ..., one thing, ...
that this, ... with all its hopping around, it is
not completely suitable for Forth. Forth, because
of the way we factor things, doesn't have a lot of
opportunity for in-lining. But there is a language
where they in-line like crazy, and that's "C". So
this system works much better for "C" on a register
machine [version of this "Novel Execution Model"]
[...] all that would happen is that the R stack
[node] disappears and is replaced by a register
bank.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> It seems that there are serious limitations. Which supports my guess
> that this is more a test chip than a product.

I'd call it another one of the many many experimental array processors
that have appeared through history. It has some pretty cool ideas and
some other ideas that didn't work so well. If you want to continue
exploring in its direction, why would you want to just increase the
memory and leave everything else the same? There's all sorts of stuff
you can change.

> As far a I understood, there is an alternate tool chain James and
> aliter did.

That sounds interesting, though I haven't watched the video.
There's also this:

https://people.eecs.berkeley.edu/~nishant/papers/Chlorophyll.pdf

> As such, my idea still stands or even more now. Get an emulation on a
> real processor and people can start playing with RAM and ROM
> sizes. Slower? does it matter?

Ok, suppose you've got an emulator and toolchain where you can vary the
amount of ram. What kinds of stuff would you try with it? I don't have
any good ideas myself. One thing I'd certainly modify is the internode
connectivity, not just the memory amounts. I'd probably also go to a 32
bit architecture with registers. But then what's left?

[rickman]

Paul Rubin wrote on 9/5/2017 10:32 PM:
> JUERGEN <epld...@aol.com> writes:
>> It seems that there are serious limitations. Which supports my guess
>> that this is more a test chip than a product.
>
> I'd call it another one of the many many experimental array processors
> that have appeared through history. It has some pretty cool ideas and
> some other ideas that didn't work so well. If you want to continue
> exploring in its direction, why would you want to just increase the
> memory and leave everything else the same? There's all sorts of stuff
> you can change.

As Juergen said, it really was a test chip. It was designed to test some
ideas that didn't need to be tested on a chip in the first place. Before
designing the GA144 they could have tested the design in simulation at any
number of level to evaluate everything from silicon performance to system
integration. But it was built with the idea that they should try it and see
what happens. This is what I was told to do when I wanted I/O timing data
to design a memory interface, I should build it and see what performance I
can get. Silly, silly, silly. They used that same idea in building the
chip before they had any real idea what could be designed with it and now
they have a chip they can't sell into more than a handful of applications.

>> As far a I understood, there is an alternate tool chain James and
>> aliter did.
>
> That sounds interesting, though I haven't watched the video.
> There's also this:
>
> https://people.eecs.berkeley.edu/~nishant/papers/Chlorophyll.pdf
>
>> As such, my idea still stands or even more now. Get an emulation on a
>> real processor and people can start playing with RAM and ROM
>> sizes. Slower? does it matter?
>
> Ok, suppose you've got an emulator and toolchain where you can vary the
> amount of ram. What kinds of stuff would you try with it? I don't have
> any good ideas myself. One thing I'd certainly modify is the internode
> connectivity, not just the memory amounts. I'd probably also go to a 32
> bit architecture with registers. But then what's left?

WTF? Exactly, change all those things and the device will use twice the
power (or more), run at half the speed (or slower) and cost much more.

What would you change about the internode connectivity? That's one of the
strongest points of the GA144.