amforth-devel — Development discussion and user support

[Amforth] Summary for ATmega644P

[Stephen S. <dee...@gm...>]

I did load the *'amforth-6.9\appl\eval-pollin\p644.*'* hex and eep files to
check things.  It works and I can make new words.  But, when I loaded (via
realterm, all ok):

   - to-name.frt
   - see.frt

see always returns 'not found' on any word I try.
> ' see see

not found ok

> ' reveal see

not found ok

>

------------------------------ In addition -----------------------
For whatever reason the "sanguino" does not work.  See previous for UART
setup, I used what was there in the assembly file.  I did check all of the
hardware and settings you mentioned. The 644 that I am using is the same as
above.  Same baud rate (preamble.inc).  It does not appear to me, on the
surface, that there is a difference between this and the p644 (from a
hardware/setup  perspective), just a USART.  I have been busier than usual,
but will work on things this weekend, dig into the template file and start
from scratch.

Regards & thanks.

Re: [Amforth] General AVR (644P and 328Px)

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

Hello Stephen,

Stephen Simmons <dee...@gm...> writes:

> I have been trying to get the 644P  'sanguino' to build and run, but it
> never initializes uart0 properly. Leaves out the initialization of the
> UBRR.  The baud rate is defined in the INC.  I believe that I have gone
> through the instructions as best I can, but they don't exactly (to me)
> match the 6.9 layout.  I have been able to build from both the command line
> and MicroChip studio.  I have been working with AVR for well
> over 20 years.

concentrating on this part.

The controller never talks to you? Is that "the error"?

given:
- controller atmega644p
- board? sanguino??? I don't think, I have one of those ...

releases/6.9/appl/arduino/sanguino.asm says:
| .include "preamble.inc"
| .equ F_CPU = 16000000
| .include "drivers/usart_0.asm"
| .include "amforth.asm"

- crystal frequency? 16 MHz
- uart? usart_0.asm, which means pins d0,d1


Now. The Arduinos are sold with a bootloader on them and
specific fuse settings. As far as I can tell, you always need to
double check and mostly change the fuses.

on atmega644p I use LFUSE=0xd7 HFUSE=0x99
or (more often)     LFUSE=0xe6 HFUSE=0x99

releases/6.9/appl/arduino/readme.txt says:
Fuses (E,H,L) FD F9 FF (Sanguino)

So there is a difference. I have in the past prodded a few hours
reading the datasheet to understand this. And then I never touch
it again. There are websites to help with this, but I always use
the datasheet.

Then there is the baudrate hiding somewhere ...
releases/6.9/avr8/preamble.inc says:
; 10 per mille (1 per cent) is ok.
.set BAUD = 38400

ok. Now, what do I actually use? I have started with amforth
before the appl/arduino directory existed. So I always base my
projects on appl/template. And thus:

| .../firmware/station-0x7f 33 > grep -v '^;' main.asm | grep -v '^$'
| .include "preamble.inc"
| .set AMFORTH_RO_SEG = NRWW_START_ADDR
| .equ F_CPU = 11059200
| .set BAUD=115200
| .include "drivers/usart_0.asm"
| .set WANT_IGNORECASE = 0
| .set WANT_INTERRUPTS = 1
| .set WANT_INTERRUPT_COUNTERS = 1
| .include "amforth.asm"

Note that I use a baud rate crystal.

Does this help?

>>>snip<

Cheers,
Erich


-- 
May the Forth be with you ...

Re: [Amforth] General AVR (644P and 328Px)

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

Hello Stephen,

welcome to the list!

Stephen Simmons <dee...@gm...> writes:

> I have been trying to get the 644P  'sanguino' to build and run, but it
> never initializes uart0 properly. Leaves out the initialization of the
> UBRR.  The baud rate is defined in the INC.

Well, the 644 has *two* serial interfaces, so one thing could
be, that you have included the wrong definition file. I do use
644PA all the time. I have a definition file for 644P somewhere,
but I need to look for it.

Another common error is the clock frequency. There is the what
the crystal has printed on. And then there are a few fuse bits,
which can make life miserable:
- there is a bit to use the internal RC oszillator at 1 MHz
  iirc.
- there is a bit to divide clock by 8 or maybe it was uart
  clock??? But configuring baud rate/8 on your terminal might
  help.

I'll check for the configuration I use over the weekend.

> ... I have been working with AVR for well over 20 years.
It's probably something minor. And you probably checked all of
the above.

> So, then I tried the UNO.hex and UNO.eep.hex on the Microchip ATmega328PB
> from the arduino directory.  It appears the PB is not compatible with the
> UNO (I don't have another option).  While it does run after any definition
> it tends to stop responding/hangs (for a bit).  For example:
>
>
> *amforth 6.9 ATmega328P Forthduino> 3 4 + .7  ok> : x2 dup + ;  ok> 2 x2 .*
>
> *amforth 6.9 ATmega328P Forthduino> 2 x2 .amforth 6.9 ATmega328P
> Forthduino> 3 4 + .*
>
> As you can see I get the banner and a prompt.  Operations like add work
> until a definition, such as, x2.  All seems fine after the 'x2' definition,
> but any attempt to use it fails.  Using the definition of x2 will cause the
> banner to reappear after several seconds. Trying to print from the top of
> the stack also causes a new banner.  The only way to recover is a
> reset/power cycle.  The EEPROM no longer matches the original UNO.eep.hex
> file (not sure if this is normal or not)..
>
> I will continue to work things, I want to eventually augment my engine
> control unit with an ATmega64M1 via CAN.  I have an extensive amount of CAN
> related software and peripherals that I would like to interface with FORTH.
>

I would not expect the prebuilt uno.* files to work on a 328P_B_
--- something I have not heard about before.


> Any hints or suggestions would be appreciated.

Cheers,
Erich

-- 
May the Forth be with you ...

[Amforth] ATmega328PB - hanging

[Stephen S. <dee...@gm...>]

I did see posts/problems with different implementations of AmForth hanging.

Not sure they are related to my issues, but they do seem similar by
description.

*One additional note:*
*The EEPROM has to be reprogrammed for the 328PB to recover, a power cycle
actually does not work!*

I did load the 644 version from the *eval-pollin* directory to my board and
it works fine, so I know it can be built.  Will try the 328 version later
on my Microchip 328PB board.

Regards

[Amforth] Didn't cut and past well... see previous post.

[Stephen S. <dee...@gm...>]

*amforth 6.9 ATmega328P Forthduino*

*> 3 4 + .*

*7  ok*

*> : x2 dup + ;*

* ok*

*> 2 x2 .*

*amforth 6.9 ATmega328P Forthduino*

*> 2 x2 .*

*amforth 6.9 ATmega328P Forthduino*

*> 3 4 + .*

*amforth 6.9 ATmega328P Forthduino*

[Amforth] General AVR (644P and 328Px)

[Stephen S. <dee...@gm...>]

I have been trying to get the 644P  'sanguino' to build and run, but it
never initializes uart0 properly. Leaves out the initialization of the
UBRR.  The baud rate is defined in the INC.  I believe that I have gone
through the instructions as best I can, but they don't exactly (to me)
match the 6.9 layout.  I have been able to build from both the command line
and MicroChip studio.  I have been working with AVR for well over 20 years.

So, then I tried the UNO.hex and UNO.eep.hex on the Microchip ATmega328PB
from the arduino directory.  It appears the PB is not compatible with the
UNO (I don't have another option).  While it does run after any definition
it tends to stop responding/hangs (for a bit).  For example:







*amforth 6.9 ATmega328P Forthduino> 3 4 + .7  ok> : x2 dup + ;  ok> 2 x2 .*



*amforth 6.9 ATmega328P Forthduino> 2 x2 .amforth 6.9 ATmega328P
Forthduino> 3 4 + .*

As you can see I get the banner and a prompt.  Operations like add work
until a definition, such as, x2.  All seems fine after the 'x2' definition,
but any attempt to use it fails.  Using the definition of x2 will cause the
banner to reappear after several seconds. Trying to print from the top of
the stack also causes a new banner.  The only way to recover is a
reset/power cycle.  The EEPROM no longer matches the original UNO.eep.hex
file (not sure if this is normal or not)..

I will continue to work things, I want to eventually augment my engine
control unit with an ATmega64M1 via CAN.  I have an extensive amount of CAN
related software and peripherals that I would like to interface with FORTH.

Any hints or suggestions would be appreciated.

Regards

[Amforth] ATmega64M1 and similar

[Stephen S. <dee...@gm...>]

There does not seem to be any UART defined for this family.

There is a LINxxx/UART component that can either be used for a LIN bus or a
UART, but it does not have the usual UDRxx structure.  I was wondering if
anyone had actually ported to the chip, there seems to be nothing in the
mailing list.

I am trying to mimic the UDRxxx implementation, but have not had much
success  so far.

Regards

[Amforth] Studio 7 Questions

[CVBruce <cv...@gm...>]

Hi all,

I finally gave up on finding a download of avrasm2.exe and associated files and downloaded Studio 7.

For those of your that have installed/run Studio 7 on non-intel Linux is there a preference between Wine and Box86 environments? Does one work better than the other?

Second question, If I remember the last time I did this, there were instructions on what to copy out of the Studio installed files to set up a command line tool chain for building AmForth that were, shall we say, less than perfect.  Are the current instructions “correct”?  Better yet does someone have a batch/shell script that will do the job for me.

Thanks,

Bruce

Re: [Amforth] Building amForth with Microchip Studio 7

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

On 09.09.2021 09:37, Tristan Williams wrote:
> Hi Helge,
>
> A mystery, but given that, as far as I know, every (modern) build
> eventually uses avrasm2.exe to create the hex files, one that should
> be solvable.
I absolutely agree. And the Studio 7 comes with avrasm2. There is a
version update from 2.1.52 as you can find in
appl\atmega2561\atmega256.lst to the current version 2.2.8. But this is
not important.

> Given that you have an UNO build working, I can only
> think that your atmega2560 build is not finding all the needed files
> (or finding some it shouldn't) or that the build target is not
> actually an atmega2560.
The target is an atmega2560. The device signature is 0x1e9801, and C
programs run fine.

> I use a Makefile based build (on macos) that is based on the one that
> is part of the distribution. I can send you an archive with the
> Makefile, list file, etc. for you to check over. I don't have access
> to a Windows machine or I would try to replicate what you are doing.
It was not a question of the build environment (make/Studio) or the OS.

The main difference between the ATmega328P and the ATmega2560 is the  is
that the file appl_8k.inc is included, if the flash size is > 8000. The
asmforth.asm can't be used in that case as it is described in
http://amforth.sourceforge.net/UG/windows.html

Instead of "amforth.asm" the file "asmforth-low.asm" must be included.
This can also be found at appl\atmega2561\atmega256.asm. But this
example is not for Arduino ATMEGA256. It uses a different USART for the
terminal.

Here is my working example:

; First is to include macros and default settings from the amforth
; directory.
	.include "preamble.inc"
; amforth needs two essential parameters
; CPU clock in hertz, 1MHz is factory default
	.equ F_CPU = 16000000
; and the actual USART port.
	.include "drivers/usart_0.asm"
; Include the whole source tree.
	.include "amforth-low.asm"

And here are the avrdude parameter to flash the device
-c usbasp -p m2560 -V -u -U flash:w:my.hex -U eeprom:w:my.eep \
	-U efuse:w:0xFD:m -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m

I am happy that I can now start Forth on my ATMEGA2560 Arduino.

Best regards,
Helge

Re: [Amforth] Building amForth with Microchip Studio 7

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

Hi Helge,

A mystery, but given that, as far as I know, every (modern) build
eventually uses avrasm2.exe to create the hex files, one that should
be solvable. Given that you have an UNO build working, I can only
think that your atmega2560 build is not finding all the needed files
(or finding some it shouldn't) or that the build target is not
actually an atmega2560. 

I use a Makefile based build (on macos) that is based on the one that
is part of the distribution. I can send you an archive with the
Makefile, list file, etc. for you to check over. I don't have access
to a Windows machine or I would try to replicate what you are doing.

Kind regards,

Tristan

On 08Sep21 19:40, Helge Kruse wrote:
> 
> 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
> 
> 
> 
> _______________________________________________
> 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 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
>