amforth-devel — Development discussion and user support

Re: [Amforth] Building amForth with Microchip Studio 7

[Helge K. <Hel...@gm...>]

On 08.09.2021 17:45, Tristan Williams wrote:
> Hi Helge,
>
> Glad you got AmForth to build with an atmega328p.
>
> Can you make avrasm2.exe output a list file, re-build and then check
> the list file for lines containing store-i ?
>
> For the atmega2560 I would expect
>
>                   .include "words/store-i.asm"
>                   .include "words/store-i_big.asm"
>
> For the atmega328p I would expect
>
>                   .include "words/store-i.asm"
>                   .include "words/store-i_nrww.asm"

Well, the .lss doesn't show the source lines for the atmega2560. But I see

atmega2560:
dict/nrww.inc(93): Including file 'words/store-i_big.asm'

atmega328p:
dict/nrww.inc(95): Including file 'words/store-i_nrww.asm'

as you expected. Further the core_8k.inc is included for the 256 instead
of the core_4k.inc for 328p.

Should I send the .lss file (121k) or make it somewhere available?


Best regards,
Helge

Re: [Amforth] Building amForth with Microchip Studio 7

[Tristan W. <ho...@tj...>]

Hi Helge,

Glad you got AmForth to build with an atmega328p.

Can you make avrasm2.exe output a list file, re-build and then check
the list file for lines containing store-i ?

For the atmega2560 I would expect 

                 .include "words/store-i.asm"
                 .include "words/store-i_big.asm"

For the atmega328p I would expect

                 .include "words/store-i.asm"
                 .include "words/store-i_nrww.asm"

Kind regards,

Tristan

On 08Sep21 10:54, Helge Kruse wrote:
> On 08.09.2021 08:06, Tristan Williams wrote:
> > Hi Helge,
> > 
> > I don't use studio, but from the command line you give below
> > 
> > > avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
> > > (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
> > > -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
> > > -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
> > > "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
> > > (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
> > 
> > it looks like it is including files from the devices\atmega32
> > directory and using m32def.inc which are associated with the atmega32
> > chip rather than the atmega328p. Somewhere the target device needs to
> > be set to an atmega328p.
> 
> This is a good point! With the correct include path I get a working,
> self-compiled amForth. Further I removed the -im32def.inc. The file is
> included in the amForth sources anyway.
> 
> Thank you.
> 
> Now I want to take the second step, build for ATmega2560. I use nearly
> the same avrsam2 command line, but changed the include path from
>     amforth-6.9\avr8\devices\atmega32
> to
>     amforth-6.9\avr8\devices\atmega2560
> 
> avrasm2.exe -fI -o my2560.hex -e my2560.eep -S my2560.tmp -W+ie
> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega2560"
> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -d
> "Debug\my2560.obj"  "main.asm"  -I "D:\Program Files
> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
> 
> Now I get several errors like:
> error: Overlap in .cseg: addr=0x1f000 conflicts with 0x1f000:0x1f396
> error: Overlap in .cseg: addr=0x1f001 conflicts with 0x1f000:0x1f396
> ...
> error: Overlap in .cseg: addr=0x1f03e conflicts with 0x1f000:0x1f396
> 
> Shouldn't this compile out of the box?
> I am also curious about this range 0x1f000:0xf1396.
> 
> Best regards,
> Helge
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Building amForth with Microchip Studio 7

[Helge K. <Hel...@gm...>]

On 08.09.2021 08:06, Tristan Williams wrote:
> Hi Helge,
>
> I don't use studio, but from the command line you give below
>
>> avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
>> (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
>> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
>> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
>> "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
>> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
>
> it looks like it is including files from the devices\atmega32
> directory and using m32def.inc which are associated with the atmega32
> chip rather than the atmega328p. Somewhere the target device needs to
> be set to an atmega328p.

This is a good point! With the correct include path I get a working,
self-compiled amForth. Further I removed the -im32def.inc. The file is
included in the amForth sources anyway.

Thank you.

Now I want to take the second step, build for ATmega2560. I use nearly
the same avrsam2 command line, but changed the include path from
     amforth-6.9\avr8\devices\atmega32
to
     amforth-6.9\avr8\devices\atmega2560

avrasm2.exe -fI -o my2560.hex -e my2560.eep -S my2560.tmp -W+ie
-I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega2560"
-I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -d
"Debug\my2560.obj"  "main.asm"  -I "D:\Program Files
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"

Now I get several errors like:
error: Overlap in .cseg: addr=0x1f000 conflicts with 0x1f000:0x1f396
error: Overlap in .cseg: addr=0x1f001 conflicts with 0x1f000:0x1f396
...
error: Overlap in .cseg: addr=0x1f03e conflicts with 0x1f000:0x1f396

Shouldn't this compile out of the box?
I am also curious about this range 0x1f000:0xf1396.

Best regards,
Helge

Re: [Amforth] Building amForth with Microchip Studio 7

[George H. <jac...@gm...>]

typo correction - " If you don't *know if* your ATmega2560 binaries are
correctly compiled, AmForth does have precompiled ready to load ATmega328p
binaries that you can load to an ArduinoUNO as a way of learning to
understand AVRDUDE and proper FUSE settings."

On Wed, Sep 8, 2021 at 2:15 PM George Herzog <jac...@gm...>
wrote:

> Hi Helen,
> I strongly advise you to* avoid *use of Atmel Studio or the Microchip
> successor.
>
> Using the standalone Atmel assembler in Windows is a much easier solution
> to control. The Microsoft VisualStudio software bogs down and has a very
> challenging learning curve with getting good results.
>
> *It sounds as though you successfully compiled binaries in hex files, but
> you may very likely hit a snag in AVRDUDE. *
>
> It is very common when installing Forth to deploy the wrong fuse setting
> and end up with no serial port response. So you might consider using an
> online Atmel Fuse calculator to confirm your fuse settings.
>
> HERE IS A LINK ==> https://www.engbedded.com/fusecalc/
>
> THERE ARE OTHERS IF THIS ONE DOESN'T APPEAL TO YOU.
>
> +++++++++++++++++++++++++
> Also, make sure that you understand what the AVRDUDE output is saying.
> There are 3 separate parts to a successful download.  The .hex file for the
> flash, the .hex file for the eeprom, and the FUSE settings.
>
> If you don't your ATmega2560 binaries are correctly compiled, AmForth does
> have precompiled ready to load ATmega328p binaries that you can load to an
> ArduinoUNO as a way of learning to understand AVRDUDE and proper FUSE
> settings.
>
> I hope this will help.
> George Herzog
>
>
>
> On Wed, Sep 8, 2021 at 3:33 AM Helge Kruse <Hel...@gm...> wrote:
>
>> I am a newby to amForth. I want to use it at ATmega 2560. For the first
>> steps I want to use the more common board Arduino UNO.
>>
>> I flashed the files uno.hex and uno.eep.hex from the directory
>> amforth-6.9\appl\arduino to my Arduino UNO. This gives me a greeting
>>
>> amforth 6.9 ATmega328P Forthduino
>>  >
>>
>> I think, the mega328p fuses and the USB/serial connection are verified.
>> Now I want to build the amForth from the sources. The documentation at
>> http://amforth.sourceforge.net/UG/quick-windows.html is a bit dated (for
>> amForth 6.6). The Atmel studio is not available anymore. I found only
>> the Microchip Studio 7 as the successor of the Atmel studio at the
>> Microchip website. (Atmel has been purchased by Microchip.)
>>
>> I set up a main.asm file as
>>
>>      .include "preamble.inc"
>>      .equ F_CPU = 16000000
>>      .include "drivers/usart.asm"
>>      .include "amforth.asm"
>>
>> and configured the include directories:
>>         $(PackRepoDir)\atmel\ATmega_DFP\1.6.364\avrasm\inc
>>         amforth-6.9\avr8
>>         amforth-6.9\avr8\devices\atmega328p
>>         amforth-6.9\appl\arduino
>>         amforth-6.9\common
>> Without these directories some .asm files had not been found. The
>> Microchip Studio 7 compiles without errors:
>>
>> avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
>> (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
>> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
>> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
>> "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
>> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
>>
>>
>> Segment   Begin    End      Code   Data   Used    Size   Use%
>> -------------------------------------------------------------
>> [.cseg] 0x000000 0x007f82   1838  11508  13346   32768  40.7%
>> [.dseg] 0x000060 0x00011f      0    191    191    2048   9.3%
>> [.eseg] 0x000000 0x000086      0    134    134    1024  13.1%
>> Assembly complete, 0 errors. 8 warnings
>>
>> I can also provide the complete assembler stdout stream. But I hesitate
>> to send such a large mail to the list without request.
>>
>> But after flashing my.hex and my.eep to the Arduino UNO I can see
>> nothing. Therefore I assume something's wrong with my build.
>>
>> Can somebody provide an minimum example for a basic amForth project with
>> the Microchip Studio 7?
>> Is there any updated documentation for the build process that handles
>> the Studio 7 environment?
>> Any hints how I find and remove the problem?
>>
>> I hope this can be easily solved. I've seen in the mailing list archive
>> that a build with mega2560 was successful lately.
>>
>> Best regards,
>> Helge
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] Building amForth with Microchip Studio 7

[George H. <jac...@gm...>]

Hi Helen,
I strongly advise you to* avoid *use of Atmel Studio or the Microchip
successor.

Using the standalone Atmel assembler in Windows is a much easier solution
to control. The Microsoft VisualStudio software bogs down and has a very
challenging learning curve with getting good results.

*It sounds as though you successfully compiled binaries in hex files, but
you may very likely hit a snag in AVRDUDE. *

It is very common when installing Forth to deploy the wrong fuse setting
and end up with no serial port response. So you might consider using an
online Atmel Fuse calculator to confirm your fuse settings.

HERE IS A LINK ==> https://www.engbedded.com/fusecalc/

THERE ARE OTHERS IF THIS ONE DOESN'T APPEAL TO YOU.

+++++++++++++++++++++++++
Also, make sure that you understand what the AVRDUDE output is saying.
There are 3 separate parts to a successful download.  The .hex file for the
flash, the .hex file for the eeprom, and the FUSE settings.

If you don't your ATmega2560 binaries are correctly compiled, AmForth does
have precompiled ready to load ATmega328p binaries that you can load to an
ArduinoUNO as a way of learning to understand AVRDUDE and proper FUSE
settings.

I hope this will help.
George Herzog



On Wed, Sep 8, 2021 at 3:33 AM Helge Kruse <Hel...@gm...> wrote:

> I am a newby to amForth. I want to use it at ATmega 2560. For the first
> steps I want to use the more common board Arduino UNO.
>
> I flashed the files uno.hex and uno.eep.hex from the directory
> amforth-6.9\appl\arduino to my Arduino UNO. This gives me a greeting
>
> amforth 6.9 ATmega328P Forthduino
>  >
>
> I think, the mega328p fuses and the USB/serial connection are verified.
> Now I want to build the amForth from the sources. The documentation at
> http://amforth.sourceforge.net/UG/quick-windows.html is a bit dated (for
> amForth 6.6). The Atmel studio is not available anymore. I found only
> the Microchip Studio 7 as the successor of the Atmel studio at the
> Microchip website. (Atmel has been purchased by Microchip.)
>
> I set up a main.asm file as
>
>      .include "preamble.inc"
>      .equ F_CPU = 16000000
>      .include "drivers/usart.asm"
>      .include "amforth.asm"
>
> and configured the include directories:
>         $(PackRepoDir)\atmel\ATmega_DFP\1.6.364\avrasm\inc
>         amforth-6.9\avr8
>         amforth-6.9\avr8\devices\atmega328p
>         amforth-6.9\appl\arduino
>         amforth-6.9\common
> Without these directories some .asm files had not been found. The
> Microchip Studio 7 compiles without errors:
>
> avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
> (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
> "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
>
>
> Segment   Begin    End      Code   Data   Used    Size   Use%
> -------------------------------------------------------------
> [.cseg] 0x000000 0x007f82   1838  11508  13346   32768  40.7%
> [.dseg] 0x000060 0x00011f      0    191    191    2048   9.3%
> [.eseg] 0x000000 0x000086      0    134    134    1024  13.1%
> Assembly complete, 0 errors. 8 warnings
>
> I can also provide the complete assembler stdout stream. But I hesitate
> to send such a large mail to the list without request.
>
> But after flashing my.hex and my.eep to the Arduino UNO I can see
> nothing. Therefore I assume something's wrong with my build.
>
> Can somebody provide an minimum example for a basic amForth project with
> the Microchip Studio 7?
> Is there any updated documentation for the build process that handles
> the Studio 7 environment?
> Any hints how I find and remove the problem?
>
> I hope this can be easily solved. I've seen in the mailing list archive
> that a build with mega2560 was successful lately.
>
> Best regards,
> Helge
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Building amForth with Microchip Studio 7

[Tristan W. <ho...@tj...>]

Hi Helge,

I don't use studio, but from the command line you give below

> avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
> (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
> "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"

it looks like it is including files from the devices\atmega32
directory and using m32def.inc which are associated with the atmega32
chip rather than the atmega328p. Somewhere the target device needs to
be set to an atmega328p.

Kind regards,

Tristan

On 07Sep21 21:32, Helge Kruse wrote:
> I am a newby to amForth. I want to use it at ATmega 2560. For the first
> steps I want to use the more common board Arduino UNO.
> 
> I flashed the files uno.hex and uno.eep.hex from the directory
> amforth-6.9\appl\arduino to my Arduino UNO. This gives me a greeting
> 
> amforth 6.9 ATmega328P Forthduino
> >
> 
> I think, the mega328p fuses and the USB/serial connection are verified.
> Now I want to build the amForth from the sources. The documentation at
> http://amforth.sourceforge.net/UG/quick-windows.html is a bit dated (for
> amForth 6.6). The Atmel studio is not available anymore. I found only
> the Microchip Studio 7 as the successor of the Atmel studio at the
> Microchip website. (Atmel has been purchased by Microchip.)
> 
> I set up a main.asm file as
> 
>     .include "preamble.inc"
>     .equ F_CPU = 16000000
>     .include "drivers/usart.asm"
>     .include "amforth.asm"
> 
> and configured the include directories:
> 	$(PackRepoDir)\atmel\ATmega_DFP\1.6.364\avrasm\inc
> 	amforth-6.9\avr8
> 	amforth-6.9\avr8\devices\atmega328p
> 	amforth-6.9\appl\arduino
> 	amforth-6.9\common
> Without these directories some .asm files had not been found. The
> Microchip Studio 7 compiles without errors:
> 
> avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
> (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
> "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
> 
> 
> Segment   Begin    End      Code   Data   Used    Size   Use%
> -------------------------------------------------------------
> [.cseg] 0x000000 0x007f82   1838  11508  13346   32768  40.7%
> [.dseg] 0x000060 0x00011f      0    191    191    2048   9.3%
> [.eseg] 0x000000 0x000086      0    134    134    1024  13.1%
> Assembly complete, 0 errors. 8 warnings
> 
> I can also provide the complete assembler stdout stream. But I hesitate
> to send such a large mail to the list without request.
> 
> But after flashing my.hex and my.eep to the Arduino UNO I can see
> nothing. Therefore I assume something's wrong with my build.
> 
> Can somebody provide an minimum example for a basic amForth project with
> the Microchip Studio 7?
> Is there any updated documentation for the build process that handles
> the Studio 7 environment?
> Any hints how I find and remove the problem?
> 
> I hope this can be easily solved. I've seen in the mailing list archive
> that a build with mega2560 was successful lately.
> 
> Best regards,
> Helge
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth] Building amForth with Microchip Studio 7

[Helge K. <Hel...@gm...>]

I am a newby to amForth. I want to use it at ATmega 2560. For the first
steps I want to use the more common board Arduino UNO.

I flashed the files uno.hex and uno.eep.hex from the directory
amforth-6.9\appl\arduino to my Arduino UNO. This gives me a greeting

amforth 6.9 ATmega328P Forthduino
 >

I think, the mega328p fuses and the USB/serial connection are verified.
Now I want to build the amForth from the sources. The documentation at
http://amforth.sourceforge.net/UG/quick-windows.html is a bit dated (for
amForth 6.6). The Atmel studio is not available anymore. I found only
the Microchip Studio 7 as the successor of the Atmel studio at the
Microchip website. (Atmel has been purchased by Microchip.)

I set up a main.asm file as

     .include "preamble.inc"
     .equ F_CPU = 16000000
     .include "drivers/usart.asm"
     .include "amforth.asm"

and configured the include directories:
	$(PackRepoDir)\atmel\ATmega_DFP\1.6.364\avrasm\inc
	amforth-6.9\avr8
	amforth-6.9\avr8\devices\atmega328p
	amforth-6.9\appl\arduino
	amforth-6.9\common
Without these directories some .asm files had not been found. The
Microchip Studio 7 compiles without errors:

avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
(x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
-I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
-I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
"Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"


Segment   Begin    End      Code   Data   Used    Size   Use%
-------------------------------------------------------------
[.cseg] 0x000000 0x007f82   1838  11508  13346   32768  40.7%
[.dseg] 0x000060 0x00011f      0    191    191    2048   9.3%
[.eseg] 0x000000 0x000086      0    134    134    1024  13.1%
Assembly complete, 0 errors. 8 warnings

I can also provide the complete assembler stdout stream. But I hesitate
to send such a large mail to the list without request.

But after flashing my.hex and my.eep to the Arduino UNO I can see
nothing. Therefore I assume something's wrong with my build.

Can somebody provide an minimum example for a basic amForth project with
the Microchip Studio 7?
Is there any updated documentation for the build process that handles
the Studio 7 environment?
Any hints how I find and remove the problem?

I hope this can be easily solved. I've seen in the mailing list archive
that a build with mega2560 was successful lately.

Best regards,
Helge

Re: [Amforth] Compiling for a headless target

[Helge K. <Hel...@gm...>]

On 05.09.2021 18:08, Erich Wälde wrote:
> Hmmm, you sure??? If I look at my code ... usart-isr-rx.asm ...
> see below.
No. I was wrong. I wrote the mail without the documentation at hand. I
remembered incorrectly that the address is compared by the
microcontroller. That was wrong. The MPC checks only the most
significant bit. The address is to be checked in the ISR.
Sorry, my fault.

Best regards,
Helge

Re: [Amforth] Compiling for a headless target

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

Hello Helge,

Helge Kruse <Hel...@gm...> writes:

> Am 04.09.2021 um 14:38 schrieb Erich Wälde:
>
>> Using the serial interface for a rs485 connection ... now, that
>> I can understand :-) I have a collection of controllers "online",
>> descriptions start here (German text):
>> Vierte Dimension 2011/1
>> https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2011-01.pdf
>> Judging from your name German text should not be a problem for you.
> Thanks for that hint. It's a very interesting article. I will experiment
> with it. Yep, German is no problem for me.
>> I'm very interested to hear, how you get along. Feel free to ask
>> about technical details.
>
> I read about the MPC and find it very interesting. Unfortunately I won't
> be able to use it, since the bus also uses broadcast addresses (126,127)
> and the MPC is specific to one address (intentionally).

Hmmm, you sure??? If I look at my code ... usart-isr-rx.asm ...
see below.

When "silent", the usart is set to 7N2. With mpc mode enabled
incoming data isr will call into usart_rx_isr WHENEVER the
highest bit of the address is set. The other 7 bits are passed
in register UDRn --- oh, oh, my reading avr assembly brain isn't
really awake ... --- and then the incoming Byte is compared to
ram_station_id. If it matches switch usart to 8N1, if not,
ignore.

Noone stops you from comparing to several such IDs, I think.


http://amforth.sourceforge.net/Projects/RS485/RS485Bus.html
has this as Forth code. In section 6 (handling an incoming byte
according to MPC-mode) you can better see the line, where the
decision is made:
| : mpc-rx-isr
|   rx-err? 0= if
|     UDR0 c@             \ -- udata
|     mpc? if
|       stationID = if  \ <== add more stationID tests here ...
|         -mpc7
|       then
|     else
|       rx-store
|     then
|   then
| ;


Unless I have misunderstood your text ...


Cheers,
Erich


--- usart-isr-rx.asm -------------------------------------------
;;; AmForth Version 4.5
;;; usart driver, receiving

.set pc_ = pc
.org URXCaddr
  jmp_ usart_rx_isr
.org pc_

; sizes have to be powers of 2!
.equ usart_rx_size = $10
.equ usart_rx_mask = usart_rx_size - 1
.dseg
usart_rx_in: .byte 1
usart_rx_out: .byte 1
usart_rx_data: .byte usart_rx_size
.cseg

.if WANT_MPC == 0              ; --- original version ---
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
usart_rx_isr:
  push xl
  in xl, SREG
  push xl
  push xh
  push zl
  push zh

  lds xh, USART_DATA
  ; optional: check for certain character(s) (e.g. CTRL-C)
  ; and trigger a soft interrupt instead of storing the
  ; charater into the input queue.
  lds xl,usart_rx_in
  ldi zl, low(usart_rx_data)
  ldi zh, high(usart_rx_data)
  add zl, xl
  adc zh, zeroh
  st Z, xh

  inc xl
  andi xl,usart_rx_mask

  sts usart_rx_in, xl

usart_rx_isr_finish:
  pop zh
  pop zl
  pop xh
  pop xl
  out SREG, xl
  pop xl
  reti

.else                          ; --- MPC version ---

usart_rx_isr:
       push xl                 ; save registers
       in xl, SREG
       push xl
       push xh
       push zl
       push zh
       push temp0

       in_ xh, UCSRA                   ; xh = UCSRnA
       mov temp0, xh                   ; temp0 = xh; save value

       andi xh, (1<<FE) | (1<<DOR) | (1<<PE) ; set zero flag

       lds xh, USART_DATA              ; xh = UDRn
       brne usart_rx_isr_finish        ; test Z flag, --> _finish on error (zero flag=0)

       lds xl,usart_rx_in              ; xl = i_in
       ldi zl, low(usart_rx_data)      ; Z = &buf[0]
       ldi zh, high(usart_rx_data)     ;
       add zl, xl                      ; Z += i_in
       adc zh, zeroh                   ; .

       sbrc temp0, MPCM                ; if (UCSRnA[MPCM] == 0)
       rjmp usart_rx_isr_mpcmode       ; {

       st Z, xh                        ; . buf[i_in] = xh (== UDRn); normal mode

       inc xl                          ; . xl += 1
       andi xl,usart_rx_mask           ; . xl %= siz (Ringbuffer)
       sts usart_rx_in, xl             ; . i_in = xl

       rjmp usart_rx_isr_finish        ; } else {

usart_rx_isr_mpcmode:                  ; multi-processor-communication mode 

       ldi zl, low(ram_station_id)          ; . Z = &ram_station_id
       ldi zh, high(ram_station_id)         ; . .
       ld  xl, Z                       ; . xl = ram_station_id
       cp  xl, xh                      ; . xl == xh?
       brne usart_rx_isr_finish        ; . if ( ram_station_id == UDRn )
       andi temp0, (~(1<<MPCM))        ; . { we are called!
       out_ UCSRA, temp0               ; . . UCSRA = temp0; clear MPCM
       ldi  temp0, (USART_C_VALUE)     ; . . temp0 = USARC_C_VALUE
       out_ UCSRC, temp0               ; . . UCSRC = temp0; 8N1 mode

usart_rx_isr_finish:                   ; } _finish

       pop temp0                       ; restore registers
       pop zh
       pop zl
       pop xh
       pop xl
       out SREG, xl
       pop xl

       reti

.endif
; ( -- ) Hardware Access
; R( --)
; initialize usart
;VE_USART_INIT_RX:
;  .dw $ff06
;  .db "+usart"
;  .dw VE_HEAD
;  .set VE_HEAD = VE_USART_INIT_RX
XT_USART_INIT_RX_ISR:
  .dw DO_COLON
PFA_USART_INIT_RX_ISR:          ; ( -- )
  .dw XT_ZERO
  .dw XT_DOLITERAL
  .dw usart_rx_in
  .dw XT_STORE

  .dw XT_EXIT

----------------------------------------------------------------

-- 
May the Forth be with you ...

Re: [Amforth] Compiling for a headless target

[Helge K. <Hel...@gm...>]

Am 04.09.2021 um 14:38 schrieb Erich Wälde:

> Using the serial interface for a rs485 connection ... now, that
> I can understand :-) I have a collection of controllers "online",
> descriptions start here (German text):
> Vierte Dimension 2011/1
> https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2011-01.pdf
> Judging from your name German text should not be a problem for you.
Thanks for that hint. It's a very interesting article. I will experiment
with it. Yep, German is no problem for me.
> I'm very interested to hear, how you get along. Feel free to ask
> about technical details.

I read about the MPC and find it very interesting. Unfortunately I won't
be able to use it, since the bus also uses broadcast addresses (126,127)
and the MPC is specific to one address (intentionally).

There is also a technical problem with the compiling in Microchip
Studio, but that's a new mail (thread).

Best regards,
Helge

Re: [Amforth] Compiling for a headless target

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

Hello Helge,

welcome to the list!

I'm late to the show, but anyways ...

I personally would not use the serial console for something
else, but rather use a atmega644 or similar, which features two
separate serial interfaces.

Replicating code is imho most easy, if a controller is read back
via avrdude or similar. The resulting files are then flashed to
the other devices.

Helge Kruse <Hel...@gm...> writes:

> Instead of dumping the contents from the target I found another
> approach. The g4 <https://github.com/mikalus/g4> converter makes
> assembly source code from Forth code. I could use it to convert my code
> to assembler code that I could add the the amForth sources.

:-) If you look closely, you will find quite some similarity of
the AmForth code (esp. with releases up to 5.5) with the output
of g4. I do not know for sure, but it seem that Matthias has
generated a lot of code with g4. So yes, go for it!


Using the serial interface for a rs485 connection ... now, that
I can understand :-) I have a collection of controllers "online",
descriptions start here (German text):
Vierge Dimension 2011/1
https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2011-01.pdf
Judging from your name German text should not be a problem for you.

More description here:
http://amforth.sourceforge.net/Projects/RS485/RS485Bus.html

I'm very interested to hear, how you get along. Feel free to ask
about technical details.


Cheers,
Erich

-- 
May the Forth be with you ...

Re: [Amforth] Compiling for a headless target

[Helge K. <Hel...@gm...>]

On 31.08.21 11:29, Helge Kruse via Amforth-devel wrote:
> But I want
> to create a hex file with a real turnkey application that I can flash on
> another ATmega2560 device. After running all Forth source code to my
> "development" board I find the flash filled with the code. It should be
> possible to clone the flash content to another board without sending all
> the source trough a UART. The other idea I mentioned was to "dump" the
> added flash memory content and create an assembler source used in the
> AVR assembler.

Instead of dumping the contents from the target I found another
approach. The g4 <https://github.com/mikalus/g4> converter makes
assembly source code from Forth code. I could use it to convert my code
to assembler code that I could add the the amForth sources.

g4 requires that the referred words are defined, so that you have to
provide stubs for words that are missing in gforth but known to amForth,
e.g. MS. But as long as you can compile in gforth you can create source
files for amForth. Including these new files in you amForth skeleton
creates a new .hex file capable to be a turnkey application, in a .hex file.

>
> The reason to differentiate between development board and the target
> device is that the target device is that the target device has only one
> USART port connected. And this port is used on a RS485 field bus.

And you can flash the new .hex file on the ISP port.

Best regards,
Helge

Re: [Amforth] Compiling for a headless target

[Helge K. <Hel...@gm...>]

On 31.08.2021 18:40, BK Navarette wrote:
> May be you could do a memory dump using avrdude terminal mode after
> building the application interactively then flash that file to the next
> avr.
>
> This might work.
Thanks for this idea. Of cause, it's not absolutely necessary to create
the hex file with from source files in the AVR assembler or the running
Forth. The ISP interface should do the job to replicate the image.

Thanks,
Helge

Re: [Amforth] Compiling for a headless target

[BK N. <bkn...@gm...>]

May be you could do a memory dump using avrdude terminal mode after 
building the application interactively then flash that file to the next avr.

This might work.

Brian-in-ohio

On 8/31/21 05:37, George Herzog wrote:
> Martin Nichols has offered the simplest solution.
>
> On Tue, Aug 31, 2021 at 5:03 PM Martin Nicholas via Amforth-devel <
> amf...@li...> wrote:
>
>> On Tue, 31 Aug 2021 06:27:50 +0200
>> Helge Kruse <Hel...@gm...> wrote:
>>
>>> Hello, I am new to amForth.
>>>
>>> amForth is an interactive Forth. The compiler runs on the target and
>>> writes to the flash memory of the device. This requires to send all
>>> the source code through the UART interface.
>>>
>>> I want to develop a Forth application for a target that uses the
>>> ATmeage256 USART for the application data. In that case it would be
>>> desired to compile the application, create a hex file and use USBasp
>>> to flash it to the target.
>>>
>>> How can I compile the Forth words, probably with the AVR assembler,
>>> for a target without a free UART? Is there any idea of a cross
>>> compiler or generating of assembler source code that could be place
>>> in a file lilke appltrunkey.asm.
>>>
>>> Are there other ways to approach?
>>>
>>> Best regards,
>>> Helge
>>>
>>>
>>>
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>
>>>
>> ATmegas have at least two USARTs, I'd use one of them for your extra
>> interface. The advantages of Forth's interactivity is lost if you can
>> no longer interact with it via the terminal - you might as well write
>> in C.
>>
>> --
>> Regards,
>>
>> Martin Nicholas.
>>
>> E-mail: rep...@mg... (Address will be valid throughout 2021).
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

[George H. <jac...@gm...>]

Martin Nichols has offered the simplest solution.

On Tue, Aug 31, 2021 at 5:03 PM Martin Nicholas via Amforth-devel <
amf...@li...> wrote:

> On Tue, 31 Aug 2021 06:27:50 +0200
> Helge Kruse <Hel...@gm...> wrote:
>
> > Hello, I am new to amForth.
> >
> > amForth is an interactive Forth. The compiler runs on the target and
> > writes to the flash memory of the device. This requires to send all
> > the source code through the UART interface.
> >
> > I want to develop a Forth application for a target that uses the
> > ATmeage256 USART for the application data. In that case it would be
> > desired to compile the application, create a hex file and use USBasp
> > to flash it to the target.
> >
> > How can I compile the Forth words, probably with the AVR assembler,
> > for a target without a free UART? Is there any idea of a cross
> > compiler or generating of assembler source code that could be place
> > in a file lilke appltrunkey.asm.
> >
> > Are there other ways to approach?
> >
> > Best regards,
> > Helge
> >
> >
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> >
>
> ATmegas have at least two USARTs, I'd use one of them for your extra
> interface. The advantages of Forth's interactivity is lost if you can
> no longer interact with it via the terminal - you might as well write
> in C.
>
> --
> Regards,
>
> Martin Nicholas.
>
> E-mail: rep...@mg... (Address will be valid throughout 2021).
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Compiling for a headless target

[Helge K. <Hel...@gm...>]

On 31.08.2021 10:41, Martin Nicholas via Amforth-devel wrote:
>>
>> I want to develop a Forth application for a target that uses the
>> ATmeage256 USART for the application data. In that case it would be
>> desired to compile the application, create a hex file and use USBasp
>> to flash it to the target.
>>
>> How can I compile the Forth words, probably with the AVR assembler,
>> for a target without a free UART? Is there any idea of a cross
>> compiler or generating of assembler source code that could be place
>> in a file lilke appltrunkey.asm.
>>
>> Are there other ways to approach?
>>
>
> ATmegas have at least two USARTs, I'd use one of them for your extra
> interface. The advantages of Forth's interactivity is lost if you can
> no longer interact with it via the terminal - you might as well write
> in C.
>

Thanks for reply. I like the interactivity at the terminal. But I want
to create a hex file with a real turnkey application that I can flash on
another ATmega2560 device. After running all Forth source code to my
"development" board I find the flash filled with the code. It should be
possible to clone the flash content to another board without sending all
the source trough a UART. The other idea I mentioned was to "dump" the
added flash memory content and create an assembler source used in the
AVR assembler.

The reason to differentiate between development board and the target
device is that the target device is that the target device has only one
USART port connected. And this port is used on a RS485 field bus. There
is no chance to connect that device to a RS232 port on the PC.


Best regards,
Helge

Re: [Amforth] Compiling for a headless target

[Martin N. <amf...@mg...>]

On Tue, 31 Aug 2021 06:27:50 +0200
Helge Kruse <Hel...@gm...> wrote:

> Hello, I am new to amForth.
> 
> amForth is an interactive Forth. The compiler runs on the target and
> writes to the flash memory of the device. This requires to send all
> the source code through the UART interface.
> 
> I want to develop a Forth application for a target that uses the
> ATmeage256 USART for the application data. In that case it would be
> desired to compile the application, create a hex file and use USBasp
> to flash it to the target.
> 
> How can I compile the Forth words, probably with the AVR assembler,
> for a target without a free UART? Is there any idea of a cross
> compiler or generating of assembler source code that could be place
> in a file lilke appltrunkey.asm.
> 
> Are there other ways to approach?
> 
> Best regards,
> Helge
> 
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 

ATmegas have at least two USARTs, I'd use one of them for your extra
interface. The advantages of Forth's interactivity is lost if you can
no longer interact with it via the terminal - you might as well write
in C.

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2021).

Re: [Amforth] Compiling for a headless target

[Tristan W. <ho...@tj...>]

Hello and welcome Helge,

> amForth is an interactive Forth. The compiler runs on the target and
> writes to the flash memory of the device. This requires to send all the
> source code through the UART interface.

This is the usual way AmForth is used. However it is possible to write
words in AVR assembler and add them to the build process that creates
the two hex files that make up the base AmForth system (these are the
two hex files that are initially flashed). Such words would be
available to you without having to send Forth code over the UART.    

> I want to develop a Forth application for a target that uses the
> ATmeage256 USART for the application data.

By default, AmForth only knows about one UART and is expecting to
receive Forth over it. If instead, you want to receive application
data over that UART you could write a Forth word(s) to parse that
application data received over the UART (write the Forth word to do
it, send it over UART, execute the Forth word, disconnect the UART
from PC, connect UART to application data source). However, I think
this would be painful to develop and (very) limited in terms of rate
of data that could be handled.  

If the UC on which AmForth is running has multiple UARTs then it is
possible to use these for application data. This I have done in the
past

https://tjnw.co.uk/files/uarts/fsm-uart.mp4

but it means writing your own UART handlers (which can be done in
Forth). Again, application data rate may be limiting. You mentioned
the ATmega256 - were you looking at ATmega256X or the ATmega256RFR2?
They all have multiple UARTs I think.

Kind regards,

Tristan

[Amforth] Compiling for a headless target

[Helge K. <Hel...@gm...>]

Hello, I am new to amForth.

amForth is an interactive Forth. The compiler runs on the target and
writes to the flash memory of the device. This requires to send all the
source code through the UART interface.

I want to develop a Forth application for a target that uses the
ATmeage256 USART for the application data. In that case it would be
desired to compile the application, create a hex file and use USBasp to
flash it to the target.

How can I compile the Forth words, probably with the AVR assembler, for
a target without a free UART? Is there any idea of a cross compiler or
generating of assembler source code that could be place in a file lilke
appltrunkey.asm.

Are there other ways to approach?

Best regards,
Helge

Re: [Amforth] Newbie with a mega2560

[Michael P. <mp...@pl...>]

Hello Erich,

I've dusted off an MSP430 board I have here and might have to load it 
with noforth just to get an idea of what his code is doing with the BME280.

He uses some sort of defining word called 'value', that I need to look 
up with the MSP430.
There are a lot of others that will jump out as I pour over this 
listing, I'm sure.

Getting ready for our Field Day weekend, which starts tomorrow at 11:00 
local time and runs through Sunday 11:00.  This will be the last year we 
work under COVID rules, meaning I work from home and log via the 
internet. We normally head out for a camping weekend on some Forest 
Service land that we obtain a permit to use.  It's located at around 
6500 feet and gives us nice coverage.

Have you tried experimenting with the MSP430?  As I remember, I picked 
up a few of these boards back when they first were introduced.  I bought 
a few of them (called Launchpads) and played with one for a while, but 
wanted to more than it was capable of at the time.

So many parts ... so little time ... !!  :)

Kind regards,

Michael
k6MLE

On 6/17/2021 2:38 AM, Erich Wälde wrote:
> Hello Michael,
>
> Michael Picco <mp...@pl...> writes:
>
>> Hello!
>>
>> I finally have figured out how to efficiently interact with Amforth on my
>> mega2560 and have installed much of the I2C stuff on it.
> Good!
>
>> Question:
>>
>> Has anyone worked out how to talk to the BME280 sensor using Amforth?  Wading
>> through the spec sheet tells me it's going to be a challenge.  It would be
>> nice not to reinvent the 'wheel', if someone has already done the
>> heavy-lifting!
> I have, much to my dismay, spent more than 20 hours on this. Not
> once in my life have I seen such an awkward interface.
> Unbelievable.
>
> The C code on
> https://github.com/BoschSensortec/BME280_driver/blob/master/bme280.c
> is working. It is just not meaningfully documented. Code using
> this can be found here
> https://github.com/adafruit/Adafruit_BME280_Library
>
> You have to very carefully study the datasheet and obey the
> "signed" vs. "unsigned" song and dance. I have written C code to
> see, whether my intermediate calculations were correct. I have
> managed to calculate temperature and humidity. The humidity
> values were significantly too low (I do have more sensors). And
> on pressure values I gave up after wading through about halfway.
>
> That being said: I was pointed to a working implementation for
> noForth on MSP430, published in "Vierte Dimension" 2020-01
> https://forth-ev.de/wiki/vd-archiv
>
>
> As I said, working the sensor with C is ok, since the adafruit
> library is written and working. Working the sensor in Forth is
> kind of horrible, because you need to reverse engineer the
> calculation. WHY not spending the silicon to do the calculation
> "on board" and produce linear, compensated readings is beyond my
> imagination.
>
> I pulled the one BME280 sensor out, I will happily give it away.
> And I ordered a handful of expensive Sensirion SHT85 sensors for
> temperature, humidity and a mpx6115 sensor for pressure (needs
> an ADC). The sensirion sensors worked for me after a couple
> hours. I did not figure out, how to check the crc that comes
> with the data --- but that is left for another time.
>
> I can send my code re. BME289 your way, if you are interested.
> But do not spend countless hours on a misdesigned interface ...
>
>
> Cheers,
> Erich
>

Re: [Amforth] Newbie with a mega2560

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

Hello Michael,

Michael Picco <mp...@pl...> writes:

> Hello!
>
> I finally have figured out how to efficiently interact with Amforth on my
> mega2560 and have installed much of the I2C stuff on it.
Good!

>
> Question:
>
> Has anyone worked out how to talk to the BME280 sensor using Amforth?  Wading
> through the spec sheet tells me it's going to be a challenge.  It would be
> nice not to reinvent the 'wheel', if someone has already done the
> heavy-lifting!

I have, much to my dismay, spent more than 20 hours on this. Not
once in my life have I seen such an awkward interface.
Unbelievable.

The C code on
https://github.com/BoschSensortec/BME280_driver/blob/master/bme280.c
is working. It is just not meaningfully documented. Code using
this can be found here
https://github.com/adafruit/Adafruit_BME280_Library

You have to very carefully study the datasheet and obey the
"signed" vs. "unsigned" song and dance. I have written C code to
see, whether my intermediate calculations were correct. I have
managed to calculate temperature and humidity. The humidity
values were significantly too low (I do have more sensors). And
on pressure values I gave up after wading through about halfway.

That being said: I was pointed to a working implementation for
noForth on MSP430, published in "Vierte Dimension" 2020-01
https://forth-ev.de/wiki/vd-archiv


As I said, working the sensor with C is ok, since the adafruit
library is written and working. Working the sensor in Forth is
kind of horrible, because you need to reverse engineer the
calculation. WHY not spending the silicon to do the calculation
"on board" and produce linear, compensated readings is beyond my
imagination.

I pulled the one BME280 sensor out, I will happily give it away.
And I ordered a handful of expensive Sensirion SHT85 sensors for
temperature, humidity and a mpx6115 sensor for pressure (needs
an ADC). The sensirion sensors worked for me after a couple
hours. I did not figure out, how to check the crc that comes
with the data --- but that is left for another time.

I can send my code re. BME289 your way, if you are interested.
But do not spend countless hours on a misdesigned interface ...


Cheers,
Erich

-- 
May the Forth be with you ...

Re: [Amforth] Newbie with a mega2560

[Michael P. <mp...@pl...>]

Hello!

I finally have figured out how to efficiently interact with Amforth on 
my mega2560 and have installed much of the I2C stuff on it.

Question:

Has anyone worked out how to talk to the BME280 sensor using Amforth?  
Wading through the spec sheet tells me it's going to be a challenge.  It 
would be nice not to reinvent the 'wheel', if someone has already done 
the heavy-lifting!

Kind regards,

Michael

K6MLE

[Amforth] AVR8: Mega 2560 Wiping Flash Memory

[Martin N. <amf...@mg...>]

I had problems with my Arduino Mega erasing parts of the flash memory;
sometimes the odd byte, sometimes the odd page.

I changed 3 things to the flashing code to make the problem go away:

1. Checked the SPMCSR:RWWSB bit. 
This is a crib from the Atmel example
(29.6.13 Simple Assembly Code Example for a Boot Loader).
From the docs: "When the RWWSB bit is set, the RWW section cannot be
accessed."

Cribbed code:
	; return to RWW section
	; verify that RWW section is safe to read
	Return:
	in temp1, SPMCSR
	sbrs temp1, RWWSB ; The RWW section is not ready yet
	ret
	; re-enable the RWW section
	ldi spmcrval, (1<<RWWSRE) | (1<<SPMEN)
	call Do_spm
	rjmp Return


2. Added a "Crash Trap" after NRWW_START_ADDR and immediately before the
flashing code. This performs a reset rather than bumbling on and
possibly overwriting some arbitrary FLASH.
I chose this snippet:
	nop   ; Some nops to synchronise.
	nop
	jmp_ PFA_COLD

Certainly a Forth in development can end up executing empty FLASH
memory. In the big Megas (store-i_big.asm) in particular, empty memory
leads inexorably to the flashing code. All this rather depends on the
function of M/C code instruction $FF, which seems undefined, so is
probably a noop.

3. Disabled interrupts much earlier.
Before any page is erased these should be switched off. Why?
The user may be writing to Page 0 or to the page containing "isr:".
Since time effectively stands still during flashing,
I issue a CLI at the earliest possible moment. The Atmel
example above says: "It is assumed that either the interrupt table is
moved to the Boot loader section or that the interrupts are disabled."
Under these circumstances the CLI in "dospm:" is no longer required.

Feel free to dispute any of these points; I'm all ears.

Remember: Aunty Atmel always knows best. She is omniscient here.

Source files:
amforth-6.9/avr8/words/store-i_big.asm
amforth-6.9/avr8/words/store-i_nrww.asm

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2021).

Re: [Amforth] Newbie with a mega2560

[Tristan W. <ho...@tj...>]

Hi Michael,

Glad it is working.

I use amforth-shell.py which is in the tools directory. It needs
python3 and pySerial to be installed to work.

A basic command line looks like this

amforth-shell.py --port DEVICE --speed 38400 FILE_TO_UPLOAD

but there are many other options and commands (such as the directive
#include). The documentation is in the python3 source.  

Best wishes,
Tristan


On 03Jun21 21:43, Michael Picco wrote:
> Hi Tristan,
> 
> I've got it up and running; even adding 'marker'.
> You have probably mentioned it before, but what is the best interface to use
> that will allow me to upload source files?
> 
> Thank you for your patience!
> 
> Kind regards,
> 
> Michael
> 
> On 6/2/2021 8:36 AM, Tristan Williams wrote:
> > Hi Michael,
> > 
> > I used
> > 
> > FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m
> > 
> > Best wishes,
> > Tristan
> > 
> > On 02Jun21 07:14, Placerville.me wrote:
> > > Hello Tristan,
> > > Thank you for this!  I will give it a try later today.  What fuse settings did you use?
> > > 
> > > Kind regards,
> > > 
> > > Michael
> > > 
> > > Sent from my iPhone
> > > 
> > > > On Jun 2, 2021, at 01:18, Tristan Williams <ho...@tj...> wrote:
> > > > 
> > > > Hi Michael,
> > > > 
> > > > I hope you got AmForth to build successfully under windows for the
> > > > atmega2560, but if not, I have built it for my Arduino MEGA using the
> > > > most recent source (r2457).
> > > > 
> > > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/
> > > > 
> > > > I have uploaded the resulting hex files to
> > > > 
> > > > https://tjnw.co.uk/amforth-bin/
> > > > 
> > > > I also loaded marker.frt onto the Arduino MEGA and checked that it
> > > > does what it should do (see [1]).
> > > > 
> > > > Best wishes,
> > > > Tristan
> > > > 
> > > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html
> > > > 
> > > > > On 24May21 17:57, Michael Picco wrote:
> > > > > Hello Martin,
> > > > > Thank you for responding!
> > > > > In my work directory, which is aptly named 'amforth-6.9', I don't see a copy
> > > > > of the template.asm file with "amforth-low.asm" mentioned.  The
> > > > > amforth-low.asm file is referenced in the avr8 subdirectory.  Is there
> > > > > something I am missing?
> > > > > 
> > > > > Kind regards,
> > > > > Michael
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote:
> > > > > > The crucial file to include for an ATmega is the confusingly named:
> > > > > > "amforth-low.asm" which needs to be un-commented in template.asm.
> > > > > > 
> > > > > > All the code is then in low flash memory apart from the flash burning
> > > > > > routine which should be found at NRWW_START_ADDR (0x01f000).
> > > > > > 
> > > > > > Often, with a new device, you need to burn the fuses "make write-fuse",
> > > > > > before flashing (and burning fuses for a second time) with "make
> > > > > > install".
> > > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > Amforth-devel mailing list for http://amforth.sf.net/
> > > > > Amf...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > > 
> > > > _______________________________________________
> > > > Amforth-devel mailing list for http://amforth.sf.net/
> > > > Amf...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > 
> > > 
> > > _______________________________________________
> > > Amforth-devel mailing list for http://amforth.sf.net/
> > > Amf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > 
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 

Re: [Amforth] Newbie with a mega2560

[Mark R. <cab...@gm...>]

On Wed, Jun 2, 2021 at 6:37 PM Tristan Williams <ho...@tj...> wrote:

> Hi Michael,
>
> I used
>
> FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m
>
> Best wishes,
> Tristan
>
> That makes sense. It's the same high fuse setting as I suggested but with
the jtag interface activated. I don't use that so I turned it off. Where
did you get the 0xDC setting for that fuse from? It really does seem to be
incorrect for a chip with 4k bootloader. Having just looked back into the
atmega2561 appl directory I just realized there isn't a makefile (or I
suppose, a bat file for windows) with the amforth defauts in it. I was just
getting ready to burn this into old 3D printer mega when I saw Tristan had
already done just that.

Good luck with the project!
Mark



> On 02Jun21 07:14, Placerville.me wrote:
> > Hello Tristan,
> > Thank you for this!  I will give it a try later today.  What fuse
> settings did you use?
> >
> > Kind regards,
> >
> > Michael
> >
> > Sent from my iPhone
> >
> > > On Jun 2, 2021, at 01:18, Tristan Williams <ho...@tj...> wrote:
> > >
> > > Hi Michael,
> > >
> > > I hope you got AmForth to build successfully under windows for the
> > > atmega2560, but if not, I have built it for my Arduino MEGA using the
> > > most recent source (r2457).
> > >
> > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/
> > >
> > > I have uploaded the resulting hex files to
> > >
> > > https://tjnw.co.uk/amforth-bin/
> > >
> > > I also loaded marker.frt onto the Arduino MEGA and checked that it
> > > does what it should do (see [1]).
> > >
> > > Best wishes,
> > > Tristan
> > >
> > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html
> > >
> > >> On 24May21 17:57, Michael Picco wrote:
> > >> Hello Martin,
> > >> Thank you for responding!
> > >> In my work directory, which is aptly named 'amforth-6.9', I don't see
> a copy
> > >> of the template.asm file with "amforth-low.asm" mentioned.  The
> > >> amforth-low.asm file is referenced in the avr8 subdirectory.  Is there
> > >> something I am missing?
> > >>
> > >> Kind regards,
> > >> Michael
> > >>
> > >>
> > >>
> > >>
> > >>> On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote:
> > >>> The crucial file to include for an ATmega is the confusingly named:
> > >>> "amforth-low.asm" which needs to be un-commented in template.asm.
> > >>>
> > >>> All the code is then in low flash memory apart from the flash burning
> > >>> routine which should be found at NRWW_START_ADDR (0x01f000).
> > >>>
> > >>> Often, with a new device, you need to burn the fuses "make
> write-fuse",
> > >>> before flashing (and burning fuses for a second time) with "make
> > >>> install".
> > >>>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Amforth-devel mailing list for http://amforth.sf.net/
> > >> Amf...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > >
> > >
> > > _______________________________________________
> > > Amforth-devel mailing list for http://amforth.sf.net/
> > > Amf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> >
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>