amforth-devel — Development discussion and user support

Re: [Amforth] String corruption

[David W. <ins...@gm...>]

Thanks Matthias. I get it!

Re: [Amforth] String corruption

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

Hi David,

> After a good couple of days of learning forth and getting my xbee
> communicating using interrupts on uart1 in API mode, this has just started
> happening and I'm stumped.
> 
> When I generate a string with
>> s" Some text",
> 
> it gets corrupted, and I keep seeing bits of the command lines I've been
> typing in the text. For example:
> 
> 
>> ." A longer bit of text"
>  ok
>> 2dup 2dup 2dup
>  ok
>> type
> e 2dup 2dupt of text ok
> 
> Also it seems that the location it's putting my string and the location of
> the TIB are very close. Is this why I'm seeing my input in the string?

Let me explain, what happens in parts. First: The interpreter uses
the memory region TIB that gets all the keystrokes from the usart line.
the interactive s" (there is a compiling s" as well) selects a subregion
from TIB. This has the side effect that a new line will destroy whatever
s" may have had in the previous line. Thus the command

s" hi there" type

will work (prints "hi there"). but

s" hi there"
type

(with a newline between the commands) will produce garbage (at least to
some degree).

The compiling s" variant does something completely different: It copies
the string into the dictionary (flash) and at runtime it gives the
flash address and length. This information uses ITYPE to do basically
the same that TYPE does for RAM based strings. The compiling s" makes
a copy to a different memory region, the interpreted s" does not; it
only gives a subregion of the TIB (or to be more precious: of the
memory buffer, SOURCE points to).

The command ." should only be used within colon definitions. It compiles
(copies) the string that follows into the dictionary (flash) and at
runtime it prints the string character by character. The ." should not
be used in interpreter mode (it does not produce an error message however)

For a simple example how strings can be dealt with, I'd recommend
http://amforth.sourceforge.net/recipes/simple-strings.html
It does not exactly cover your problems, but may give you an
idea how thing could be done.

Matthias

[Amforth] String corruption

[David W. <ins...@gm...>]

Hi All.

After a good couple of days of learning forth and getting my xbee
communicating using interrupts on uart1 in API mode, this has just started
happening and I'm stumped.

When I generate a string with
> s" Some text",

it gets corrupted, and I keep seeing bits of the command lines I've been
typing in the text. For example:


> ." A longer bit of text"
 ok
> 2dup 2dup 2dup
 ok
> type
e 2dup 2dupt of text ok

Also it seems that the location it's putting my string and the location of
the TIB are very close. Is this why I'm seeing my input in the string?

> ." A longer bit of text"
 ok
> .s
14 170  ok
> tib
 ok
> .s
16D 14 170  ok
>

What's going on? I have re-flashed and started from scratch a couple of
times because I initially thought I was running out of memory.

Any advice welcome.

Thanks,

David

Re: [Amforth] SVN revision tagging

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

Hi Enoch,

> My solution was to create a svnversion word through the Makefile:

Way shorter than I expeced. Smart. I've put into the recipe
at http://amforth.sourceforge.net/recipes/build-timestamp.html

Thank you
Matthias

P/S M reminds me that you did not accept my amforth-shell.py patch yet :-)
Really? ;)

Re: [Amforth] SVN revision tagging

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

Hello Matthias,

>> It is a solution but I prefer a word like svnrev. 
>
> :=)

My solution was to create a svnversion word through the Makefile:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

AMFORTH := ../amforth/trunk
CORE := $(AMFORTH)/core
DEVICE := $(CORE)/devices/$(MCU)

SVNVERSION := `svnversion -n $(AMFORTH)`

$(TARGET).hex: $(TARGET).asm *.inc words/*.asm $(CORE)/*.asm $(CORE)/words/*.asm $(DEVICE)/*.asm
	$(XASM) -I $(CORE) -o $(TARGET).hex -e $(TARGET).eep -l $(TARGET).lst $(TARGET).asm
	echo ": svnversion .\" r$(SVNVERSION)\" ;" >svnversion.frt

Now in the application:
~~~~~~~~~~~~~~~~~~~~~~~

\ #include svnversion.frt

: myturnkey
\ snip
    applturnkey
    space svnversion
;

' myturnkey is turnkey

The result:
~~~~~~~~~~~

amforth 4.9 AT90CAN128 r1306M

Thanks, Enoch.

P/S M reminds me that you did not accept my amforth-shell.py patch yet :-)

Re: [Amforth] SVN revision tagging

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

Hi,

> It is a solution but I prefer a word like svnrev. 

:=)

> 
> In this context, I recommend having a ChangeLog file at amforth root (as
> recommended by GNU coding stadard) whose revision number is captured by
> the a.m. word.

I try to give every commit a meaningful change message, but I wont do
that twice for every commit. Thus "svn log" *should have* given all you
need, but on my system it prints only up to rev 1268, dropping anything
that happens in trunk since then (4.9 was release around that
rev). Strange.

Anyway: sourceforge has quite a few tools installed that may give you
the information you want:
http://amforth.svn.sourceforge.net/viewvc/amforth?revision=1304&view=revision
has a navigation feature, the
RSS feed tells you all about what happens. Noteworthy changes are
documented in the News section and at http://amforth.sf.net/.

wrt the GNU coding style I like
http://www.kernel.org/doc/Documentation/CodingStyle (2nd paragraph) with
modifications ;=)

Matthias

Re: [Amforth] SVN revision tagging

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

Thanks Mathias, 

It is a solution but I prefer a word like svnrev. 

In this context, I recommend having a ChangeLog file at amforth root (as
recommended by GNU coding stadard) whose revision number is captured by
the a.m. word.

True, as you said before, I should roll up my sleeves and get some
things done myself :-)

Regards, Enoch.

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

> Hi all,
>
> until a full blown solution is available,
> one may find http://amforth.sourceforge.net/recipes/build-timestamp.html
> not completely useless. The solution should work
> for all recent versions of amforth. I'm not too
> happy with the name of the word, if someone has
> a better one, I'd appreciate any suggestions.
>
>  > cold
>  amforth 5.0 ATmega32 16000 kHz
>  Nov 23 2012 19:00:42
>  > built
>  Nov 23 2012 19:00:42 ok
>  >
>
>
> Matthias
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov

Re: [Amforth] SVN revision tagging

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

Hi all,

until a full blown solution is available,
one may find http://amforth.sourceforge.net/recipes/build-timestamp.html
not completely useless. The solution should work
for all recent versions of amforth. I'm not too
happy with the name of the word, if someone has
a better one, I'd appreciate any suggestions.

 > cold
 amforth 5.0 ATmega32 16000 kHz
 Nov 23 2012 19:00:42
 > built
 Nov 23 2012 19:00:42 ok
 >


Matthias

Re: [Amforth] SVN revision tagging

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

Hi Eoch,

> Can you insert the SVN revision no. into Amforth ID message i.e.,
> "amforth r1304..." instead of "amforth 4.9..." (as is fit for a
> release).

Well, lets have a short look at that task

The command svnversion gives the revision number of the last
commit. But: Of which file / directory? You can only change
the build machine to call svnversion in the top level amforth
directory (where the appl/template and the core/ directories
are).

mt@ayla:~/amforth/trunk$ svnversion -c
494:1304
mt@ayla:~/amforth/trunk$ svnversion
1268:1304
mt@ayla:~/amforth/trunk$

This gives you a number (or two, seems to depend
on the version of svnversion itself), which you
need to incorporate into your application somehow. e.g.
a word like applturnkey that gets modified during the
hex file generation:

; ( -- n ) utilities
; R( -- )
VE_SVN_REV:
    .dw $ff0b
    .db "svn-version",0
    .dw VE_HEAD
    .set VE_HEAD = VE_SVN_REV
XT_SVN_REV:
    .dw DO_COLON
PFA_SVN_REV:
    .dw XT_DOLITERAL
    .dw $GLOBALID$   ; <- this is a placeholder for search/modify
    .dw XT_EXIT

Calling this word gives the rev-number on the stack.

I very much prefer getting a patchset for that change, I do not
want to deal with all this myself ;) But please a patchset, that
can deal with (at least some) errors and other oddities as well,
failures at this point should not break the build process. IMHO.

Matthias

[Amforth] SVN revision tagging

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

Hello Matthias,

Can you insert the SVN revision no. into Amforth ID message i.e.,
"amforth r1304..." instead of "amforth 4.9..." (as is fit for a
release).

Thank you, Enoch.

Re: [Amforth] amforth-shell.py

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

Hi Enoch,


> When cleaning up my code to make it uploadable through the minicom
> plugin as well I noted that commented #include's are not recognized by
> the shell (though promised). Below is a patch that straightens things
> up.

Many thanks for it.

> 
> Also, I seek confirmation that amforth will not change it's single line
> only ( comment ) behavior

As I understand the forth standard, a multiline ( ) comment is only
available for file content (section 11 of the standard text). Otherwise
a "parse area" is used to detect the closing ). If the parsing
area is exhausted, a refill is not requested, leaving a somewhat
strange state IMHO.

A small test with gforth gave me the following

mt@ayla:~$ gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
( foo   ok
bar )
:2: Undefined word
>>>bar<<< )
Backtrace:
$7F7DAC7B4A68 throw
$7F7DAC7CACE0 no.extensions
$7F7DAC7B4D28 interpreter-notfound1

The same "program" from a file works fine

mt@ayla:~$ cat test.fs
( foo
  bar )
mt@ayla:~$ gforth test.fs
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
bye
mt@ayla:~$

I'd recommend using ( comments ) on a single line basis only.
That seems to be a save bet for all systems. Its not impossible
that amforth gets the multiline comments on the commmand prompt,
I'd not hold my breath waiting however ;)

Matthias

[Amforth] amforth-shell.py

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

Hi,

When cleaning up my code to make it uploadable through the minicom
plugin as well I noted that commented #include's are not recognized by
the shell (though promised). Below is a patch that straightens things
up.

Also, I seek confirmation that amforth will not change it's single line
only ( comment ) behavior to make the following uploadable both by
amforth and by shell (which recognizes multiple line comments). Example:

(
\ PORTE
&46 constant PORTE			\ Data Register, Port E
&45 constant DDRE			\ Data Direction Register, Port E
&44 constant PINE			\ Input Pins, Port E
)

Thank you, Enoch.

Index: tools/amforth-shell.py
===================================================================
--- tools/amforth-shell.py	(revision 1300)
+++ tools/amforth-shell.py	(working copy)
@@ -711,18 +711,20 @@
                 result[-1] += " " + w[:i+1]
                 result[-1] = result[-1][1:]  # remove extra initial space
                 w = w[i+1:]
+
             if in_delim_comment:
                 try:
-                   i = w.index(")")
+                    i = w.index(")")
                 except ValueError:
-                   continue
-                in_delim_comment = False
-                w = w[i+1:]
+                    pass
+                else:
+                    in_delim_comment = False
+                    w = w[i+1:]
 
             if not w:
                 continue
             if w in self._amforth_regs:
-              w = self._amforth_regs[w]
+                w = self._amforth_regs[w]
 
             if char_quote:
                 result.append(w)
@@ -739,7 +741,7 @@
             if not in_delim_comment and not in_line_comment:
                 if w == "\\":
                     in_line_comment = True
-                    break
+                    continue
 
                 elif w in self._config.current_behavior.start_string_words:
                     in_string = True

Re: [Amforth] From frt to asm

[Michael K. <mi-...@t-...>]

Hi Hannu.


Am 27.10.2012 um 21:57 schrieb Hannu Vuolasaho:
..
> Am I right if I say it doesn't know my own assembler words?

You are right.

It knows a lot of amforth words which are ANS forth.
As g4 is written in gforth adding more simple words is quite easy.
Take a look at their syntax in those examples at the end of g4 source.
And append more there.

Michael





>
> Maybe there should be link on amforth web page to this tool.
>
> And if amforth-shell maintainer want to catch feature request I'd  
> like to see this as part of it. Then it would be nice to save some  
> words when shell would convert registers to addresses without  
> including device.frt.
>
> Best regards,
> Hannu Vuolasaho
>  		 	   		
> ---------------------------------------------------------------------- 
> --------
> WINDOWS 8 is here.
> Millions of people.  Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to  
> resources.
> http://windows8center.sourceforge.net/
> join-generation-app-and-make-money-coding-fast/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] From frt to asm

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

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

> Am 27.10.2012 21:01, schrieb Enoch:
>> Hello Matthias,
>> 
>> I believe that downloading code from the application should be
>> a discouraged practice, reasons below.
>
> I disagree.
>
>> 
>> Matthias Trute <mt...@we...> writes:
>> 
>>>> *Downloading* hex code from the application is what I do now. Quite ugly
>>>> IMO.
>>>
>>> Whats wrong with it? It keeps the state of the controller just the
>>> same way MARKER does and you can transfer that state to (possibly)
>>> a lot of other controllers (of the same type).
>> 
>> 1. Downloading application compiled code may inadvertently introduce
>> source code bugs. For example, a programmer needs to hand type some
>> device-init to get his source to work in the application and forgets to
>> add the same to the source file itself. This can go unnoticed for a long
>> while since the downloaded code does include this device-init.
>
> Sounds like you want to separate your application code (or parts of it)
> from the amforth core code *and* you seem to want to combine your
> application code in binary form (aka hex or asm files) with other
> amforth cores or different controller types. Am I right?
>
> If the answer is yes: no way. Moreover I don't see even chance to do
> it that way.

Hand typing source to the application and later downloading of the
compiled hex from the application for safe keeping reminds me of the bad
practice in the old days were people could alter instructions from the
computer front panel switches and later could save the "core memory" to
a disc file...  A recipie for losing the integrity of the source code.
Anyone here old enough to remember the mini-computer age?

Anyway, the beauty of OSS is that it can cater to any taste. I will
certainly give G4 a serious try. Already made the first step:
svn co http://www.forth-ev.de/repos/g4

:-)

Thanks, Enoch.

Re: [Amforth] From frt to asm

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

> From: mi-...@t-...
> Date: Sat, 27 Oct 2012 21:14:02 +0200
> To: amf...@li...
> Subject: Re: [Amforth] From frt to asm
> 
> Hi,
> 
> if you need any help with g4 just ask me.

I didn't tried (yet) it but looks nice tool to cherry pick words which work. Am I right if I say it doesn't know my own assembler words?

Maybe there should be link on amforth web page to this tool.

And if amforth-shell maintainer want to catch feature request I'd like to see this as part of it. Then it would be nice to save some words when shell would convert registers to addresses without including device.frt.

Best regards,
Hannu Vuolasaho
 		 	   		  

Re: [Amforth] From frt to asm

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

Am 27.10.2012 21:01, schrieb Enoch:
> Hello Matthias,
> 
> I believe that downloading code from the application should be
> a discouraged practice, reasons below.

I disagree.

> 
> Matthias Trute <mt...@we...> writes:
> 
>>> *Downloading* hex code from the application is what I do now. Quite ugly
>>> IMO.
>>
>> Whats wrong with it? It keeps the state of the controller just the
>> same way MARKER does and you can transfer that state to (possibly)
>> a lot of other controllers (of the same type).
> 
> 1. Downloading application compiled code may inadvertently introduce
> source code bugs. For example, a programmer needs to hand type some
> device-init to get his source to work in the application and forgets to
> add the same to the source file itself. This can go unnoticed for a long
> while since the downloaded code does include this device-init.

Sounds like you want to separate your application code (or parts of it)
from the amforth core code *and* you seem to want to combine your
application code in binary form (aka hex or asm files) with other
amforth cores or different controller types. Am I right?

If the answer is yes: no way. Moreover I don't see even chance to do
it that way.

> 2. Host compiled Forth code can easily be enhanced with hand written
> asm.

The concept of "host compiled" is more or less the opposite of what
amforth is designed for. The initial hex files are the solution
for the chicken-and-egg problem *only*.

Matthias

Re: [Amforth] From frt to asm

[Michael K. <mi-...@t-...>]

Hi,

if you need any help with g4 just ask me.

Michael


Am 27.10.2012 um 20:13 schrieb Erich Waelde:

> Hi,
>
> On 10/27/2012 08:06 PM, Enoch wrote:
>> Is there an automated method to compile frt to asm to skip  
>> uploading of
>> debugged words?
>
> Have a look at
> http://www.forth-ev.de/repos/g4/
> This is a gforth program to konvert forth source code
> to amforth-look-alike assembly.
>
> Cheers,
> Erich
>
> ---------------------------------------------------------------------- 
> --------
> WINDOWS 8 is here.
> Millions of people.  Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to  
> resources.
> http://windows8center.sourceforge.net/
> join-generation-app-and-make-money-coding-fast/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] From frt to asm

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

Hello Matthias,

I believe that downloading code from the application should be
a discouraged practice, reasons below.

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

>> *Downloading* hex code from the application is what I do now. Quite ugly
>> IMO.
>
> Whats wrong with it? It keeps the state of the controller just the
> same way MARKER does and you can transfer that state to (possibly)
> a lot of other controllers (of the same type).

1. Downloading application compiled code may inadvertently introduce
source code bugs. For example, a programmer needs to hand type some
device-init to get his source to work in the application and forgets to
add the same to the source file itself. This can go unnoticed for a long
while since the downloaded code does include this device-init.

2. Host compiled Forth code can easily be enhanced with hand written
asm.

Thanks, Enoch.

Re: [Amforth] From frt to asm

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

Hi,


> *Downloading* hex code from the application is what I do now. Quite ugly
> IMO.

Whats wrong with it? It keeps the state of the controller just the
same way MARKER does and you can transfer that state to (possibly)
a lot of other controllers (of the same type).

Matthias

Re: [Amforth] From frt to asm

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

Hi,

Is there an automated method to compile frt to asm to skip uploading of
debugged words?

*Downloading* hex code from the application is what I do now. Quite ugly
IMO.

Thanks, Enoch.

Re: [Amforth] From frt to asm

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

Hi,

On 10/27/2012 08:06 PM, Enoch wrote:
> Is there an automated method to compile frt to asm to skip uploading of
> debugged words?

Have a look at
http://www.forth-ev.de/repos/g4/
This is a gforth program to konvert forth source code
to amforth-look-alike assembly.

Cheers,
Erich

[Amforth] From frt to asm

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

Hi,

Is there an automated method to compile frt to asm to skip uploading of
debugged words?

Uploading hex code from the application is what I do now. Quite ugly
IMO.

Thanks, Enoch.

Re: [Amforth] Help using second uart

[David W. <ins...@gm...>]

> Some kind of a mixture of
> http://amforth.sourceforge.net/recipes/interrupts.html and
> http://amforth.sourceforge.net/recipes/redirect-io.html
> should do what you want to do (and perhaps the multitasker)


Thanks Erich, I'll have a go at that.

Cheers,

David

Re: [Amforth] Help using second uart

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

Hi David,

> I don't need a Forth prompt on the other uart - I'm just chatting to
> other devices, initially an Omnikey RFID R/W module, and I'll probably
> also want to hook up to XBee radios later. So I just want to write a
> string of bytes to the second uart and have the response read into a
> buffer under interrupt control. So, just implementing interrupt driven
> serial receive on uart1.

Some kind of a mixture of
http://amforth.sourceforge.net/recipes/interrupts.html and
http://amforth.sourceforge.net/recipes/redirect-io.html
should do what you want to do (and perhaps the multitasker)

I'm too lazy to convert the assembly usart word to forth
code. There *was* a technical reason to use assembly for
interrupts in the first amforth versions, but that is
no longer the case. Never change a running system ;)

Matthias

Re: [Amforth] Help using second uart

[David W. <ins...@gm...>]

> Hello David,
> welcome to the club!

> I'm not sure, if I understand your question correctly.
> a. are you trying to use usart1 instead of usart0? Or
> b. are you trying to use both usart1 and usart0 "simultaneously"?

Hello Erich,

Thanks for your quick reply!

I don't need a Forth prompt on the other uart - I'm just chatting to
other devices, initially an Omnikey RFID R/W module, and I'll probably
also want to hook up to XBee radios later. So I just want to write a
string of bytes to the second uart and have the response read into a
buffer under interrupt control. So, just implementing interrupt driven
serial receive on uart1. I could implement this in Forth from scratch
if needed, but I was just wondering if it's 'included in the box' so
to speak, so I don't have to.

Thanks for any advice.

David.