amforth-devel — Development discussion and user support

Re: [Amforth-devel] "FORGET" in amForth v3.3

[Ian J. <ij...@sa...>]

Hello,

Can you use marker?  This worked OK for me.

 From memory - marker creates a word. When that word is executed it  
removes itself and all subsequent words from the dictionary(s).

Simple example:

words
marker qux
words
qux
words

I guess there are some issues but it works OK in 3.4 from my simple  
experiments.

Ian


On 24-Jun-09, at 3:42 AM, Ivan Rudenok wrote:

> Hello, Forthers!
> I'm using amForth v3.3 for AT90CAN128.
> I’ve a problem to develop a word „forget“. I’ll use only  
> onedictionary and I need this word to let MCU forget my own words.  
> Cananyone help me?
> Cheers,
> Ivan

[Amforth-devel] "FORGET" in amForth v3.3

[Ivan R. <iva...@go...>]

Hello, Forthers!

I'm using amForth v3.3 for AT90CAN128.

I’ve a problem to develop a word „forget“. I’ll use only one
dictionary and I need this word to let MCU forget my own words. Can
anyone help me?

Cheers,

Ivan

Re: [Amforth-devel] a few snippets around SPI

[Kalus M. <mic...@on...>]

Moin Erich.

ein spiwr hatte ich neulich für den butterfly formuliert um das  
externe dataflash anzusprechen. Kannst das gebauchen?

Achtung: Das Assemblerwort spiwr war noch für die alte headerstruktur  
des amforth. Header muss für amforth 3.4 angepasst werden!

Grüße, Michael

[Amforth-devel] two more words for lib/bitnames.frt

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

Hello,

I found these useful, so I suggest to add them to
lib/bitnames.frt

: pin_highZ ( pinmask portaddr -- )
  over over pin_input low
;
: pin_pullup_on ( pinmask portaddr -- )
  over over pin_input high
;


Cheers,
Erich

[Amforth-devel] a few snippets around SPI

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

Hello,

I spent some time fiddling with spi devices:
. MAX186 12 bit ADC
. Hope RFM12

I split out a bit-bang version (not that you ever need this
on an AVR :-) and a version using the spi interface. Please
find attached two examples. Tested with amforth 3.4.

Since for every byte there is a response byte, sending
several bytes in a row might be a little messy. Also the
docs say, that between bytes releasing and requesting "slave
select" will synchronize the slave again. It did work
without that for me _so_far_ ... but you never know. The bit
bang version seems to slow to handle incoming rfm data. At
least I did not yet get it to work properly.

Matthias, feel free to add the relevant sections to the lib
directory of amforth.

Cheers,
Erich

[Amforth-devel] ButterForth amforth 3.4 on FreeBSD/butterfly summary

[Ian J. <ij...@sa...>]

Hello everyone.

I'm still working on getting amforth and the butterfly application  
working for my environment.

I have to go off-line for a few weeks at least.  I posted two  
questions to the list so far and got some good solutions.  I have also  
found some minor problems.  Others might get some value from this so I  
will try to summarize.

This has taken me some time but mostly because I am not familiar with  
atmel products nor forth.

Thanks to Matthius, Erich, and Michael for their help.

Platform:

I'm running on host platform Free BSD 6.3 the AMD64 release.
I'm currently using Avra 1.2.3, avrdude, svn 1.6x, gmake, an STK500  
via serial port.

Open issues:

- tx0 is still referred to in lib\multitask.frt and appl\avr-butterfly 
\blocks\lcd.frt
- lcd.frt is not currently working for me even using simply lcdemit
- parsing ( ) style comments is problematic - easy workaround is to  
strip comments before/while uploading
- currently I am not able to use amforth-upload.py though in the past  
this was working for me - no time to debug

First Successes:

- Avra 1.2.3 will build amforth 3.4.x for atmega169 from source with  
some simple modifications.
- Updates to amforth-shell.py allow reliable serial uploads of forth  
code.
- The ADC module is currently working with a few modifications.

Avra Changes:

- The FreeBSD "ports" version of avra is/was an old version.  I  
rebuilt from source the 1.2.3 version in the usual way.

- Avra needs the atmega169.inc file from the studio.  I think for  
other processors you could manually edit such a file or convert the  
xml file to create all the defines.  For me this looks like a couple  
of hours of work.

- Avra also needs a device ATmega169 added to the device.c file in the  
device_list structure.  I added the following:
   {  "ATmega169",        8192,     0x100,     1024,    512,  
DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
again I think this should be relatively simple for most other processors

- The old style include files have slightly different definitions.   
One source change that was needed in the bf.asm file was:
; IGJ - comment out new style value
; .equ amforth_interpreter = NRWW_START_ADDR
; IGJ attempted hack for older assembler
.equ amforth_interpreter = LARGEBOOTSTART

There is a better way to do this I'm sure.

Forth Changes:

Avra 1.2.3 will fail with overlapping code segment errors however my  
1.0x version of Avra with the same modifications as above will work  
with 3.4.  Matthius checked in some changes that I believe are simple  
commenting out of a couple of offending (to Avra) lines.

There are a number of dependancies not noted in the code.  I didn't  
know to look out for these.
For the ADC module I noted the following:

In dict_appl.inc we need set-current.asm to support marker.

.include "words/set-current.asm" ; for marker

In adc.frt I noted:
\ adc routines
\ IGJ 2009-05-04 a few comments
\ needs atmega169.frt from library/devices
\ needs bitnames.frt from library
\ needs marker.frt from ANS library

To use bitnames there was a minor problem:

Bitnames needed minor mods to upload/compile in amforth:

: bitmask: create  ( C: "ccc" portadr n -- ) ( R: -- pinmask portadr )
must become:
: bitmask: create \ ( C: "ccc" portadr n -- ) ( R: -- pinmask portadr )

possibly there is some change between the parser in 3.x and earlier  
versions?

In adc.frt a similar looking problem for parsing lines beginning with  
() style comments, the value of the first term on each row is  
corrupted with the current form in 3.4.

  create bf_temps \ temperature list from -15 celsius to +60, taken  
directly from atmels sources

     ( -15 ) 923 , 917 , 911 , 904 , 898 ,
     ( -10 ) 891 , 883 , 876 , 868 , 860 ,
     (  -5 ) 851 , 843 , 834 , 825 , 815 ,

Moved the () comments to EOL i.e.
  ( -15 ) 923 , 917 , 911 , 904 , 898 ,
becomes
923 , 917 , 911 , 904 , 898 ,  ( -15 )

Reloaded and this corrects the table.  Temperature reads to reasonable  
level.

amforth-shell.py changes:

Michael suggested moving usart routines to polling which has had  
success with in amforth 2.9.  I was not feeling all that comfortable  
to do this.  I think xon/off or character by character pacing might be  
a better long term approach.  For now I just slow things down.

Serial uploads became reliable after I added a 0.3 second sleep in the  
send_line method in python.  Possibly 0.2 seconds is enough. I did  
limited experimentation.

def send_line(f,line):
     global debug
     # interactive prompt: 'okr\n> '
     # compiling prompt: 'ok'
     # error prompt: ' ?? '
     f.send(line)
     # take it easy and sleep a bit
     time.sleep(0.3)
     print "+",
     sys.stdout.flush() # don't want to wait for progress indicator
     # get response
     r = f.expect(['ok', 'ok\r\n> ', ' \?\? ', fdpexpect.TIMEOUT,

OK that's it for now.

Ian

Re: [Amforth-devel] Marker in butterfly amforth 3.4

[Ian J. <ij...@sa...>]

Marker problem solved!

My patched version of Avra 1.2.3 works fine with these amforth patches  
and adding set-current to appl_dict.inc. (blush)

Marker loaded just fine using the python shell program.

I made a minor change to bf.asm and perhaps a makefile change.  I will  
not be able to get back to this for a couple of days but I'll try to  
post the complete set of changes.  I should double check a few things.

Everything seems more stable now.  Perhaps amforth and I are getting  
to know each other.

Ian

On 29-Apr-09, at 4:36 AM, Matthias Trute wrote:

> Since I use the wine&atmel avrasm2.exe pair, I did not notice the
> problems here, sorry for that. I just made a few changes to the
> code and checked them into the subversion repository that address
> both your problems. I could not test them, since "my" avra does
> not know the atmega169.

Re: [Amforth-devel] Butterfly Forth Serial Challenges

[Kalus M. <mic...@on...>]

Hi Ian.


Am 27.04.2009 um 13:52 schrieb Ian Jefferson:
..
> I've been able to load several versions of amforth, most recently 3.4
> but all of them seem to exhibit some kind of serial interface issue.
> I'm looking for suggestions to debug this problem.

You may want to take a look at:
http://www.forth-ev.de/wiki/doku.php/en:projects:avr:polling_key_emit

There you find a simple I/O which is not using interrupts. I  
substituted amforth-2.9 with those words the other day. That  
eliminateted those transmitting errors sending forth code to my  
Butterfly.

Michael

Re: [Amforth-devel] Marker in butterfly amforth 3.4

[Ian J. <ij...@sa...>]

Hi Matthias,

Thanks very much.  I'm very excited about amforth.  It's a fantastic  
tool for these small platforms.

The butterfly seems to be one of the best platforms for such a  
system.  Hopefully just using amforth and posting will be helpful to  
someone.

I'm beginning to understand the compromises to such language platform.

On 29-Apr-09, at 4:36 AM, Matthias Trute wrote:

>> following errors.
>
> Since I use the wine&atmel avrasm2.exe pair, I did not notice the
> problems here, sorry for that. I just made a few changes to the
> code and checked them into the subversion repository that address
> both your problems. I could not test them, since "my" avra does
> not know the atmega169.
>

What Avra version are you running?
Do you have a butterfly?

I've patched Avra 1.0.x version (worked) and the 1.2.3 version  
(generated the overlapping Code-segment errors).  I don't really know  
what I'm doing but the patch seems simple and straightforward.  I can  
double check it and post it here.  It's basically one line in device.c  
but I think device.c is different depending on release.  The atmega169  
still has the old style .inc files available in Studio that seem to  
work with both tavarasm and avra.

I'll stick with the current releases.  I have not had this much fun in  
a long time.

Ian

Re: [Amforth-devel] Marker in butterfly amforth 3.4

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

Ian,


> I'd assumed this was some kind of serial issue but discovered that  
> marker depends on get-current and set-current.
> 
> The 3.4 butterfly application (hex files) don't include set-current.
> 
> Looking at the source it looks like it needs
> 
> .include "words/set-current.asm"
> 
> added?

A fine place would be the appl_dict.inc file, the problem you describe
is really a big one: Which words should always be included and which
are used only seldom. I decided (for now) that marker is  a nice tool
but....

[avra errors]

> following errors.

Since I use the wine&atmel avrasm2.exe pair, I did not notice the
problems here, sorry for that. I just made a few changes to the
code and checked them into the subversion repository that address
both your problems. I could not test them, since "my" avra does
not know the atmega169.

> Should I look back a few revisions of amforth for the butterfly?

Not really, since I do not introduce those errors by intention. Earlier
versions _may_ not have the errors described above, but _do_ have other
errors (usually documented in the changelog on the website)

Bye
Matthias

Re: [Amforth-devel] Marker in butterfly amforth 3.4

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

Hello Ian,

Ian Jefferson wrote:
> While chasing my serial problem I noticed that marker is not working.
> 
> I'd assumed this was some kind of serial issue but discovered that  
> marker depends on get-current and set-current.
> 
> The 3.4 butterfly application (hex files) don't include set-current.
> 
> Looking at the source it looks like it needs
> 
> .include "words/set-current.asm"

You can do this in dict_appl.inc
...
.include "words/set-current.asm" ; for marker
.include "words/set-order.asm"   ; ./.

Then build a new amforth, which can load marker.
There may be better solutions ...

> I have not tried this yet as I've been struggling with Avra.  Avra  
> 1.0x assembles the project after adding a device in the device  
> structure in device.c.  Avra 1.2.3 fails to assemble with the  
> following errors.
> 
> Pass 1...
> ../../core/words/udslashmod.asm(21) : Warning : Found CR (0x0d)  
> without LF (0x0a). Please add a LF.
> ../../core/words/dnegate.asm(17) : Warning : Found CR (0x0d) without  
> LF (0x0a). Please add a LF.
> Error: Overlapping Code-segments :
>    Start = 0x001A, End = 0x001A, Length = 0x0001
>    Start = 0x001A, End = 0x001B, Length = 0x0002
> Please check your .ORG directives !
> Error: Overlapping Code-segments :
>    Start = 0x001C, End = 0x001C, Length = 0x0001
>    Start = 0x001C, End = 0x001D, Length = 0x0002
> Please check your .ORG directives !
> gmake: *** [bf.hex] Error 1
> 
> I gather around Avra 1.2.2 there was some overlapping segments  
> checking added.
I'm using avra 1.2.2 Build 94 (11. May 2007) (from 
avra_1.2.2-1_i386.deb) for my stuff.

However, there are some files with version 2 assembler 
around, e.g. those directly out of Atmels AVRStudio files, 
which avra cannot handle correctly. This may be another 
source of problems.

> 
> Should I look back a few revisions of amforth for the butterfly?
Always worth a try, but no garantees ;-)
I'm mostly working with atmega32 not atmega169 as on the 
butterfly.

Good luck!
Erich

[Amforth-devel] Marker in butterfly amforth 3.4

[Ian J. <ij...@sa...>]

While chasing my serial problem I noticed that marker is not working.

I'd assumed this was some kind of serial issue but discovered that  
marker depends on get-current and set-current.

The 3.4 butterfly application (hex files) don't include set-current.

Looking at the source it looks like it needs

.include "words/set-current.asm"

added?

I have not tried this yet as I've been struggling with Avra.  Avra  
1.0x assembles the project after adding a device in the device  
structure in device.c.  Avra 1.2.3 fails to assemble with the  
following errors.

Pass 1...
../../core/words/udslashmod.asm(21) : Warning : Found CR (0x0d)  
without LF (0x0a). Please add a LF.
../../core/words/dnegate.asm(17) : Warning : Found CR (0x0d) without  
LF (0x0a). Please add a LF.
Error: Overlapping Code-segments :
   Start = 0x001A, End = 0x001A, Length = 0x0001
   Start = 0x001A, End = 0x001B, Length = 0x0002
Please check your .ORG directives !
Error: Overlapping Code-segments :
   Start = 0x001C, End = 0x001C, Length = 0x0001
   Start = 0x001C, End = 0x001D, Length = 0x0002
Please check your .ORG directives !
gmake: *** [bf.hex] Error 1

I gather around Avra 1.2.2 there was some overlapping segments  
checking added.

Should I look back a few revisions of amforth for the butterfly?

Thanks

Ian

[Amforth-devel] Butterfly Forth Serial Challenges

[Ian J. <ij...@sa...>]

Hi everyone,

I've done enough reading that I think I can ask this question.

I have been puttering with butterfly-s over the last couple of  
months.  I have a simple project that is essentially a complicated  
thermostat.  I ended up choosing amforth as the platform for a lot of  
reasons interactive, fast, reasonably small etc.  I don't get a lot of  
time to play.

I've been able to load several versions of amforth, most recently 3.4  
but all of them seem to exhibit some kind of serial interface issue.   
I'm looking for suggestions to debug this problem.

I'm using FreeBSD 6.4 AMD64 for the host platform.  I use avrdude with  
an STK500 connected via /dev/cuad0 then ISP to the butterfly which is  
sitting on an Ecros technology AVR butterfly carrier.  http://www.ecrostech.com/

The ISP provides around 5.2V of VCC to the butterfly and with the same  
12V linear supply from a velleman kit the onboard Ecros regulator  
supplies 3.2V vcc.

So far I have just programmed the existing hex files for the butterfly  
application.  I have not rebuilt the source yet.  I'm still working on  
getting avra configured and I cannot run wine on this host platform.

I've tried running both minicom and the amforth-shell.py.  I've used  
the isp and the on board ecros power supply (not both at once).  I use  
the same serial port and cable for programming as for interactive  
communication with the butterfly.

It appears that amforth is running correctly but there are two "bad"  
behaviours.  One is that I usually have to hit reset 2-3 times  
initially to get the standard amforth prompt.  Sometimes I get garbage  
characters after a reset finally I get the amforth prompt.  I can  
define words and add numbers print simple results after the initial  
difficulty.

The second more troublesome issue is I can't seem to upload a  
significant program.  For instance the marker.frt I was only able to  
get running once.  What happens is when I run the upload command from  
the amforth-shell.py tool I get a dozen +'s as expected then I'll get  
a series of "error!!".

I read the source for the python script and I gather that this  
indicates that the expect script is getting back something  
unexpected.  An error code.  Sometimes I just get timeouts and once  
after many timeouts marker.frt loaded apparently.  I'm not sure if it  
truly worked correctly but I could do:

marker -ian
words \ -ian is listed
-ian
words \ -ian is not listed

All this leads me to think that there is something I'm overlooking for  
serial communications.

One other thing.  I have used the serial interface exactly the same  
way to upload assembler programs using the boot loader, obviously  
without amforth.  So I'm guessing the serial hardware on both the  
butterfly, carrier board, and host computer are OK.?  Either that or  
there is some careful error correction on the boot loader serial  
programming.

Suggestions?

Thanks in advance.

Ian

Re: [Amforth-devel] [bug] stack underflow not caught

[Kalus M. <mic...@on...>]

Hi Erich.


Am 01.04.2009 um 20:46 schrieb Erich Waelde:
..
>> : .s ( -- )
>>  depth 0> if
>>  depth sp@ swap 0
>>  do i . 1+ 1+ dup . dup @ >< . cr loop 1+ 1+
>>  else sp@ then 53 ( S ) emit space . ;
>
> This works for me better when removing "><" and
> substituting "u." for "."

Sorry, I picked the wrong version for the posting: In older amforth  
versions  ><  changed byte order in top of stack to get a readable  
address or item. And there was no u. in those days. Double cell stack  
order changed with amforth Version 2.7 and there is a u. nowadays  
too. So you have to replace  >< .  by   u.   I guess.

Michael

Re: [Amforth-devel] [bug] stack underflow not caught

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

Hi,

> 
> : .s ( -- )
>  depth 0> if
>  depth sp@ swap 0
>  do i . 1+ 1+ dup . dup @ >< . cr loop 1+ 1+
>  else sp@ then 53 ( S ) emit space . ;

This works for me better when removing "><" and
substituting "u." for "."

just me nitpicking :-)

Thanks and cheers,
Erich

Re: [Amforth-devel] [bug] missing "then" not caught by compiler

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

So I call it a feature then, ok.
Kalus Michael wrote:
> Hi Erich.
> 
> Its more like "keep it simple".
> 
> Tiny microprocessor forth systems usualy dont abort unstructured code.
> For example in fig forth or Rockwell AIM65 Forth the ;s just returned, 
> no error checking at all:
> 
> aim65:
> code: ;S  ( IP <-- RP )
> PLA
> STA 9F
> PLA
> STA A0
> JMP NEXT
> 
> fig forth entsprechend, zB. 8086:
> code: ;S
> MOV SI,[BP]  ( IP <-- R1 )
> INC BP
> INC BP
> JMP NEXT
> 
> 
> And amforth does not check for it too:
> : ';'  compile exit [ ;
> 
> 
> Big Forth systems do abort compilation if code ist unstructured. This is 
> done by setting local variables which are checked by ; finaly.
> 
> Use depth of stack as a minor check. If stack depth has changed after 
> compilation of a word look twice what was done there. So if you find a 
> bad definition, enclose it in DEPTH and if it does not read 0 1 like in
>  depth : test 1 2 3 . . . ; depth .s <2> 0 1  ok
> revise code.
> 
> 
> Michael
> 
> 
> 
> 
> 
> Am 31.03.2009 um 20:56 schrieb Erich Waelde:
> 
>> Hello,
>>
>> amforth, rev.736 (3.4)
>>
>>
>> amforth 3.4 ATmega32 ok
>> > : test1 0= if -1  ( no then ) ;
>>  ok
>> > : test2 0= if -1 else 0 ( no then ) ;
>>  ok
>> > 1 test1 .
>> --- hangs here until reset ---
>> amforth 3.4 ATmega32
>> > 1 test2 .
>>  ?? -13 8
>> >
>>
>> if statements missing the trailing "then" will compile
>> without the compiler barking. I consider this a bug.
>>
>> calling such a word will produce a "hang" in one case.
>> This can be viewed as another bug, but that is not
>> important. In the other case it is producing an
>> error message at least.
>>
>> Cheers,
>> Erich
>>
> 

Re: [Amforth-devel] [bug] stack underflow not caught

[Kalus M. <mic...@on...>]

Hi Erich.

May be you want to try my version.

: .s ( -- )
  depth 0> if
  depth sp@ swap 0
  do i . 1+ 1+ dup . dup @ >< . cr loop 1+ 1+
  else sp@ then 53 ( S ) emit space . ;

"S" stands for "to strand" meaning "auf den Grund laufen" = beneath  
bottom of stack. I used S since B could be mixed up with a hex value.  
It will not dump memory if stack is empty, just gives the strand  
address in that case.

You can have  it as assembler code as well.

Michael




Am 31.03.2009 um 21:03 schrieb Erich Waelde:

> Hello,
>
> amforth rev.736 (3.4)
>
> another misbehaviour is that stack underflow conditions are
> not caught:
>
> > 1 2 3 .s
> 0 809 3
> 1 80B 2
> 2 80D 1
>  ok
> > . . .
> 3 2 1  ok
> > .
> 10  ok
> > .
> 2348  ok
> > .
> 465  ok
> > .s
> 0 815 4008
> 1 817 8C0
> 2 819 AB48
> 3 81B C9
> 4 81D 8558
> 5 81F 40B4
> 6 821 848C
> 7 823 C7E
> 8 825 702D
> 9 827 C0E1
> ...
> this goes on for quite a while :-)
>
> This is an old bug, really, but it has become more prominent
> by dumping the whole memory on another ".s". I believe this
> is new behaviour.
>
>
> Cheers,
> Erich

Re: [Amforth-devel] [bug] missing "then" not caught by compiler

[Kalus M. <mic...@on...>]

Hi Erich.

Its more like "keep it simple".

Tiny microprocessor forth systems usualy dont abort unstructured code.
For example in fig forth or Rockwell AIM65 Forth the ;s just  
returned, no error checking at all:

aim65:
code: ;S  ( IP <-- RP )
PLA
STA 9F
PLA
STA A0
JMP NEXT

fig forth entsprechend, zB. 8086:
code: ;S
MOV SI,[BP]  ( IP <-- R1 )
INC BP
INC BP
JMP NEXT


And amforth does not check for it too:
: ';'  compile exit [ ;


Big Forth systems do abort compilation if code ist unstructured. This  
is done by setting local variables which are checked by ; finaly.

Use depth of stack as a minor check. If stack depth has changed after  
compilation of a word look twice what was done there. So if you find  
a bad definition, enclose it in DEPTH and if it does not read 0 1  
like in
  depth : test 1 2 3 . . . ; depth .s <2> 0 1  ok
revise code.


Michael





Am 31.03.2009 um 20:56 schrieb Erich Waelde:

> Hello,
>
> amforth, rev.736 (3.4)
>
>
> amforth 3.4 ATmega32 ok
> > : test1 0= if -1  ( no then ) ;
>  ok
> > : test2 0= if -1 else 0 ( no then ) ;
>  ok
> > 1 test1 .
> --- hangs here until reset ---
> amforth 3.4 ATmega32
> > 1 test2 .
>  ?? -13 8
> >
>
> if statements missing the trailing "then" will compile
> without the compiler barking. I consider this a bug.
>
> calling such a word will produce a "hang" in one case.
> This can be viewed as another bug, but that is not
> important. In the other case it is producing an
> error message at least.
>
> Cheers,
> Erich
>

[Amforth-devel] [bug] stack underflow not caught

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

Hello,

amforth rev.736 (3.4)

another misbehaviour is that stack underflow conditions are
not caught:

 > 1 2 3 .s
0 809 3
1 80B 2
2 80D 1
  ok
 > . . .
3 2 1  ok
 > .
10  ok
 > .
2348  ok
 > .
465  ok
 > .s
0 815 4008
1 817 8C0
2 819 AB48
3 81B C9
4 81D 8558
5 81F 40B4
6 821 848C
7 823 C7E
8 825 702D
9 827 C0E1
...
this goes on for quite a while :-)

This is an old bug, really, but it has become more prominent
by dumping the whole memory on another ".s". I believe this
is new behaviour.


Cheers,
Erich

[Amforth-devel] [bug] missing "then" not caught by compiler

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

Hello,

amforth, rev.736 (3.4)


amforth 3.4 ATmega32 ok
 > : test1 0= if -1  ( no then ) ;
  ok
 > : test2 0= if -1 else 0 ( no then ) ;
  ok
 > 1 test1 .
--- hangs here until reset ---
amforth 3.4 ATmega32
 > 1 test2 .
  ?? -13 8
 >

if statements missing the trailing "then" will compile
without the compiler barking. I consider this a bug.

calling such a word will produce a "hang" in one case.
This can be viewed as another bug, but that is not
important. In the other case it is producing an
error message at least.

Cheers,
Erich

[Amforth-devel] learning amforth

[Nathaniel H. <nat...@gm...>]

I don't know all the words or what they do.  Sometimes the comments
aren't enough information for me.  What can I do to find out what
(unnamed) does?

Thanks,
Nate

Re: [Amforth-devel] amforth trunk atmel168

[Nathaniel H. <nat...@gm...>]

Yes I did it on the command line too: wine ~/avrasm2.exe -I
~/Appnotes/ -I ../../core  -e template.hex.eep -l template.hex.lst -m
template.hex.map template.asm

I haven't tried the gui under wine.

On Thu, Feb 26, 2009 at 12:52 AM, Matthias Trute <mt...@we...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
>> btw: how does the studio work under wine?
>>
>>> It works great.  I thought you would know that.  What assembler are you using?
>
> Only the command line assembler, not the GUI.
>
> Matthias
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJpko/9bEHdGEMFjMRAgcEAJ4o9QuYRrCu8hbcZOpLtxtVzTTrzgCfW53D
> 1TNK2zWO3PplaQH/hfHEza8=
> =Y2RE
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] amforth trunk atmel168

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

> btw: how does the studio work under wine?
> 
>> It works great.  I thought you would know that.  What assembler are you using?

Only the command line assembler, not the GUI.

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJpko/9bEHdGEMFjMRAgcEAJ4o9QuYRrCu8hbcZOpLtxtVzTTrzgCfW53D
1TNK2zWO3PplaQH/hfHEza8=
=Y2RE
-----END PGP SIGNATURE-----

Re: [Amforth-devel] amforth trunk atmel168

[Nathaniel H. <nat...@gm...>]

Thanks Matthias.

On Wed, Feb 25, 2009 at 12:44 PM, Matthias Trute <mt...@we...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathaniel,
>
> Nathaniel Haggard wrote:
>
>> I'm trying to compile amforth for an atmel168 using ubuntu hardy,
>> amforth trunk, and AvrStudio416 under wine.
>
> trunk may not always work with all assemblers and host systems. You
> may get better results with the released versions.
>
> btw: how does the studio work under wine?

It works great.  I thought you would know that.  What assembler are you using?

>
>> It fails to compile with this command: "wine ~/avrasm2.exe -I
>> ~/Appnotes/ -I ../../core  -e template.hex.eep -l template.hex.lst -m
>> template.hex.map template.asm"
>>
>> The first error was "No newline at the end of noop.asm" and that was
>> easy to fix.
>
> Fixed as well before last release ;=)
>
>>
>> These other two errors are more tricky:
>
> Not really since the are caused by the same reason.
> Atmel hast changed the definition files over time and
> esp the label names for the interrupt vectors are
> not part of the XML part description files. The
> easy fix is to guess the right name
>
>> forward referenced symbol 'ADCaddr' in .org
>
> is the 'ADCCaddr' in some versions of the include files.
>
>> template.asm(13): info: '../../core\devices/atmega168.asm' included from here
>> template.asm(33): Including file '../../core\amforth.asm'
>> ../../core\amforth.asm(8): error: Overlap in .cseg: addr=0x0 conflicts
>> with 0x0:0x1
>> template.asm(33): info: '../../core\amforth.asm' included from here
>
> This is a follow-up error of the first one is will be gone with the
> proper value für the ADC-Interrupt..
>

Yes I noticed it was ADCCaddr in the include files.  When I changed it
that error went away.

> For a few chips I already used the converter script that produces the
> amforth device definition file and use the address values instead
> of some symbolic names. But the generator is not perfect so I did not
> change the existing device files. I should do so for the next release.
>
> Matthias
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJpZ+C9bEHdGEMFjMRAubmAKDIVth5H9liEM3GHjGtwSjUiojdMQCgq9BR
> ANJ7RjE2wc39weoYIC/xSLw=
> =xDif
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

The LED on this breadboard with the amforth programmed atmega168 is blinking.

Nate

Re: [Amforth-devel] amforth trunk atmel168

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nathaniel,

Nathaniel Haggard wrote:

> I'm trying to compile amforth for an atmel168 using ubuntu hardy,
> amforth trunk, and AvrStudio416 under wine.

trunk may not always work with all assemblers and host systems. You
may get better results with the released versions.

btw: how does the studio work under wine?

> It fails to compile with this command: "wine ~/avrasm2.exe -I
> ~/Appnotes/ -I ../../core  -e template.hex.eep -l template.hex.lst -m
> template.hex.map template.asm"
> 
> The first error was "No newline at the end of noop.asm" and that was
> easy to fix.

Fixed as well before last release ;=)

> 
> These other two errors are more tricky:

Not really since the are caused by the same reason.
Atmel hast changed the definition files over time and
esp the label names for the interrupt vectors are
not part of the XML part description files. The
easy fix is to guess the right name

> forward referenced symbol 'ADCaddr' in .org

is the 'ADCCaddr' in some versions of the include files.

> template.asm(13): info: '../../core\devices/atmega168.asm' included from here
> template.asm(33): Including file '../../core\amforth.asm'
> ../../core\amforth.asm(8): error: Overlap in .cseg: addr=0x0 conflicts
> with 0x0:0x1
> template.asm(33): info: '../../core\amforth.asm' included from here

This is a follow-up error of the first one is will be gone with the
proper value für the ADC-Interrupt..

For a few chips I already used the converter script that produces the
amforth device definition file and use the address values instead
of some symbolic names. But the generator is not perfect so I did not
change the existing device files. I should do so for the next release.

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJpZ+C9bEHdGEMFjMRAubmAKDIVth5H9liEM3GHjGtwSjUiojdMQCgq9BR
ANJ7RjE2wc39weoYIC/xSLw=
=xDif
-----END PGP SIGNATURE-----