amforth-devel — Development discussion and user support

Re: [Amforth] successful compilation with avra

[Brian K N. <bkn...@gm...>]

That is awesome news!
Brian-in-ohio


On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> wrote:

> Hello AmForth. It has been some time and quite weird things since last I've
> been here. I am still using AmForth with my trusty atmega1284p and learning
> the language as time permits. I remember having heard talk that avra had
> gotten (almost) to the point of being able to compile the source tree here.
> First I tried with 1.3 I think and it failed miserably. Then I found a repo
> on github (Ro5bert/avra) that seemed to almost but not quite do it. I was
> getting a pile of errors for macro calls. So looking into the issues I saw
> that someone had forked that repo and fixed the issue. Something to do with
> not having a space between the opening parenthesis and the macro name. So I
> tracked down the fix branch (srtlg/avra -b development-issue54 if I
> remember correctly) and built that locally. Then substituted that avra
> version with the wine one I had been using to build.
> It still didn't build. Very almost, but not quite.
> However, the issue was with errors in /avr8/words/d-lesszero.asm about the
> Y register not being declared and/or able to be used for the adiw call.
> Looking into the source tree I found other usages of y in those calls but
> they were all in lower case.
> Yeah, that did fix it. I'm not sure that I can flash my controller here
> since I'm on summer break but it does seem promising. Or maybe I did pack
> my programmer and can give it a go. The file sizes are the same or similar
> but there are differences. Granted, I've made changes that may not be
> represented in my working project and it may just be that.
> Time will tell but it would be great to get rid of the need to use wine to
> build AmForth here.
> Well well well. It appears to have worked. I make install'd the whole thing
> (since for some reason I did pack my usbasp and could try it out. I'm sure
> more testing is needed but this really is pretty cool.
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] successful compilation with avra

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

Hello AmForth. It has been some time and quite weird things since last I've
been here. I am still using AmForth with my trusty atmega1284p and learning
the language as time permits. I remember having heard talk that avra had
gotten (almost) to the point of being able to compile the source tree here.
First I tried with 1.3 I think and it failed miserably. Then I found a repo
on github (Ro5bert/avra) that seemed to almost but not quite do it. I was
getting a pile of errors for macro calls. So looking into the issues I saw
that someone had forked that repo and fixed the issue. Something to do with
not having a space between the opening parenthesis and the macro name. So I
tracked down the fix branch (srtlg/avra -b development-issue54 if I
remember correctly) and built that locally. Then substituted that avra
version with the wine one I had been using to build.
It still didn't build. Very almost, but not quite.
However, the issue was with errors in /avr8/words/d-lesszero.asm about the
Y register not being declared and/or able to be used for the adiw call.
Looking into the source tree I found other usages of y in those calls but
they were all in lower case.
Yeah, that did fix it. I'm not sure that I can flash my controller here
since I'm on summer break but it does seem promising. Or maybe I did pack
my programmer and can give it a go. The file sizes are the same or similar
but there are differences. Granted, I've made changes that may not be
represented in my working project and it may just be that.
Time will tell but it would be great to get rid of the need to use wine to
build AmForth here.
Well well well. It appears to have worked. I make install'd the whole thing
(since for some reason I did pack my usbasp and could try it out. I'm sure
more testing is needed but this really is pretty cool.

[Amforth] Followup: AmForth Project open for adoption

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

Sorry, hit the button quite prematurely :)


Dear AmForthers,

thank you so much for your kind words!

So far a person behind the email address "in...@un..." has
offered to help with AmForth. I have suggested to make an
appearance on the list.

Martin Nicholas has suggested to forward the original email to
comp.lang.forth. I have asked Bernd Paysan (of gforth fame) to
forward the original announcement. So the news it might reach a
greater group.

Brian Navarette has asked, whether the code of my "small" fork
is available. Yes it is, see below.

One of the things I did, but never announced is this: I
converted the subversion repository to git in two variants:

In this repository the release tree is spread out like in the
original subversion repository:
> https://git.sr.ht/~amforth/code-tree

And in this repository the releases have been converted to git
branches:
> https://git.sr.ht/~amforth/code

The account 'amforth' on sourcehut.org is a paid account. I'm
happy to provide funding for this account for the foreseeable
future and pass it on later. Carsten Strotmann has reserved the
domain amforth.net. currently it points to the sourceforge page,
if I am not mistaken.
> https://www.amforth.net/

So these are things to play with.

The web interface for Sourcehut.org works completely without
JavaScript, which is why I have chosen them and migrated all my
repositories. On top, changes on tickets and code can be coupled
to email. So changes can be managed with email workflows.
However, I have not understood all the neccessary details. I
don't remember just now, whether I configured a new mailing
list, probably not. Because I never really tested the workflow.

But these are all puzzle pieces to play with.

I admit that I have hesitated with the mailing list move as
well. I am a little concerned that this move might break the
small community. However, I would be more than happy to be
proven wrong.


So where is the above mentioned fork of AmForth Version 5.0? You
can find it in this repository:
> https://git.sr.ht/~ew/hbv3_am50forth
The corresponding project featuring the rs485 connected
controllers is growing at
> https://git.sr.ht/~ew/hausbus-v3
The hardware I use is described there as well
> https://git.sr.ht/~ew/TheStack

The second test is running happily and blinking its LED. 544000
seconds uptime without a hitch, so it's about halfway of what I
want to see (10^6 seconds or 12 days). I have started to
document this journey, and it should turn into English text
along the way.


Conclusions:
- Though I have stepped down, I am still the one with the keys,
  the janitor, so to speak.
- I don't think I am going to drop off the planet soon. Or at
  least this risk is not much greater than it was before.

What can you do?
- I would suggest that 3 people receive the credentials for
  sourceforge and sourcehut, just to reduce the bus factor. I
  suggest Carsten Strotmann, Tristan Williams and Martin
  Nicholas, but that is just me. Speak out, please.
- I still have a half baken document, how to make a release. So
  I should just send this as is, or add it to the repositories.
- everyone can make up their mind, if they prefer to move to git
  and sourceforge.
- whoever has more insight to the puzzle pieces at sourcehut can
  try to play with a email based workflow. I strongly suggest to
  create a public bug ticket instance, I percieved this as a
  significant lack in the past.

I would like to read your thoughts on the list. I have no idea,
how many there are reading. The number of subscribers is
probably not a good estimate. So, speak up, make yourself heard.
Thanks!

Cheers,
Erich


Erich Wälde <ew....@na...> writes:

> Dear AmForthers,
>
> I am herewith stepping down from the maintainer role of AmForth. For details,
> read on. If anyone is interested to take over, get in touch with me.
>
>
> In 2020 I received the logins of amforth.sourceforge.net, basically because I
> was lucky enough to have met Matthias personally a few times. At that time I
> had a lot of ideas on how to proceed. And while I managed to create an
> official release, there are a few obstacles in this path.
>
> First and foremost I am facing a health issue. It is subtle, but it
> seriously limits, what I can do. I still have to make several difficult
> decisions regarding my daily life. I have started to decrease the number of
> things on my list by cancelling items. I have to accept the fact, that I'm not
> in a position any more to advance the AmForth project in a meaningful way.
>
> Secondly, AmForth has become complex over time. Matthias added support for
> three more target platforms (msp430, arm, riscv32). Allthough access to these
> is easily achievable, I use only avr. And I use it less these days.
>
> Thirdly, AmForths tools are depending heavily on python code, a language I
> consider myself illiterate in. I have written a few small perl scripts around
> AmForth to serve my needs. I heavily depend on those and on a Makefile.
>
> Add the fact, that in 2020 I spent countless hours to port my data acquisition
> stuff at home from amforth 4.6 to 6.9 and it just did not become stable. To
> this day I still have no clue, why the thing hangs itself after some time,
> sometimes hours, sometimes several days. In other words: unusable.
>
>
> Step back: what would I have done, if I didn't know Matthias, and the project
> would just have become silent? Simplify. Simplify heavily.
>
> Very recently I have made a fork of AmForth release 5.0. That version is
> before support for msp430 was officially added (5.5). That version happens to
> compile with avra rather than wine/avrasm2.exe. Along the way I found, that
> avra has seen new releases, which add support for my beloved atmega644p and
> lots of fixes, which is nice! This removes the dependancy from wine and allows
> for smaller systems for development.
>
> So I have picked up my data acquisition project again with the fork mentioned
> above. Any Interrupt Service Routines are written in assembly to avoid the
> thing that I uncovered in 2017, namely a race condition 1 bit wide and 1
> instruction cycle long. I pick missing bits and pieces from later releases. I
> would like to add a few features regarding sensors with different needs. A
> first experiment has run more than 10^6s (12d) without any failure. So I am
> moderately optimistic to continue along this simplified path.
>
>
> Thanks to all, who have answered the list, contributed code, ideas,
> documentation in one form or other. It has been an interesting experience.
> And should you still care to listen: if you have one or a few more important
> plans, do not delay them, you might be unable to pursue them later.
>
> Happy hacking, and use the Forth!
>
> Cheers
> Erich

-- 
May the Forth be with you ...

[Amforth] Followup: AmForth Project open for adoption

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

Erich Wälde <ew....@na...> writes:

> [[PGP Signed Part:Undecided]]
>
> Dear AmForthers,
>
> I am herewith stepping down from the maintainer role of AmForth. For details,
> read on. If anyone is interested to take over, get in touch with me.
>
>
> In 2020 I received the logins of amforth.sourceforge.net, basically because I
> was lucky enough to have met Matthias personally a few times. At that time I
> had a lot of ideas on how to proceed. And while I managed to create an
> official release, there are a few obstacles in this path.
>
> First and foremost I am facing a health issue. It is subtle, but it
> seriously limits, what I can do. I still have to make several difficult
> decisions regarding my daily life. I have started to decrease the number of
> things on my list by cancelling items. I have to accept the fact, that I'm not
> in a position any more to advance the AmForth project in a meaningful way.
>
> Secondly, AmForth has become complex over time. Matthias added support for
> three more target platforms (msp430, arm, riscv32). Allthough access to these
> is easily achievable, I use only avr. And I use it less these days.
>
> Thirdly, AmForths tools are depending heavily on python code, a language I
> consider myself illiterate in. I have written a few small perl scripts around
> AmForth to serve my needs. I heavily depend on those and on a Makefile.
>
> Add the fact, that in 2020 I spent countless hours to port my data acquisition
> stuff at home from amforth 4.6 to 6.9 and it just did not become stable. To
> this day I still have no clue, why the thing hangs itself after some time,
> sometimes hours, sometimes several days. In other words: unusable.
>
>
> Step back: what would I have done, if I didn't know Matthias, and the project
> would just have become silent? Simplify. Simplify heavily.
>
> Very recently I have made a fork of AmForth release 5.0. That version is
> before support for msp430 was officially added (5.5). That version happens to
> compile with avra rather than wine/avrasm2.exe. Along the way I found, that
> avra has seen new releases, which add support for my beloved atmega644p and
> lots of fixes, which is nice! This removes the dependancy from wine and allows
> for smaller systems for development.
>
> So I have picked up my data acquisition project again with the fork mentioned
> above. Any Interrupt Service Routines are written in assembly to avoid the
> thing that I uncovered in 2017, namely a race condition 1 bit wide and 1
> instruction cycle long. I pick missing bits and pieces from later releases. I
> would like to add a few features regarding sensors with different needs. A
> first experiment has run more than 10^6s (12d) without any failure. So I am
> moderately optimistic to continue along this simplified path.
>
>
> Thanks to all, who have answered the list, contributed code, ideas,
> documentation in one form or other. It has been an interesting experience.
> And should you still care to listen: if you have one or a few more important
> plans, do not delay them, you might be unable to pursue them later.
>
> Happy hacking, and use the Forth!
>
> Cheers
> Erich


-- 
May the Forth be with you ...

Re: [Amforth] AmForth Project open for adoption

[Brian K N. <bkn...@gm...>]

Is the fork of amforth available anywhere?
brian-in-ohio

On 5/16/22, Martin Nicholas via Amforth-devel
<amf...@li...> wrote:
> Erich,
>
> Thanks for all your work.
>
> You may wish to advertise the vacancy on the USENET comp.lang.forth. A
> G account will do the job.
>
> On Fri, 06 May 2022 09:17:23 +0200
> Erich Wälde <ew....@na...> wrote:
>
>> Dear AmForthers,
>>
>> I am herewith stepping down from the maintainer role of AmForth. For
>> details, read on. If anyone is interested to take over, get in touch
>> with me.
>>
>>
>> In 2020 I received the logins of amforth.sourceforge.net, basically
>> because I was lucky enough to have met Matthias personally a few
>> times. At that time I had a lot of ideas on how to proceed. And while
>> I managed to create an official release, there are a few obstacles in
>> this path.
>>
>> First and foremost I am facing a health issue. It is subtle, but it
>> seriously limits, what I can do. I still have to make several
>> difficult decisions regarding my daily life. I have started to
>> decrease the number of things on my list by cancelling items. I have
>> to accept the fact, that I'm not in a position any more to advance
>> the AmForth project in a meaningful way.
>>
>> Secondly, AmForth has become complex over time. Matthias added
>> support for three more target platforms (msp430, arm, riscv32).
>> Allthough access to these is easily achievable, I use only avr. And I
>> use it less these days.
>>
>> Thirdly, AmForths tools are depending heavily on python code, a
>> language I consider myself illiterate in. I have written a few small
>> perl scripts around AmForth to serve my needs. I heavily depend on
>> those and on a Makefile.
>>
>> Add the fact, that in 2020 I spent countless hours to port my data
>> acquisition stuff at home from amforth 4.6 to 6.9 and it just did not
>> become stable. To this day I still have no clue, why the thing hangs
>> itself after some time, sometimes hours, sometimes several days. In
>> other words: unusable.
>>
>>
>> Step back: what would I have done, if I didn't know Matthias, and the
>> project would just have become silent? Simplify. Simplify heavily.
>>
>> Very recently I have made a fork of AmForth release 5.0. That version
>> is before support for msp430 was officially added (5.5). That version
>> happens to compile with avra rather than wine/avrasm2.exe. Along the
>> way I found, that avra has seen new releases, which add support for
>> my beloved atmega644p and lots of fixes, which is nice! This removes
>> the dependancy from wine and allows for smaller systems for
>> development.
>>
>> So I have picked up my data acquisition project again with the fork
>> mentioned above. Any Interrupt Service Routines are written in
>> assembly to avoid the thing that I uncovered in 2017, namely a race
>> condition 1 bit wide and 1 instruction cycle long. I pick missing
>> bits and pieces from later releases. I would like to add a few
>> features regarding sensors with different needs. A first experiment
>> has run more than 10^6s (12d) without any failure. So I am moderately
>> optimistic to continue along this simplified path.
>>
>>
>> Thanks to all, who have answered the list, contributed code, ideas,
>> documentation in one form or other. It has been an interesting
>> experience. And should you still care to listen: if you have one or a
>> few more important plans, do not delay them, you might be unable to
>> pursue them later.
>>
>> Happy hacking, and use the Forth!
>>
>> Cheers
>> Erich
>>
>
>
>
> --
> Regards,
>
> Martin Nicholas.
>
> E-mail: mg...@mg....
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] AmForth Project open for adoption

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

Erich,

Thanks for all your work.

You may wish to advertise the vacancy on the USENET comp.lang.forth. A
G account will do the job.

On Fri, 06 May 2022 09:17:23 +0200
Erich Wälde <ew....@na...> wrote:

> Dear AmForthers,
> 
> I am herewith stepping down from the maintainer role of AmForth. For
> details, read on. If anyone is interested to take over, get in touch
> with me.
> 
> 
> In 2020 I received the logins of amforth.sourceforge.net, basically
> because I was lucky enough to have met Matthias personally a few
> times. At that time I had a lot of ideas on how to proceed. And while
> I managed to create an official release, there are a few obstacles in
> this path.
> 
> First and foremost I am facing a health issue. It is subtle, but it
> seriously limits, what I can do. I still have to make several
> difficult decisions regarding my daily life. I have started to
> decrease the number of things on my list by cancelling items. I have
> to accept the fact, that I'm not in a position any more to advance
> the AmForth project in a meaningful way.
> 
> Secondly, AmForth has become complex over time. Matthias added
> support for three more target platforms (msp430, arm, riscv32).
> Allthough access to these is easily achievable, I use only avr. And I
> use it less these days.
> 
> Thirdly, AmForths tools are depending heavily on python code, a
> language I consider myself illiterate in. I have written a few small
> perl scripts around AmForth to serve my needs. I heavily depend on
> those and on a Makefile.
> 
> Add the fact, that in 2020 I spent countless hours to port my data
> acquisition stuff at home from amforth 4.6 to 6.9 and it just did not
> become stable. To this day I still have no clue, why the thing hangs
> itself after some time, sometimes hours, sometimes several days. In
> other words: unusable.
> 
> 
> Step back: what would I have done, if I didn't know Matthias, and the
> project would just have become silent? Simplify. Simplify heavily.
> 
> Very recently I have made a fork of AmForth release 5.0. That version
> is before support for msp430 was officially added (5.5). That version
> happens to compile with avra rather than wine/avrasm2.exe. Along the
> way I found, that avra has seen new releases, which add support for
> my beloved atmega644p and lots of fixes, which is nice! This removes
> the dependancy from wine and allows for smaller systems for
> development.
> 
> So I have picked up my data acquisition project again with the fork
> mentioned above. Any Interrupt Service Routines are written in
> assembly to avoid the thing that I uncovered in 2017, namely a race
> condition 1 bit wide and 1 instruction cycle long. I pick missing
> bits and pieces from later releases. I would like to add a few
> features regarding sensors with different needs. A first experiment
> has run more than 10^6s (12d) without any failure. So I am moderately
> optimistic to continue along this simplified path.
> 
> 
> Thanks to all, who have answered the list, contributed code, ideas,
> documentation in one form or other. It has been an interesting
> experience. And should you still care to listen: if you have one or a
> few more important plans, do not delay them, you might be unable to
> pursue them later.
> 
> Happy hacking, and use the Forth!
> 
> Cheers
> Erich
> 



-- 
Regards,

Martin Nicholas.

E-mail: mg...@mg....

Re: [Amforth] AmForth Project open for adoption

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

Thanks  for your efforts.

On Fri, May 6, 2022, 3:37 PM Erich Wälde <ew....@na...> wrote:

>
> Dear AmForthers,
>
> I am herewith stepping down from the maintainer role of AmForth. For
> details,
> read on. If anyone is interested to take over, get in touch with me.
>
>
> In 2020 I received the logins of amforth.sourceforge.net, basically
> because I
> was lucky enough to have met Matthias personally a few times. At that time
> I
> had a lot of ideas on how to proceed. And while I managed to create an
> official release, there are a few obstacles in this path.
>
> First and foremost I am facing a health issue. It is subtle, but it
> seriously limits, what I can do. I still have to make several difficult
> decisions regarding my daily life. I have started to decrease the number of
> things on my list by cancelling items. I have to accept the fact, that I'm
> not
> in a position any more to advance the AmForth project in a meaningful way.
>
> Secondly, AmForth has become complex over time. Matthias added support for
> three more target platforms (msp430, arm, riscv32). Allthough access to
> these
> is easily achievable, I use only avr. And I use it less these days.
>
> Thirdly, AmForths tools are depending heavily on python code, a language I
> consider myself illiterate in. I have written a few small perl scripts
> around
> AmForth to serve my needs. I heavily depend on those and on a Makefile.
>
> Add the fact, that in 2020 I spent countless hours to port my data
> acquisition
> stuff at home from amforth 4.6 to 6.9 and it just did not become stable. To
> this day I still have no clue, why the thing hangs itself after some time,
> sometimes hours, sometimes several days. In other words: unusable.
>
>
> Step back: what would I have done, if I didn't know Matthias, and the
> project
> would just have become silent? Simplify. Simplify heavily.
>
> Very recently I have made a fork of AmForth release 5.0. That version is
> before support for msp430 was officially added (5.5). That version happens
> to
> compile with avra rather than wine/avrasm2.exe. Along the way I found, that
> avra has seen new releases, which add support for my beloved atmega644p and
> lots of fixes, which is nice! This removes the dependancy from wine and
> allows
> for smaller systems for development.
>
> So I have picked up my data acquisition project again with the fork
> mentioned
> above. Any Interrupt Service Routines are written in assembly to avoid the
> thing that I uncovered in 2017, namely a race condition 1 bit wide and 1
> instruction cycle long. I pick missing bits and pieces from later
> releases. I
> would like to add a few features regarding sensors with different needs. A
> first experiment has run more than 10^6s (12d) without any failure. So I am
> moderately optimistic to continue along this simplified path.
>
>
> Thanks to all, who have answered the list, contributed code, ideas,
> documentation in one form or other. It has been an interesting experience.
> And should you still care to listen: if you have one or a few more
> important
> plans, do not delay them, you might be unable to pursue them later.
>
> Happy hacking, and use the Forth!
>
> Cheers
> Erich
>
> --
> May the Forth be with you ...
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] AmForth Project open for adoption

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

Dear AmForthers,

I am herewith stepping down from the maintainer role of AmForth. For details,
read on. If anyone is interested to take over, get in touch with me.


In 2020 I received the logins of amforth.sourceforge.net, basically because I
was lucky enough to have met Matthias personally a few times. At that time I
had a lot of ideas on how to proceed. And while I managed to create an
official release, there are a few obstacles in this path.

First and foremost I am facing a health issue. It is subtle, but it
seriously limits, what I can do. I still have to make several difficult
decisions regarding my daily life. I have started to decrease the number of
things on my list by cancelling items. I have to accept the fact, that I'm not
in a position any more to advance the AmForth project in a meaningful way.

Secondly, AmForth has become complex over time. Matthias added support for
three more target platforms (msp430, arm, riscv32). Allthough access to these
is easily achievable, I use only avr. And I use it less these days.

Thirdly, AmForths tools are depending heavily on python code, a language I
consider myself illiterate in. I have written a few small perl scripts around
AmForth to serve my needs. I heavily depend on those and on a Makefile.

Add the fact, that in 2020 I spent countless hours to port my data acquisition
stuff at home from amforth 4.6 to 6.9 and it just did not become stable. To
this day I still have no clue, why the thing hangs itself after some time,
sometimes hours, sometimes several days. In other words: unusable.


Step back: what would I have done, if I didn't know Matthias, and the project
would just have become silent? Simplify. Simplify heavily.

Very recently I have made a fork of AmForth release 5.0. That version is
before support for msp430 was officially added (5.5). That version happens to
compile with avra rather than wine/avrasm2.exe. Along the way I found, that
avra has seen new releases, which add support for my beloved atmega644p and
lots of fixes, which is nice! This removes the dependancy from wine and allows
for smaller systems for development.

So I have picked up my data acquisition project again with the fork mentioned
above. Any Interrupt Service Routines are written in assembly to avoid the
thing that I uncovered in 2017, namely a race condition 1 bit wide and 1
instruction cycle long. I pick missing bits and pieces from later releases. I
would like to add a few features regarding sensors with different needs. A
first experiment has run more than 10^6s (12d) without any failure. So I am
moderately optimistic to continue along this simplified path.


Thanks to all, who have answered the list, contributed code, ideas,
documentation in one form or other. It has been an interesting experience.
And should you still care to listen: if you have one or a few more important
plans, do not delay them, you might be unable to pursue them later.

Happy hacking, and use the Forth!

Cheers
Erich

-- 
May the Forth be with you ...

Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

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

The big advantage with the Arduino Mega is lots of 8 bit ports available
for parrallel i/o.  The Arduino Uno pretty much forces all i/o to be
serialized one way or another.

On Sun, Apr 17, 2022 at 3:33 PM Martin Nicholas via Amforth-devel <
amf...@li...> wrote:

> On Sun, 17 Apr 2022 07:47:15 +0100
> Tristan Williams <ho...@tj...> wrote:
>
> > Hi Christian,
> >
> > Glad it worked.
> >
> > > How much of 256KB flash is effectively usable with AmForth on the
> > > 2560? ?
> >
>
> 64k only (which is heaps) - W and IP are 16-bits only. The upper 64k is
> still available, a little bit is used for the flashing code. I use
> some of this space for user messages.
>
> > Good question. I don't know. The file avr8/words/store-i_big.asm may
> > give some clues.
> >
> > > Will this work as well on a Chinese  ATmega2560ProMini (with FTDI
> > > USB chip for terminal input) ?
> >
> > Again, I don't know. However, if the board has an ATmega2560 mcu
> > running at 16 MHz then there is good chance. I think only by flashing
> > the board and testing it will you have a better idea.
> >
>
> The clones work fine. Out of the box you might have to blow the fuses
> first - before flashing the memory.
>
> --
> Regards,
>
> Martin Nicholas.
>
> E-mail: rep...@mg... (Address will be valid throughout 2022).
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

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

On Sun, 17 Apr 2022 07:47:15 +0100
Tristan Williams <ho...@tj...> wrote:

> Hi Christian,
> 
> Glad it worked.
> 
> > How much of 256KB flash is effectively usable with AmForth on the
> > 2560? ?  
> 

64k only (which is heaps) - W and IP are 16-bits only. The upper 64k is
still available, a little bit is used for the flashing code. I use
some of this space for user messages.

> Good question. I don't know. The file avr8/words/store-i_big.asm may
> give some clues. 
> 
> > Will this work as well on a Chinese  ATmega2560ProMini (with FTDI
> > USB chip for terminal input) ?  
> 
> Again, I don't know. However, if the board has an ATmega2560 mcu
> running at 16 MHz then there is good chance. I think only by flashing
> the board and testing it will you have a better idea. 
> 

The clones work fine. Out of the box you might have to blow the fuses
first - before flashing the memory.

-- 
Regards,

Martin Nicholas.

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

Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

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

Hello,
I  believe only 50% of the Arduino Mega flash is available to Forth for
dictionary use.

This is simply a hardware barrier that exists. The additional 126kb
theoretically can be put to use in other ways, but I've not seem actually
solutions.
On Sun, Apr 17, 2022, 2:48 PM Tristan Williams <ho...@tj...> wrote:

> Hi Christian,
>
> Glad it worked.
>
> > How much of 256KB flash is effectively usable with AmForth on the 2560? ?
>
> Good question. I don't know. The file avr8/words/store-i_big.asm may give
> some
> clues.
>
> > Will this work as well on a Chinese  ATmega2560ProMini (with FTDI USB
> chip for terminal input) ?
>
> Again, I don't know. However, if the board has an ATmega2560 mcu
> running at 16 MHz then there is good chance. I think only by flashing
> the board and testing it will you have a better idea.
>
> > If so, may I share your links with a friend who has an
> ATmega2560ProMini?
>
> Yes.
>
> Kind regards,
>
> Tristan
>
> On 16Apr22 16:34, Christian Hinse wrote:
> > Hi Tristan.
> >
> > Your r2457AmForth  version is working fine on my Arduino MEGA with
> ATmega2560, except for a few garbled character after the reset. But that is
> probably normal. It occurs on the UNO as well.
> >
> > > amforth 7.0 ATmega2560 16000 kHz
> > > words
> > int-trap int@ int! -int +int #int irq[]# postpone (marker) end-code
> code forth-wordlist wordlist set-current >body s>d bounds init-ram ee>ram
> #tib tib source-tib refill-tib 2swap cmove dnegate dabs j * icompare
> nfa>cfa name>string traverse-wordlist search-wordlist (defer) defer@
> defer! Udefer! Udefer@ Rdefer! Rdefer@ Edefer! Edefer@ i-cell+ to unused
> noop ver ?stack rectype-null rectype-xt rec-find rec-num rectype-dnum
> rectype-num recognize forth-recognizer interpret depth rp0 sp0 warm cold
> pause quit .input .error .ready .ok find-xt parse-name /string source parse
> >number number char refill accept cscan cskip throw catch handler ' type
> spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r sign #>
> #s # <# hold hld tolower toupper within max min abs mod / negate u/mod /mod
> turnkey bl hex decimal bin allot here ehere dp key? key emit? emit pad >in
> tuck 2drop 2dup cell+ cells base state f_cpu environment fill s" ." pick
> words show-wordlist u.r u. dinvert d- d+ d2/ d2* nr> n>r -1 2 1 = 2literal
> @i (i!) !i @e !e 2r> 2>r up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +!
> rshift lshift ?negate 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log2
> > < u> u< 0 true d0< d0> 0> 0< 0= <> r@ >r r> nip rot drop over swap ?dup
> dup !u @u c@ c! ! @ (value) execute exit applturnkey nfa>lfa compare
> cfg-recs cfg-order get-current map-stack set-stack get-stack ?abort abort
> abort" [char] immediate recurse user constant variable [ ] ; :noname :
> does> reveal wlscope header create lp lp0 >l l> endloop ?do leave +loop
> loop do again until repeat while begin then else if ahead sliteral literal
> ['] , compile ( \ (create-in) (create) latest newest 1ms name>flags umin
> umax ud* m+ sleep !wdc wdr c!@spi bm-toggle bm-clear bm-set b> >b b!- b!+
> nb! b! b@- b@+ nb@ b@ a> >a a!- a!+ na! a! a@- a@+ na@ a@ +usart ubrr
> tx?-poll tx-poll rx?-buf rx-buf isr-rx >rx-buf  ok
> > >
> >
> > Some question:
> >
> >   *   How much of 256KB flash is effectively usable with AmForth on the
> 2560?
> >   *   Will this work as well on a Chinese  ATmega2560ProMini (with FTDI
> USB chip for terminal input) ?
> >   *   If so, may I share your links with a friend who has an
> ATmega2560ProMini?
> >
> > Thanks a lot for your help.
> >
> > Christian Hinse
> > ________________________________
> > From: Tristan Williams <ho...@tj...>
> > Sent: 16 April 2022 06:05
> > To: amf...@li... <
> amf...@li...>
> > Subject: Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No
> reponse at console
> >
> > Hello Christian,
> >
> > Below is a link to AmForth hex files I built for my Arduino MEGA using
> the
> > (then) most recent source (r2457). The console baud rate is 38400 and
> > build details are in the atmega2560.asm file.
> >
> > https://tjnw.co.uk/amforth-bin/
> >
> > Some background info is contained in this message thread.
> >
> > https://sourceforge.net/p/amforth/mailman/message/37296323/
> >
> > Hope this helps and let me know if you get it up and running.
> >
> > Kind regards,
> >
> > Tristan
> >
> > On 16Apr22 07:08, Christian Hinse wrote:
> > > Hi to your support team.
> > >
> > > I have AmForth working properly on an Arduino UNO.
> > >
> > > I am now trying to use it with an Arduino MEGA using the Atmega2560
> but I get no console response after programming the files  atmega256.hex
> and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of
> downloaded file amforth-6.9.zip.
> > >
> > > I still consider myself as a beginner hobbyist and  I do not yet have
> the ability to assemble my one code from source.
> > >
> > >   *   Are these Hex file effectively compatible with the Arduino MEGA
> using the ATmega2560 ?
> > >   *   What are the fuses that I should use with the Arduino MEGA.using
> the ATmega2560 ?
> > >
> > > I am currently using the followings fuses:
> > >
> > > Reading fuses...
> > > >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U
> hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h
> > > SUCCESS: Read high fuse
> > > SUCCESS: Read low fuse
> > > SUCCESS: Read extended fuse
> > >
> > > My serial port COM7 is transmitting to the Arduino MEGA  because I can
> see the RX LED flashing. I don not see an response on the TX LED or the
> console.
> > >
> > >   *   Am I using HEX files that are not compatible with the Arduino
> MEGA using an ATmega2560 MCU ?
> > >   *   If not, what can I do to make these files work with the Arduino
> MEGA using the ATmega2560.
> > >
> > > I would appreciate your help to resolve this problem.
> > >
> > > Thanks.
> > >
> > > Christian Hinse
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

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

Hi Christian,

Glad it worked.

> How much of 256KB flash is effectively usable with AmForth on the 2560? ?

Good question. I don't know. The file avr8/words/store-i_big.asm may give some
clues. 

> Will this work as well on a Chinese  ATmega2560ProMini (with FTDI USB chip for terminal input) ?

Again, I don't know. However, if the board has an ATmega2560 mcu
running at 16 MHz then there is good chance. I think only by flashing
the board and testing it will you have a better idea. 

> If so, may I share your links with a friend who has an  ATmega2560ProMini?

Yes.

Kind regards,

Tristan

On 16Apr22 16:34, Christian Hinse wrote:
> Hi Tristan.
> 
> Your r2457AmForth  version is working fine on my Arduino MEGA with ATmega2560, except for a few garbled character after the reset. But that is probably normal. It occurs on the UNO as well.
> 
> > amforth 7.0 ATmega2560 16000 kHz
> > words
> int-trap int@ int! -int +int #int irq[]# postpone (marker) end-code code forth-wordlist wordlist set-current >body s>d bounds init-ram ee>ram #tib tib source-tib refill-tib 2swap cmove dnegate dabs j * icompare nfa>cfa name>string traverse-wordlist search-wordlist (defer) defer@ defer! Udefer! Udefer@ Rdefer! Rdefer@ Edefer! Edefer@ i-cell+ to unused noop ver ?stack rectype-null rectype-xt rec-find rec-num rectype-dnum rectype-num recognize forth-recognizer interpret depth rp0 sp0 warm cold pause quit .input .error .ready .ok find-xt parse-name /string source parse >number number char refill accept cscan cskip throw catch handler ' type spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r sign #> #s # <# hold hld tolower toupper within max min abs mod / negate u/mod /mod turnkey bl hex decimal bin allot here ehere dp key? key emit? emit pad >in tuck 2drop 2dup cell+ cells base state f_cpu environment fill s" ." pick words show-wordlist u.r u. dinvert d- d+ d2/ d2* nr> n>r -1 2 1 = 2literal @i (i!) !i @e !e 2r> 2>r up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift ?negate 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log2 > < u> u< 0 true d0< d0> 0> 0< 0= <> r@ >r r> nip rot drop over swap ?dup dup !u @u c@ c! ! @ (value) execute exit applturnkey nfa>lfa compare cfg-recs cfg-order get-current map-stack set-stack get-stack ?abort abort abort" [char] immediate recurse user constant variable [ ] ; :noname : does> reveal wlscope header create lp lp0 >l l> endloop ?do leave +loop loop do again until repeat while begin then else if ahead sliteral literal ['] , compile ( \ (create-in) (create) latest newest 1ms name>flags umin umax ud* m+ sleep !wdc wdr c!@spi bm-toggle bm-clear bm-set b> >b b!- b!+ nb! b! b@- b@+ nb@ b@ a> >a a!- a!+ na! a! a@- a@+ na@ a@ +usart ubrr tx?-poll tx-poll rx?-buf rx-buf isr-rx >rx-buf  ok
> >
> 
> Some question:
> 
>   *   How much of 256KB flash is effectively usable with AmForth on the 2560?
>   *   Will this work as well on a Chinese  ATmega2560ProMini (with FTDI USB chip for terminal input) ?
>   *   If so, may I share your links with a friend who has an  ATmega2560ProMini?
> 
> Thanks a lot for your help.
> 
> Christian Hinse
> ________________________________
> From: Tristan Williams <ho...@tj...>
> Sent: 16 April 2022 06:05
> To: amf...@li... <amf...@li...>
> Subject: Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console
> 
> Hello Christian,
> 
> Below is a link to AmForth hex files I built for my Arduino MEGA using the
> (then) most recent source (r2457). The console baud rate is 38400 and
> build details are in the atmega2560.asm file.
> 
> https://tjnw.co.uk/amforth-bin/
> 
> Some background info is contained in this message thread.
> 
> https://sourceforge.net/p/amforth/mailman/message/37296323/
> 
> Hope this helps and let me know if you get it up and running.
> 
> Kind regards,
> 
> Tristan
> 
> On 16Apr22 07:08, Christian Hinse wrote:
> > Hi to your support team.
> >
> > I have AmForth working properly on an Arduino UNO.
> >
> > I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get no console response after programming the files  atmega256.hex  and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file amforth-6.9.zip.
> >
> > I still consider myself as a beginner hobbyist and  I do not yet have the ability to assemble my one code from source.
> >
> >   *   Are these Hex file effectively compatible with the Arduino MEGA using the ATmega2560 ?
> >   *   What are the fuses that I should use with the Arduino MEGA.using the ATmega2560 ?
> >
> > I am currently using the followings fuses:
> >
> > Reading fuses...
> > >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h
> > SUCCESS: Read high fuse
> > SUCCESS: Read low fuse
> > SUCCESS: Read extended fuse
> >
> > My serial port COM7 is transmitting to the Arduino MEGA  because I can see the RX LED flashing. I don not see an response on the TX LED or the console.
> >
> >   *   Am I using HEX files that are not compatible with the Arduino MEGA using an ATmega2560 MCU ?
> >   *   If not, what can I do to make these files work with the Arduino MEGA using the ATmega2560.
> >
> > I would appreciate your help to resolve this problem.
> >
> > Thanks.
> >
> > Christian Hinse
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

[Christian H. <hin...@ou...>]

Hi Tristan.

Your r2457AmForth  version is working fine on my Arduino MEGA with ATmega2560, except for a few garbled character after the reset. But that is probably normal. It occurs on the UNO as well.

> amforth 7.0 ATmega2560 16000 kHz
> words
int-trap int@ int! -int +int #int irq[]# postpone (marker) end-code code forth-wordlist wordlist set-current >body s>d bounds init-ram ee>ram #tib tib source-tib refill-tib 2swap cmove dnegate dabs j * icompare nfa>cfa name>string traverse-wordlist search-wordlist (defer) defer@ defer! Udefer! Udefer@ Rdefer! Rdefer@ Edefer! Edefer@ i-cell+ to unused noop ver ?stack rectype-null rectype-xt rec-find rec-num rectype-dnum rectype-num recognize forth-recognizer interpret depth rp0 sp0 warm cold pause quit .input .error .ready .ok find-xt parse-name /string source parse >number number char refill accept cscan cskip throw catch handler ' type spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r sign #> #s # <# hold hld tolower toupper within max min abs mod / negate u/mod /mod turnkey bl hex decimal bin allot here ehere dp key? key emit? emit pad >in tuck 2drop 2dup cell+ cells base state f_cpu environment fill s" ." pick words show-wordlist u.r u. dinvert d- d+ d2/ d2* nr> n>r -1 2 1 = 2literal @i (i!) !i @e !e 2r> 2>r up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift ?negate 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log2 > < u> u< 0 true d0< d0> 0> 0< 0= <> r@ >r r> nip rot drop over swap ?dup dup !u @u c@ c! ! @ (value) execute exit applturnkey nfa>lfa compare cfg-recs cfg-order get-current map-stack set-stack get-stack ?abort abort abort" [char] immediate recurse user constant variable [ ] ; :noname : does> reveal wlscope header create lp lp0 >l l> endloop ?do leave +loop loop do again until repeat while begin then else if ahead sliteral literal ['] , compile ( \ (create-in) (create) latest newest 1ms name>flags umin umax ud* m+ sleep !wdc wdr c!@spi bm-toggle bm-clear bm-set b> >b b!- b!+ nb! b! b@- b@+ nb@ b@ a> >a a!- a!+ na! a! a@- a@+ na@ a@ +usart ubrr tx?-poll tx-poll rx?-buf rx-buf isr-rx >rx-buf  ok
>

Some question:

  *   How much of 256KB flash is effectively usable with AmForth on the 2560?
  *   Will this work as well on a Chinese  ATmega2560ProMini (with FTDI USB chip for terminal input) ?
  *   If so, may I share your links with a friend who has an  ATmega2560ProMini?

Thanks a lot for your help.

Christian Hinse
________________________________
From: Tristan Williams <ho...@tj...>
Sent: 16 April 2022 06:05
To: amf...@li... <amf...@li...>
Subject: Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

Hello Christian,

Below is a link to AmForth hex files I built for my Arduino MEGA using the
(then) most recent source (r2457). The console baud rate is 38400 and
build details are in the atmega2560.asm file.

https://tjnw.co.uk/amforth-bin/

Some background info is contained in this message thread.

https://sourceforge.net/p/amforth/mailman/message/37296323/

Hope this helps and let me know if you get it up and running.

Kind regards,

Tristan

On 16Apr22 07:08, Christian Hinse wrote:
> Hi to your support team.
>
> I have AmForth working properly on an Arduino UNO.
>
> I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get no console response after programming the files  atmega256.hex  and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file amforth-6.9.zip.
>
> I still consider myself as a beginner hobbyist and  I do not yet have the ability to assemble my one code from source.
>
>   *   Are these Hex file effectively compatible with the Arduino MEGA using the ATmega2560 ?
>   *   What are the fuses that I should use with the Arduino MEGA.using the ATmega2560 ?
>
> I am currently using the followings fuses:
>
> Reading fuses...
> >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h
> SUCCESS: Read high fuse
> SUCCESS: Read low fuse
> SUCCESS: Read extended fuse
>
> My serial port COM7 is transmitting to the Arduino MEGA  because I can see the RX LED flashing. I don not see an response on the TX LED or the console.
>
>   *   Am I using HEX files that are not compatible with the Arduino MEGA using an ATmega2560 MCU ?
>   *   If not, what can I do to make these files work with the Arduino MEGA using the ATmega2560.
>
> I would appreciate your help to resolve this problem.
>
> Thanks.
>
> Christian Hinse
>
>
>
>
>
> _______________________________________________
> 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] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

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

Hello Christian,

Below is a link to AmForth hex files I built for my Arduino MEGA using the
(then) most recent source (r2457). The console baud rate is 38400 and
build details are in the atmega2560.asm file.

https://tjnw.co.uk/amforth-bin/

Some background info is contained in this message thread.

https://sourceforge.net/p/amforth/mailman/message/37296323/

Hope this helps and let me know if you get it up and running. 

Kind regards,

Tristan 

On 16Apr22 07:08, Christian Hinse wrote:
> Hi to your support team.
> 
> I have AmForth working properly on an Arduino UNO.
> 
> I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get no console response after programming the files  atmega256.hex  and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file amforth-6.9.zip.
> 
> I still consider myself as a beginner hobbyist and  I do not yet have the ability to assemble my one code from source.
> 
>   *   Are these Hex file effectively compatible with the Arduino MEGA using the ATmega2560 ?
>   *   What are the fuses that I should use with the Arduino MEGA.using the ATmega2560 ?
> 
> I am currently using the followings fuses:
> 
> Reading fuses...
> >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h
> SUCCESS: Read high fuse
> SUCCESS: Read low fuse
> SUCCESS: Read extended fuse
> 
> My serial port COM7 is transmitting to the Arduino MEGA  because I can see the RX LED flashing. I don not see an response on the TX LED or the console.
> 
>   *   Am I using HEX files that are not compatible with the Arduino MEGA using an ATmega2560 MCU ?
>   *   If not, what can I do to make these files work with the Arduino MEGA using the ATmega2560.
> 
> I would appreciate your help to resolve this problem.
> 
> Thanks.
> 
> Christian Hinse
> 
> 
> 
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

[Christian H. <hin...@ou...>]

Hi to your support team.

I have AmForth working properly on an Arduino UNO.

I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get no console response after programming the files  atmega256.hex  and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file amforth-6.9.zip.

I still consider myself as a beginner hobbyist and  I do not yet have the ability to assemble my one code from source.

  *   Are these Hex file effectively compatible with the Arduino MEGA using the ATmega2560 ?
  *   What are the fuses that I should use with the Arduino MEGA.using the ATmega2560 ?

I am currently using the followings fuses:

Reading fuses...
>>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h
SUCCESS: Read high fuse
SUCCESS: Read low fuse
SUCCESS: Read extended fuse

My serial port COM7 is transmitting to the Arduino MEGA  because I can see the RX LED flashing. I don not see an response on the TX LED or the console.

  *   Am I using HEX files that are not compatible with the Arduino MEGA using an ATmega2560 MCU ?
  *   If not, what can I do to make these files work with the Arduino MEGA using the ATmega2560.

I would appreciate your help to resolve this problem.

Thanks.

Christian Hinse

[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
>