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.fo...@nassur.net> wrote:

> * Replies will be sent through Spamex to
> amforth-devel@lists.sourceforge.net
> * 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 <carl8...@spamex.com <mailto:carl8...@spamex.com>>
> >      To: amforth-devel@lists.sourceforge.net
> >      <mailto:amforth-devel@lists.sourceforge.net>
> >      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/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
------------------------------------------------------------------------------
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/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Reply via email to