amforth-devel — Development discussion and user support

Re: [Amforth-devel] Atmega 1284p

[pito <pi...@vo...>]

Matthias,
mind an average windoze user cannot run the provided python files
(I've tried python 3.x and 2.7 as well). It would be great to find
an python expert who is able to port the stuff to windoze python..
And yes, the 1284P is DIL40 and 44smd drop in replacement for 32 and
644. My guess is it will be the mainstream for the next 2y.
Pito.

----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth-devel] Atmega 1284p
Datum: 15.8.2010 - 9:46:26

> Pito,
> 
> > Hi, There is the atmega1284p available (128k
> > flash, 16k ram, dil40)
> > > - drop in replacement of 32, 64 - so quite sexy
> > chip. Do you plan to
> > > support it? P.
> 
> amforth has a utility named pd2amforth that
> creates the device
> specific driver files. All of the currently
> delivered controller
> files (core/devices/*) are generated with that
> tool. I excpect no
> problems with that new controller, it should work.
> Formal support is
> unlikly, I cannot buy each controller type and
> test it myself, sorry.
> 
> Matthias
> 
> 
> 
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth-devel] How to compile amforth with recent avra

[Marcin C. <sa...@sa...>]

Hello, as the FreeBSD user I decided to give avra a try. 
It was necessary to add some patches to the assembler and
one dubious change to amforth, but it works very well,
and even .hex files are the same when produced by avra
and the Atmel tool.

I have posted patches to the newest avra (trunk, they might
work with 1.3.0 release) on Sourceforge:

3044547         Error:: ldi can only use a high register (r16 - r31)
                 https://sourceforge.net/tracker/?func=detail&aid=3044547&group_id=55499&atid=477233

3044545         movw y, z causes Error:: No register associated with y and z
                 https://sourceforge.net/tracker/?func=detail&aid=3044545&group_id=55499&atid=477233

3044541         .ifndef does not work (Can't redefine constant, use .SET)
                 https://sourceforge.net/tracker/?func=detail&aid=3044541&group_id=55499&atid=477233

As per suggestion I am using Atmel include files taked from the latest
AVR Studio (I place them in /usr/local/libdata/avra and modify avr-build.xml
accordingly).

The only (trivial) issue left is that avra checks all code ranges
produced by the assembler and complains if overlap occurs.
Atmel assembler does not care and happily produces two lines
in HEX file for the same range.

This happens when the serial rx or tx via IRQ is enabled,
core/devices/atmega328p/device.asm produces:

.org $024
          rcall isr ; USART Rx Complete
.org $026
          rcall isr ; USART, Data Register Empty

and core/drivers/usart-isr-[rt]x.asm produce:

.org URXCaddr (or .org UDREaddr)
   jmp_ usart_rx_isr

I have enclosed a silly patch (irq.patch) that encloses them
info .ifdefs to avoid producing overlapping assembly.
I am not sure this is the right way to handle it, though.

Enclosed please find also patches to solve flash size
exceeded problem when producing .hex files for arduino.

One question by the way: At amforth_interpreter (0x3800 in case of
328p) we start the inner interpreter (label DO_DODOES).

Wouldn't that make sense to to have an additional "jmp_ amforthstart"
there as well? This would probably allow booting Amforth independent
of the BOOTRST fuse setting.

And finally, there is a patch attached for ant files to 
call avra. I am flashing one Arduino board (ATmega 328p 
Duemilanove) with another one (ATmega168 Freeduino) via
In-circuit Serial Programming.

--Marcin

Re: [Amforth-devel] Atmega 1284p

[<an...@ki...>]

Yup just got the info and compared info.

These are drop in's. I will see if I can find a supplier for the DIL
package option.

Well spotted Pito. You are a star.

Just revised my board layouts and building a prototype. (I will socket
it this time). When I am happy with the board layout I will publish it
via my home web site and probably via RepRap too.

Cheers

Andy kirby

On 15/08/10 11:49, an...@ki... wrote:
> If it is available as a DIL 40 and a drop in for the 644p. I don't mind
> getting a couple and trying them in the minimalist board I have designed
> and built that emulates the Sanguino.
> 
> 
> 
> On 15/08/10 08:46, Matthias Trute wrote:
>> Pito,
>>
>>> Hi, There is the atmega1284p available (128k flash, 16k ram, dil40)
>>> - drop in replacement of 32, 64 - so quite sexy chip. Do you plan to
>>> support it? P.
>>
>> amforth has a utility named pd2amforth that creates the device
>> specific driver files. All of the currently delivered controller
>> files (core/devices/*) are generated with that tool. I excpect no
>> problems with that new controller, it should work. Formal support is
>> unlikly, I cannot buy each controller type and test it myself, sorry.
>>
>> Matthias
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by 
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev 
>> _______________________________________________
>> Amforth-devel mailing list
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Atmega 1284p

[<an...@ki...>]

If it is available as a DIL 40 and a drop in for the 644p. I don't mind
getting a couple and trying them in the minimalist board I have designed
and built that emulates the Sanguino.



On 15/08/10 08:46, Matthias Trute wrote:
> Pito,
> 
>> Hi, There is the atmega1284p available (128k flash, 16k ram, dil40)
>> - drop in replacement of 32, 64 - so quite sexy chip. Do you plan to
>> support it? P.
> 
> amforth has a utility named pd2amforth that creates the device
> specific driver files. All of the currently delivered controller
> files (core/devices/*) are generated with that tool. I excpect no
> problems with that new controller, it should work. Formal support is
> unlikly, I cannot buy each controller type and test it myself, sorry.
> 
> Matthias
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Atmega 1284p

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

Pito,

> Hi, There is the atmega1284p available (128k flash, 16k ram, dil40)
> - drop in replacement of 32, 64 - so quite sexy chip. Do you plan to
> support it? P.

amforth has a utility named pd2amforth that creates the device
specific driver files. All of the currently delivered controller
files (core/devices/*) are generated with that tool. I excpect no
problems with that new controller, it should work. Formal support is
unlikly, I cannot buy each controller type and test it myself, sorry.

Matthias

Re: [Amforth-devel] Atmega 1284p

[<an...@ki...>]

As far as I was aware the largest (Memory device) in a DIL package was
the 644p.

If there is one better I would be interested. Especially if it is a drop
in for the 644p but having more memory etc.

Haven't seen one yet though. That is why Arduino Mega which is a 1280
although it is a surface mount only package.

I am all ears do tell.

Cheers

Andy Kirby





On 14/08/10 21:18, pito wrote:
> Hi, There is the atmega1284p available (128k flash, 16k ram, dil40)
> - drop in replacement of 32, 64 - so quite sexy chip. Do you plan to
> support it? P.
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth-devel] Atmega 1284p

[pito <pi...@vo...>]

Hi, There is the atmega1284p available (128k flash, 16k ram, dil40)
- drop in replacement of 32, 64 - so quite sexy chip. Do you plan to
support it? P.

Re: [Amforth-devel] Serial - CTS - word compilation

[pito <pi...@vo...>]

Hi Erich,
my idea was to stop FTDI (or PC when none usb is used) during
critical activities amforth does. Without any special tools like
python apps.

So ideally I need to know the points I have to pull CTS of the FTDI
high. 
One is the flashing. The second would be the parsing. And so on. I
am sure by this kind of handshake you may eliminate special tools.
My goal is 115k baud with any terminal programme. Other issue is to
have a small rx buffer implemented. However, the cooperation of
experts is required..
Pito





----- PŮVODNÍ ZPRÁVA -----
Od: "Erich Waelde" <ew....@na...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth-devel] Serial - CTS - word compilation
Datum: 13.8.2010 - 20:48:02

> Hello Pito,
> 
> On 08/13/2010 02:17 PM, pito wrote:
> > ...
> >
> > However, when using Terraterm, HW handshake, no
> > delays, no waiting
> > > on 'ok', it does not work. The question is
> > whether amforth needs to
> > > stop receiving after each character in order to
> > process it, and -
> > > whether there is a input buffer, as the FTDI may
> > shoot few bytes
> > > (from its buffer)even CTS is pulled high - so
> > one need tu pull CTS
> > > high before the input buffer is full.
> > So it is not so easy as I assumed...Pito.
> 
> Well, the character need to be stored and are
> echoed back.
> On receiving CRLF amforth will start to parse the
> received line
> and execute it accordingly. After that a new
> prompt is issued.
> 
> This is the reason, why amforth-upload.py waits
> for the echoed
> character to be received, and after a CRLF waits
> for the ok prompt.
> This is a handshake of sorts.
> 
> 
> >...
> >> I hope the code is correct..
> >> When upload e.g. the _sieve_ you can see how
> >> the
> >> >> amforth flashes.
> >> Quite surprised - so many flashes to see.. So
> >> you
> >> >> do not buffer the
> >> whole word to be compiled but do flashes line
> >> by
> >> 
> If you look into the code, you will find that the
> inner workings
> of i! will check, whether there are any bits,
> which will go from
> 0 (zero) to 1 (one). IFF that is the case, the
> correspondig block
> is copied to a separate area and updated, the
> original block is
> erased and then rewritten. "block" refers to a
> logical chunk of
> flash memory. This is as good as it can get in
> order to write
> into flash, but not loosing too much time by
> rewriting every
> block every time.
> 
> 
> Cheers,
> Erich
> 
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Serial - CTS - word compilation

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

Hello Pito,

On 08/13/2010 02:17 PM, pito wrote:
> ...
>
> However, when using Terraterm, HW handshake, no delays, no waiting
> on 'ok', it does not work. The question is whether amforth needs to
> stop receiving after each character in order to process it, and -
> whether there is a input buffer, as the FTDI may shoot few bytes
> (from its buffer)even CTS is pulled high - so one need tu pull CTS
> high before the input buffer is full.
> So it is not so easy as I assumed...Pito.

Well, the character need to be stored and are echoed back.
On receiving CRLF amforth will start to parse the received line
and execute it accordingly. After that a new prompt is issued.

This is the reason, why amforth-upload.py waits for the echoed
character to be received, and after a CRLF waits for the ok prompt.
This is a handshake of sorts.


>...
>> I hope the code is correct..
>> When upload e.g. the _sieve_ you can see how the
>> amforth flashes.
>> Quite surprised - so many flashes to see.. So you
>> do not buffer the
>> whole word to be compiled but do flashes line by

If you look into the code, you will find that the inner workings
of i! will check, whether there are any bits, which will go from
0 (zero) to 1 (one). IFF that is the case, the correspondig block
is copied to a separate area and updated, the original block is
erased and then rewritten. "block" refers to a logical chunk of
flash memory. This is as good as it can get in order to write
into flash, but not loosing too much time by rewriting every
block every time.


Cheers,
Erich

[Amforth-devel] polling vs. isr communication was: SOLVED: amforth 4.0 for atmega328p (duemilanove) ...

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

Hi Ken,

On 08/13/2010 01:55 AM, ken...@al... wrote:
> Thank you.  The new fuse values got my BBB (a "freeduino" clone of the
> arduino duemilanove) working.  I will have to go back and see if I still
> have to use polling input rather than the rx isr.

using polling or isr communication is, as far as I can tell, more a
matter of taste than anything else. Some folks have strong opinions on
this subject. I have used both successfully. YMMV.

Cheers,
Erich

Re: [Amforth-devel] SOLVED: amforth 4.0 for atmega328p (duemilanove) fails to compile new words

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

Hi Christian,

On 08/13/2010 09:35 AM, Christian Kellermann wrote:
> Hi Erich!
>
> * Erich Waelde<ew....@na...>  [100812 19:26]:
>> With help from Matthias it was found that the fuse settings were causing this.
>>
>> Using
>>
>> avrdude: reading hfuse memory: 0xd9
>> avrdude: reading lfuse memory: 0xff
>> avrdude: reading efuse memory: 0x05
>>
>> everything works as expected.
>> Please note that the above settings are different from what is found in
>> releases/4.0/appl/arduino/readme.txt
>
> Many thanks for debugging this! In which way apart from the fuses
> does your setup differ from the default one in the release/subversion
> repository?


use the files found in releases/4.0/appl/arduino
and move the line
.include "dict_minimum.inc"
from dict_appl_core.inc to dict_appl.inc

create a makefile (stolen from appl/template :-)


Please find a diff appended.
Cheers,
Erich



diff -Naur ../amforth/releases/4.0/appl/arduino/dict_appl_core.inc arduino//dict_appl_core.inc
--- ../amforth/releases/4.0/appl/arduino/dict_appl_core.inc     2010-07-02 21:16:37.000000000 +0200
+++ arduino//dict_appl_core.inc 2010-08-13 20:25:35.000000000 +0200
@@ -6,8 +6,6 @@
  .include "words/istore_nrww.asm"
  .include "words/ifetch.asm"

-.include "dict_minimum.inc"
-
  .include "words/d-2star.asm"
  .include "words/d-plus.asm"
  .include "words/d-minus.asm"
@@ -31,4 +29,4 @@

  .include "dict_compiler.inc"
  .include "words/show-wordlist.asm"
-.include "device.inc"
\ No newline at end of file
+.include "device.inc"
diff -Naur ../amforth/releases/4.0/appl/arduino/dict_appl.inc arduino//dict_appl.inc
--- ../amforth/releases/4.0/appl/arduino/dict_appl.inc  2010-07-02 21:16:37.000000000 +0200
+++ arduino//dict_appl.inc      2010-08-13 20:25:48.000000000 +0200
@@ -2,3 +2,5 @@
  ; they may be moved to the core dictionary if needed
  .include "dict_usart.inc"

+.include "dict_minimum.inc"
+
diff -Naur ../amforth/releases/4.0/appl/arduino/makefile arduino//makefile
--- ../amforth/releases/4.0/appl/arduino/makefile       1970-01-01 01:00:00.000000000 +0100
+++ arduino//makefile   2010-08-13 20:23:46.000000000 +0200
@@ -0,0 +1,87 @@
+# simple makefile for building the
+# template project.
+
+# sometimes the login shell causes trouble
+SHELL=/bin/bash
+
+# --- edit these values ------------------------------------
+# Name of your application (useful, if you rename template.asm)
+TARGET=duemilanove
+
+# versions before 2.1 may produce some warnings
+# but should produce a running system. You should
+# _always_ use the trunk.
+
+AMFORTH=../../amforth/releases/4.0/core
+#AMFORTH=../../core
+
+# the MCU should be identical to the device
+# setting in template.asm
+MCU=atmega328p
+
+# set the fuses according to your MCU
+LFUSE=0xFF
+HFUSE=0xD9
+# some MCU have this one, see write-fuses target below
+EFUSE=0x05
+
+# serial port
+CONSOLE=/dev/ttyUSB0
+
+# directories
+DIR_ATMEL=~/wine/AvrAssembler2
+
+# programms / flags
+SP12=-c sp12 -i 10 -P /dev/parport0
+USB=-c avr911  -P /dev/ttyUSB3
+PP=-c stk200  -P /dev/parport0
+JTAG=-c jtag2 -P /dev/ttyUSB2
+BURNER=$(SP12)
+AVRDUDE=avrdude
+AVRDUDE_FLAGS=-q $(BURNER) -p $(MCU)
+
+AVRA=avra -I $(DIR_ATMEL)/Appnotes2
+
+AVRASM=wine $(DIR_ATMEL)/avrasm2.exe -I $(DIR_ATMEL)/Appnotes
+
+# ----------------------------------------------------------
+
+INCLUDE=-I $(AMFORTH) -I $(AMFORTH)/devices/$(MCU)
+
+default:  $(TARGET).hex
+
+erase:
+       $(AVRDUDE) $(AVRDUDE_FLAGS) -e
+
+marker:
+       amforth-upload.py  -t ${CONSOLE} lib/misc.frt lib/bitnames.frt lib/ans94/marker.frt devices/atmega328p.frt
+
+install: $(TARGET).hex
+       $(AVRDUDE) $(AVRDUDE_FLAGS)  -e -U flash:w:$(TARGET).hex:i -U eeprom:w:$(TARGET).eep.hex:i
+
+upload_file:
+       cat $(TARGET).fs | unfold_fs > $(TARGET).fs.unfold
+       trim_fs $(TARGET).fs.unfold  > $(TARGET).fs.upload
+upload: upload_file
+       amforth-upload.py  -t ${CONSOLE} $(TARGET).fs.upload
+
+$(TARGET).hex: $(TARGET).asm $(AMFORTH)/*.asm $(AMFORTH)/words/*.asm $(AMFORTH)/devices/$(MCU)/*.asm
+#      $(AVRA) $(INCLUDE) --listmac -l $(TARGET).lst -m $(TARGET).map $(TARGET).asm
+       $(AVRASM) $(INCLUDE) -fI -v0 -e $(TARGET).eep.hex -l $(TARGET).lst $(TARGET).asm
+
+$(TARGET).back:
+       $(AVRDUDE) $(AVRDUDE_FLAGS)  -U flash:r:$(TARGET).hex:i -U eeprom:r:$(TARGET).eep.hex:i
+
+clean:
+       rm -f $(TARGET).hex
+       rm -f $(TARGET).eep.hex
+       rm -f $(TARGET).lst
+       rm -f $(TARGET).map
+       rm -f $(TARGET).cof
+       rm -f $(TARGET).obj
+
+write-fuse:
+       $(AVRDUDE) $(AVRDUDE_FLAGS) -U efuse:w:$(EFUSE):m -U hfuse:w:$(HFUSE):m -U lfuse:w:$(LFUSE):m
+
+read-fuse:
+       $(AVRDUDE) $(AVRDUDE_FLAGS) -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h

Re: [Amforth-devel] Serial - CTS - word compilation

[pito <pi...@vo...>]

Hi,
I've tried the CTS stuff with amforth but not succesfully yet (as I
can remeber with that basic it worked ..). I did following (pls mind
the reverse CTS against my previuos post)>

PORTB 0 portpin: LED   ( LED flashes when amforth flashes the flash)
PORTD 2 portpin: CTS   ( FTDI CTS: when HIGH it indicates to FTDI to
stop)

: i_cts! 
CTS pin_output  
LED pin_output 
LED high 
CTS high
(i!) 
LED low 
CTS low
;

' i_cts! is i!

However, when using Terraterm, HW handshake, no delays, no waiting
on 'ok', it does not work. The question is whether amforth needs to
stop receiving after each character in order to process it, and -
whether there is a input buffer, as the FTDI may shoot few bytes
(from its buffer)even CTS is pulled high - so one need tu pull CTS
high before the input buffer is full.
So it is not so easy as I assumed...Pito.

----- PŮVODNÍ ZPRÁVA -----
Od: "pito" <pi...@vo...>
Komu: mt...@we..., amf...@li...
Předmět: Re: [Amforth-devel] Serial - CTS - word compilation
Datum: 13.8.2010 - 11:22:02

> Matthias, thanks for the hint! I immediately (as a
> first step) did
> the visualization of the flash writes (an blue LED
> attached via 1k
> to PB.0 and ground, so when PB.0 is high it lits):
> 
> PORTB 0 portpin: PB.0
> 
> : i_see! PB.0 pin_output PB.0 high (i!) PB.0 low ;
> 
> ' i_see! is i!
> 
> I hope the code is correct..
> When upload e.g. the _sieve_ you can see how the
> amforth flashes.
> Quite surprised - so many flashes to see.. So you
> do not buffer the
> whole word to be compiled but do flashes line by
> line..
> P.
> 
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "Matthias Trute" <mt...@we...>
> Komu: "Everything around amforth"
> <amf...@li...>
> Předmět: Re: [Amforth-devel] Serial - CTS - word
> compilation
> Datum: 13.8.2010 - 8:00:29
> 
> > Hi,
> > 
> > 
> > > The routine which flashes the flash with a new
> > > compiled word shall
> > > > simply at very beginning put the CTS signal
> > > > to
> > > > > > LOW and when finished
> > > > put back to HIGH.
> > 
> > Its easy to do since i! is a deferred word to
> > (i!). You may define
> > your own word which pre and post process
> > anything
> > > you want and call
> > (i1) inside.
> > 
> > In addition you can add a plausibility check for
> > the addresses as well
> > and increase the robustness at all.
> > 
> > If you send me your code I may include it as an
> > example.
> > 
> > 
> > Matthias
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > > > > > This SF.net email is sponsored by 
> > 
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev 
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > 
> 
> 
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Serial - CTS - word compilation

[pito <pi...@vo...>]

Matthias, thanks for the hint! I immediately (as a first step) did
the visualization of the flash writes (an blue LED attached via 1k
to PB.0 and ground, so when PB.0 is high it lits):

PORTB 0 portpin: PB.0

: i_see! PB.0 pin_output PB.0 high (i!) PB.0 low ;

' i_see! is i!

I hope the code is correct..
When upload e.g. the _sieve_ you can see how the amforth flashes.
Quite surprised - so many flashes to see.. So you do not buffer the
whole word to be compiled but do flashes line by line..
P.

----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth-devel] Serial - CTS - word compilation
Datum: 13.8.2010 - 8:00:29

> Hi,
> 
> 
> > The routine which flashes the flash with a new
> > compiled word shall
> > > simply at very beginning put the CTS signal to
> > LOW and when finished
> > > put back to HIGH.
> 
> Its easy to do since i! is a deferred word to
> (i!). You may define
> your own word which pre and post process anything
> you want and call
> (i1) inside.
> 
> In addition you can add a plausibility check for
> the addresses as well
> and increase the robustness at all.
> 
> If you send me your code I may include it as an
> example.
> 
> 
> Matthias
> 
> 
> 
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] SOLVED: amforth 4.0 for atmega328p (duemilanove) fails to compile new words

[Christian K. <ck...@pe...>]

Hi Erich!

* Erich Waelde <ew....@na...> [100812 19:26]:
> With help from Matthias it was found that the fuse settings were causing this.
> 
> Using
> 
> avrdude: reading hfuse memory: 0xd9
> avrdude: reading lfuse memory: 0xff
> avrdude: reading efuse memory: 0x05
> 
> everything works as expected.
> Please note that the above settings are different from what is found in
> releases/4.0/appl/arduino/readme.txt

Many thanks for debugging this! In which way apart from the fuses
does your setup differ from the default one in the release/subversion
repository?

Kind regards,

Christian

Re: [Amforth-devel] Serial - CTS - word compilation

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

Hi,


> The routine which flashes the flash with a new compiled word shall
> simply at very beginning put the CTS signal to LOW and when finished
> put back to HIGH.

Its easy to do since i! is a deferred word to (i!). You may define
your own word which pre and post process anything you want and call
(i1) inside.

In addition you can add a plausibility check for the addresses as well
and increase the robustness at all.

If you send me your code I may include it as an example.


Matthias

Re: [Amforth-devel] SOLVED: amforth 4.0 for atmega328p (duemilanove) fails to compile new words

[<ken...@al...>]

Thank you.  The new fuse values got my BBB (a "freeduino" clone of the
arduino duemilanove) working.  I will have to go back and see if I still
have to use polling input rather than the rx isr.

Regards,
Ken


On Thu, 12 Aug 2010 19:24 +0200, "Erich Waelde" <ew....@na...>
wrote:
> For the records:
> 
> With help from Matthias it was found that the fuse settings were causing
> this.
> 
> Using
> 
> avrdude: reading hfuse memory: 0xd9
> avrdude: reading lfuse memory: 0xff
> avrdude: reading efuse memory: 0x05
> 
> everything works as expected.
> Please note that the above settings are different from what is found in
> releases/4.0/appl/arduino/readme.txt
> 
> 
> Cheers,
> Erich
> 
> 
>  > ver
> amforth 3.8 ATmega328P ok
>  > words
> i@ (i!) i! e@ e! not s>d up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +!
> rshift lshift 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log
> 2 d< d> 0> u> u< true 0 0< > < 0= = <> r@ >r r> rot drop over swap ?dup
> dup c@ c! ! @ execute exit -int +int fill show-wordlist order ge
> t-order get-current environment? environment end-code code abort abort"
> [char] immediate recurse user constant variable [ ] ; :noname :
> does> create ?do leave +loop loop do again until repeat while begin then
> else if literal int! applturnkey +usart baud tx? tx rx? rx is R
> defer Edefer words s" ." .s u. dinvert d- d+ d2* init-user ee>ram ee-user
> tib d2/ cmove dnegate dabs d>s j * defer@ defer! icompare find
>   search-wordlist to value unused noop ver ?stack interpret depth rp0 sp
>   sp0 cold pause quit place word /string source cscan parse 2swap
>  >number number char refill accept cskip throw catch handler ' type count spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r
> d.r sign #> #s # <# hold hld within max min abs mod / negate u/mod */
> /mod */mod turnkey heap edp bl hex decimal bin ['] , compile ( \ a
> llot here /key key? key emit? emit pad #tib >in cell+ cells base state
> f_cpu  ok
>  > : one 1 ;
>   ok
>  > 1 2 3 .s
> 0 2217 3
> 1 2219 2
> 2 2221 1
>   ok
>  > one
>   ok
>  > .s
> 0 2215 1
> 1 2217 3
> 2 2219 2
> 3 2221 1
>   ok
> 
> 
> 
> On 08/07/2010 08:45 PM, Erich Waelde wrote:
> > Hello,
> >
> > playing with an duemilanove board (atmega328p).
> >
> > I'm building this from files in amforth/releases/4.0/app/template
> > not from the arduino directory. This setup is big enough to just
> > work (tested on atmega32).
> >
> > So with the following changes to template.asm
> > diff -wu template.asm ../../amforth/releases/4.0/appl/template/template.asm
> > --- template.asm	2010-08-07 20:31:40.000000000 +0200
> > +++ ../../amforth/releases/4.0/appl/template/template.asm	2010-07-02 21:16:39.000000000 +0200
> > @@ -12,19 +12,12 @@
> >    ; files include the *def.inc from atmel internally.
> >    .include "device.asm"
> >
> > -; fixes for atmega328p
> > -.equ TXEN = TXEN0
> > -.equ UCSZ0 = UCSZ00
> > -.equ RXEN = RXEN0
> > -.equ RXCIE = RXCIE0
> > -
> > -	
> >    ; amforth needs two essential parameters
> >    ; cpu clock in hertz, 1MHz is factory default
> > -.equ F_CPU = 16000000
> > +.equ F_CPU = 8000000
> >
> >    ; initial baud rate of terminal
> > -.include "drivers/usart_0.asm"
> > +.include "drivers/usart.asm"
> >    .equ BAUD = 9600
> >    .equ USART_B_VALUE = (1<<TXEN) | (1<<RXEN) | (1<<RXCIE)
> >    .equ USART_C_VALUE = (3<<UCSZ0)
> >
> >
> > and
> > MCU=atmega328p
> > in makefile, I can successfully build an amforth, upload it to the controller,
> > and talk to it:
> >   >
> >    ok
> >   >
> >    ok
> >   >  ver
> > amforth 4.0 ATmega328P ok
> >   >  words
> > i@ (i!) i! e@ e! not s>d up! up@><  cmove>  unloop i sp! sp@ rp! rp@ +! rshift lshift 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log
> > 2 d<  d>  0>  u>  u<  true 0 0<  >  <  0= =<>  r@>r r>  rot drop over swap ?dup dup c@ c! ! @ execute exit -int +int show-wordlist +usart baud t
> > x? tx rx? rx order get-order get-current environment? environment end-code code abort abort" [char] immediate recurse user constant vari
> > able [ ] ; :noname : does>  create ?do leave +loop loop do again until repeat while begin then else if literal int! applturnkey is Rdefer
> >    Edefer words s" ." .s u. dinvert d- d+ d2* init-user ee>ram ee-user tib d2/ cmove dnegate dabs d>s j * defer@ defer! icompare find sear
> > ch-wordlist to value unused noop ver ?stack interpret depth rp0 sp sp0 cold pause quit place word /string source cscan parse 2swap>numb
> > er number char refill accept cskip throw catch handler ' type count spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r s
> > ign #>  #s #<# hold hld within max min abs mod / negate u/mod */ /mod */mod turnkey bl hex decimal bin ['] , compile ( \ allot here edp
> > dp /key key? key emit? emit pad #tib>in cell+ cells base state f_cpu  ok
> >
> >
> > HOWEVER, after trying to create a new word, it stops working:
> >
> >   >  : one 1 ;
> >    ?? -13 10
> >   >  1 .s
> >    ?? -13 5
> >   >  .s
> >    ?? -13 3
> >   >  .s
> >    ?? -13 3
> >   >  1
> >    ok
> >   >  .
> >    ok
> >   >  depth
> >    ?? -13 6
> >
> > This looks to me like the pointer to the wordlist has gone off into the wild.
> > Comparing template.asm to arduino/duemilanove.asm does not show suspicious
> > differences (see below).
> >
> > More ideas?
> > Erich
> >
> >
> >    diff -wu template.asm ../../amforth/releases/4.0/appl/arduino/duemilanove.asm | less
> > --- template.asm        2010-08-07 20:31:40.000000000 +0200
> > +++ ../../amforth/releases/4.0/appl/arduino/duemilanove.asm     2010-07-02 21:16:37.000000000 +0200
> > @@ -1,48 +1,23 @@
> > -; This is a template for an amforth project.
> > -;
> > -; The order of the entries (esp the include order) must not be
> > -; changed since it is very important that the settings are in the
> > -; right order
> > -;
> > -; first is to include the macros from the amforth
> > -; directory
> >    .include "macros.asm"
> > -
> > -; include the amforth device definition file. These
> > -; files include the *def.inc from atmel internally.
> >    .include "device.asm"
> >
> > -; fixes for atmega328p
> > -.equ TXEN = TXEN0
> > -.equ UCSZ0 = UCSZ00
> > -.equ RXEN = RXEN0
> > -.equ RXCIE = RXCIE0
> > -
> > +  .equ HLDSIZE  = $10 ; 16 bit cellsize with binary representation
> > +  .equ TIBSIZE  = $64 ; 80 characters is one line...
> > +  .equ APPUSERSIZE = 0  ; size of application user area
> >
> > -; amforth needs two essential parameters
> > -; cpu clock in hertz, 1MHz is factory default
> > +; cpu clock in hertz
> >    .equ F_CPU = 16000000
> > -
> > -; initial baud rate of terminal
> > +; baud rate of terminal
> >    .include "drivers/usart_0.asm"
> >    .equ BAUD = 9600
> > -.equ USART_B_VALUE = (1<<TXEN) | (1<<RXEN) | (1<<RXCIE)
> > -.equ USART_C_VALUE = (3<<UCSZ0)
> > -
> > -
> > -.equ HLDSIZE  = $10    ; 16 bit cellsize with binary representation
> > -.equ TIBSIZE  = $64    ; ANS94 needs at least 80 characters per line
> > -.equ APPUSERSIZE = 0   ; size of application specific user area in bytes
> > -
> > -; addresses of various data segments
> > -.set here = ramstart           ; initial HERE at compile time, grows upward
> > -.set rstackstart = RAMEND      ; start address of return stack, grows downward
> > -.set stackstart  = RAMEND - 80 ; start address of data stack, grows downward
> > -.equ amforth_interpreter = max_dict_addr ; the same value as NRWW_START_ADDR
> > -; change only if you know what to you do
> > -.equ NUMWORDLISTS = 8 ; number of word lists in the searh order, at least 8
> > +.equ USART_B_VALUE = (1<<TXEN0) | (1<<RXEN0) | (1<<RXCIE0)
> > +.equ USART_C_VALUE = (1<<UCSZ01) | ( 1<<UCSZ00)
> >
> > -.equ want_fun = 0 ; in case of an error out print an additional line with an caret indicating the error position
> > +.set here = ramstart           ; start address of HERE, grows upward
> > +.set rstackstart = RAMEND
> > +.set stackstart  = RAMEND - 80
> > +.set amforth_interpreter = max_dict_addr
> >
> > -; include the whole source tree.
> > +.set NUMWORDLISTS = 8
> > +.equ want_fun = 0
> >    .include "amforth.asm"
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by
> >
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth-devel] Serial - CTS - word compilation

[pito <pi...@vo...>]

Hi,
I've seen in an atmel Basic implementation (and I've tried - it
works) a feature which may help amforth with the required delay
during the flashing the new word - to use CTS signal.
The routine which flashes the flash with a new compiled word shall
simply at very beginning put the CTS signal to LOW and when finished
put back to HIGH. The LOW on CTS tells the PC side not to send data.
So no delays needs to be set in terminal.
As the most of users use FTDI USB-RS232: one pin of atmega (defined
as output) shall be connected to CTS. The DTR<->DSR at atmega side
connected together.
Pito

Re: [Amforth-devel] SOLVED: amforth 4.0 for atmega328p (duemilanove) fails to compile new words

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

For the records:

With help from Matthias it was found that the fuse settings were causing this.

Using

avrdude: reading hfuse memory: 0xd9
avrdude: reading lfuse memory: 0xff
avrdude: reading efuse memory: 0x05

everything works as expected.
Please note that the above settings are different from what is found in
releases/4.0/appl/arduino/readme.txt


Cheers,
Erich


 > ver
amforth 3.8 ATmega328P ok
 > words
i@ (i!) i! e@ e! not s>d up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log
2 d< d> 0> u> u< true 0 0< > < 0= = <> r@ >r r> rot drop over swap ?dup dup c@ c! ! @ execute exit -int +int fill show-wordlist order ge
t-order get-current environment? environment end-code code abort abort" [char] immediate recurse user constant variable [ ] ; :noname :
does> create ?do leave +loop loop do again until repeat while begin then else if literal int! applturnkey +usart baud tx? tx rx? rx is R
defer Edefer words s" ." .s u. dinvert d- d+ d2* init-user ee>ram ee-user tib d2/ cmove dnegate dabs d>s j * defer@ defer! icompare find
  search-wordlist to value unused noop ver ?stack interpret depth rp0 sp sp0 cold pause quit place word /string source cscan parse 2swap
 >number number char refill accept cskip throw catch handler ' type count spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r
d.r sign #> #s # <# hold hld within max min abs mod / negate u/mod */ /mod */mod turnkey heap edp bl hex decimal bin ['] , compile ( \ a
llot here /key key? key emit? emit pad #tib >in cell+ cells base state f_cpu  ok
 > : one 1 ;
  ok
 > 1 2 3 .s
0 2217 3
1 2219 2
2 2221 1
  ok
 > one
  ok
 > .s
0 2215 1
1 2217 3
2 2219 2
3 2221 1
  ok



On 08/07/2010 08:45 PM, Erich Waelde wrote:
> Hello,
>
> playing with an duemilanove board (atmega328p).
>
> I'm building this from files in amforth/releases/4.0/app/template
> not from the arduino directory. This setup is big enough to just
> work (tested on atmega32).
>
> So with the following changes to template.asm
> diff -wu template.asm ../../amforth/releases/4.0/appl/template/template.asm
> --- template.asm	2010-08-07 20:31:40.000000000 +0200
> +++ ../../amforth/releases/4.0/appl/template/template.asm	2010-07-02 21:16:39.000000000 +0200
> @@ -12,19 +12,12 @@
>    ; files include the *def.inc from atmel internally.
>    .include "device.asm"
>
> -; fixes for atmega328p
> -.equ TXEN = TXEN0
> -.equ UCSZ0 = UCSZ00
> -.equ RXEN = RXEN0
> -.equ RXCIE = RXCIE0
> -
> -	
>    ; amforth needs two essential parameters
>    ; cpu clock in hertz, 1MHz is factory default
> -.equ F_CPU = 16000000
> +.equ F_CPU = 8000000
>
>    ; initial baud rate of terminal
> -.include "drivers/usart_0.asm"
> +.include "drivers/usart.asm"
>    .equ BAUD = 9600
>    .equ USART_B_VALUE = (1<<TXEN) | (1<<RXEN) | (1<<RXCIE)
>    .equ USART_C_VALUE = (3<<UCSZ0)
>
>
> and
> MCU=atmega328p
> in makefile, I can successfully build an amforth, upload it to the controller,
> and talk to it:
>   >
>    ok
>   >
>    ok
>   >  ver
> amforth 4.0 ATmega328P ok
>   >  words
> i@ (i!) i! e@ e! not s>d up! up@><  cmove>  unloop i sp! sp@ rp! rp@ +! rshift lshift 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log
> 2 d<  d>  0>  u>  u<  true 0 0<  >  <  0= =<>  r@>r r>  rot drop over swap ?dup dup c@ c! ! @ execute exit -int +int show-wordlist +usart baud t
> x? tx rx? rx order get-order get-current environment? environment end-code code abort abort" [char] immediate recurse user constant vari
> able [ ] ; :noname : does>  create ?do leave +loop loop do again until repeat while begin then else if literal int! applturnkey is Rdefer
>    Edefer words s" ." .s u. dinvert d- d+ d2* init-user ee>ram ee-user tib d2/ cmove dnegate dabs d>s j * defer@ defer! icompare find sear
> ch-wordlist to value unused noop ver ?stack interpret depth rp0 sp sp0 cold pause quit place word /string source cscan parse 2swap>numb
> er number char refill accept cskip throw catch handler ' type count spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r s
> ign #>  #s #<# hold hld within max min abs mod / negate u/mod */ /mod */mod turnkey bl hex decimal bin ['] , compile ( \ allot here edp
> dp /key key? key emit? emit pad #tib>in cell+ cells base state f_cpu  ok
>
>
> HOWEVER, after trying to create a new word, it stops working:
>
>   >  : one 1 ;
>    ?? -13 10
>   >  1 .s
>    ?? -13 5
>   >  .s
>    ?? -13 3
>   >  .s
>    ?? -13 3
>   >  1
>    ok
>   >  .
>    ok
>   >  depth
>    ?? -13 6
>
> This looks to me like the pointer to the wordlist has gone off into the wild.
> Comparing template.asm to arduino/duemilanove.asm does not show suspicious
> differences (see below).
>
> More ideas?
> Erich
>
>
>    diff -wu template.asm ../../amforth/releases/4.0/appl/arduino/duemilanove.asm | less
> --- template.asm        2010-08-07 20:31:40.000000000 +0200
> +++ ../../amforth/releases/4.0/appl/arduino/duemilanove.asm     2010-07-02 21:16:37.000000000 +0200
> @@ -1,48 +1,23 @@
> -; This is a template for an amforth project.
> -;
> -; The order of the entries (esp the include order) must not be
> -; changed since it is very important that the settings are in the
> -; right order
> -;
> -; first is to include the macros from the amforth
> -; directory
>    .include "macros.asm"
> -
> -; include the amforth device definition file. These
> -; files include the *def.inc from atmel internally.
>    .include "device.asm"
>
> -; fixes for atmega328p
> -.equ TXEN = TXEN0
> -.equ UCSZ0 = UCSZ00
> -.equ RXEN = RXEN0
> -.equ RXCIE = RXCIE0
> -
> +  .equ HLDSIZE  = $10 ; 16 bit cellsize with binary representation
> +  .equ TIBSIZE  = $64 ; 80 characters is one line...
> +  .equ APPUSERSIZE = 0  ; size of application user area
>
> -; amforth needs two essential parameters
> -; cpu clock in hertz, 1MHz is factory default
> +; cpu clock in hertz
>    .equ F_CPU = 16000000
> -
> -; initial baud rate of terminal
> +; baud rate of terminal
>    .include "drivers/usart_0.asm"
>    .equ BAUD = 9600
> -.equ USART_B_VALUE = (1<<TXEN) | (1<<RXEN) | (1<<RXCIE)
> -.equ USART_C_VALUE = (3<<UCSZ0)
> -
> -
> -.equ HLDSIZE  = $10    ; 16 bit cellsize with binary representation
> -.equ TIBSIZE  = $64    ; ANS94 needs at least 80 characters per line
> -.equ APPUSERSIZE = 0   ; size of application specific user area in bytes
> -
> -; addresses of various data segments
> -.set here = ramstart           ; initial HERE at compile time, grows upward
> -.set rstackstart = RAMEND      ; start address of return stack, grows downward
> -.set stackstart  = RAMEND - 80 ; start address of data stack, grows downward
> -.equ amforth_interpreter = max_dict_addr ; the same value as NRWW_START_ADDR
> -; change only if you know what to you do
> -.equ NUMWORDLISTS = 8 ; number of word lists in the searh order, at least 8
> +.equ USART_B_VALUE = (1<<TXEN0) | (1<<RXEN0) | (1<<RXCIE0)
> +.equ USART_C_VALUE = (1<<UCSZ01) | ( 1<<UCSZ00)
>
> -.equ want_fun = 0 ; in case of an error out print an additional line with an caret indicating the error position
> +.set here = ramstart           ; start address of HERE, grows upward
> +.set rstackstart = RAMEND
> +.set stackstart  = RAMEND - 80
> +.set amforth_interpreter = max_dict_addr
>
> -; include the whole source tree.
> +.set NUMWORDLISTS = 8
> +.equ want_fun = 0
>    .include "amforth.asm"
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] 2variable definition - 2 versions

[Leon M. <leo...@gm...>]

Awesome -- I'm all set then. Thanks again for explaining all this.
-Leon

Re: [Amforth-devel] 2variable definition - 2 versions

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

Leon,

> The description of HERE reads "address of the next free dictionary
> cell" -- which sounds like the old version. So is the code bleeding
> edge but not the comments?

Have you ever seen a valid and correct comment in source code? ;=)
just fixed it, thank you.

> So the html is based off the sources, which has definitions that are
> essentially compiled by hand?

Yes.

> But if I were defining VARIABLE
> interactively, ':' would take care of adding (LITERAL) for me?

The (literal) is included automatically (and needs to get
smarter somehow for dealing with double cell numbers, see
Pitos bug with the 1.).

> Is the "(CREATE) COMPILE COMPILE" in the definition of VARIABLE
> another artifact of being compiled by hand?

There is no compile compile... ? And never has been in 
variable.asm? the sequence "compile compile" can be
the result of a "postpone compile" in real forth code.

> If I were defining
> VARIABLE interactively, I would be able to use CREATE?

sure.

The current definition is as follows:

: variable here constant 2 allot ;

Matthias

Re: [Amforth-devel] 2variable definition - 2 versions

[Leon M. <leo...@gm...>]

I think I'm understanding this now, so hopefully one more round of
questions will clear everything up.

On Mon, Aug 9, 2010 at 1:11 PM, Matthias Trute <mt...@we...> wrote:
> They usually reflect the bleeding edge of development but
> not every subversion commit. Currently it shows the
> brand new implementation of variable based upon constant...

The description of HERE reads "address of the next free dictionary
cell" -- which sounds like the old version. So is the code bleeding
edge but not the comments?

http://amforth.sourceforge.net/words/XT_HERE.html

> You'd better read the sources, since the html versions are somewhat
> broken, the script generating the files tries to make forth
> code from the assembly sources, with mixed success however..
...
> The sequence (literal) <number> is a 1:1 translation of a
> compiled number. Think of it as the number only.

So the html is based off the sources, which has definitions that are
essentially compiled by hand? But if I were defining VARIABLE
interactively, ':' would take care of adding (LITERAL) for me?

> The (create) word is a factor from the defining words that
> makes only a vocabulary entry without an XT or data field.
> The XT is filled afterwardds by words like : (with the DO_COLON
> address) or variable/constant (with PFA_DOVARIABLE) etc. A RAM
> based dictionary would not need to do so, but a flash based one
> will honor the not necessairy flash re-write that is needed while
> overwriting the XT.

Is the "(CREATE) COMPILE COMPILE" in the definition of VARIABLE
another artifact of being compiled by hand? If I were defining
VARIABLE interactively, I would be able to use CREATE?

Thanks again for your patience in answering all of this.

-Leon

Re: [Amforth-devel] amforth - how to make him case insensitive

[pito <pi...@vo...>]

Andy,
yes, you are right - there is a lot other things to do with amforth
development. Of course I am not pushing you or the broad amforth
community into any action regarding amforth, it is just a normal
discusion.. I am not biased with any forth - as my forth skills are
minimal, so my perception what would be nice to have is just a point
of view of Mr. XY.

I do understand you like it as it is, however I do understand you
might be happy to have more than ~few users of it in the future. So
as a normal user (who has other options as well) when I take the
amforth (or any other forth), firstly I flash the stuff into the
chip and then I start tackling the promt, the first thing one does
is he/she starts to google and upload ready words into it (examples,
libraries, tests, benchmarks, etc.) which are from 99.978% a happy
mixture of lowercase and uppercase words. So based on your
recommendation one has to start to write his own filters, conversion
tools, analysers, transcoders.. with help of VB or python, at best
under linux (to fit the amforth lowercase ideology), BTW with the
similar issues like Matthias is indicating to me: - what to do with
." HeLLo woRlD" (of course nothing, this shall not be transformed to
xxx_case, it is obvious, we talk words only)? 

My point is the amforth (or pForth, PFForth, FlashForth,....) will
not be considered (by 99% of people) from a very moment as the tool
for programming a microcontroller today, but as a nice little gadget
for playing, learning, evaluating, thinking about forth and related
concepts as a representative of stack based machines. Therefore for
me, as a guy who was also quite technical long time ago, but now
much more customer centric, it means I shall offer (when not
performing a l'art pour l'art exercise only) something one may
practically use (in the way I described above) from scratch - and to
simply google, upload and run a SIEVE WRITTEN IN UPPERCASE ... as
normally nobody is able to write (I mean to program) the SIEVE in
amforth even in lowercase just to test weather the amforth even
works..
This is just my point guys, your mileage may vary... P.

----- PŮVODNÍ ZPRÁVA -----
Od: an...@ki...
Komu: amf...@li...
Předmět: Re: [Amforth-devel] amforth - how to make him case
Datum: 9.8.2010 - 23:35:43

> You won't hear me argue against this view point
> because I like it too.
> 
> For the very good technical reasons already
> outlined.
> 
> I guess ultimately if the case sensitivity is too
> much to live with,
> there is always the option of taking a fork and
> maintaining it yourself.
> Such is the Open Nature of Open Source.
> 
> Alternatively there are many text preprocessing
> tools (Unix/Linux) that
> will pre-process text into what ever case you
> want. Before squirting it
> at the Amforth laden micro-controller.
> 
> Case sensitivity is good, leave it be, move on,
> their is so much more
> that is important to do, this argument is trivial
> and unworthy of such
> capable individuals.
> 
> Sorry if this posting is offensive, enough
> already, vote with your feet.
> 
> 
> 
> On 09/08/10 19:18, Matthias Trute wrote:
> > Üito,
> > 
> >> The simplest solutiom might be to translate all
> >> uppercase letters
> >> >> (A-Z) into lowercase when input or exercised or
> >> compiled.
> >> > 
> > And what do I do with strings like ." hello
> > world " ?
> > > Turn it into HELLO WORLD? No way.
> > 
> > and again: _I_ like the case sensitive feature
> > very much.
> > > 
> > Matthias
> > 
> > 
> > ------------------------------------------------------------------------------>
> > This SF.net email is sponsored by 
> > > > 
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev 
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> ------------------------------------------------------------------------------This
> SF.net email is sponsored by 
> > 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] amforth - how to make him case insensitive

[<an...@ki...>]

You won't hear me argue against this view point because I like it too.

For the very good technical reasons already outlined.

I guess ultimately if the case sensitivity is too much to live with,
there is always the option of taking a fork and maintaining it yourself.
Such is the Open Nature of Open Source.

Alternatively there are many text preprocessing tools (Unix/Linux) that
will pre-process text into what ever case you want. Before squirting it
at the Amforth laden micro-controller.

Case sensitivity is good, leave it be, move on, their is so much more
that is important to do, this argument is trivial and unworthy of such
capable individuals.

Sorry if this posting is offensive, enough already, vote with your feet.



On 09/08/10 19:18, Matthias Trute wrote:
> Üito,
> 
>> The simplest solutiom might be to translate all uppercase letters
>> (A-Z) into lowercase when input or exercised or compiled.
> 
> And what do I do with strings like ." hello world " ?
> Turn it into HELLO WORLD? No way.
> 
> and again: _I_ like the case sensitive feature very much.
> 
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Sieve example - elapsed time

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

Pito,

> 
> However the example states:
> \ runtime: ATMega644 @ 16MHz 2,3 seconds per DO-PRIME.
> 
> Based on that a have to get aprox. 3,2sec instead. Can somebody
> confirm that demo time, just to avoid my confusion whether my code
> works fine..

I do not remember with which version of amforth I run the benchmark.
Its long ago, I'm sure. Probably amforth is faster now? I should re-run 
the benchmark again, it seems un-avoidable.. ;=)

Matthias

Re: [Amforth-devel] amforth - how to make him case insensitive

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

Üito,

> The simplest solutiom might be to translate all uppercase letters
> (A-Z) into lowercase when input or exercised or compiled.

And what do I do with strings like ." hello world " ?
Turn it into HELLO WORLD? No way.

and again: _I_ like the case sensitive feature very much.

Matthias