amforth-devel — Development discussion and user support

Re: [Amforth] git question/moving to sourchut

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

Dear AmForthers,


despite Dieters excellent demonstration of how to deal with branches:

> Dear Erich,
> One of the easiest ways to look for the evolution of a file is
> $ git log --all --graph
> This lists all commits, where  was changed, and rather nice ascii-art graphs.
> The --all flag looks into all branches.
> If you want to do more sophisticated actions per file/branch, you will have to use "git plumbing" functions.
> Plumbing functions are for low-level tasks, and are more appropriate for scripts.
> For example:
> file=tools/amforth-upload.py
> for branch in $(git for-each-ref    --format='%(refname)'   refs/heads); do
>     br=$(echo $branch | sed "s/.*///")
>     echo $br $(git show $br:$file | md5sum | cut -f1 -d" ") ; done
> done
> produces a list of md5 sums for each branch where file occurs.
> git for-each-ref    --format='%(refname)'   refs/heads : produces a list of branches
>
> git show :                       : prints the contents of the file at branch
> The rest of the code is just for nicer outputs.
> There are a multitude of methods to perform a given task in git.
> Sometimes there are just too many flags and commands...
> Kind regards,
> Dieter


I found another reason to stay with the releases folder as a
folder.

I do have quite a collection of "projects" using AmForth. Since
they were created at diffent times and for different purposes,
they point to specific releases of AmForth most of the time.
Just a quick look through one of my trees:
> ew@ceres:~/Forth/atmega2 18 > find . -iname makefile -exec grep '^AMFORTH=' {} \; | sort -u
> AMFORTH=~/Forth/amforth/releases/4.0/core
> AMFORTH=~/Forth/amforth/releases/5.0/core
> AMFORTH=~/Forth/amforth/releases/5.5/core
> AMFORTH=~/Forth/amforth/releases/5.5/core
> AMFORTH=~/Forth/amforth/releases/6.3
> AMFORTH=~/Forth/amforth/releases/6.4
> AMFORTH=~/Forth/amforth/releases/6.6
> AMFORTH=~/Forth/amforth/releases/6.8
> AMFORTH=~/Forth/amforth/releases/6.8
> AMFORTH=~/Forth/amforth/releases/6.9
> AMFORTH=~/Forth/amforth/trunk

This option ceases to exist with branches. I am of course not
willing to check out the correct Version, even automatically, in
order to build AmForth just now in just this folder.

Yes, yes. I know, it is not git'ish.


In order to experiment I created another repository at
https://git.sr.ht/~amforth/code-tree

These commands were used to create it:
> cd path/to/your/favourite/place
> mkdir amforth.git
> cd amforth.git
> svn2git https://svn.code.sf.net/p/amforth/code --rootistrunk

> ls
> # releases/  trunk/
> du -sm .
> # 569   .

> git remote add origin gi...@gi...:~amforth/code-tree
> git push --set-upstream origin master

sourcehut helpfully points out, that it does not see a License
file :)


So we see unfolding that "migrations" are possibly more involved
than anticipated. The true effort involved remains unknown until
you actually made it.

So, any other ideas?
Move the releases folder into what is now trunk?
Move the external, bit rotting amforth-community repository into
what is now trunk, too?



Cheers,
Erich




-- 
May the Forth be with you ...

Re: [Amforth] Howto: conversion of svn to git

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

Ok, found an omission,
> $ git push --set-upstream origin master
is not enough, it will push only master. So I issued
> $ git push --all
now all branches show up in
https://git.sr.ht/~amforth/code/refs
and in

git pull
git branch -a

Cheers,
Erich



Erich =?utf-8?Q?W=C3=A4lde?= <ew....@na...> writes:

> Dear AmForthers,
>
> I forgot to "document", how I did it, in case someone else finds
> this useful.
>
> Cheers,
> Erich
>
>
> working on Debian 10 (buster), amd64
>
> cd path/to/svn/working/tree
>
> svn up
>
> svn info
> # Path: .
> # Working Copy Root Path: /home/ew/eGeek/sourceforge.net/amforth-code
> # URL: svn+ssh://erw...@sv.../p/amforth/code
> # Relative URL: ^/
> # Repository Root: svn+ssh://erw...@sv.../p/amforth/code
> # Repository UUID: fd1c0b69-5d68-47f5-910c-86182ebb6ecd
> # Revision: 2457
> # Node Kind: directory
> # Schedule: normal
> # Last Changed Author: erwaelde
> # Last Changed Rev: 2457
> # Last Changed Date: 2020-12-30 17:15:03 +0100 (Wed, 30 Dec 2020)
>
> sudo apt install svn2git # ruby stuff
>
> cd path/to/your/favourite/place
>
> mkdir amforth.git
>
> cd amforth.git
>
> svn2git https://svn.code.sf.net/p/amforth/code --branches releases
> # ...
> # r2457 = 0a29a13bc693b187d4eaa49f936bda90e7be7958 (refs/remotes/svn/trunk)
> # Checked out HEAD:
> #   https://svn.code.sf.net/p/amforth/code/trunk r2457
> # ...
>
> git remote add origin gi...@gi...:~amforth/code
>
> git remote -v
> # origin        gi...@gi...:~amforth/code (fetch)
> # origin        gi...@gi...:~amforth/code (push)
>
> $ git push --set-upstream origin master
>
> git log
> # commit 0a29a13bc693b187d4eaa49f936bda90e7be7958 (HEAD -> master, origin/master)
> # Author: erwaelde <erwaelde@fd1c0b69-5d68-47f5-910c-86182ebb6ecd>
> # Date:   Wed Dec 30 16:15:03 2020 +0000
> # 
> #     added tools/partdescription
> # 
> # commit ebdf8caa204c3b1725688e47160d92c37a0b6a8c
> # Author: erwaelde <erwaelde@fd1c0b69-5d68-47f5-910c-86182ebb6ecd>
> # Date:   Fri Dec 18 21:41:20 2020 +0000
> # 
> #     Early release of a new test subdirectory. Only one targetboard so far. See test/Howto.txt
> # ...


-- 
May the Forth be with you ...

[Amforth] Granted commit privileges to Carsten Strotmann

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

Dear AmForthers,

I have added the public key of Carsten Strotmann to

https://sr.ht/~amforth

This grants write access to any aspect of the repository.


I know Carsten personally since probably 2007 iirc. We first met
on the "Linux-Tag" while it was in Berlin for the first time.
Since then we have met many times on the yearly meeting of
"Forth Gesellschaft e.V.", several "Linux Tage" staffing the
Forth booth, several CCC congresses and other occasions. We also
did a number of Forth classes together, trying to spread the
word. Carsten is a Forther for a much longer time than I am.

So I'm very pleased to have Carstens expertise in this project.
Thanks for joining!

Cheers,
Erich


-- 
May the Forth be with you ...

[Amforth] Howto: conversion of svn to git

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

Dear AmForthers,

I forgot to "document", how I did it, in case someone else finds
this useful.

Cheers,
Erich


working on Debian 10 (buster), amd64

cd path/to/svn/working/tree

svn up

svn info
# Path: .
# Working Copy Root Path: /home/ew/eGeek/sourceforge.net/amforth-code
# URL: svn+ssh://erw...@sv.../p/amforth/code
# Relative URL: ^/
# Repository Root: svn+ssh://erw...@sv.../p/amforth/code
# Repository UUID: fd1c0b69-5d68-47f5-910c-86182ebb6ecd
# Revision: 2457
# Node Kind: directory
# Schedule: normal
# Last Changed Author: erwaelde
# Last Changed Rev: 2457
# Last Changed Date: 2020-12-30 17:15:03 +0100 (Wed, 30 Dec 2020)

sudo apt install svn2git # ruby stuff

cd path/to/your/favourite/place

mkdir amforth.git

cd amforth.git

svn2git https://svn.code.sf.net/p/amforth/code --branches releases
# ...
# r2457 = 0a29a13bc693b187d4eaa49f936bda90e7be7958 (refs/remotes/svn/trunk)
# Checked out HEAD:
#   https://svn.code.sf.net/p/amforth/code/trunk r2457
# ...

git remote add origin gi...@gi...:~amforth/code

git remote -v
# origin        gi...@gi...:~amforth/code (fetch)
# origin        gi...@gi...:~amforth/code (push)

$ git push --set-upstream origin master

git log
# commit 0a29a13bc693b187d4eaa49f936bda90e7be7958 (HEAD -> master, origin/master)
# Author: erwaelde <erwaelde@fd1c0b69-5d68-47f5-910c-86182ebb6ecd>
# Date:   Wed Dec 30 16:15:03 2020 +0000
# 
#     added tools/partdescription
# 
# commit ebdf8caa204c3b1725688e47160d92c37a0b6a8c
# Author: erwaelde <erwaelde@fd1c0b69-5d68-47f5-910c-86182ebb6ecd>
# Date:   Fri Dec 18 21:41:20 2020 +0000
# 
#     Early release of a new test subdirectory. Only one targetboard so far. See test/Howto.txt
# ...

-- 
May the Forth be with you ...

Re: [Amforth] git question/moving to sourchut

[<di...@sc...>]

Dear Erich,
One of the easiest ways to look for the evolution of a file is
$ git log --all --graph 
This lists all commits, where  was changed, and rather nice ascii-art graphs.
The --all flag looks into all branches.
If you want to do more sophisticated actions per file/branch, you will have to use "git plumbing" functions.
Plumbing functions are for low-level tasks, and are more appropriate for scripts.
For example:
file=tools/amforth-upload.py
for branch in $(git for-each-ref    --format='%(refname)'   refs/heads); do 
    br=$(echo $branch | sed "s/.*///")
    echo $br $(git show $br:$file | md5sum | cut -f1 -d" ") ; done
done
produces a list of md5 sums for each branch where file occurs.
git for-each-ref    --format='%(refname)'   refs/heads : produces a list of branches

git show :                       : prints the contents of the file at branch
The rest of the code is just for nicer outputs.
There are a multitude of methods to perform a given task in git.
Sometimes there are just too many flags and commands...
Kind regards,
Dieter
Am Mi., Apr. 21, 2021 13:47 schrieb Erich Wälde :
Dear AmForthers,

long time no hear. Yes I know. All I can say is: I was very un-motivated to do
anything involving atmega microcontrollers or AmForth. When I packed
everything away in September 2020, I was very frustrated. I wanted to
implement a new version of my data collector stuff, and it kept failing on me
for no apparent reason. This went on for several months until I decided to put
everything out of sight.

Beginning of February 2021 I started to play with this stuff again. Just for
my own pleasure, not telling anyone. So currently I have this working (again):

- TX -- a atmega644pa microcontroller, running AmForth-6.9
using a 434MHz radio to transmit sensor data
using a mightyohm geiger counter as sensor (it reports about 20
events/minute :)

- RX -- a atmega644pa microcontroller, running AmForth-6.9
using a 434MHz radio to receive said data

- a Raspberry Pi connected to the serial interface of RX requesting data every
10 Minutes, sending that data off via mqtt. MQTT relays the datagrams via
telegraf into an influxdb, grafana makes the collected data visible to a web
browser. This part I had set up over winter to replace my outdated and
somewhat dodgy pgplot/perl driven visualization.

This setup is quite stable. I see occasional outliers, so transport is not as
robust as it could be.

Sounds like full success? Well. Maybe. I also spent countless hours on the
let's say intriguing interface of the Bosch Sensortec BME280 sensor
(temperature, relative humidity, pressure). While the sensor may be top notch,
I did not grok the imho complicated calculations, which are neccessary to
convert the Bits into a human readable value. Working in C is much simpler,
bacause C code is available, and because the compiler will do all sorts of
signed/unsigned acrobatics for me. Yes there is Forth code available as well,
e.g. from our nice neighbours in Netherlands, as published in Vierte Dimension
2020-01:
https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2020-01.pdf (https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2020-01.pdf)

I have given up on this for now, and I have ordered some (expensive!)
Sensirion STH85 sensors (temperature, rel. humidity). I have some SHT71, but I
broke the last one.

So, all of this is to say, I am hopefully out of hibernation.

Regarding the AmForth Project:

1.
I have registered an account at sourcehut.org:
https://git.sr.ht/~amforth (https://git.sr.ht/~amforth)

The repository is currently empty, but that should change.

2.
I have experimented a little with svn2git. Thanks for your experiments and
various hints on the mailing list.

There is one thing I am still very undecided:

When I try to understand a problem in the AmForth code, I often do something
like:

find or grep -rl $something in ./releases/*/avr8/...
pipe this through md5sum to see what changed when
Then do diffs between specific releases.
A more complete example is given below.

IFF I convert the ./releases/ directories to git branches, then this will not
be possible any more, I think. The I have to use git blame and git diff
between branches.

Currently I think having all files unfolded in a directory tree has its
merits. At least in the sense that I know, how to deal with this.

But this is highly against the git way, as I understand it. So I am inclined
to create branches, but I would highly appreciate hints on how to efficiently
find out about changes of a given file during its history. How are you doing
this? Ah, web interface ... how about the command line?

3.
During a completely different experiment that you find here
https://ew.srht.site/ (https://ew.srht.site/)
I think I have understood, how to create static html content in such a way
that it will be served by sourcehut. Currently "not found"
https://amforth.srht.site/ (https://amforth.srht.site/)
but that shall change as well.

4.
I intent to give admin privileges to at least two more people. Carsten
Strotmann has given me a key already. So if anyone else is interested, please
get in touch with me.

Cheers,
Erich

----------------------------------------------------------------------
example for find/grep diff workflow:

$ md5sum ~/bin/amforth-upload.py releases/*/tools/amforth-upload.py trunk/tools/amforth-upload.py
c0a6266c243a724da85074fc6a7bc315  /home/ew/bin/amforth-upload.py
a6e355913f567148d6129638d1979dd0  releases/2.7/tools/amforth-upload.py
5e7458e0382bf29d4820c4f1f720222c  releases/2.8/tools/amforth-upload.py
5e7458e0382bf29d4820c4f1f720222c  releases/2.9/tools/amforth-upload.py
5e7458e0382bf29d4820c4f1f720222c  releases/3.0/tools/amforth-upload.py
5e7458e0382bf29d4820c4f1f720222c  releases/3.1/tools/amforth-upload.py
5e7458e0382bf29d4820c4f1f720222c  releases/3.2/tools/amforth-upload.py
5e7458e0382bf29d4820c4f1f720222c  releases/3.3/tools/amforth-upload.py
d98ce0c817fd19cba4474e13b56f566f  releases/3.4/tools/amforth-upload.py
d98ce0c817fd19cba4474e13b56f566f  releases/3.5/tools/amforth-upload.py
d98ce0c817fd19cba4474e13b56f566f  releases/3.6/tools/amforth-upload.py
d98ce0c817fd19cba4474e13b56f566f  releases/3.7/tools/amforth-upload.py
d98ce0c817fd19cba4474e13b56f566f  releases/3.8/tools/amforth-upload.py
d98ce0c817fd19cba4474e13b56f566f  releases/3.9/tools/amforth-upload.py
c0a6266c243a724da85074fc6a7bc315  releases/4.0/tools/amforth-upload.py
3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.1/tools/amforth-upload.py
3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.2/tools/amforth-upload.py
3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.3/tools/amforth-upload.py
3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.4/tools/amforth-upload.py
3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.5/tools/amforth-upload.py
3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.6/tools/amforth-upload.py
7bee7d2eb669aad5c4b77c93c74d1941  releases/4.7/tools/amforth-upload.py
7bee7d2eb669aad5c4b77c93c74d1941  releases/4.8/tools/amforth-upload.py
e8f55df9f17ceb38228ba68270ca019d  releases/4.9/tools/amforth-upload.py
e8f55df9f17ceb38228ba68270ca019d  releases/5.0/tools/amforth-upload.py
e8f55df9f17ceb38228ba68270ca019d  releases/5.1/tools/amforth-upload.py
e8f55df9f17ceb38228ba68270ca019d  releases/5.2/tools/amforth-upload.py
e8f55df9f17ceb38228ba68270ca019d  releases/5.3/tools/amforth-upload.py
e8f55df9f17ceb38228ba68270ca019d  releases/5.4/tools/amforth-upload.py
e8f55df9f17ceb38228ba68270ca019d  releases/5.5/tools/amforth-upload.py
e8f55df9f17ceb38228ba68270ca019d  releases/5.6/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/5.7/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/5.8/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/5.9/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/6.0/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/6.1/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/6.2/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/6.3/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/6.4/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/6.5/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/6.6/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/6.7/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/6.8/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  trunk/tools/amforth-upload.py
#+end_example

I'm using amforth-upload.py from release 4.0. This version /works/ for
me. Changes occured in these releases:

#+begin_example
a6e355913f567148d6129638d1979dd0  releases/2.7/tools/amforth-upload.py
d98ce0c817fd19cba4474e13b56f566f  releases/3.4/tools/amforth-upload.py
c0a6266c243a724da85074fc6a7bc315  releases/4.0/tools/amforth-upload.py
3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.1/tools/amforth-upload.py
7bee7d2eb669aad5c4b77c93c74d1941  releases/4.7/tools/amforth-upload.py
e8f55df9f17ceb38228ba68270ca019d  releases/4.9/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  releases/5.7/tools/amforth-upload.py
faf3f05fbb4126a290d435e83e3e90ee  trunk/tools/amforth-upload.py
#+end_example

#+begin_example
for R in 2.7 3.4 4.0 4.1 4.7 4.9 5.7
do
ls -l releases/$R/tools/amforth-upload.py
#wc -l releases/$R/tools/amforth-upload.py
done

-rwxr-x--- 1 ew ew 6201 2020-04-05 12:27 releases/2.7/tools/amforth-upload.py*
-rwxr-x--- 1 ew ew 6921 2020-04-05 12:27 releases/3.4/tools/amforth-upload.py*
-rwxr-x--- 1 ew ew 7408 2020-04-05 12:27 releases/4.0/tools/amforth-upload.py*
-rwxr-x--- 1 ew ew 7409 2020-04-05 12:27 releases/4.1/tools/amforth-upload.py*
-rwxr-x--- 1 ew ew 7414 2020-04-05 12:27 releases/4.7/tools/amforth-upload.py*
-rwxr-x--- 1 ew ew 7541 2020-04-05 12:27 releases/4.9/tools/amforth-upload.py*
-rwxr-x--- 1 ew ew 7978 2020-04-05 12:27 releases/5.7/tools/amforth-upload.py*

232 releases/2.7/tools/amforth-upload.py
253 releases/3.4/tools/amforth-upload.py
264 releases/4.0/tools/amforth-upload.py
264 releases/4.1/tools/amforth-upload.py
261 releases/4.7/tools/amforth-upload.py
261 releases/4.9/tools/amforth-upload.py
269 releases/5.7/tools/amforth-upload.py

... and so on. Similar game with no-jtag.asm led to recognize that the
active file was essentially empty at the time.

-- 
May the Forth be with you ...

_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/ (http://amforth.sf.net/)
Amf...@li... (mailto:Amf...@li...)
https://lists.sourceforge.net/lists/listinfo/amforth-devel (https://lists.sourceforge.net/lists/listinfo/amforth-devel)

[Amforth] Code copied to sourcehut.org

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

Dear AmForthers,

I have just now converted r2457 of
svn://svn.code.sf.net/p/amforth/code

via svn2git and pushed it to

https://git.sr.ht/~amforth/code/tree

If you would please be so kind as to give it a try.
Test your usual workflow.
Are all files in the expected places?
Can you assemle your favourite .hex files?
Can you create patches (email form)?

Play with it.

Do you see something odd or unexpected?


Cheers,
Erich



-- 
May the Forth be with you ...

[Amforth] git question/moving to sourchut

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

Dear AmForthers,

long time no hear. Yes I know. All I can say is: I was very un-motivated to do
anything involving atmega microcontrollers or AmForth. When I packed
everything away in September 2020, I was very frustrated. I wanted to
implement a new version of my data collector stuff, and it kept failing on me
for no apparent reason. This went on for several months until I decided to put
everything out of sight.

Beginning of February 2021 I started to play with this stuff again. Just for
my own pleasure, not telling anyone. So currently I have this working (again):

- TX -- a atmega644pa microcontroller, running AmForth-6.9
  using a 434MHz radio to transmit sensor data
  using a mightyohm geiger counter as sensor (it reports about 20
  events/minute :)

- RX -- a atmega644pa microcontroller, running AmForth-6.9
  using a 434MHz radio to receive said data

- a Raspberry Pi connected to the serial interface of RX requesting data every
  10 Minutes, sending that data off via mqtt. MQTT relays the datagrams via
  telegraf into an influxdb, grafana makes the collected data visible to a web
  browser. This part I had set up over winter to replace my outdated and
  somewhat dodgy pgplot/perl driven visualization.

This setup is quite stable. I see occasional outliers, so transport is not as
robust as it could be.

Sounds like full success? Well. Maybe. I also spent countless hours on the
let's say intriguing interface of the Bosch Sensortec BME280 sensor
(temperature, relative humidity, pressure). While the sensor may be top notch,
I did not grok the imho complicated calculations, which are neccessary to
convert the Bits into a human readable value. Working in C is much simpler,
bacause C code is available, and because the compiler will do all sorts of
signed/unsigned acrobatics for me. Yes there is Forth code available as well,
e.g. from our nice neighbours in Netherlands, as published in Vierte Dimension
2020-01:
https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2020-01.pdf

I have given up on this for now, and I have ordered some (expensive!)
Sensirion STH85 sensors (temperature, rel. humidity). I have some SHT71, but I
broke the last one.


So, all of this is to say, I am hopefully out of hibernation.


Regarding the AmForth Project:

1.
I have registered an account at sourcehut.org:
https://git.sr.ht/~amforth

The repository is currently empty, but that should change.


2.
I have experimented a little with svn2git. Thanks for your experiments and
various hints on the mailing list.

There is one thing I am still very undecided:

When I try to understand a problem in the AmForth code, I often do something
like:

find or grep -rl $something in ./releases/*/avr8/...
pipe this through md5sum to see what changed when
Then do diffs between specific releases.
A more complete example is given below.

IFF I convert the ./releases/ directories to git branches, then this will not
be possible any more, I think. The I have to use git blame and git diff
between branches.

Currently I think having all files unfolded in a directory tree has its
merits. At least in the sense that I know, how to deal with this.

But this is highly against the git way, as I understand it. So I am inclined
to create branches, but I would highly appreciate hints on how to efficiently
find out about changes of a given file during its history. How are you doing
this? Ah, web interface ... how about the command line?


3.
During a completely different experiment that you find here
https://ew.srht.site/
I think I have understood, how to create static html content in such a way
that it will be served by sourcehut. Currently "not found"
https://amforth.srht.site/
but that shall change as well.


4.
I intent to give admin privileges to at least two more people. Carsten
Strotmann has given me a key already. So if anyone else is interested, please
get in touch with me.


Cheers,
Erich



----------------------------------------------------------------------
> example for find/grep diff workflow:
> 
> $ md5sum ~/bin/amforth-upload.py releases/*/tools/amforth-upload.py trunk/tools/amforth-upload.py
> c0a6266c243a724da85074fc6a7bc315  /home/ew/bin/amforth-upload.py
> a6e355913f567148d6129638d1979dd0  releases/2.7/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/2.8/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/2.9/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/3.0/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/3.1/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/3.2/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/3.3/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.4/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.5/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.6/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.7/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.8/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.9/tools/amforth-upload.py
> c0a6266c243a724da85074fc6a7bc315  releases/4.0/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.1/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.2/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.3/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.4/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.5/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.6/tools/amforth-upload.py
> 7bee7d2eb669aad5c4b77c93c74d1941  releases/4.7/tools/amforth-upload.py
> 7bee7d2eb669aad5c4b77c93c74d1941  releases/4.8/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/4.9/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.0/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.1/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.2/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.3/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.4/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.5/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.6/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/5.7/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/5.8/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/5.9/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.0/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.1/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.2/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.3/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.4/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.5/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.6/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.7/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.8/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  trunk/tools/amforth-upload.py
>        #+end_example
> 
>        I'm using amforth-upload.py from release 4.0. This version /works/ for
>        me. Changes occured in these releases:
> 
>        #+begin_example
> a6e355913f567148d6129638d1979dd0  releases/2.7/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.4/tools/amforth-upload.py
> c0a6266c243a724da85074fc6a7bc315  releases/4.0/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.1/tools/amforth-upload.py
> 7bee7d2eb669aad5c4b77c93c74d1941  releases/4.7/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/4.9/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/5.7/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  trunk/tools/amforth-upload.py
>        #+end_example
> 
>        #+begin_example
> for R in 2.7 3.4 4.0 4.1 4.7 4.9 5.7
> do
>     ls -l releases/$R/tools/amforth-upload.py
>     #wc -l releases/$R/tools/amforth-upload.py
> done
> 
> -rwxr-x--- 1 ew ew 6201 2020-04-05 12:27 releases/2.7/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 6921 2020-04-05 12:27 releases/3.4/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7408 2020-04-05 12:27 releases/4.0/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7409 2020-04-05 12:27 releases/4.1/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7414 2020-04-05 12:27 releases/4.7/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7541 2020-04-05 12:27 releases/4.9/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7978 2020-04-05 12:27 releases/5.7/tools/amforth-upload.py*
> 
> 232 releases/2.7/tools/amforth-upload.py
> 253 releases/3.4/tools/amforth-upload.py
> 264 releases/4.0/tools/amforth-upload.py
> 264 releases/4.1/tools/amforth-upload.py
> 261 releases/4.7/tools/amforth-upload.py
> 261 releases/4.9/tools/amforth-upload.py
> 269 releases/5.7/tools/amforth-upload.py
> 
>      ... and so on. Similar game with no-jtag.asm led to recognize that the
>      active file was essentially empty at the time.


-- 
May the Forth be with you ...

[Amforth] patch for amforth-shell.py

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

amforth-shell.py replaces known mcu register names with their
values. This makes it very easy to create a file like this and upload
it to the mcu (in this case avr8)

#include ms.frt

: low     ( mask port --   ) dup c@ rot invert and swap c! ;
: high    ( mask port --   ) dup c@ rot or swap c! ;

: blink ( -- )
    #32 DDRB high
    begin
        #32 PORTB low 
        1000 ms
        #32 PORTB high
        1000 ms
    key? until
;

connecting via serial and typing blink makes the led on pin 13 of an
uno blink until a key is pressed. However, the Forth system knows
nothing about DDRB or PORTB as these were substituted on-the-fly by
amforth-shell.py during the upload. This does save some flash memory
and does simplify writing code, but it is not always what you want. If
you wanted to use PORTB at the interpreter prompt, you can't as it
does not exist as a constant. Adding

#37 constant PORTB

will not help either, as amforth-shell.py still substitutes on-the-fly
creating a new word $25, as

' $25 execute .

will show. I looked to see if I could turn this behaviour off, but
I couldn't find an option to do this. The patch below changes this,
adding the option

  --no-regsub, -X       Do NOT replace mcu registers with their values.

The default behaviour remains unchanged, with register names
substituted on-the-fly.

--- ../amforth-6.93/tools/amforth-shell.py	2020-12-03 15:29:07.000000000 +0000
+++ ../amforth-6.93/tools/new-shell.py	2020-12-16 17:42:48.000000000 +0000
@@ -648,9 +648,12 @@
             help="Add Include directory")
         parser.add_argument("--uploaded-wl", "-U", action="store_true", default=False,
             help="Keep the list of uploaded filenames in the dictionary.")
+        parser.add_argument("--no-regsub", "-X", action="store_true", default=False,
+            help="Do NOT replace mcu registers with their values.")
 
         parser.add_argument("files", nargs="*", help="may be found via the environment variable AMFORTH_LIB")
         arg = parser.parse_args()
+        self.noregsub = arg.no_regsub 
         self.debug = arg.debug_serial
         self.max_line_length = arg.line_length
         self._serial_port = arg.port
@@ -917,7 +920,7 @@
                 continue
             if w in self._appl_defs:
                 w = self._appl_defs[w]
-            elif w in self._amforth_regs:
+            elif w in self._amforth_regs and not self.noregsub :
                 w = self._amforth_regs[w]
             elif w.upper() in self.stdwords:
                 w = w.lower()

[Amforth] [PATCH] Update to "Arduino-HelloWorld.rst.txt" recipe

[Carsten S. <ca...@st...>]

Hi AmForth List,

on the weekend I've run the "Arduino Hello World" recipe and found 
two
issues:

a) the recipe jumps from pin 5 to pin 7 of Port B in the middle of 
the
recipe, that was confusing

b) modern AmForth does not seem to include the word "ms" in the 
kernel

Attached is a patch that changes to Port to use Digital-13 on the
Arduino all the time (to be consistent) and gives information 
where to
find the word "ms" (or how to quickly define it).


<https://git.sr.ht/~cstrotm/AmForth/commit/a2a968b7c02aff5afd622f842aeda9a21ddcdc92.patch>

Greetings

Carsten


>From a2a968b7c02aff5afd622f842aeda9a21ddcdc92 Mon Sep 17 00:00:00 
2001
From: Carsten Strotmann <ca...@st...>
Date: Mon, 1 Mar 2021 13:55:20 +0100
Subject: [PATCH] Fix port number in example and add information on 
word "ms"

---
 .../TG/recipes/Arduino-HelloWorld.rst.txt     | 52 
 +++++++++++--------
 1 file changed, 29 insertions(+), 23 deletions(-)

diff --git 
a/doc/htdocs/_sources/TG/recipes/Arduino-HelloWorld.rst.txt 
b/doc/htdocs/_sources/TG/recipes/Arduino-HelloWorld.rst.txt
index 7de8045..93bb471 100644
--- a/doc/htdocs/_sources/TG/recipes/Arduino-HelloWorld.rst.txt
+++ b/doc/htdocs/_sources/TG/recipes/Arduino-HelloWorld.rst.txt
@@ -9,7 +9,7 @@ attached to the port Digital-13. For this recipe, 
the amforth system
 is already loaded onto the ardiuno. Instructions to do it are in 
 the
 :ref:`User Guide`.
 
-To quickly test the hardware start a terminal (e.g. screen 
 /dev/ttyACM0 38400) 
+To quickly test the hardware start a terminal (e.g. screen 
/dev/ttyACM0 38400)
 and enter the following commands (assuming an Arduino Uno)
 
 .. code-block:: forth
@@ -19,12 +19,12 @@ and enter the following commands (assuming an 
Arduino Uno)
    > $00 $25 c!
 
 The LED turned on until the last command is executed. The 
 character
-:command:`>` is the command prompt, if you see it, you can enter 
-any commands. You'll never enter that character yourselves. A 
+:command:`>` is the command prompt, if you see it, you can enter
+any commands. You'll never enter that character yourselves. A
 command line can be up to 80 characters long.
 
 The commands above are pretty obscure. To make them easier to
-understand we define labels for some numbers, so called 
+understand we define labels for some numbers, so called
 constants:
 
 .. code-block:: forth
@@ -35,24 +35,24 @@ constants:
 The arduino uses its own numbering schema for pins, but
 for now we use the atmega one: digial-13 is the same as
 bit 7 of port B. Port B has 8 pins and three registers to
-configure them. we need two of them: The Data Direction 
-Register (DDR) and the PORT (Output) Register. The third 
+configure them. we need two of them: The Data Direction
+Register (DDR) and the PORT (Output) Register. The third
 register is used for reading from the port (PIN).
 
 The above commands can now be written as
 
 .. code-block:: forth
 
-  > $20 DDRB c! 
+  > $20 DDRB c!
   > $20 PORTB c!
   > $00 PORTB c!
 
 Technically the same but easier to read.
 
 Next we do not want to enter all commands interactively. Forth
-has the reputation of an extendible command set. 
+has the reputation of an extendible command set.
 
-Good forth coding style means to have many small words which do 
 exactly 
+Good forth coding style means to have many small words which do 
exactly
 one thing. Most forth commands are built with only a handful 
 other commands.
 
 The first command in this example sets up the Data Direction 
 Register DDR
@@ -68,7 +68,7 @@ The same in Forth is:
 
 .. code-block:: forth
 
-   > : led-init  $80 DDRB c! ;
+   > : led-init  $20 DDRB c! ;
     ok
    >
 
@@ -81,17 +81,17 @@ With this command line the interpreter learns 
a new command:
     ok
    >
 
-It writes the number 128 (hex 80) to the register DDRB (hex 24)
-as defined above. This makes the 7th bit of PORTB an Output pin.
+It writes the number 32 (hex 20) to the register DDRB (hex 24)
+as defined above. This makes the 5th bit of PORTB an Output pin.
 
 Calling our newly defined word does not change anything
 visible. But with the next word, the LED will turn on:
 
 .. code-block:: forth
 
-  : led-on $80 PORTB c! ;
+  : led-on $20 PORTB c! ;
 
-Here the 7th bit will be set to 1, and that makes the led to be 
 connected
+Here the 5th bit will be set to 1, and that makes the led to be 
connected
 to VCC (5V) and it will turn on (the LED is connected to ground 
 already).
 
 If the led-on command does not turn on the LED just call the
@@ -123,9 +123,15 @@ Our next word will simplify this and gives 
the real blink experience:
 
   : led-blink led-on 500 ms led-off 500 ms ;
 
-Calling this command will turn on the led, waits for half a 
 second, turn it
-off again and waits another half a second before returning to the 
 command
-prompt.
+Calling this command will turn on the led, waits for half a 
second,
+turn it off again and waits another half a second before 
returning to
+the command prompt. If the word `ms` is not found, it can be 
loaded
+from `<AmForth>/common/lib/forth2012/facility/ms.frt` or defined
+assembler
+
+.. code-block:: forth
+
+  : ms 0 ?do 1ms loop ;
 
 With this command you can blink the led a few times
 
@@ -148,11 +154,11 @@ To make it blink "forever", we define 
another command word:
         led-blink
         key?
      until
-     key drop 
+     key drop
    ;
 
-Since this is our first command which needs more than 1 line, the 
-interpreter acts more complex. It changes the command prompt 
 until 
+Since this is our first command which needs more than 1 line, the
+interpreter acts more complex. It changes the command prompt 
until
 the end of the command definition is reached (the command ``;``)
 The ouput in the terminal window looks like
 
@@ -167,7 +173,7 @@ The ouput in the terminal window looks like
     okkey drop
     ok;
     ok
-   > 
+   >
 
 This word first prints some text ("press any key to stop") and 
 starts a loop.
 This loop lets the led blink once and checks for a keystroke. If 
 no key
@@ -185,7 +191,7 @@ Where to go next
 ................
 
 This example is very basic. Next steps may involve library code
-like :ref:`Digital Ports`. Related to it are the :ref:`Upload` 
 for 
+like :ref:`Digital Ports`. Related to it are the :ref:`Upload` 
for
 files with forth code.
 
-More Arduino related stuff is in :ref:`Arduino Analog`. 
+More Arduino related stuff is in :ref:`Arduino Analog`.
-- 
2.30.1

[Amforth] wordlist tools

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

I have been using wordlists to store and catalogue information for a
different project and found I needed some more tools in addition to
those in the distribution

Source and more details below

https://tjnw.co.uk/wlt/

Kind regards,

Tristan

Re: [Amforth] A project using an AmForth recogniser

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

I have added parts two and three of the project.

https://tjnw.co.uk/limpicprog/

Best wishes,
Tristan

On 06Jan21 18:56, Tristan Williams wrote:
> First part of project to make tinkering in the shed easier.
> 
> https://tjnw.co.uk/limpicprog/
> 
> Best wishes,
> Tristan
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth] Useful additions to the "Extended VM"

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

It's a handy way of using the A & B variables as local variables when
needed.

    .dw $ff03
    .db "a>r"
    .dw VE_HEAD
    .set VE_HEAD = VE_ATOR
XT_ATOR:
    .dw PFA_ATOR
PFA_ATOR:
      push ah
      push al
    jmp_ DO_NEXT

    .dw $ff03
    .db "r>a"
    .dw VE_HEAD
    .set VE_HEAD = VE_AFROMR
XT_AFROMR:
    .dw PFA_AFROMR
PFA_AFROMR:
      pop al
      pop ah
    jmp_ DO_NEXT


Quick and simple definitions which allow you to do stuff like this:
: workwitha
	a>r
		use a with impunity
	r>a
;

I've translated these from my own version, so I hope it's survived.

--
Regards,

Martin Nicholas.

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

[Amforth] A project using an AmForth recogniser

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

First part of project to make tinkering in the shed easier.

https://tjnw.co.uk/limpicprog/

Best wishes,
Tristan

[Amforth] AVR-Dx Port

[Stephen D <au....@gm...>]

Hi all,
now that Erich has provided the Python source I've taken time to
investigate generating the device control files.

Microchip have made changes to the device files between Studio 6.2 and 7.0.

In 6.2:
- filename is <device>.xml
- schema version 0.3
- no support for AVR-Dx parts

In 7.0
- filename is <device>.atdf
- inconsistent schema versions 0.3 (old parts), 4.4 (new parts)
- module names change e.g. ANALOG_COMPARATOR becomes AC (mega128)
- xml module element nesting changes e.g. USART0/USART1 now nested under
USART (mega128)

I should be able to tweak the existing python scripts to generate the
required device.asm, device.py and .frt code but the module and register
name changes are likely to cause a great deal of inconsistency between the
AVR-Dx parts and the earlier AVR models.

An alternative option would be to regenerate the entire avr8/devices tree.
A lot of work and a lot of potential breakage. It would however mean that
the new style register and module names would be applied consistently to
all devices.

I imagine there are other options.

Regards,
S

Re: [Amforth] Added tools/partdescription to svn

[Stephen D <au....@gm...>]

Thanks Erich. I’ve completed the first step. With the help of the kind
folks over at avrfreaks.net I have been able to integrate the latest Atmel
Assembler (2.2.8) and AVR-Dx .inc files into the amforth tools download. I
have an updated Atmel-Assembler.tgz file ready to upload.

I will send you a link to the file personally.

Regards,
Stephen

On Thu, 31 Dec 2020 at 03:23, Erich Wälde <ew....@na...> wrote:

>
> Hello,
>
> as promised, I added the script "pd2amforth" to the source tree,
> see amforth/trunk/tools/partdescription/...
>
> > $ svn commit . -m 'added tools/partdescription'
> > Password:
> > Sending        doc/source/index.rst
> > Adding         tools/partdescription
> > Adding         tools/partdescription/00README
> > Adding         tools/partdescription/ATmega16.xml
> > Adding         tools/partdescription/ATmega32.xml
> > Adding         tools/partdescription/ATmega328P.xml
> > Adding         tools/partdescription/pd
> > Adding         tools/partdescription/pd/__init__.py
> > Adding         tools/partdescription/pd/convert_number.py
> > Adding         tools/partdescription/pd/device.py
> > Adding         tools/partdescription/pd/interrupts.py
> > Adding         tools/partdescription/pd/make_path.py
> > Adding         tools/partdescription/pd/register.py
> > Adding         tools/partdescription/pd/sleep.py
> > Adding         tools/partdescription/pd/wdt.py
> > Adding         tools/partdescription/pd2amforth
> > Transmitting file data ..............done
> > Committing transaction...
> > Committed revision 2457.
>
> I have written what little I know into a 00README file in that
> directory. May it be of help.
>
> Cheers,
> Erich
>
> PS: the website is not yet updated
>
>
> --
> 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] Added tools/partdescription to svn

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

Hello,

as promised, I added the script "pd2amforth" to the source tree,
see amforth/trunk/tools/partdescription/...

> $ svn commit . -m 'added tools/partdescription'
> Password: 
> Sending        doc/source/index.rst
> Adding         tools/partdescription
> Adding         tools/partdescription/00README
> Adding         tools/partdescription/ATmega16.xml
> Adding         tools/partdescription/ATmega32.xml
> Adding         tools/partdescription/ATmega328P.xml
> Adding         tools/partdescription/pd
> Adding         tools/partdescription/pd/__init__.py
> Adding         tools/partdescription/pd/convert_number.py
> Adding         tools/partdescription/pd/device.py
> Adding         tools/partdescription/pd/interrupts.py
> Adding         tools/partdescription/pd/make_path.py
> Adding         tools/partdescription/pd/register.py
> Adding         tools/partdescription/pd/sleep.py
> Adding         tools/partdescription/pd/wdt.py
> Adding         tools/partdescription/pd2amforth
> Transmitting file data ..............done
> Committing transaction...
> Committed revision 2457.

I have written what little I know into a 00README file in that
directory. May it be of help.

Cheers,
Erich

PS: the website is not yet updated


-- 
May the Forth be with you ...

Re: [Amforth] Newbie getting started with AVR128DA48

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

Both 328eForth and FlashForth wpuld be easier starting points for a newbie.

If one must use AmForth, studying the directory structure and content is
key to finding out how to compile to a specific target.

On Tue, Dec 29, 2020, 11:22 PM Brian <bkn...@gm...> wrote:

> Perhaps the Arduino controlled by Eforth would be a good help. It has
> the full assembly code explained for eforth might be a good jumping off
> point its available at
>
> http://www.forth.org/OffeteStore/OffeteStore.html. A good read no matter
> what.
>
> Brian-in-ohio
>
> On 12/29/20 4:05 AM, Stephen D wrote:
> > Hi all,
> > would like to try running amforth on one of the new AVR processors, the
> > AVR128DA48 to be exact. A Curiosity Nano board turned up this week and
> I'm
> > keen to give it a try.
> >
> > Am a total newb with regards to amforth and forth in general but have
> > plenty of AVR programming experience, both in C and assembler. Have
> looked
> > through the User and Technical Guides but not found an answer to my
> > question:
> >
> > How do you define a new AVR8 chip within amforth?
> >
> > I have looked through the files under /avr8/devices/atmega* e.g.
> > device.asm, device.inc etc. They all claim to be "generated
> automatically".
> > I have not been able to find where the automatic generation is performed.
> > Is anyone able to point me in the right direction please?
> >
> > Thanks,
> > Stephen
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Newbie getting started with AVR128DA48

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

Perhaps the Arduino controlled by Eforth would be a good help. It has 
the full assembly code explained for eforth might be a good jumping off 
point its available at

http://www.forth.org/OffeteStore/OffeteStore.html. A good read no matter 
what.

Brian-in-ohio

On 12/29/20 4:05 AM, Stephen D wrote:
> Hi all,
> would like to try running amforth on one of the new AVR processors, the
> AVR128DA48 to be exact. A Curiosity Nano board turned up this week and I'm
> keen to give it a try.
>
> Am a total newb with regards to amforth and forth in general but have
> plenty of AVR programming experience, both in C and assembler. Have looked
> through the User and Technical Guides but not found an answer to my
> question:
>
> How do you define a new AVR8 chip within amforth?
>
> I have looked through the files under /avr8/devices/atmega* e.g.
> device.asm, device.inc etc. They all claim to be "generated automatically".
> I have not been able to find where the automatic generation is performed.
> Is anyone able to point me in the right direction please?
>
> Thanks,
> Stephen
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie getting started with AVR128DA48

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

Hello Stephen,

I wanted to do something similar with the ATmega4809 on a Curiosity Nano last
year but ran out of time/skill.

https://sourceforge.net/p/amforth/mailman/search/?q=4809

> There appear to be a number of changes at the C macro and register level
> from the previous mega generation. I have not dug deep enough into the
> AmForth code yet but it may require a fair bit of rework.

That was what I found also, and would agree that it may require a fair
bit of rework - both in terms of the AmForth code, but also the tool
chain more generally. All that being said, to have AmForth able to run
on this newer generation of mcu would be fantastic.

Best wishes,
Tristan

On 29Dec20 23:02, Stephen D wrote:
> Hi Erich,
> thank you for getting back to me so quickly.
> 
> On Tue, 29 Dec 2020 at 22:30, Erich Wälde <ew....@na...> wrote:
> 
> > Well, well. This is one of the secrets that I have not yet
> > uncovered from the files I have. You might not know that the
> > author of AmForth has left this planet earlier this year. So we
> > have to make due with some code archeology :)
> >
> 
> I saw with surprise and sadness the news of Matthias' passing. I imagine
> this has caused a great deal of disruption for this project. If I can help
> in any way I will.
> 
> AVR128DA48. What a beast. I skimmed the datasheet only briefly
> > https://www.microchip.com/wwwproducts/en/AVR128DA48
> >
> > If you want to work your way to support this chip, I suggest to
> > make a twofold approach:
> >
> > 1. Have a controller, which is supported by AmForth already,
> > like the venerable atmega328p. Use this to set up the whole tool
> > chain and verify, that you can build and upload it, and that the
> > result is actually working. Unless, of course, you have done
> > this already.
> >
> 
> I have access to an STK600 and several devices in the atmega family.
> Haven't programmed one with AmForth yet but based on what I've read in the
> documentation I am not expecting too many problems.
> 
> 
> > 2. Then try to fill in pieces for the new controller. Start with
> > the files of a supported controller with the same size flash/ram
> > /eeprom.
> >
> > You have to make sure, that the new controller uses the exakt
> > same set of assembly instructions --- it probably does not,
> > because I read the word "hardware multiplier"
> >
> > > The AVR128DA48 microcontroller is part of the AVR DA family
> > > featuring the AVR processor with hardware multiplier - running
> > > at up to 24 MHz and with 128 KB Flash, 16 KB SRAM and 512
> > > bytes of EEPROM in 48-pin packages.
> >
> 
> I don't think it's going to be straight forward -
> https://ww1.microchip.com/downloads/en/Appnotes/Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdf
> There appear to be a number of changes at the C macro and register level
> from the previous mega generation. I have not dug deep enough into the
> AmForth code yet but it may require a fair bit of rework.
> 
> Meanwhile I will have a look whether I can uncover the generator
> > scripts from some dusty corner ...
> >
> > Ok, I think I found them:
> > > $ ls -l pd2amforth ./pd/*
> > > -rw-r----- 1 ew ew  122 2015-09-03 18:09 ./pd/__init__.py
> > > -rw-r----- 1 ew ew  226 2015-09-03 18:09 ./pd/convert_number.py
> > > -rw-r----- 1 ew ew 2183 2016-10-18 20:40 ./pd/device.py
> > > -rw-r----- 1 ew ew 1187 2016-10-18 20:40 ./pd/interrupts.py
> > > -rw-r----- 1 ew ew  200 2015-09-03 18:09 ./pd/make_path.py
> > > -rw-r----- 1 ew ew 1618 2016-10-18 20:40 ./pd/register.py
> > > -rw-r----- 1 ew ew 1509 2016-10-18 20:40 ./pd/sleep.py
> > > -rw-r----- 1 ew ew 1065 2016-10-18 20:40 ./pd/wdt.py
> > > -rwxr-x--- 1 ew ew 1840 2016-10-18 20:40 pd2amforth*
> >
> >
> > I do not know really, how they work, but I can certainly add
> > them to the repository ...
> >
> 
> Thanks, please let me know when you have had a chance to add the scripts,
> device.py looks interesting.
> 
> 
> > Cheers,
> > Erich
> >
> 
> Cheers,
> Stephen
> 
> 
> >
> > --
> > May the Forth be with you ...
> 
> 
> And also with you ;)
> 
> _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie getting started with AVR128DA48

[Stephen D <au....@gm...>]

Hi Erich,
thank you for getting back to me so quickly.

On Tue, 29 Dec 2020 at 22:30, Erich Wälde <ew....@na...> wrote:

> Well, well. This is one of the secrets that I have not yet
> uncovered from the files I have. You might not know that the
> author of AmForth has left this planet earlier this year. So we
> have to make due with some code archeology :)
>

I saw with surprise and sadness the news of Matthias' passing. I imagine
this has caused a great deal of disruption for this project. If I can help
in any way I will.

AVR128DA48. What a beast. I skimmed the datasheet only briefly
> https://www.microchip.com/wwwproducts/en/AVR128DA48
>
> If you want to work your way to support this chip, I suggest to
> make a twofold approach:
>
> 1. Have a controller, which is supported by AmForth already,
> like the venerable atmega328p. Use this to set up the whole tool
> chain and verify, that you can build and upload it, and that the
> result is actually working. Unless, of course, you have done
> this already.
>

I have access to an STK600 and several devices in the atmega family.
Haven't programmed one with AmForth yet but based on what I've read in the
documentation I am not expecting too many problems.


> 2. Then try to fill in pieces for the new controller. Start with
> the files of a supported controller with the same size flash/ram
> /eeprom.
>
> You have to make sure, that the new controller uses the exakt
> same set of assembly instructions --- it probably does not,
> because I read the word "hardware multiplier"
>
> > The AVR128DA48 microcontroller is part of the AVR DA family
> > featuring the AVR processor with hardware multiplier - running
> > at up to 24 MHz and with 128 KB Flash, 16 KB SRAM and 512
> > bytes of EEPROM in 48-pin packages.
>

I don't think it's going to be straight forward -
https://ww1.microchip.com/downloads/en/Appnotes/Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdf
There appear to be a number of changes at the C macro and register level
from the previous mega generation. I have not dug deep enough into the
AmForth code yet but it may require a fair bit of rework.

Meanwhile I will have a look whether I can uncover the generator
> scripts from some dusty corner ...
>
> Ok, I think I found them:
> > $ ls -l pd2amforth ./pd/*
> > -rw-r----- 1 ew ew  122 2015-09-03 18:09 ./pd/__init__.py
> > -rw-r----- 1 ew ew  226 2015-09-03 18:09 ./pd/convert_number.py
> > -rw-r----- 1 ew ew 2183 2016-10-18 20:40 ./pd/device.py
> > -rw-r----- 1 ew ew 1187 2016-10-18 20:40 ./pd/interrupts.py
> > -rw-r----- 1 ew ew  200 2015-09-03 18:09 ./pd/make_path.py
> > -rw-r----- 1 ew ew 1618 2016-10-18 20:40 ./pd/register.py
> > -rw-r----- 1 ew ew 1509 2016-10-18 20:40 ./pd/sleep.py
> > -rw-r----- 1 ew ew 1065 2016-10-18 20:40 ./pd/wdt.py
> > -rwxr-x--- 1 ew ew 1840 2016-10-18 20:40 pd2amforth*
>
>
> I do not know really, how they work, but I can certainly add
> them to the repository ...
>

Thanks, please let me know when you have had a chance to add the scripts,
device.py looks interesting.


> Cheers,
> Erich
>

Cheers,
Stephen


>
> --
> May the Forth be with you ...


And also with you ;)

_______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Newbie getting started with AVR128DA48

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

Hello Stephen,

welcome to the list!

Stephen D writes:

> Hi all,
> would like to try running amforth on one of the new AVR processors, the
> AVR128DA48 to be exact. A Curiosity Nano board turned up this week and I'm
> keen to give it a try.
>
> Am a total newb with regards to amforth and forth in general but have
> plenty of AVR programming experience, both in C and assembler. Have looked
> through the User and Technical Guides but not found an answer to my
> question:
>
> How do you define a new AVR8 chip within amforth?
>
> I have looked through the files under /avr8/devices/atmega* e.g.
> device.asm, device.inc etc. They all claim to be "generated automatically".
> I have not been able to find where the automatic generation is performed.
> Is anyone able to point me in the right direction please?

Well, well. This is one of the secrets that I have not yet
uncovered from the files I have. You might not know that the
author of AmForth has left this planet earlier this year. So we
have to make due with some code archeology :)

AVR128DA48. What a beast. I skimmed the datasheet only briefly
https://www.microchip.com/wwwproducts/en/AVR128DA48

If you want to work your way to support this chip, I suggest to
make a twofold approach:

1. Have a controller, which is supported by AmForth already,
like the venerable atmega328p. Use this to set up the whole tool
chain and verify, that you can build and upload it, and that the
result is actually working. Unless, of course, you have done
this already.

2. Then try to fill in pieces for the new controller. Start with
the files of a supported controller with the same size flash/ram
/eeprom.

You have to make sure, that the new controller uses the exakt
same set of assembly instructions --- it probably does not,
because I read the word "hardware multiplier"

> The AVR128DA48 microcontroller is part of the AVR DA family
> featuring the AVR processor with hardware multiplier - running
> at up to 24 MHz and with 128 KB Flash, 16 KB SRAM and 512
> bytes of EEPROM in 48-pin packages.


Meanwhile I will have a look whether I can uncover the generator
scripts from some dusty corner ...

Ok, I think I found them:
> $ ls -l pd2amforth ./pd/*
> -rw-r----- 1 ew ew  122 2015-09-03 18:09 ./pd/__init__.py
> -rw-r----- 1 ew ew  226 2015-09-03 18:09 ./pd/convert_number.py
> -rw-r----- 1 ew ew 2183 2016-10-18 20:40 ./pd/device.py
> -rw-r----- 1 ew ew 1187 2016-10-18 20:40 ./pd/interrupts.py
> -rw-r----- 1 ew ew  200 2015-09-03 18:09 ./pd/make_path.py
> -rw-r----- 1 ew ew 1618 2016-10-18 20:40 ./pd/register.py
> -rw-r----- 1 ew ew 1509 2016-10-18 20:40 ./pd/sleep.py
> -rw-r----- 1 ew ew 1065 2016-10-18 20:40 ./pd/wdt.py
> -rwxr-x--- 1 ew ew 1840 2016-10-18 20:40 pd2amforth*


I do not know really, how they work, but I can certainly add
them to the repository ...

Cheers,
Erich



-- 
May the Forth be with you ...

[Amforth] Newbie getting started with AVR128DA48

[Stephen D <au....@gm...>]

Hi all,
would like to try running amforth on one of the new AVR processors, the
AVR128DA48 to be exact. A Curiosity Nano board turned up this week and I'm
keen to give it a try.

Am a total newb with regards to amforth and forth in general but have
plenty of AVR programming experience, both in C and assembler. Have looked
through the User and Technical Guides but not found an answer to my
question:

How do you define a new AVR8 chip within amforth?

I have looked through the files under /avr8/devices/atmega* e.g.
device.asm, device.inc etc. They all claim to be "generated automatically".
I have not been able to find where the automatic generation is performed.
Is anyone able to point me in the right direction please?

Thanks,
Stephen

[Amforth] First release of ./test subdir

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

Dear AmForthers,

2020-11-02 I wrote:

> 3. Add testing scripts --- I have a set of scripts for that, but I
>    have not run this stuff yet. However, in my opinion adding a
>    working test suite is far more important at the moment, than
>    anything else.
>
>    This includes preparing some hardware with 4 relevant target boards
>    in order to simplify the process.
>

I have committed r2456 with an added ./test tree.
It features one board (avr8-at644p) and a handful of test cases:
> ./bin/grok-test-log.pl tmp/unit-test.log
> TESTING addition
> INCORRECT RESULT: t{ 1 1 + -> 10 }t
>       2/3 ok, (1 failed)
> TESTING subtraction
> INCORRECT RESULT: t{ 21 4 - -> 16 }t
>       4/5 ok, (1 failed)
> TESTING multiplication
> INCORRECT RESULT: t{ $ffff -1 * -> $efff }t
>       3/4 ok, (1 failed)
> Summary:
>       9/12 ok, (3 failed)


Feel free to experiment. This is by no means ready for primetime
or complete. I add the text of the Howto below. Yes its lengthy.
But it wouldn't be worth your time if it was much shorter.


I am awaiting you comments, ideas, contributions.


Thank you for your patience and time!

Stay healthy!
Norhtern winter solstice upcoming in less than 3 days!

Cheers,
Erich




--- ./trunk/test/Howto.txt -------------------------------------------

* test

  How to run this stuff?

** prolog

   This new "test" tree is a "release early" thing. I can run "make
   test" on exactly my specific target board. I have written only a
   handful of tests in order to demonstrate the tree structure and the
   scripts. It probably needs a few more scripts and iterations to get
   this all into a clean state.


   While preparing this I realized that I probably do things quite a
   bit different. Here is why:

   Firstly, when I started with AmForth (version 2.1) neither
   "amforth-upload.py" let alone "amforth-shell.py" existed. They came
   in version 2.7 and 3.2 respectively. I remember using
   "tools/am4up.c" from within minicom and maybe other exiting hacks.

   Secondly, since sending comments to the controller were clearly a
   waste of time, I did, what any "good (tm)" Unix citizen would do: I
   wrote a few (perl) scripts as filters to make this more pleasant.
   "fs.unfold" and "fs.trim" --- they are included in
   : trunk/test/bin
   These scripts are quite simple.

   - fs.unfold :: will read the given input line by line. If a line
     starts with the pattern '^[#]*include\s+' then the next word is
     used as a file name (no spaces allowed). The file name is
     expected to be relative to the current directory. There is no
     searching and thus no error-multiple-files-found to handle. If
     the path/name does not exist, too bad, the script will bail out!

     To make the tree structure look identical in all projects, I use
     symlinks to point into the relevant source tree.

     If the file is found, its content will be added verbatim to the
     output stream, of course resolving any new include statements if
     present (recursively call the script itself again).

     The output is annotated with text markers, the resulting output
     is there to be read by human eyes.

   - fs.trim :: is removing comments, trailing whitespace, empty
     lines. It compresses whitespace after the first word (I like the
     indentation to be kept, it makes reading more pleasant while the
     code is uploading.

   And in the Makefile I will unfold by program.fs file, trim it and
   then uplaod it. Any error makes the pipeline "Fail early!"

   I switched to amforth-upload.py when it became available for the
   upload part. However, I stayed with an old version (4.0), because I
   did not like something about the newer version.

   Then along came "amforth-shell.py". It is spectacularly useful for
   newcomers. However: it needs a nicely populated tree and it changes
   the uploaded source code behind my neck (e.g. replacing PORTA by
   the appropriate value). While I do agree that this is nice for
   others, I hate it. I will not learn, that I forgot to define
   something. This will bite me when "away from home" without the
   nicely populated tree of useful files, of course.

   After that the "#require" thing came along. for similar reasons I
   don't like it, and therefore I wrote another script to delete
   these lines: "fs.del_require".

   The astute reader may have noticed, that in my little world
   comments are comments:
   : \ #include
   : \ #require
   are just comments. They are ignored.


   So, this is why things are set up like they are:
   - no searching
   - bail out on the slightest error
   - be strict to make this experiment /reproducible/

   In the interactive world, by all means use amforth-shell.py if you
   like!


** preparations

   As usual you will need all external software, to make this run. In
   my case this is at least (you hopefully get the idea):

   : bash perl python make wine/AvrAsm2 avrdude minicom

   Then there are a few /important/ symlinks.

   1.
   : trunk/avr8/Atmel -> your/local/path/to/AvrAssembler2
   This is referenced in
   : trunk/test/firmware/avr8-at644p/Makefile
   to find the Atmel assembler (run with wine)

   2.
   : trunk/test/firmware/avr8-at644p/lib
   : trunk/test/firmware/avr8-at644p/lib-avr8
   which point back into the source code tree. This is my way to find
   files like the Hayes tester
   : include lib/forth2012/tester/tester-amforth.frt
   or any other loadable forth code.
   These symlinks are currently checked in, so nothing to do.


   And there are a number of variables in
   : trunk/test/Makefile
   : trunk/firmware/avr8-at644p/Makefile
   describing the programmer and the serial interface. These should
   maybe go into separate files to be included ...



** directory tree explained

   : trunk
   :     +-- avr8
   :     |   +-- Atmel -> .local.path.to/AvrAssembler2
   :     |
   :     +-- test
   :     |   +-- Makefile
   :     |   +-- bin
   :     |   |   +-- amforth-upload-4.0.py
   :     |   |   +-- fs.del_require
   :     |   |   +-- fs.trim
   :     |   |   +-- fs.unfold
   :     |   |   +-- grok-test-log.pl
   :     |   |
   :     |   +-- cases
   :     |   |   +-- common
   :     |   |   |   +-- double
   :     |   |   |   |   +-- t_2over.frt
   :     |   |   |   +-- t_arithmetic.fs
   :     |   |   +-- avr8
   :     |   |
   :     |   +-- firmware
   :     |       +-- avr8-at644p
   :     |           +-- Makefile
   :     |           +-- dict_appl.inc
   :     |           +-- dict_appl_core.inc
   :     |           +-- first.fs
   :     |           +-- lib      -> ../../../common/lib
   :     |           +-- lib-avr8 -> ../../../avr8/lib
   :     |           +-- testfirmware.asm
   :     |           +-- testfirmware.fs
   :     |           +-- words
   :     |               +-- applturnkey.asm
   :     |               +-- qmark.asm

   - "test" is the new subdirectory.
   - "test/bin" holds hopefully all needed scripts.
   - "test/firmware" holds subdirectories for specific
     "architecture"-"target board" combinations. An obvious new
     candidate would be "avr8-duemilanove" or similar.
   - "test/cases" holds a tree of test case files.


** prepare a given target board

   : make firmware TARGET=avr8-at644p
   : make firmware-install TARGET=avr8-at644p

   Please note that the exact configuration of your target boards need
   possibly new subdirectories, specific values for cpu speed, baud
   rate, and serial interface, maybe much more.

   This would also be the place to include more .asm functions.

   "firmware" and "firmware-install" are make targets in
   : firmware/$arch-$target/Makefile
   They are called from the top level Makefile.

   I resisted the urge to create a superfancy single session make.
   While modern and sexy it is close to unpenetrable if you have not
   used this before.

** run tests

   : make upload-tester TARGET=avr8-at644p
   : make test TARGET=avr8-at644p

   Uploading the hayes tester is a separate step. The relevant file
   can be amended to include any desired .frt files, of course.

** write new tests

   Well, this is hopefully simple, get inspired by the few examples
   available.



** Epilog

   As said, this is "minimal art work".

   Don't be afraid to experiment with it.

   My goal is to make it simple for anyone to actually run the test
   suite.

   It should be simple to add more test cases. The structure should
   maybe follow the structure in the lib source directories.

   It should be possible to add a new board for any supported
   architecture with modest effort.


-- 
May the Forth be with you ...

Re: [Amforth] 2020 festive paper exchange

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

Hello David and Erich,

Thank you very much for your links. I will certainly have plenty to
keep me occupied and away from the TV over the holidays.

> Finite State Machines in Forth (J.V. Noble 1995)

Perhaps J.V. Noble's Finite State Machines in Forth and Erich's Vierte
Dimension article could be referenced on the AmForth website? For a
newcomer to Forth like me, it is too useful a paper to have to rely on
finding it by chance!

Best wishes,
Tristan

On 10Dec20 18:23, Erich Wälde wrote:
> Hello Tristan,
> 
> Tristan Williams writes:
> 
> > Hello AmForthers,
> >
> > With the season's TV not to everybody's taste and ownership of the
> > remote control contested, having an alternative activity is a good
> > idea. Over the decades there have been many good Forth papers written,
> > but finding approachable, self-contained ones is not always easy (for
> > me at least). Whilst it has been mentioned on the mailing list before,
> > here is one of my favourites
> >
> > Finite State Machines in Forth (J.V. Noble 1995)
> > http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html
> 
> This is indeed a very nice paper. So nice indeed, that I
> produced a working demo for AmForth :-)
> 
> https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2012-02.pdf
> page 6. in German, as you have guessed already.
> 
> 
> > Do you have any papers/articles to share?
> 
> One of my favourite papers is this:
> Salvatore Gaglio et al. -- Use of Forth to Enable Distributed
> Processing onWireless Sensor Networks
> 
> https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2016-01.pdf
> page 9, in English!
> and references therein.
> 
> 
> Cheers,
> Erich
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] 2020 festive paper exchange

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

Hello Tristan,

Tristan Williams writes:

> Hello AmForthers,
>
> With the season's TV not to everybody's taste and ownership of the
> remote control contested, having an alternative activity is a good
> idea. Over the decades there have been many good Forth papers written,
> but finding approachable, self-contained ones is not always easy (for
> me at least). Whilst it has been mentioned on the mailing list before,
> here is one of my favourites
>
> Finite State Machines in Forth (J.V. Noble 1995)
> http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html

This is indeed a very nice paper. So nice indeed, that I
produced a working demo for AmForth :-)

https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2012-02.pdf
page 6. in German, as you have guessed already.


> Do you have any papers/articles to share?

One of my favourite papers is this:
Salvatore Gaglio et al. -- Use of Forth to Enable Distributed
Processing onWireless Sensor Networks

https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2016-01.pdf
page 9, in English!
and references therein.


Cheers,
Erich