amforth-devel — Development discussion and user support

Re: [Amforth] Re Distributing Amforth for Arduino

[<car...@sp...>]

dnyberg,

Thanks for the encouragement.  I will keep poking about, as time permits,
and see what source for programmed
chips might be available.

Carl


On Sun, Jul 21, 2013 at 11:30 AM, <dn...@se...> wrote:

> * Replies will be sent through Spamex to
> amf...@li...
> * For additional info click -> http://www.spamex.com/i/?v=79288160
>
> I would say that your idea is feasible with the existing toolchain, if
> your business model is adjusted a little bit:
>
> 1) You must sell the user TWO programmed chips, with instructions making
> it very clear a chip can be bricked by a bug.
>
> 2) Along with the two chips, the instructions "when you brick chip 1, swap
> to chip 2, mail me chip 1. For 1 year I will reprogram and return your
> bricked chip for fixed $X each time, post paid (say $5 maybe). That
> guarantees the user a cheap rescue, pays you a little each reprogram,
> limits the time you have committed to a cost (postal rates may go up or
> something). If someone wanted extra insurance, they could certainly buy
> two pair chips, so they could have 3 bricked ones in the mail and still be
> operational!
>
> If you did that, it could work.
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Fwd: Native Forth for Arduino Uno

[<car...@sp...>]

Matthias,

Another post indicated that it was possible (likely) that a 328P with
AmForth might be bricked
during developing a program.  With you 328P being surface mount it sounds
as if that is a
show stopper, depending on how dead the 328P was.

My understanding is that surface mount 328P's were only used when  the DIP
versions were not available.
 I only have one Arduino Uno and it is the DIP version.

I have a project with a deadline and my scarcest resource is time.  Even if
it isn't rocket science I can't
let myself get sidetracked with peripheral activities.

You said,in an earlier post, that the Arduino Uno wouldn't be your first
choice for a SBC for AmForth.  I'm
not locked into the Arduino Uno,  It was available at an attractive price
for this project.  Can your recommend
another SBC that would come up in Forth and be in this general price range?
 I wouldn't mind pausing the
development of my existing Arduino Uno  "c" program and try another board
if it would get me up and running
 in Forth without delay.

I appreciate your input.

Carl










On Sun, Jul 21, 2013 at 11:00 AM, Matthias Trute <mt...@we...> wrote:

> * Replies will be sent through Spamex to
> amf...@li...
> * For additional info click -> http://www.spamex.com/i/?v=79288160
>
> Hi Carl,
>
> > Thank you for your detailed analysis of the situation.  I have to
> > admit that we have different goals or that I don't understand the
> > problem.  I'm willing to believe that it's that I don't understand,
> > but I get the flavor that you are shooting for a solution which uses
> > the actual chip in the Arduino Uno and want to be able to recover
> > its original operation.
>
> All of my arduino's have SMD chips. I could not replace them, not even
> if I would need to.
>
> > I had hoped for a solution where the original ATmega328P is removed
> > from the board and replaced with another 328P already programed for
> > AmForth.
>
> Since the arduino provide the ISP pins for in place programming (a 2x3
> pin header), I see no need to physically replace the chips. All that
> differs is software and it can be changed any time. You need
> a ISP capable programming device (e.g. another arduino with an
> ISP-MK2 sketch or a real programmer like the AVR ISP MK2 from Atmel).
>
> There's no rocket science involved.
>
> > I appreciate your interest and would be pleased to hear your take on
> >  removing the existing 328P and replacing it with a pre-programmed
> > Forth chip. I would think bootloader considerations would go away
> > under these circumstances.
>
> The bootloader can easily re-programmed with the Arduino IDE (there's a
> menu option for it). All you need (again) is a programming device. And
> after that, your arduino works as nothing has happened at all.
>
> Matthias
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Fwd: Native Forth for Arduino Uno

[Erich W. <ew....@na...>]

Hello Carl,

the mailing list is working :-)
Thanks for your reply.

On 07/21/2013 12:02 AM, car...@sp... wrote:
> Erich,
> 
> Thank you for your detailed analysis of the situation.  I have to admit
> that we have different goals or that I don't understand
> the problem.  I'm willing to believe that it's that I don't understand, but
> I get the flavor that you are shooting for a solution
> which uses the actual chip in the Arduino Uno and want to be able to
> recover its original operation.
Correct.

> I had hoped for a solution where the original ATmega328P is removed from
> the board and replaced with another 328P
> already programed for AmForth.  Nothing has been done to the original 328P
> and the user could install it again anytime he desired.

Ah, I see.
There are socketed versions of the duemilanove board, I have one of those.
But smd chips seem to be much more common, as fas as I can tell.

> As far as options, I would be glad to have any system that in general
> followed Leo Brodie's "Starting Forth" as much as AmForth
> would allow.  I used to use Forth quite extensively to modify the operation
> of photocopiers to control individual subsystems for special testing.
>  I would much rather be using Forth in developing my current device than
> using "c".
> 
> I appreciate your interest and would be pleased to hear your take on
> removing the existing 328P and replacing it with a pre-programmed Forth
> chip.

Ok, so you have a socketed chip, fine. You have say 5 more chips with
amForth preprogrammed. So you can work happily and errors will brick
them. If you send them back to the person who programmed them in the first
place, fine. However: After two rounds or so, you have almost paid for
the programmer that I recommend anyway (40 Eur for a good one).

The Arduino project has put a lot of work into making the whole system
nearly unbrickable. Yet they cater for reprogramming the bootloader,
because it will be needed rather sooner than later.

Apart from "get yourself a programmer" there are other options:

? Is there a hacker space or similar near you? If so, try to get in contact
  and visit them. They can teach you how to reprogramm the arduino, I'm sure.
  They might have one to lend or a do-it-yourself type for a nice tip.

? Do you have colleages/friends who play with microcontrollers? One will
  have such a programmer. And he/she may teach you how to use it.

? Are you involved in some other "social group" (sports, some hobby ...)?
  Did you ask there?

I'm probably just reminding you of the obvious: There are people out there
playing with AVR microcontrollers, and there might be just one around the
corner ...  you could even ask on this list "is someone near $location" :-)


> I would think bootloader considerations would go away under these
> circumstances.
As Matthias said, if you have a programmer, everything is under control.

Cheers,
Erich

[Amforth] Re Distributing Amforth for Arduino

[<dn...@se...>]

I would say that your idea is feasible with the existing toolchain, if
your business model is adjusted a little bit:

1) You must sell the user TWO programmed chips, with instructions making
it very clear a chip can be bricked by a bug.

2) Along with the two chips, the instructions "when you brick chip 1, swap
to chip 2, mail me chip 1. For 1 year I will reprogram and return your
bricked chip for fixed $X each time, post paid (say $5 maybe). That
guarantees the user a cheap rescue, pays you a little each reprogram,
limits the time you have committed to a cost (postal rates may go up or
something). If someone wanted extra insurance, they could certainly buy
two pair chips, so they could have 3 bricked ones in the mail and still be
operational!

If you did that, it could work.

Re: [Amforth] Fwd: Native Forth for Arduino Uno

[Matthias T. <mt...@we...>]

Hi Carl,

> Thank you for your detailed analysis of the situation.  I have to
> admit that we have different goals or that I don't understand the
> problem.  I'm willing to believe that it's that I don't understand,
> but I get the flavor that you are shooting for a solution which uses
> the actual chip in the Arduino Uno and want to be able to recover
> its original operation.

All of my arduino's have SMD chips. I could not replace them, not even
if I would need to.

> I had hoped for a solution where the original ATmega328P is removed
> from the board and replaced with another 328P already programed for
> AmForth.

Since the arduino provide the ISP pins for in place programming (a 2x3
pin header), I see no need to physically replace the chips. All that
differs is software and it can be changed any time. You need
a ISP capable programming device (e.g. another arduino with an
ISP-MK2 sketch or a real programmer like the AVR ISP MK2 from Atmel).

There's no rocket science involved.

> I appreciate your interest and would be pleased to hear your take on
>  removing the existing 328P and replacing it with a pre-programmed
> Forth chip. I would think bootloader considerations would go away
> under these circumstances.

The bootloader can easily re-programmed with the Arduino IDE (there's a
menu option for it). All you need (again) is a programming device. And
after that, your arduino works as nothing has happened at all.

Matthias

Re: [Amforth] Fwd: Native Forth for Arduino Uno

[<car...@sp...>]

Erich,

Thank you for your detailed analysis of the situation.  I have to admit
that we have different goals or that I don't understand
the problem.  I'm willing to believe that it's that I don't understand, but
I get the flavor that you are shooting for a solution
which uses the actual chip in the Arduino Uno and want to be able to
recover its original operation.

I had hoped for a solution where the original ATmega328P is removed from
the board and replaced with another 328P
already programed for AmForth.  Nothing has been done to the original 328P
and the user could install it again anytime he desired.

As far as options, I would be glad to have any system that in general
followed Leo Brodie's "Starting Forth" as much as AmForth
would allow.  I used to use Forth quite extensively to modify the operation
of photocopiers to control individual subsystems for special testing.
 I would much rather be using Forth in developing my current device than
using "c".

I appreciate your interest and would be pleased to hear your take on
removing the existing 328P and replacing it with a pre-programmed Forth
chip.
I would think bootloader considerations would go away under these
circumstances.

Regards,

Carl






On Sat, Jul 20, 2013 at 1:19 PM, Erich Waelde <ew....@na...> wrote:

> * Replies will be sent through Spamex to
> amf...@li...
> * For additional info click -> http://www.spamex.com/i/?v=79288160
>
> Hi Carl, hi all,
>
> On 07/20/2013 03:30 PM, Matthias Trute wrote:
> > Hi all,
> >
> > there seems to go something wrong with the mailing list,
> > so I forward a message to it. Can someone help Carl?
> >
> > Matthias
> >
> >      ---------- Forwarded message ----------
> >      From: Carl Baxter <car...@sp... <mailto:car...@sp...>>
> >      To: amf...@li...
> >      <mailto:amf...@li...>
> >      Cc:
> >      Date: Thu, 18 Jul 2013 21:50:20 -0700
> >      Subject: Native Forth for Arduino Uno
> >        I am developing a project using an Arduino Uno board and
> >        their c/c++ language.  It would be more productive for
> >        me to be doing this in Forth but the project deadline keeps
> >        me from stopping work, getting the necessary tools and
> >        learning how to put amForth on the board.
> >
> >        Is there some source of a programmed Forth chip that I could
> >        just install and be up and running.
>
> Not that I know of.
>
> >  I would think
> >        there would be a market for such an item.  It seems to me that
> when
> >      someone has already programmed one chip for the Arduino Uno he has
> >      solved the
> >      problem for everybody.
>
>
> Sounds easy, but isn't. I (or Matthias or *someone*) could provide
> .hex files and the problem seems solved. Someone else could preprogramm
> arduino to forthuinos and ship them, at hopefully modest cost.
> However, it isn't easy.
>
> a. How to flash the arduino?
>
>    amForth and the arduino bootloader programm are mutually exclusive.
>
>    + could the bootloader be fixed to export an API to (i!) (the function
>      to write a word to flash)? Probably so, however, this code is under
>      someone elses control. This someone else has no incentive to do and
>      maintain these changes, so this is a dead end imho.
>
>    + could amForth be changed into a "sketch" such that it loads with said
>      bootloader? Probably so, however, its less clear that the result is
>      something you can or want to use "standalone" without the arduino
>      bootloader.
>
>    The "obvious" solution to this problem is knowing how to assemble the
>    relevant .hex files and having a usable programmer to flash the arduino.
>    This is imho a bigger hurdle to a beginner (of Forth *and*
> microcontrollers
>    at the same time).
>
> b. How to recover a bricked arduino?
>
>    amForth puts little in the way between the programmer and the
> controller.
>    In other words you are entirely able to change some important byte in
>    flash or eeprom, and then your controller may be dead. Dead as in "it
>    is not talking to me any more".
>
>    To recover this situation, you are back to solving point a.
>
>    You can try to make amForth unbrickable. Again, whether these changes
> are
>    desirable is not clear.
>
> c. Trying out amForth
>
>    A colleage of mine and I have given several workshops to interested
> folks
>    in the past:
>    + up to 20 people, 1 board for 2 people
>    + approx. 3 hours time (which is short) up to 8 hours.
>    + we hand out preflashed arduinos with danger shields (they have LEDS
>      and a buzzer among other stuff)
>    + never underestimate the time it takes until everyone has a working
>      serial connection!
>    + The preloaded system has already loaded bitnames.frt and a handful
>      of other libs.
>    + we then guide the folks through making a morse code emitter.
>    This is great fun. But we always need to reprogram one or more boards
>    due to "bricking is easy"
>
>    So this opens another route: can amForth be made "always recoverable".
>    Probably yes, but again: it is not clear, whether the result pleases
>    me or anyone else not using arduinos. Several pieces to make amForth
>    recoverable have been discussed in the mailing list or presented as
>    Examples in (Vierte Dimension, german only, found at www.forth-ev.de).
>    It doesn't make amForth any simpler internally.
>
>    I should mention that we had lengthy discussions about which
>    board to use. I personally prefer other boards over the arduino.
> However,
>    they are so well known and easy to get that we eventually went with
> them.
>
>
> d. What exactly should the preprogrammed arduino have?
>
>    I *always* need to add my favourite stuff to the plain vanilla
>    amForth build. For example: I *HATE* case insensitivity. FOO is
>    not Foo is not foo, imho. Therefore I will always set
>      .set WANT_IGNORECASE = 0
>    whereas the default is 1. We haven't programmed a single line yet,
>    but we already have to make a decision. Along the same line of
>    argument, which of these should be included by default?
>
>    .include "dict_wl.inc"
>    .include "words/fill.asm"
>    .include "words/1ms.asm"
>    .include "words/notequalzero.asm"
>    .include "words/uzerodotr.asm"
>    .include "words/udotr.asm"
>    ;.include "words/no-jtag.asm"
>    .include "words/spirw.asm"
>    .include "words/2spirw.asm"
>
>    Now, what exactly should be on a preprogrammed board? And does one size
>    fit them all? Probably not.
>
>    I firmly believe that teaching people to use amForth includes the
> toolchain
>    to recover a bricked board. If I send them home without that, they will
> hate
>    me very soon, and very understandably so.
>
>
>    I'm not saying that solving the original problem is impossible, but I'm
>    probably not much help in doing so. Writing more libraries may help.
> That's
>    why some of my code can be found in
>    svn://svn.code.sf.net/p/amforth/code/applications/ewlib
>    Use at your own risk.
>
>
> >      If no one is making a market in programmed Forth chips, I would be
> >      willing to buy 50 if I had to and try to promote them.  The way it
> is
> >      being done now is very off-putting to people who would just like to
> >      try Forth,
>
> And then there is always the option to use gforth on your PC. Forth is not
> limited to microcontrollers. But trying out microcontrollers for the first
> or second time together with trying out Forth may be a fairly big pile.
>
>
> Cheers,
> Erich, not being of much help this time.
>
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Fwd: Native Forth for Arduino Uno

[Erich W. <ew....@na...>]

Hi Carl, hi all,

On 07/20/2013 03:30 PM, Matthias Trute wrote:
> Hi all,
> 
> there seems to go something wrong with the mailing list,
> so I forward a message to it. Can someone help Carl?
> 
> Matthias
> 
>      ---------- Forwarded message ----------
>      From: Carl Baxter <car...@gm... <mailto:car...@gm...>>
>      To: amf...@li...
>      <mailto:amf...@li...>
>      Cc:
>      Date: Thu, 18 Jul 2013 21:50:20 -0700
>      Subject: Native Forth for Arduino Uno
>        I am developing a project using an Arduino Uno board and
>        their c/c++ language.  It would be more productive for
>        me to be doing this in Forth but the project deadline keeps
>        me from stopping work, getting the necessary tools and
>        learning how to put amForth on the board.
> 
>        Is there some source of a programmed Forth chip that I could
>        just install and be up and running.

Not that I know of.

>  I would think
>        there would be a market for such an item.  It seems to me that when
>      someone has already programmed one chip for the Arduino Uno he has
>      solved the
>      problem for everybody.


Sounds easy, but isn't. I (or Matthias or *someone*) could provide
.hex files and the problem seems solved. Someone else could preprogramm
arduino to forthuinos and ship them, at hopefully modest cost.
However, it isn't easy.

a. How to flash the arduino?

   amForth and the arduino bootloader programm are mutually exclusive.
   
   + could the bootloader be fixed to export an API to (i!) (the function
     to write a word to flash)? Probably so, however, this code is under
     someone elses control. This someone else has no incentive to do and
     maintain these changes, so this is a dead end imho.

   + could amForth be changed into a "sketch" such that it loads with said
     bootloader? Probably so, however, its less clear that the result is
     something you can or want to use "standalone" without the arduino
     bootloader.

   The "obvious" solution to this problem is knowing how to assemble the
   relevant .hex files and having a usable programmer to flash the arduino.
   This is imho a bigger hurdle to a beginner (of Forth *and* microcontrollers
   at the same time).

b. How to recover a bricked arduino?

   amForth puts little in the way between the programmer and the controller.
   In other words you are entirely able to change some important byte in
   flash or eeprom, and then your controller may be dead. Dead as in "it
   is not talking to me any more".

   To recover this situation, you are back to solving point a.

   You can try to make amForth unbrickable. Again, whether these changes are
   desirable is not clear.

c. Trying out amForth

   A colleage of mine and I have given several workshops to interested folks
   in the past:
   + up to 20 people, 1 board for 2 people
   + approx. 3 hours time (which is short) up to 8 hours.
   + we hand out preflashed arduinos with danger shields (they have LEDS
     and a buzzer among other stuff)
   + never underestimate the time it takes until everyone has a working
     serial connection!
   + The preloaded system has already loaded bitnames.frt and a handful
     of other libs.
   + we then guide the folks through making a morse code emitter.
   This is great fun. But we always need to reprogram one or more boards
   due to "bricking is easy"

   So this opens another route: can amForth be made "always recoverable".
   Probably yes, but again: it is not clear, whether the result pleases
   me or anyone else not using arduinos. Several pieces to make amForth
   recoverable have been discussed in the mailing list or presented as
   Examples in (Vierte Dimension, german only, found at www.forth-ev.de).
   It doesn't make amForth any simpler internally.

   I should mention that we had lengthy discussions about which
   board to use. I personally prefer other boards over the arduino. However,
   they are so well known and easy to get that we eventually went with them.


d. What exactly should the preprogrammed arduino have?

   I *always* need to add my favourite stuff to the plain vanilla
   amForth build. For example: I *HATE* case insensitivity. FOO is
   not Foo is not foo, imho. Therefore I will always set
     .set WANT_IGNORECASE = 0
   whereas the default is 1. We haven't programmed a single line yet,
   but we already have to make a decision. Along the same line of
   argument, which of these should be included by default?

   .include "dict_wl.inc"
   .include "words/fill.asm"
   .include "words/1ms.asm"
   .include "words/notequalzero.asm"
   .include "words/uzerodotr.asm"
   .include "words/udotr.asm"
   ;.include "words/no-jtag.asm"
   .include "words/spirw.asm"
   .include "words/2spirw.asm"

   Now, what exactly should be on a preprogrammed board? And does one size
   fit them all? Probably not.

   I firmly believe that teaching people to use amForth includes the toolchain
   to recover a bricked board. If I send them home without that, they will hate
   me very soon, and very understandably so.


   I'm not saying that solving the original problem is impossible, but I'm
   probably not much help in doing so. Writing more libraries may help. That's
   why some of my code can be found in
   svn://svn.code.sf.net/p/amforth/code/applications/ewlib
   Use at your own risk.


>      If no one is making a market in programmed Forth chips, I would be
>      willing to buy 50 if I had to and try to promote them.  The way it is
>      being done now is very off-putting to people who would just like to
>      try Forth,

And then there is always the option to use gforth on your PC. Forth is not
limited to microcontrollers. But trying out microcontrollers for the first
or second time together with trying out Forth may be a fairly big pile.


Cheers,
Erich, not being of much help this time.

Re: [Amforth] Fwd: Native Forth for Arduino Uno

[Hannu V. <vu...@ms...>]

Hi!

Can't help with this problem, however I've given some thought to Arduino lately
on _native_ forth for Arduino. I haven't had time for try to do it. Anyway I'd
like to share my ideas.

Propably most of AVRs which people have are arduinos. IMHO Amforth should
be more Arduino friendly. This would mean some development

1) Libraries. People are propably familiar with Arduino's libraries so AmForth
should have similar libraries. Even I love bitnames.frt people still want to do
1 12 digital-write etc.

Everyone knows that coming from C to forth is hard. Everything is upside
down and there are so many things to keep in mind. At least to make LED
blink shouldn't be non-understandable.

2) Ready to flash binaries. This is already done. However how many Arduino
users can flash the binaries with the IDE or is it even possible.

3) Arduino sketch for AmForth. Open scetch mystically generate binaries
and flash.

I'm not even sure myself what this means. Maybe my point is to open file
in ArduinoIDE and stuff happens magically.

4) Forth is not for everyone. Arduino bootlader in AmForth. Requires some
development and careful designing so that bootloader could prepare forth
rather minimalistic system or be supressed bootloader only and flash 
Arduino software

Is this even possible? How the non-writable areas go in flash?

Best regards,
Hannu Vuolasaho

> Date: Sat, 20 Jul 2013 15:30:41 +0200
> From: mt...@we...
> To: amf...@li...
> Subject: [Amforth] Fwd: Native Forth for Arduino Uno
> 
> Hi all,
> 
> there seems to go something wrong with the mailing list,
> so I forward a message to it. Can someone help Carl?
> 
> Matthias
> 
>      ---------- Forwarded message ----------
>      From: Carl Baxter <car...@gm... <mailto:car...@gm...>>
>      To: amf...@li...
>      <mailto:amf...@li...>
>      Cc:
>      Date: Thu, 18 Jul 2013 21:50:20 -0700
>      Subject: Native Forth for Arduino Uno
>        I am developing a project using an Arduino Uno board and
>        their c/c++ language.  It would be more productive for
>        me to be doing this in Forth but the project deadline keeps
>        me from stopping work, getting the necessary tools and
>        learning how to put amForth on the board.
> 
>        Is there some source of a programmed Forth chip that I could
>        just install and be up and running.  I would think
>        there would be a market for such an item.  It seems to me that when
>      someone has already programmed one chip for the Arduino Uno he has
>      solved the
>      problem for everybody.
> 
>      If no one is making a market in programmed Forth chips, I would be
>      willing to buy 50 if I had to and try to promote them.  The way it is
>      being done now is very off-putting to people who would just like to
>      try Forth,
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel 		 	   		  

[Amforth] Fwd: Native Forth for Arduino Uno

[Matthias T. <mt...@we...>]

Hi all,

there seems to go something wrong with the mailing list,
so I forward a message to it. Can someone help Carl?

Matthias

     ---------- Forwarded message ----------
     From: Carl Baxter <car...@gm... <mailto:car...@gm...>>
     To: amf...@li...
     <mailto:amf...@li...>
     Cc:
     Date: Thu, 18 Jul 2013 21:50:20 -0700
     Subject: Native Forth for Arduino Uno
       I am developing a project using an Arduino Uno board and
       their c/c++ language.  It would be more productive for
       me to be doing this in Forth but the project deadline keeps
       me from stopping work, getting the necessary tools and
       learning how to put amForth on the board.

       Is there some source of a programmed Forth chip that I could
       just install and be up and running.  I would think
       there would be a market for such an item.  It seems to me that when
     someone has already programmed one chip for the Arduino Uno he has
     solved the
     problem for everybody.

     If no one is making a market in programmed Forth chips, I would be
     willing to buy 50 if I had to and try to promote them.  The way it is
     being done now is very off-putting to people who would just like to
     try Forth,

Re: [Amforth] words/icompare.asm bugfix

[Matthias T. <mt...@we...>]

Hi Enoch,

 > Signed comparison prevented us until now from enjoying UTF-8.
> Not any more :-)

Cool. Thanks (and committed)

>
> : Σ  0 swap 0  do  +  loop  ;
>> 7 8 9 3 Σ .
> 24  ok

Was it ALT-S or Right-Alt-S or Shift-Ctrl-S?? ;)


Matthias

[Amforth] words/icompare.asm bugfix

[Enoch <ix...@ho...>]

Hello Matthias & All:

Signed comparison prevented us until now from enjoying UTF-8.
Not any more :-)

: Σ  0 swap 0  do  +  loop  ;
> 7 8 9 3 Σ .
24  ok

Patch at http://pastebin.com/seSSPUtx

Regards, Enoch.

Re: [Amforth] CREATE DOES> bugfix

[Matthias T. <mt...@we...>]

Hi Enoch,


> Please find in <http://pastebin.com/BCQgjHFw> a bug-fix to properly
> create words via DOES> which, through the wlscope mechanism, are put on
> a non current wordlist.

Thanks, patch applied.

>
> BTW, DOES> created words are immediately revealed... I would prefer we
> follow the XT_COLON model, but that's hard work to change :-(

And would not honor the ANS94 spec as well.

Matthias

[Amforth] CREATE DOES> bugfix

[Enoch <ix...@ho...>]

Hello Matthias & All:,

Please find in <http://pastebin.com/BCQgjHFw> a bug-fix to properly
create words via DOES> which, through the wlscope mechanism, are put on
a non current wordlist.

BTW, DOES> created words are immediately revealed... I would prefer we
follow the XT_COLON model, but that's hard work to change :-(

Regards, Enoch.

Re: [Amforth] utf8 words

[Enoch <ix...@ho...>]

Hello Matthias,

Matthias Trute <mt...@we...> writes:

> Hi,
>
>> By the way, forth-rc1 does not prohibit such ideas. It writes:
>>
>> 3.1.2.1 "The graphic forms of characters outside the hex range {20
>>          ... 7E} are implementation defined."
>>
>> Comments?
>
> I'm old enough to *know* that anything beyond 7bit ASCII is a no no
> for a programming language. Esp when terminals are in the way (my
> minicom is very dependent on LANG settings in what it sends to
> the controller, in German there are a few such characters like öäü).

For this reason I dumped minicom and now use the "no nonsense" picocom:
https://code.google.com/p/picocom/ and rely on GNOME Terminal
emulation.

In development mode it is of-course amforth-shell.py, the undisputed
king (again using GNOME Terminal underneath).

> So I take the freedom and declare the "implementation defined" part as
> "may or may not work, good luck".
>
> ;=)

BTW, even in the old days before Unicode standardization there were
programming languages which allowed symbols outside the 7bit
ASCII. Remember APL ?

What's wrong when dealing with set objects to use common math symbols:
class1 class2 ∪ item ∈ if ...
class1 class2 ∩ ...

Those of us using Emacs type symbols like that easily using TeX input
method.

Perhaps I should do something about that element of luck ;-)

Regards, Enoch.

Re: [Amforth] utf8 words

[Matthias T. <mt...@we...>]

Hi,

> By the way, forth-rc1 does not prohibit such ideas. It writes:
>
> 3.1.2.1 "The graphic forms of characters outside the hex range {20
>          ... 7E} are implementation defined."
>
> Comments?

I'm old enough to *know* that anything beyond 7bit ASCII is a no no
for a programming language. Esp when terminals are in the way (my
minicom is very dependent on LANG settings in what it sends to
the controller, in German there are a few such characters like öäü).

So I take the freedom and declare the "implementation defined" part as
"may or may not work, good luck".

;=)

Matthias

[Amforth] utf8 words

[Enoch <ix...@ho...>]

Wake up AmForth-ers :-)

As on all modern hosts it is easy to produce UTF-8 characters wouldn't
it be nice to be able to write something like this:

\ ( X1 X2 .. Xn n -- Sigma )
: Σ  0 swap 0  do  +  loop ;

Interestingly AmForth compiles the above successfully yet it cannot find
these UTF-8 character-strings in its dictionary:

|C|    6|\ ( X1 X2 .. Xn n -- sum )
|S|    7|: Σ  0 swap 0  do  +  loop ;
|W|    8|
|S|    9|10 20 30 3 Σ .
|E=Σ ?? -13 13 

> words
Σ ->test ...

Think how nice would be our programs' new look. 

☹  (frowning face)  throwing some exception
⚑⚐ (black- white- flags) meet the new "false" "true" symbols.

By the way, forth-rc1 does not prohibit such ideas. It writes:

3.1.2.1 "The graphic forms of characters outside the hex range {20
        ... 7E} are implementation defined."

Comments?

Regards, Enoch.

P/S I'm sure that Chuck Moore, Forth inventor, wouldn't mind. He'd
already gone into color-Forth :-)

Re: [Amforth] 128KB flash access

[Enoch <ix...@ho...>]

Hello Matthias,

Matthias Trute <mt...@we...> writes:

> Hi Enoch,
>
>> Would you be ready to replace the autogenerated readflashcell /
>> writeflashcell code in device.asm for 128KB architectures as follows:
>
> Some of the 128KB devices use two bits in the RAMPZ register (at
> least according to the partdescription files). And all of the
> 256KB devices (obviously). Your patch potentially breaks them
> all.
>

My project's AVR does not mind writing non-0s to RAMPZ bits 1-7. 256KB
devices can use two ROLs followed by two RORs to restore. AmForth, BTW,
does not currently support >128KB Flash programs.

If readflashcell and writeflashcell were in macros.asm I would not mind
if they had a destructive temp7 side-effect (AmForth ASM programmer must
be familiar with macros.asm). Not so the case with the automatically
generated device.asm which is a sort of hardware description.

>> P/S I have rewritten your usart ISR drivers to support RTS/CTS/DTR in a
>> generic way (using application supplied macros).
>
> I rewrote (internally) the assembly code with plain forth code:
>
>   ; : isr-rx USART_DATA c@
>   ;    dup 3 = if cold then \ ctrl-c check
>   ;    usart_rx_data usart_rx_in c@ dup >r
>   ;    + c!
>   ;    r> 1+ usart_rx_mask and usart_rx_in c!
>   ; ;
>   ; setup with
>   ; ' isr-rx URXCaddr int!
>
> It the verbatim translation of the existing code, it took
> (IIRC) a few minutes to write it. It has
> some possibilities for improvements / factors, that the
> assembly code does not have. One could be your CTS/RTS (or
> XON/XOFF) flow control.
>
>> BTW, I can now upload code using any send-file utility which respects
>> CTS, so bye-bye echo monitoring :-) Will share code if you are interested.
>
> I am, as long as you use forth ;)

Here I have a different opinion. The use of ASM in the implementation of
the kernel, if it leads to faster execution yet without code size
bloating, is *a good thing*. Ordinary AmForth users would thank you if
their Forth code would run faster.

> Since CTS/RTS use additional hardware a recipe
> for the cookbook would be great.

Subject to the GPL license you and any other AmForth-er are welcome to
examine my changes at https://github.com/wexi/amforth-shadow

Using #ifdef in the kernel makes the use of CTS/RTS/DTR optional. The
application supplied macros are exlained at
https://github.com/wexi/amforth-shadow/blob/master/amforth-shadow.org

For the record, here is amforth-shadow non compete agenda:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AmForth master site is http://amforth.sourceforge.net/ -- We hope it
accepts our experimental code :-)

About another experimental code hoping to be integrated into AmForth HQ:
I am very happy with those "soft interrupts" (SLIH). They enabled me to
accomplish things from within ISRs which would otherwise have required
multitasking.

I look forward to help in further AmForth development as my time allows.
Thank you for your great work.

Regards, Enoch.

Re: [Amforth] 128KB flash access

[Matthias T. <mt...@we...>]

Hi Enoch,

> Would you be ready to replace the autogenerated readflashcell /
> writeflashcell code in device.asm for 128KB architectures as follows:

Some of the 128KB devices use two bits in the RAMPZ register (at
least according to the partdescription files). And all of the
256KB devices (obviously). Your patch potentially breaks them
all.

> P/S I have rewritten your usart ISR drivers to support RTS/CTS/DTR in a
> generic way (using application supplied macros).

I rewrote (internally) the assembly code with plain forth code:

  ; : isr-rx USART_DATA c@
  ;    dup 3 = if cold then \ ctrl-c check
  ;    usart_rx_data usart_rx_in c@ dup >r
  ;    + c!
  ;    r> 1+ usart_rx_mask and usart_rx_in c!
  ; ;
  ; setup with
  ; ' isr-rx URXCaddr int!

It the verbatim translation of the existing code, it took
(IIRC) a few minutes to write it. It has
some possibilities for improvements / factors, that the
assembly code does not have. One could be your CTS/RTS (or
XON/XOFF) flow control.

> BTW, I can now upload code using any send-file utility which respects
> CTS, so bye-bye echo monitoring :-) Will share code if you are interested.

I am, as long as you use forth ;)
Since CTS/RTS use additional hardware a recipe
for the cookbook would be great.

Matthias

[Amforth] 128KB flash access

[Enoch <ix...@ho...>]

Hello Matthias & All:

Would you be ready to replace the autogenerated readflashcell /
writeflashcell code in device.asm for 128KB architectures as follows:

-	clr temp7
-	lsl zl
-	rol zh
-	rol temp7
-	out_ RAMPZ, temp7
-	elpm @0, Z+
-	elpm @1, Z+
+  lsl	zl
+  rol	zh
+  rol	zh
+  out	RAMPZ, zh
+  ror	zh
+  elpm	@0, Z+
+  elpm	@1, Z+

I find it improper to damage temp7 which an application programmer may
want to use. RAMPZ does not care what you write into bits 1-7.

Thanks, Enoch.

P/S I have rewritten your usart ISR drivers to support RTS/CTS/DTR in a
generic way (using application supplied macros). Works well so far.
BTW, I can now upload code using any send-file utility which respects
CTS, so bye-bye echo monitoring :-) Will share code if you are interested.

[Amforth] Adding 1-wire, or other abilities to amForth

[Michael P. <mp...@rc...>]

Back in May of 2011, Neal Crook posted what has been a very helpful
guide to building an amForth image for the Arduino using AVR Studio. 
Fast-forward to 2013 and I have used that guide to successfully create
an image of amForth 5.1 on what is now called Atmel Studio 6.

What I seem to be having trouble with is giving my Uno the 1-wire
capabilities.  I'm not exactly sure just where to include the 1wire.asm
file for the build and what might need to be modified in that file in
order to run on the Uno.

Has anyone had success with this?  Would you be willing to post the
steps you took?

Regards,

Michael

Re: [Amforth] Waking up a dormant forum :-)

[Matthias T. <mt...@we...>]

Hi,

> A Forth system can be implemented with as little as 7 words written in

3 words, according to Frank Seargant.

> assembly. This stuff is simpler to port to the next controller, or at least
> less work. So the next question is: is this "keep the assembly part as
> small as possible" credo important for amforth? Probably not, because it
> is designed to run on "atmega" exclusively. The "atXmega" stuff has been
> largely abandoned, if I remember correctly.

atxmega frustate me everytime I re-start with them. The tool chain on
linux is not yet ready for them. IMHO. But I do not give up, yet ;)
And who knows, maybe I use the code as inspiration for something
completely other controllers? I've got a few ARM's right on my desk...

> So, no, apart maybe from readability of the code there is not much to say
> against using more assembly.

I'd agree if someone writes an optimizing cross-compiler from forth code
to assembler code. Simply converting from one syntax notation to another
is already done with the G4 tool.

Matthias

Re: [Amforth] Is it possible to compile Forth defined words in PC before programming the ATmega?

[Matthias T. <mt...@we...>]

Hi Wojciech

> If I want to extend the standard dictionary with some words defined
> by me, is it possible to compile them on PC so, that when ATmega is
> programmed, my words are already available?

Why do you want to mimic the C programming style? Edit/Compile/Upload?
Thats soo old-fashioned...

> I simply want to avoid relatively lengthy process of adding the new
> definitions after programming

I'd recommend Erich's strategy: flash the base amforth system, add
your (tested) words and read the flash/eepprom back to the PC. Now
you can go back to this stage at any time. Alternatively or in addition
set a marker and hope that the errors in your new words do not destroy
the existing flash/eeprom content. That would be faster to rewind.

> (and minimize the EEPROM usage, as it is rewritten, whenever new word
> is defined ;-)

Strange. I still use the same Atmega16 for my development amforth was
created on initially. If there is one system that got re-flashed and
tortured, I'd consider this one in the top 5. Should I mention,
that it still works fine?

> ) I know, that I can do it defining the new words in assembler, but
> the syntax is not very easy to read and write... is there any better
> solution?

Just forget assembler. Really. There are cases in which assembler is
unavoidable (e.g. the 1-wire core words) but they are not that large.
At least they should not be so.

Matthias

Re: [Amforth] Is it possible to compile Forth defined words in PC before programming the ATmega?

[Erich W. <ew....@na...>]

Hello,

On 06/10/2013 10:01 AM, Wojciech Zabołotny wrote:
> Hi,
> 
> If I want to extend the standard dictionary with some words defined by me, is it possible to compile them on PC so, that when ATmega is programmed, my words are already available?
> I simply want to avoid relatively lengthy process of adding the new definitions after programming (and minimize the EEPROM usage, as it is rewritten, whenever new word is defined ;-) )
> I know, that I can do it defining the new words in assembler, but the syntax is not very easy to read and write...
> is there any better solution?
> 

There is a little gforth tool at
http://www.forth-ev.de/repos/g4/

if you feed amforth source code to it, it will
produce the equivalent .asm code in the same
style as most of the words/*.asm file look.

"value" is not supported at the moment, maybe more.
But it should be possible to fix g4.fs accordingly.


Another option to "reprogram the controller to a known state" is
this:
. put amforth onto the controller
. add whatever words you want
. read the flash/eeprom state back to your PC
use these files to reprogramm. See makefile for appropriate
targets.


Cheers,
Erich


ew@metis:~/Forth 2 > gforth g4.fs

; g4 macro definitions: <0>
; g4 version #31
; some alias <0>
; label ; headers <0>
; compiling words <0>
user:<4> 0 -149508408 -149508392 0
user:<4> 0 -149508408 -149508392 0
; some state smart words
; g4 macro compiler
; control structures <0>
; exceptions utils <0>
; Simple words <0>
; _: to           _cr _."     .dw XT_TO "              _; does not
work this way
; added more words
; finis
; Items on stack: <0> mk 10. 6.2013 11:44:25

Gforth 0.6.2-20060527, Copyright (C) 1995-2006 Free Software
Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
variable N
; defining a variable:
VE_N:
    .dw $FF01
    .db "N",0
    .dw VE_HEAD
    .set VE_HEAD = VE_N
XT_N:
    .dw PFA_DOVARIABLE
PFA_N:
    .dw heap
    .set heap = heap + CELLSIZE
 ok
: N+ ( -- ) 1 N +!
VE_N+:
    .dw $FF02
    .db "N+"
    .dw VE_HEAD
    .set VE_HEAD = VE_N+
XT_N+:
    .dw DO_COLON
PFA_N+:        ; ( -- )
    .dw XT_DOLITERAL
    .dw $1
    .dw XT_N
    .dw XT_PLUSSTORE
_] bye

Re: [Amforth] Waking up a dormant forum :-)

[Erich W. <ew....@na...>]

Hello,

answering late ...

On 06/06/2013 09:37 PM, Enoch wrote:
> Hello AmForth-ers,
> 
> Can somebody give me good reasons why we should not convert words/*.asm
> implementations (as much as possible) from VM assembly to AVR
> assembly. 

Isn't this about the usual tradeoff between "portability" and "speed/size"?
A Forth system can be implemented with as little as 7 words written in
assembly. This stuff is simpler to port to the next controller, or at least
less work. So the next question is: is this "keep the assembly part as
small as possible" credo important for amforth? Probably not, because it
is designed to run on "atmega" exclusively. The "atXmega" stuff has been
largely abandoned, if I remember correctly.

So, no, apart maybe from readability of the code there is not much to say
against using more assembly.

AVRStudio is in my case not an argument at all, because I do not use it.


Cheers,
Erich

[Amforth] Is it possible to compile Forth defined words in PC before programming the ATmega?

[Wojciech Z. <wz...@is...>]

Hi,

If I want to extend the standard dictionary with some words defined by me, is it possible to compile them on PC so, that when ATmega is programmed, my words are already available?
I simply want to avoid relatively lengthy process of adding the new definitions after programming (and minimize the EEPROM usage, as it is rewritten, whenever new word is defined ;-) )
I know, that I can do it defining the new words in assembler, but the syntax is not very easy to read and write...
is there any better solution?
-- 
TIA & Regards,
Wojtek