Re: [Amforth-devel] Connection to host

[Andy K. <an...@ak...>]

Mathias

I think we probably agree on a large percentage of the below.

Where we probably diverge a touch is that I think forth should be 
sufficient in and of itself.

I should be able to program in forth and create further firmware in the 
same forth. I should be able to do everything (including put a forth 
environment on to a virgin chip) without ever needing anything but forth.

I am principally a C and Assembler programmer, programming for me comes 
before the language that the program is expressed in. (It's probably as 
a result of a CS degree and background)

Whilst I can and do program in a number of languages (professionally and 
otherwise) I fail to see why anyone else should......

Being multi lingual is great (for me) as a European (Multi lingual wet 
ware environment) I value it highly (multi lingual firm/hardware 
environment).

Unfortunately a large proportion of humanity is no where near as gifted 
(Nor as talented) why should they miss out and be unable to contribute 
their own capabilities (gifted or talented). Because they are 
linguistically challenged.

Forth is a very particular case in point. It isn't suitable for 
everyone. Not everyone can get a grip on RP (Reverse Polish, or stack 
based) notation much less the programmatic equivalent. Their minds don't 
work that way.

By the same token if their minds do but they struggle with infix 
notation why should they have to bother with C, or any other infix 
language (that can be used to express computer instruction).

Mathias I don't know if you are gifted or talented (or both), certainly 
you are a clever guy. Clearly you have proved yourself many times over 
by producing amforth. I think you are missing out on your just 
recognition through amforth being difficult to adopt by folk who don't 
have enough languages under their belt.

Erich

Yup you have found me out, I have been a militant supporter of Open 
source and "Standing on the shoulders of giants" since before the 
INTERNET was graphical (As well as contributing fiscally to the FSF, and 
always will do). The last 2 or 3 years most of my support has been 
behind the RepRap project http://reprap.org. I can see a big future for 
amforth in synergy with this project if it can get over it's Arduino 
Hardware allergy. I really wouldn't want to see either project struggle 
for the influence of the other though.........















Matthias Trute wrote:
> Andy,
> 
>> I have read the docs explaining the issues with the bootloader and 
>> arduino and fully agree. You are somewhat caught by how the architecture 
>> of the AVR's was designed. I don't see it as being a limitation of 
>> either amforth or Arduino. They are quite different animals. Trying to 
>> make one like the other could be a mistake.
>>   
> 
> It's not a limitation, but a question of what a program could do
> with the varios types of memories in the atmegas. IMHO most of
> the programmers think of the flash as a read-only mempory that
> needs hugh amounts of work to deal with. At most they place
> some constant data (string literals) in it. The bootloaders reflect
> that in many ways: They do not provide an API for the essential
> flash write operation, this function is only available if the bootloader
> reads data from the serial line. If you take a deeper look at the code,
> they usually do not use function (if coded in C) but operate
> in a single main() function without split-out modules, that could
> theoretically re-arranged to call the result an API.
> 
> Back to the arduino: The hardware works pretty well with amforth,
> the only thing missing is the arduino bootloader, that is not able
> to flash the amforth binary. If you use some other method for
> transferring amforth, everything's fine. But it's probably not an
> arduino anymore (the bootloader has a monitor as a debugging aid
> as well) since you cannot use the arduino software any longer.
>> In the interim, all (an easy statement to make) that amforth appears to 
>> lack for it to be able to give newbies a quick way in is a binary image 
>> (no compiling, or tool-chain necessary) for a very select number of off 
>> the shelf micro boards, and a detailed how-to do ICSP using avrdude and 
>> ultimately from a board running amforth (board to identical board clone 
>> using a forth programming routine).
>>   
> 
> There are way too many different boards out there, so I decided
> against selecting on of them and provide hex files for it. The
> AVR Butterfly is an exception, but it is somehow the same as the
> arduino: The bootloader is in the way: the one from atmel is
> unusable and once amforth is on the chip, you are on you own.
> 
> Since the use of an programming hardware tool is essential for
> using amforth, I selected the "advanced end uses" as the intended
> audience. It's definitly (and sadly) not a beginners toy...
> 
>> I fully agree that anyone capable of contributing to the current project 
>>   would have the necessary skills already. What about the next 
>> generation of would be forth hackers that have yet to discover that they 
>> are up for it though ??
>>   
> 
> Really good question. IMHO the most interesting part is that
> forth gives you an extendible command interpreter at hand.
> The price is that you need to learn how to deal with microcontrollers
> and that there is a tool chain with both soft- and hardware to be used.
> 
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>