Re: [Amforth] OFFLIST Re: A RISC-V update

[Erich Wälde]

so, it's not offlist at all, sigh.
Oh, well.
E.

Erich Wälde  writes:

> [[PGP Signed Part:Undecided]]
> Hello Tristan,
>

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] OFFLIST Re: A RISC-V update

[Erich Wälde]

Hello Tristan,

I'm quite impressed by the progress you make. And I think it's
high time to at least answer: "I read your mails" :)

That being said, I don't know, how much of my health stuff I
mentioned to you. So I'll let you know this much:

1. Last July my right eye suffered an ablatio retinae. This in
itself is bad already, but not entirely unexpected, since I am
myopic since the age of 10. So it got fixed by surgery, I'll
spare you all the interesting details. The repair didn't last
and it came off again TWO more times! And just because, in
November my left eye suffered the same problem. So from November
10.th to the end of the year I was not seeing much and somewhat
depressed over all. In January the final step for the right eye
was done and I start to see a lot better now. But even reading
on the screen was close to impossible for two months. Sigh. I
have not been to work since July, and with some luck I can start
going there again (reduced time initially) in March.

2. About 6 years ago I acquired a thing called "chronic fatigue
syndrom". This term is for lack of better understanding, what's
going on. The symptoms are similar or maybe the same as in Long
Covid, but the phenomenon has existed before. I readily admit,
that I have only a very mild version of this. But I can feel the
lack of power (physically and mentally) every day. The whole
thing is not understood, let alone any root causes. Anyway. This
has forced me to let go of several things, including the amforth
projekt.


With that now out of the way, I would suggest, that you receive
the login credentials for the source forge repository. Unless of
course, you have different plans. It's up to you. If you are
interested, do you have some sort of pgp key or so, where I can
send the magic spells hidden from prying eyes?


Along other lines: I have started to play with my avr/atmega
boards again, and I am currently working to get a much newer
radio chip connected and working: the hopeRF rfm69. In
comparison to the old rfm12 this is a wizzard module. It can
handle packet radio on it's own, while the rfm12 could only
handle one byte transmit/receive, one byte in the fifo. Plus the
rfm69 will handle aes encryption, automatic checksumming and
other useful tricks on its own. However, that means that I need
to read a lot of documentation and other projects' code to
understand, how to tame the beast. I can currently send
something, but I have not tried to receive the datagram yet. I
can "see" the transmission in gnuradio with an DVB-T stick used
as receiver. The whole thing is fun, but I am very slow.

Let me know, what you think.
Cheers,
Erich

I'll attach my public key:
pub   rsa4096 2020-12-12 [SC]
  03D05884448B9F17B9EC536ADBA0681A2AFE4FE1
uid   [ultimate] Erich Wälde (AmForth project) 

-- next part --




h...@tjnw.co.uk writes:

> A risc-v update.
>
> AmForth-RV update
>
> Good progress made with the CH32V307 [0]
>
> Words defined in the RAM dictionary can now be appended to the FLASH
> dictionary so user defined words (individual words or the entire RAM
> dictionary) are able to survive a reset. This was one of my major
> milestones and (in my mind) a requirement for a self-hosted Forth. I
> was not able to achieve this with the FE310 based red v board.
>
> Additionally, something new to AmForth. Compiled C objects can be linked
> into AmForth-RV and called from within CODEWORDs. This is a build
> level modification and arguments are passed to the C function using
> assembly according to the risc-v calling convention.
>
> The CH32V307 makes a very good target mcu for AmForth-RV and for
> experimenting with embedded RISC-V in general.
>
> - The development board is inexpensive and available [1] [2]
> - There is official documentation and many 3rd party resources
> - The mcu can program its own flash whilst executing from flash
> - AmForth-RV can be built with an open source toolchain (build in < 3s, flash 
> in
>  < 6s )
>
> If you are interested in trying some risc-v hardware I think it is a
> good choice.
>
> AmForth-RV is still experimental, but has made a step in the direction
> of being less so. There are quite a few decisions to be made, so any
> thoughts on what AmForth-RV might look like in the future are very much
> welcomed.
>
> Best wishes,
> Tristan
>
> [0] https://github.com/openwch/ch32v307
> [1] https://wchofficialstore.aliexpress.com/store/1100367542
> [2] https://www.aliexpress.com/item/1005004329125620.html
> (and many other suppliers)
>
> A brief annotated/edited session showing saving a RAM dictionary word.
>
> // see if a word 3+ has been defined //
>
>  ok
>> show 3+
> LFA. (LFA)... FFA. (FFA)... NFA. XT.. (XT) word
>  

Re: [Amforth] Maintainer(s) for AmForth

[Erich Wälde]

Hello all,

good to see some interest in this project again.



Mark Roth  writes:

> Good morning AmForth'ers (feel free to adjust the greeting with your RTC).

>snip<<

>> Tristan wrote, if I'm not mistaken
>>
>> The fact is that this project is still useful.
>>
>> I completely agree. AmForth is quite special as an embedded Forth in
>> that it has wordlists, recognizers and comprehensive documentation.
>>
>> In suggesting a maintainer group the idea was that the effort required
>> to preserve and update AmForth could be divided up, and perhaps if
>> some of the more mundane aspects of avoiding bit rot are done, then
>> people with more specialised skills, but less time, might feel more
>> able to help.
>>
>> What would I suggest for the near term?
>>
>
> This seems to me to pretty much sum up a good mission statement of what
> AmForth is and why it can continue to be viable. Even with ONLY the focus
> on the AVR8 side of the repo, which is the core of it, adding more up to
> date chips as Tristan mentions later is a great way to interest new people
> and keep things from going to seed. So I'll sum up the points made and
> expand where needed.


So, jumping right into the TODO section
>
> 0. Where should the official repo be?
in December 2020 I have created a git based version of the
repository at
  https://git.sr.ht/~amforth/

it comes in two flavours:
- code-tree :: the releases tree is preserved as is, since it is
a lot simpler for me to find changes across versions with find,
grep et al.
- code :: the releases tree is converted to git branches, which
just proves, that it can be done.

The repository at sourcehut is currently paid by me. Sourcehut
has integration with email workflows, it is possible to have
tickets and commits be handled by email to some extent, maybe
completely. The web frontend works without javascript, which is
why I am there with my private stuff as well.

That being said: I am still somewhat hesitant to move everything
over, since I fear that the small community (think mailing list)
might not resubscribe at the new place. I could be wrong though.
And if a quorum of '3' is sufficient, go for it :)

I still offer to send authentication stuff regarding
sourceforge.net to folks on this list. However, at the time
nobody expressed interest.


> 1. At least two people with write access to the repo for
> redundancy.
Tristan? Mark? Else?

> 2. Make a 7.0 release at that time including
>> a. the avra build
>> b. an up to date version of the project makefile
>> c. at least the first layers of documentation brought up to date
>> d. the prebuilt hex files (really just a cleaning of the project
>> directory in general)

I personally think, the avra build is important. This was the
remaining head ache for me, relying on a piece of proprietary
software, which might break at the least convenient time. Now I
do accept, that not everyone is on Linux/*BSD.

I still have a file which documents the steps to build a release
and the associated web site. (I'll stuff this into a separate
email)

I am not a friend of prebuilt hex files, but again, other people
have different preferences. I'd rather push someone through
creating their .hex files, because it opens the world for them.

> 3. Deciding on a better way to communicate be it built in like
> github has or something that goes hand in hand.


> 4. Discussing what it would take to continue on with something
> like the RISC-V side of the repo.

I have created a personal fork of amForth starting at version
5.0, because it did build with avra, and it is before the other
target platforms were included
- MSP430 at version 5.6
- RV32 at version 6.7
- ARM at version 6.8

I have yet to find a stability problem in my use/setup on avr
amForth, which has not surfaced. I decided to go back to a
version with simpler overall structure (and some known bugs :)

I agree that risc-v is the most appealing future target, I would
not hesitate to remove msp430 and arm and point users to
mecrisp.



>
> So, that is the way I see it. I'd like to add right up front that while I
> am not very skilled with forth I have spent a good deal of time learning
> how to get better with it. It is pretty much the only language I have
> studied these last couple of years. I am time rich so I will volunteer a
> portion of that time if there is a viable way to make AmForth feel more
> modern. To me right now it feels like an old dusty attic. There are still
> great things to be discovered, but they are up a creaky flight of stairs,
> in a poorly lit room and covered in a bit of dusty age. A big part of that
> for me is the Source Forge side. I use git locally and github publicly
> (although I have used a couple other flavors of public git when needed). I
> am painfully aware that there are issues in using github. I get that, but I
> like the overall tool and the fact there is no cost outlay to have
> something anyone can get at. A bugtracker, discussions, wiki etc are things
> I put a lot

[Amforth] promised doc: how to make a release

[Erich Wälde]

As promised.
The file is plain ascii .org mode format:


--- Howto-make-a-release.org ---
# 2020-10-12  amforth/erwaelde

* How to properly make a release?

  Somewhat machine readable version.

** Intro

   #+begin_quote
 1. check all version numbers in trunk

- doc/Makefile being one place. This seems to be used in all
  generated documentation, which is nice.
- common/words/env-forthversion.asm is another place with different
  syntax!
Judging by commit r2271, these are all places indeed. Yay!

 2. update doc/source/index.rst and optionally history.rst in
trunk and commit

 3. "svn copy" trunk to releases/$VERSION; commit message collects
the accumulated one line change descriptions
This is the most visible change in the source tree
e.g. see commit r2244 (rel 6.5)

 4. create all .hex files for target boards in appl/
arduino,atmega2561,eval-pollin,hifive1,launchpad-arm,launchpad430,
template

I had forgotten that these exsisted. They are in the release archive
only, not in the source tree. Now I understand, why people
sometimes ask about them.

This step is detailed in a few .xml files. Matthias used ant to
build them. I have not built these before, but this looks doable,
provided I get all relevant toolchains up and running.

 5. create the documentation
- htdocs, the web page
- books, did you know that all the content of the webpage shows up
  in amforth.pdf (made with pdflatex) and AmForth.epub (made with
  sphinx-build)? Amazing! These books are part of the download .zip
  archive.

  This step is a "cd doc; make all" --- provided sphinx pdflatex
  and all the good stuff is installed.

 6. create a new temporary tree to collect everything, that goes into
the release archive:
- sources
- some of the scripts, tools, meta-files
- the generated documentation from releases/$VERSION, without the
  document sources, but including the "books"

I have not found anything that looks like doing this.

 7. create the .zip and .tar.gz archives (the easy part), and upload
them to their correct location in the sourceforge.net file tree
(the not so obvious part).

I found out that these release archives were built by Matthias.
The files for 6.8 are about 7 MB in size.

Whereas if you download "the latest sources", sourceforge will
generate a snapshot of "trunk". This is a plain copy, without all
the niceties included in the archives mentioned here. This archive
is currently 35 MB in size.

 8. sync the generated documentation with the online website

I have done this a few times now, but I'm still asking myself, if I
see all relevant pieces or not.

 9. Increment the version numbers in trunk and commit


 So nine easy steps to code nirvana? Hmmm.
   #+end_quote


** Go to the correct directory

   #+begin_src sh
cd ~/eGeek/sourceforge.net/amforth-code
   #+end_src

** Check current Version Strings

   Fortunately only three files:

   #+begin_src sh
(
cd trunk
grep '^VERSION' doc/Makefile

cat common/words/env-forthversion.asm
cat shared/words/env-forthversion.s
)
   #+end_src

** update doc/source/index.rst

   Do /not/ delete any blank lines in this file, they are sorely needed!

   #+begin_src diff
ew@ceres:~/eGeek/sourceforge.net/amforth-code 7 > svn diff trunk/
Index: trunk/doc/source/index.rst
===
--- trunk/doc/source/index.rst  (revision 2451)
+++ trunk/doc/source/index.rst  (working copy)
@@ -36,6 +36,9 @@
 See the code section at Sourceforge to get the
 `most recent sources 
`__
 
+18.10.2020: release 6.9
+...
+
 * tools/amforth-shell.py fixed python3 error (in --no-error-on-output
   option path), fix provided by Tristan Williams.
 * tools/amforth-shell.py fixed indentation error in line 1146, fix provided by 
Tristan Williams.
   #+end_src

   : svn commit trunk/doc/source/index.rst -m 'call it version 6.9'
   : svn up


** create releases/$Version

   #+begin_src sh
svn cp trunk/ releases/6.9
   #+end_src

   Alle ? Dateien werden hier mitkopiert, aber wenigstens nicht mit
   add verziert. Aha.

   edit svn.msg, collect all comments from index.rst since last release

   : svn commit . --file svn.msg
   : svn up


** increment $Version

   : vi trunk/doc/Makefile
   : vi trunk/common/words/env-forthversion.asm
   : vi trunk/shared/words/env-forthversion.s
   : svn commit trunk/doc/Makefile trunk/common/words/env-forthversion.asm 
trunk/shared/words/env-forthversion.s -m 'Increment version to 7.0'


** commit

   see e.g. r2432 .. r2434

** checkout a temp. release tree

   #+begin_src sh
cd ~
mkdir tmp-amforth-code
cd tmp-amforth-code
svn checkout svn://svn.code.sf.net/p/amforth/code/releases/6.9
cd 6.9
# add Atmel AvrAsm2 tree
wget 
https://sourceforge.net/proje

Re: [Amforth] Maintainer(s) for AmForth

[Erich Wälde]

Hi Mark,

Mark Roth  writes:

> Here is the clean link.
>
> https://github.com/CableGuy67/avra

Thanks for pulling this together.

I can successfully build the executable on debian 12, gcc 13.2
on a riscv64 machine. :)

I would kindly suggest to increase the version number, or add
some local suffix.

Thanks,
Erich

> On Mon, Sep 25, 2023 at 8:30 AM Mark Roth  wrote:
>
>>
>>
>> > Talking of maintenance, I note that avra (on Sourceforge) hasn't been
>>
>>> > updated since 2019. Maybe it's completed?

PS: to me it seems, that Robert Russel has ceased all activity
on github. Whatever that means.



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] avra on a raspi zero v1

[Erich Wälde]

Hello Mark, hello all,

congrats to your hack-box! :)

This is very close to what I am currently using (software wise).
I had ordered a Hifive Unmatched, a riscv64 computer in miniITX
Format. And once I got it going with Debian unstable, I
installed: avra, minicom (terminal), avrdude (burner), perl and
my scripts to use it for dabbling with amForth. No wine and
avrasm.exe involved. I have not upgraded my avra along the lines
mentioned recently, but I plan to. Granted, it is a much bigger
machine, but at least it is not collecting dust.

The warning with "'" missing a closing ' ... yes well. It does
work in the end, so no sweat.

Cheers,
Erich

Mark Roth  writes:

> Hello all.
>
> I managed to day to cobble together my AmForth "computer" which is pretty
> much the reason for avoiding using wine to build things. It consists of a
> raspberry pi zero W v1(whatever point 5 maybe) as a base with raspian lite
> on it. That has a usb hub, an old palm pilot folding keyboard the
> connection to my uart for the controller and the usbasp to program. The
> display was a bit overboard as it's a waveshare hdmi 800x480 7 inch thing
> that makes it possible to actually use it for real.
>
> Tonight I managed to get all the cobbled bits to work together and to build
> everything including avra on the zero then flash the controller. So, no
> real computer but using e4thcom after flashing let me get in and use that
> nice big screen as a terminal.
>
> I still haven't sorted out the single tick thing but I can kind of see
> where it is coming from in avra. Pretty sure my C skills have faded over
> the decades that it may just be a problem to look past.
>
> I guess now it's time to work on a nice box for the whole thing so I could
> sit anywhere, plug in a powerbank and hack away. I'll try and get some
> better documentation up soon but it really wasn't terribly difficult. It
> was really really nice to do everything from Raspian knowing that wine
> wasn't an option.
>
> Enjoy the weekend,
> Mark
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] successful compilation with avra

[Erich Wälde]

Hello Brian and Mark,

very nice to see emails on this list :)

Compiling amforth with avra?

I have made numerous experiments a long time ago and again more
recently. If memory serves me well:
- Amforth had been good with avra, at least in the 4.x range.
- However, avrasm2.exe could do more clever tricks, and Matthias
started using those.
- I did make a fork of amForth from Version 5.0, this can be
assembled with avra, see:
https://git.sr.ht/~ew/hbv3_am50forth
- avra received a bit of attention not so long ago (same repo
you found):
https://github.com/Ro5bert/avra
> $ avra --version
> AVRA: advanced AVR macro assembler (version 1.4.2)
which among other changes now includes my favourite atmega644p.

So, I am currently dabbling with my fork again in the hope to
eventually catch that problem of long term stability. There is
absolutely no reason, why I have to reprogram one or two of my
controllers a few times per year, because they do not start up
after a power cycle, which in turn is done, because the
communication with that controller ceases to work. I went back
to amforth 5.0 for simplicity reasons.


All that being said, I would be very interested to see the
changes, maybe, just maybe we can fix the amForth source tree
enough to make avra happy.


Cheers,
Erich

Brian K Navarette  writes:

> That is awesome news!
> Brian-in-ohio
>
>
> On Thu, Aug 24, 2023 at 2:59 PM Mark Roth  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/
>> Amforth-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Followup: AmForth Project open for adoption

[Erich Wälde]

Sorry, hit the button quite prematurely :)


Dear AmForthers,

thank you so much for your kind words!

So far a person behind the email address "i...@unbina.re" 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  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

[Amforth] Followup: AmForth Project open for adoption

[Erich Wälde]

Erich Wälde  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 ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] AmForth Project open for adoption

[Erich Wälde]

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/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

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

[Erich Wälde]

Hello Stephen,

Stephen Simmons  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 = 1600
| .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 ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

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

[Erich Wälde]

Hello Stephen,

welcome to the list!

Stephen Simmons  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-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

[Erich Wälde]

Hello Helge,

Helge Kruse  writes:

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

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

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

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


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


Unless I have misunderstood your text ...


Cheers,
Erich


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

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

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

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

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

  inc xl
  andi xl,usart_rx_mask

  sts usart_rx_in, xl

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

.else  ; --- MPC version ---

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

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

   andi xh, (1< _finish on error 
(zero flag=0)

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

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

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

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

   rjmp usart_rx_isr_finish; } else {

usart_rx_isr_mpcmode:  ; multi-processor-communication mode 

   ldi zl, low(ram_station_id)  ; . Z = &ram_station_id
   ldi zh, high(ram_station_id) ; . .
   ld  xl, Z   ; . xl = ram_station_id
   cp  xl, xh  ; . xl == xh?
   brne usart_rx_isr_finish; . if ( ram_station_id == UDRn )
   andi temp0, (~(1<http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

[Erich Wälde]

Hello Helge,

welcome to the list!

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

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

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

Helge Kruse  writes:

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

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


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

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

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


Cheers,
Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie with a mega2560

[Erich Wälde]

Hello Michael,

Michael Picco  writes:

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

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

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

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

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

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


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

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

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


Cheers,
Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] marker failing? was: Newbie with a mega2560

[Erich Wälde]

I took the liberty to snip off the thread.

Hello Michael,

Michael Picco  writes:

> Hello!
>
> I seem to have stumbled across an issue.
>
> First code I wrote was to blink the LED onboard.  This worked just fine.
> Then I went to add 'marker'.  Entered it line-by-line ... got the 'Ok' after
> each line.  After adding the last line (semicolon), the board froze up.  Did a
> warm boot and then executed 'words' to see what was there.  It came back with
> ?? -13 5.
>
> What came to mind is perhaps not enough memory is allocated prior to flashing
> and I'm overwriting something I shouldn't.
>
> Any ideas?

I THOUGHT marker.frt needed something else, but apparently not:

On a atmega644pa with a brand new installed amforth 6.9:

> > ver
> amforth 6.9 ATmega644P ok
> > words
> int-trap int@ int! -int +int #int irq[]# >body s>d bounds
> init-ram ee>ram #tib tib source-tib ... ok
> >

Inspecting avr8/lib/forth2012/core-ext/marker.frt
There are no '#include', no '#requires' or other unobvious things.

I loaded just marker.frt (ignore the tools, just look at the
echo of amforth-upload.py)

> $ make marker CONSOLE=/dev/ttyUSB2 
> MARKER_LIST=lib-avr8/forth2012/core-ext/marker.frt
> cat lib-avr8/forth2012/core-ext/marker.frt | unfold_fs | trim_fs > zz.tmp.fs
> amforth-upload.py  -t /dev/ttyUSB2 zz.tmp.fs
> : marker
>  okget-current @e dp
>  okcreate
>  ok(marker) 0 do i @e , 2 +loop
>  ok, ,
>  ok  does>
>  ok(marker) 0 do dup @i i !e 1+ 2 +loop
>  okdup @i to dp
>  ok1+  @i get-current !e
>  ok;
>  ok
> time:  2.2858850956  seconds
> rm -f zz.tmp.fs
Works for me(tm).

Back to the serial console:
> > words
> marker int-trap int@ int! -int +int #int irq[]# >body s>d bounds
> init-ram ee>ram #tib tib source-tib ...
> ... applturnkey postpone (marker) end-code code ... ok
> >

Note that ' (marker) ' is deeper down the wordlist.

So? 
> ?? -13 5
says: there was an error (-13) before column 5 in the input. Example:
> > 1 2 + bla
>  ?? -13 9 
> >

HOWEVER, the controller should not freeze. Sometimes it looks
like it's frozen, because the cmd loop is still in compiling
mode after ':'. So entering ';' sometimes makes the prompt
appear again.


Cheers,
Erich

>snip<---


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie with a mega2560

[Erich Wälde]

Hello Michael,

welcome to the club!

Michael Picco  writes:

> Hello,
>
> I am attempting to use the mega2560 as a nicely featured development platform
> for AmForth-6.9.  The machine I'm using is a Win10 box, with Microchip Studio
> version 7 installed.
>
> In the zip file, under appl/atmega2561, I notice atmega256.eep.hex and
> atmega256.hex.  The eep.hex file doesn't seem to get recognized by 
> Studio 7.  Do I need to rename it to just a ".eep" file?

you write mega25_60_ and refer to mega25_61_ typo? Or are they
reasonably the same???

>
> Can I start building the platform by flashing these files into the board?  If
> so, what is the process to add functionality (I2C, SPI, etc.)?  As a total
> newbie!
>
> If it's necessary to recompile and create new hex files, the process is
> unclear.  Is it spelled out somewhere such that a beginner can follow 
> some basic steps to make the proper file(s)?
>
> It is my understanding that both flash and EEPROM need to be written, along
> with the fuses, [E:0xFF, H: 0xDC, L:0xFF].  Do I have these
> correct?

Fuses are a bit tricky. You can sort of brick your device. It
will not talk to you any more, and ways out are with varying
tricks ... So be careful.

I do not have a 2560. If I had to use one, I would hunt down the
data sheet and read the section about the fuses. And this is
plenty confusing stuff. Try to translate the above settings into
words. Bit by bit. There is also a "fuse calculator" somewhere
online ...
http://eleccelerator.com/fusecalc/

There is even an Android App for this LOL!
https://play.google.com/store/apps/details?id=me.chayan.avrfusecalculator&hl=en_US&gl=US


Again: Do not brick your only one device! If you can possibly
help it :-) I have done this. So you don't have to, right?


> Once I get this figured out, I'd like to submit a write-up for newbies and
> perhaps draw more users into AmForth. 

There is some document about your setup ... vom Karl maybe ...

http://amforth.sourceforge.net/UG/amforth_user.html
http://amforth.sourceforge.net/UG/windows.html

I have no idea how useful this is today. But feel free to update
this document.


> How might I get this posted, when
> completed?
just send it to this list. I'm working on migrating to git.
see https://git.sr.ht/~amforth/
for starters.

Cheers,
Erich



-- 
May the Forth be with you ...

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] git question/moving to sourchut

[Erich Wälde]

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 g...@git.sr.ht:~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 ...

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

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

[Erich Wälde]

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?=  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://erwae...@svn.code.sf.net/p/amforth/code
> # Relative URL: ^/
> # Repository Root: svn+ssh://erwae...@svn.code.sf.net/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 g...@git.sr.ht:~amforth/code
>
> git remote -v
> # origing...@git.sr.ht:~amforth/code (fetch)
> # origing...@git.sr.ht:~amforth/code (push)
>
> $ git push --set-upstream origin master
>
> git log
> # commit 0a29a13bc693b187d4eaa49f936bda90e7be7958 (HEAD -> master, 
> origin/master)
> # Author: erwaelde 
> # Date:   Wed Dec 30 16:15:03 2020 +
> # 
> # added tools/partdescription
> # 
> # commit ebdf8caa204c3b1725688e47160d92c37a0b6a8c
> # Author: erwaelde 
> # Date:   Fri Dec 18 21:41:20 2020 +
> # 
> # Early release of a new test subdirectory. Only one targetboard so far. 
> See test/Howto.txt
> # ...


-- 
May the Forth be with you ...

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Granted commit privileges to Carsten Strotmann

[Erich Wälde]

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-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Howto: conversion of svn to git

[Erich Wälde]

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://erwae...@svn.code.sf.net/p/amforth/code
# Relative URL: ^/
# Repository Root: svn+ssh://erwae...@svn.code.sf.net/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 g...@git.sr.ht:~amforth/code

git remote -v
# origing...@git.sr.ht:~amforth/code (fetch)
# origing...@git.sr.ht:~amforth/code (push)

$ git push --set-upstream origin master

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

-- 
May the Forth be with you ...

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Code copied to sourcehut.org

[Erich Wälde]

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-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] git question/moving to sourchut

[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

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/amfor

[Amforth] Added tools/partdescription to svn

[Erich Wälde]

Hello,

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

> $ svn commit . -m 'added tools/partdescription'
> Password: 
> Sendingdoc/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/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie getting started with AVR128DA48

[Erich Wälde]

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-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] First release of ./test subdir

[Erich Wälde]

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{ $ -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/ symlink

Re: [Amforth] 2020 festive paper exchange

[Erich Wälde]

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/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Trying to build AmForth for Atmega8

[Erich Wälde]

Hallo David,

long time no see :)
well, unfortunately ...

I have tried to assemble amforth-6.9 for atmega8.

The uart thing is quite simple to fix, as has been pointed out:

in template.asm:
-.include "drivers/usart_0.asm"
+.include "drivers/usart.asm"

And you made some progress on the "Overlap in .cseg".

cont. below ...

David Kuehling writes:

> Hi,
>
> I've been trying to get AmForth onto this Atmega 8 based platform:
>
>   https://www.elektronik-labor.de/Lernpakete/Pingong.html
>   https://www.elektronik-labor.de/Elo/ELO.html
>
> Which is sold cheaply as a toy:
>
>   
> https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843
>
> Already soldered the ISP connector and a serial TTL cable.  However,
> AmForth (v6.9) does not seem to compile for Atmega8 in its current
> version.  Copying the template directory and editing makefile to say
> "MCU=atmega8", I'm getting a lot of compiler errors that indicate an
> overflow of the RWW dictionary space:
>
> ../../avr8\amforth-interpreter.asm(4): error: Overlap in .cseg: addr=0xc00 
> conflicts with 0x7a:0xc58
> ../../avr8\amforth-interpreter.asm(5): error: Overlap in .cseg: addr=0xc01 
> conflicts with 0x7a:0xc58
> [..]
>
> If I randomly comment out words in avr/appl_2k.inc, I get a little
> further.  However, then compilation errs out in the UART driver code and
> complains about stuff in macros.asm:
>
> ../../avr8\drivers/usart_0.asm(1): error: Undefined symbol: UBRR0L
> ../../avr8\drivers/usart_0.asm(2): error: Undefined symbol: UBRR0H
> ../../avr8\drivers/usart_0.asm(3): error: Undefined symbol: UCSR0C
> ../../avr8\drivers/usart_0.asm(4): error: Undefined symbol: UCSR0B
> ../../avr8\drivers/usart_0.asm(5): error: Undefined symbol: UCSR0A
> ../../avr8\drivers/usart_0.asm(12): error: Undefined symbol: RXC0
> ../../avr8\drivers/usart_0.asm(13): error: Undefined symbol: UDRE0
> ../../avr8\drivers/usart_0.asm(14): error: Undefined symbol: TXEN0
> ../../avr8\drivers/usart_0.asm(15): error: Undefined symbol: RXEN0
> ../../avr8\drivers/usart_0.asm(16): error: Undefined symbol: RXCIE0
> ../../avr8\drivers/usart_0.asm(17): error: Undefined symbol: UDRIE0
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
>
> And this is even before I try to resolve all the problems arising from
> the words that I commented out.
>
> Maybe the Atmega8-specific code has been bit-rotting without being used
> for too long already?  What do you think are my chances to make this
> work again?  Any ideas what's wrong about the Uart drivers and how to
> strip down AmForth to fit into 8 kB of flash?  Or has AmForth just
> gotten too old and fat over the years to render this undertaking
> unachievable?

Bitrot is maybe the wrong word for this. AmForth has grown in
features and thus in size. 8 kiB flash is imho too small. It was
too small for a long time already, because you really need a few
kB free space for your own programm, right?

Maybe starting with AmForth-4.x is more successful?

You may be able to just get it to work, but then what?

I would like to see, what needs to be stripped out until it
fits. But I guess it is really not worth the effort.


Just for the sake of the argument I tried AmForth-4.0 (release
2010-07-01). It does not assemble, even though there is only 1
overlap conflict. Sigh.

The atmega8 has worked, but I have no idea which release made it
fail the size constraints.


Maybe I should place a more prominent warning on the webpage.
Currently we have this:

webpage> AmForth for the AVR8 needs 8 to 12 KB Flash memory, 80
webpage> bytes EEPROM, and 200 bytes RAM for the core system.



> (I did some experiments with an Arduino Uno clone first, and had no
> problem compiling and setting up AmForth on it.)
>
> Maybe the Arduboy [1] would be better suited to AmForth, but it's also
> more costly and complex to program.  I'm also eyeing the uzebox [2], but
> getting its video driver into AmForth would be a daunting
> endevour.

Arduboy features a atmega32u4. AmForth does not have support for
the USB interface, should that be important.

uzebox features an atmega644 controller. Now that I use
routinely and it has plenty of space.


Dear David,
you picked a new time sink, it seems. :-)

Cheers,
Erich

>
> cheers,
>
> David
>
> [1] 
> https://www.reichelt.de/arduboy-arduino-kompatibles-miniaturspielsystem-ard-arduboy-p254388.html?&trstct=pos_0&nbc=1
> [2] http://belogic.com/uzebox/index.asp


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Contemplating automatic tests

[Erich Wälde]

Dear AmForthers,

Monday evening doing a little AmForth related stuff, how is that?
Full disclosure: I am using emacs/org-mode. So I created a habit
for Monday. And boy those red colored bars saying "not done"
become annoying quickly. So better do something :)


Contemplating the Test Cases Thing

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

Turns out that the set of scripts isn't all that great. So:
What would I like to achieve?

There will be a ./test/ directory, which holds the test cases and
the files to programm my available target hw for the tests.

: cd test
: make targets  # shall produce firmware for target boards
: make install $target  # flash the particular target board
: make test $target # calls the runner on a given list of test cases

The result should be something like this:
: make test $target
: . loading tester on $target, ok.
: . 0/12  test/common/test-A.frt, ok
: . 1/19  test/common/test-B.frt, 1 error
: 1 error in 21 tests

The verbatim output goes to runner.log or something such.


*configuration*

- which target board do I want to use?
- which programmer and its paramters do I have?
- which details for the serial (or other?) connection?


*terminology*

- unit-under-test :: this is the function (asm of forth word) to
  be tested.
  : : unit-under-test ( stack -- effect )
  :   definition
  : ;

  These live in the directories arm, avr8, common, msp430,
  risc-v, shared ... these trees should remain unchanged imho.

- test case :: this is a statement to load unit-under-test and
  its possible dependencies, plus a collection of "t{ ... }t"
  statements to exercise unit-under-test:
  : #include unit-under-test.fs
  : t{ stack  function  changed stack }t

  Other forms of test procedures should be possible as long as
  they produce output, which can be understood by the runner.

  There are dragons lurking here when it comes to #include or
  #require.

- runner :: this is a script which can talk to a target board
  (via serial), feed a testcase file, collect the resulting
  output and extract the results

- tester :: this is an implementation of the Hayes tester. It
  defines 't{' '}t' and a few more words.

- firmware :: for every target board to be used, we require
  a well equipped AmForth firmware. I expect this firmware to be
  somewhat special and separate from the examples in the ./appl/
  subdirectory.

There are possible complications known as setup/teardown. Markers
could possibly help. On the other hand, I have not yet exhausted
the flash or RAM of a atmega-644a.


*possible tree layout*

: amforth/trunk
: ...
: +-- test/
: +-- Makefile \ top of magic
: +-- M.programmer.mk  \ make vars to specify my programmer
: +-- M.connection.mk  \ make vars to specify serial connection
: +-- bin/ \ any tools
: |   +-- runner.pl
: |
: +-- tester/  \ place for tester words? optional?
: |
: +-- firmware/
: |   +-- avr8-at644p/
: |   |   +-- Makefile
: |   |   +-- dict_appl_core.inc
: |   |   +-- dict_appl.inc\ includes dict_local.inc
: |   |   +-- dict_local.inc   \ all additional words to load in this 
context
: |   |   +-- testfirmware.asm \ top level definition for target 
firmware
: |   |   +-- words/
: |   |   +-- applturnkey.asm  \ project specific
: |   |
: |   +-- $target-$controller/
: |   |   +-- Makefile
: |   |   +-- ...
: |   ...
: |
: +-- cases/
: |   +-- common/  \ testcases for all target boards
: |   |   +-- stack-test.frt
: |   |   ...
: |   |
: |   +-- avr8/\ testcases for specific target boards
: |   |   +-- ...
: |   ...
: |
: +-- logs/\ place for logfiles?


Assuming that Mr.Someone has installed the relevant tools,
editing the M.*.mk files should be enough to
- produce firmware for at least one target
- install the firmware on said target
- load and evaluate the available tests

All of this in a few lines of shell commands.

Does that sound like a plausible plan?

Next step: create this structure for one target and a few test
cases and see, how we fare.

Cheers,
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] some patches to the ARM section of the webpage

[Erich Wälde]

Hello Carsten,

Carsten Strotmann writes:

> please find attached two patches for the amForth website
> source, ARM pages.

thank you for the patches. I have committed them and updated the
web site --- not without deleting it first, sigh.

> My editor (Emacs) cleans the whitespace, if that is an issue,
> I'll remove that and resend.

Not a problem.

Cheers,
Erich

>
> Greetings
>
> Carsten
> -- next part --
> An embedded and charset-unspecified text was scrubbed...
> Name: 0001-Adding-information-that-amForth-targets-32bit-ARM.patch
> -- next part --
> An embedded and charset-unspecified text was scrubbed...
> Name: 0002-Fixed-a-typo.patch
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] draft: roadmap for AmForth

[Erich Wälde]

Dear AmForthers,

some time ago (2020-08-02), Mark Roth suggested to come up with a
"road map". Now while mapping unknown territory is a challenge of
sorts, it might be not that difficult in this case.

This my personal point of view, it might change anytime without prior
notice.

1. Accumulate all commits since Jan 2019 and call it *release 6.9*
   That I have done. :)

2. Document the exact steps that were needed to create "a release".
   Well yes, I have these lines, but not in shape and maybe not
   complete. It should be added to the repository nonetheless.

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.

4. Call this *release 7.0*

5. Convert and Move Repository

   Currently it looks like I would have to convert the svn repository
   to a git repository with a tool like svn2git. This is a process I
   would like to avoid, so if someone knows how to convert the
   repository "server side", or even how to export the complete svn
   repository on sourceforge into a big file ... all hints are kindly
   appreciated.

   I would then move to sourcehut.org. Why?

   - I do have an account there already
   - sourcehut offers accounts for a very reasonable amount of money.
   - sourchut works without javascript! Can you believe this? No? Try it.
 For me this is a major step in the correct direction. [1]
   - I would order and pay for a new project account
   - I would like to add at least two collaborators with full access
 from day one. Volunteers?

   This is going to include more things than just converting the
   repository:

   - possibly convert the releases/N.M directories into branches
   - create a new space for the webpage
   - automate generation of the webpage, serverside if possible
   - document how to locally generate the documentation --- well, the
 stuff you have to install before "cd doc; make all".
   - look into the use of javascript and possible ways to reduce that,
 should it be desirable
   - create an archive for (some of) the old tarballs
   - archive and transfer the mailing list content
   - create a new mailing list
   - automate the generation of a release
   - document the release process
   - start using the bugtracker (preferably with connection to the
 mailing list)
   - test the branch-edit-pull.request-merge workflow
   - possibly convert "Opinion" into a prober blog?
   - setup a redirection notice on sourceforge, close everything else
 down.
   - possibly dissolve amforth/community into a ./contrib/
 subdirectory, test the stuff again and document it better
 https://sourceforge.net/p/amforth/community/HEAD/tree/

   And this list is not complete.

6. Call this *release 8.0*

7. Remove arm msp430 riscv for the sake of simplicity -- unless
   someone speaks up to offer help.

   Carsten has offered support for arm and riscv --- Thank you!

   msp430 anyone?

8. Fix and automate the creation of the reference cards

   - include ALL available WORDs (not only the ones in a particular
 build)
   - include the exact file path(s), where WORD is defined
   - possibly add a Forth equivalent (.asm WORDS)
   - possibly a pointer to a worked example

   In order to achieve that I would rework the existing perl script
   AND add any missing file headers, possibly in a new/enhanced
   format.


If we get this far, then imho we have /advanced considerably/.




Does this sound like a worthwile plan?

I'm sure there are other ideas and suggestions.

Point 5 is huge and needs to be broken into smaller steps.


I would appreciate any response, and if you could
include, which target you are using, all the better.


Still reading?
Thank you for your precious time.

Happy forthing,
Erich



[1] I'm using torbrowser most of the time. I'm using firefox to
work at amforth.sourceforge.net. However, NoScript or uMatrix do
an excellent job, but break the sf.net webpage routinely. I do
not see all the buttons and what not unless I really switch off
NoScript. This is not, what I prefer.

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] List of Supported Device Features in Amforth Documentation?

[Erich Wälde]

Hello Frank,

and welcome to the list.

fra...@fraber.de writes:

> Hi!
>
>
> Summary: I believe you could greatly increase the
> number of Amforth users with little effort providing
> one Wiki page per hardware device. There you would
> provide fuse settings, name of a suitable binary,
> parameters for the flasher etc. in order to reduce the
> frustration of a rookie to see the first Forth prompt.
> It's only 20-50 devices, that's not much compared to
> the list of devices in Arch Linux for example (I found
> my specific laptop model there...).
> SourceForge offers a Wiki very suitable for that!

* wiki pages:

Well, maybe. However man- or woman-power is the key resource to
this. I will certainly not start such a thing on my own.

Moreover, I'm convinced that reading a datasheet and having
"control" over your board is worth more than writing more
documentation --- which will be outdated sooner than you wish.


> In Detail:
>
> I'm a fellow open source guy, running a project
> here on SourceForge for a living:
> https://sourceforge.net/projects/project-open/
> Also, 30 years ago I wrote a Forth for Inmos
> Transputers...

Cool! I have not written my own Forth, and I have resisted the
urge for over 10 years. I just try to keep this project alive
after the original author had to abandon it.

> So: Congratulations to your work on Amforth!
> I managed to get it running on a barebone AtMega
> 328 for a hobby project (a tracked robot with my
> son...).
>
> I implemented drivers for both stepper motors
> and DC motors with angle coders without too much
> trouble and to send Forth commands over SPI.
>
> However, I got some trouble trying to connect
> multiple 328s to a single RasPi and finally serious
> trouble with spikes from the DC motors affecting
> the SPI bus :-(

You absolutely must provide separate power supplies for the
controller and for the DC motors. I would not even share the
same ground. Use opto couplers and appropriate diodes and
capacitors to filter the effects of the motors. Other projects
have solved this sort of thing, just hunt for them.
https://roboternetz.de/ is one.

> For the next iteration I'd like to decouple the
> various I/O subsystems electrically and use UART
> over USB for communication in order to address the
> issues both with multiple devices (USB hub as PI
> HAT) and noise (USB has differential signaling...)
>
> So, I'd like to use a 32U4 or Mega 2560 or similar
> for each subsystem and a RasPi Zero W as a base,
> but I haven't yet purchased anything.
> Here some information on the supported features
> would come in handy. I've spent several hours
> trying to understand if/how Amforth supports
> USB/UART in these model. 6.9 doesn't seem to
> support it at all, correct?
>
>
> There isn't much space in a robot, and USB cables
> are surprisingly bulky. And now imagine that I'd
> somehow need to have 2x USB for each Atmega...

* USB is,

well, not cool. I would never even try to build something on
USB, should my life depend on it. I have seen way too many
difficulties with industrial anything on USB. Keep it simple!

If you come up with patches to make usb on the 32u4 work, I
shall look into integrating them. And I'm sure there are more
readers on the list, who would try them.


> I wonder if I'm the only one trying to build a more
> complex system using Amforth or if others had
> similar problems...
>
> I have also found very few postings in the Internet
> from people connecting multiple Arduinos to
> a RasPI or to build bigger projects in general.
> That's precisely where I see the value of Amforth,
> because it introduces a protocol layer that is
> easy to debug and decouples the subsystems.

* robot or other complex system:

If you play with software (no matter which one exactly), you are
not dealing with software alone. Never. You are dealing with
hardware (printed circuit board, components, chips, cables! and
connectors!), power (there is much to be learned about power
supplies), signals and impedance (like it or not), a programmer,
an assembler, and finally the software system itself. You cannot
run this software in empty space.


I myself have a modestly complex setup with atmega32 controllers
on a RS485 bus. The software I wrote using AmForth 4.6 is
running since maybe 10 years with very few hiccups. However: I
have failed miserably to recreate this system with AmForth 6.8+
on nice and shiny boards with atmega644pa controllers. And I
have no idea, why. It works for some time and then all of a
sudden the controller stops dead in it's tracks and blocks any
access. Very interestingly: a reset or power cycle does *NOT*
help. So I'm currently completely out of ideas.


The essence of this is: start very simple. Try to make your
project run for extented periods of time. And see where it gets
you. If you tend to use an ARM controller, do not hesitate to
try Mecrisp (Author Matthias Koch). Mecrisp is a native Forth
and not an indirect threaded one. I have no experience with arm
con

Re: [Amforth] [ANN] release 6.9 is available

[Erich Wälde]

Hello Jim,

Jim Tittsler writes:

> On Mon, Oct 19, 2020 at 2:46 AM Erich Wälde  wrote:
>> One thing remains: the "download the latest release" Button still
>> points to 6.8 --- I have no idea, where to look. Oh well.
>
> As project administrator, visit
> https://sourceforge.net/projects/amforth/files/amforth/6.9/ then click
> the 'i' (information) button for the desired file.  In addition to the
> normal file details, an administrator can specify a "default download"
> (by platform).

With sufficient thrust, äh javascript and 3rd party connections
and reloading ... yes there are (i) buttons showing up. :)

Thank you very much for pointing me to the correct place!

Cheers,
Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] [ANN] release 6.9 is available

[Erich Wälde]

Dear AmForthers,

today I called it "release 6.9".

The "commits" part is quite simple.

- r2452 -- only doc/source/index.rst
- r2453 -- copy of trunk as release/6.9
- r2454 -- in trunk increment version strings (3 files)

There is some more work in creating the tar balls.

I have decided to remove the doc/Projects folder from the release
tarballs, because it increases their size from <10 MB to >100 MB.
This is probably the reason why Matthias had the Projects not included
in the archives either.

One thing remains: the "download the latest release" Button still
points to 6.8 --- I have no idea, where to look. Oh well.

This release rolls up everything that had been committed since
2019-01-07.

The website is updated, too.

Happy Forthing!

Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Ref Card Generation quo vadis?

[Erich Wälde]

Dear AmForthers,

I tend to disagree on some of this ...

What you argue for is a "architecture and project-specific"
"reduced" refcard. At least this is, what I understand.


I have used the refcard extensively in the beginnings of my
AmForth journey. And I would argue any time, that the refcard
should please include /all/ /available/ things --- whether or
not they are in my build. This is akin to the "Complete
Instruction Set Summary" found in the document describing the
AVR assembly instructions.

Whether or not a given word is /in my build/ ... " words " to
rescue. Or just trying this /interactively/ on the serial
prompt. Or reading the .lst file from the build (for .asm
definitions).


The examples by Tristan
>> https://tjnw.co.uk//amforth-6.92/appl/arduino/uno.html
>> https://tjnw.co.uk//amforth-6.92/appl/arduino/custom.html
look nice and clean.

However, /I/ did not notice, the words are actually links ---
only after Marks comment. For me attributes like this are pretty
much /invisible/, although they are quite common (They can be
topped by buttons that appear only /after/ I have selected
something -- sigh).


IMHO a worthwhile extension of the refcard would include a
pointer to the source (in readable form), something like

> WORD  ( stack -- effect )
> - one-line-description
> - colon definition equivalent, if the word is in .asm
> - .../path/to/file.frt -- one entry if this is a /common/ .frt file
> - .../path/to/arch/file.asm -- several entries (one per line) if
>   this is a target-specific .asm file

This way it is clear, where to look, if the word is missing in
my build. It even indirectly tells you, on what targets this
WORD is available. And all this information should be visible on
a printed version of the refcard, too.


The pre-made .hex files for the arduino targets are a double
edged sword imho: On one hand they considerably lower the bar to
get to your first AmForth-prompt. On the other hand, they do not
teach users about fuses, about .lst and .map and include files,
etc. This is where the "can we please include words X and Y"-
wishlist comes from. But with pre-made files, users give up
control over their project --- to some extent. I would encourage
everyone get on top of the complete tool chain immediately after
the first pre-made file runs successfully.


But lets assume for this paragraph we want these "target and
build specific" refcards (which formats is another question
imho). How are we going about them? Is their production included
in the project Makefile? Are they produced by /every/ build? How
long does that take and what would be an acceptable time? And
how much tools do we add as a dependency?

The minimal toolchain is already substantial (from my Linux
centric point of view):

- the sources (via tarball, subversion/git, ...)
- the assembler (AvrAsm2 plus wine, unfortunately)
- an editor (/any!/)
- make to help with the build (could be done with shell commands
  in principle)
- a programmer (hardware)
- a program to talk to the programmer (avrdude or similar)
- a serial cable of some sort (hardware)
- a program to talk to the serial interface (minicom et al.,
  amforth-upload.py, amforth-shell.py)
- possibly some programm (evince, xpdf, ...) to read the
  documentation offline.

Even if we produce the refcard using an upgraded perl script,
imho this is going the wrong way.



One other thing I find interesting to note in this lengthy
thread: So far we have only looked at

"How to generate the documentation from the sources?"

But there is another option:

"How to generate the source from a (large) description of the
whole system?"

This is called "literate programming", as everyone and their dog
knows, of course :-)

I envision something like "every word has a description,
including any reasoning why it is implemented in such a way,
plus a description of the source code in some form. From this
description a .frt and/or .asm (variable asm formats)" is
generated, along with the Technical Handbook, the RefCard and
what not.

HOWEVER! I have tried to produce code like this. This is a not
so modest pain up the backside for a project, which is on the
move, which is not fully implemented. Literate Programming alone
is unable to track the evolution of the code, unless you rewrite
the description every time. I still think there is value to this
idea, but it is not the one answer to rule all questions.

I will not even try to convert AmForth to such a structure,
because it requires a lot of work PLUS an even larger tool
chain. :-)


Too Long; Didn't Read:

- I argue for a full refcard, not a reduced one
- I argue for a bit more information on the refcard
- I argue against pre-made .hex files
- I argue for less dependencies
- I do not argue for "produce the code from documentation" :-)

- my current priority is "how to make a release". And I'm not
  there yet.

- I'm willing to accept patches fixing the headers of .asm
  files.

- I'm willing to rewrite the refcard scripts, since I

[Amforth] [Solved] @ vs c@ (was: rshift not zero padded)

[Erich Wälde]

Hello Mark,

so you found the subtle difference between @ and c@, congrats! :-)

Mark Roth writes:

> So because of grabbing a word it seems that I was bringing in the PINB
> register as well that had a value in it. So that is where the extra bits
> came from.
>
> : cylon
>> $ff ddra c! 1 porta c!
>> begin 40 ms
>> 7 0 do porta c@ 2* porta c! 40 ms loop
>> 7 0 do porta c@ 2/ porta c! 40 ms loop
>> key? until ;
>
>
> So this works exactly as I wanted it to. I am really starting to understand
> the value of interactive debugging by just running each line to see what is
> going on. Once I looked at the stack while stepping it made
> perfect sense.


Numbers: Over time I have adopted the style to prefix each and
every number except for 0 and 1. I have been in the situation
too often, that base was not 10 like expected but rather 16.

>: cylon
> $ff ddra c! 1 porta c!
> begin #40 ms
> #7 0 do porta c@ 2* porta c! #40 ms loop
> #7 0 do porta c@ 2/ porta c! #40 ms loop
> key? until ;


Number output

>> It's a common display situation in Forth. Leading zeros aren't display,
>> even when they exist.

/Very often/ I use " u0.r " for exactly this reason.


Cheers,
Erich



-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AmForth Weekend 3 + Leonardo

[Erich Wälde]

resend to list.

Hello Tristan,

thank you indeed for pointing this out!


> Erich Wälde writes:
>> Tristan Williams writes:
>>> Erich Wälde writes:
>>> After that all the remaining hex files could be built.
>>> ONLY arduino/leonardo.hex is missing.
>>
>> I am not sure if the Leonardo was excluded because AmForth cannot make
>> use the of the Leonardo's USB connection, but it builds without error
>> on r2450.
> Aha, good to know. I admit that I did not read all error
> messages. Something in my environment could /easily/ be ...
> well, /customized/ :-)
>
> I'll have another look.

This is funny, but highly unobvious:

Turns out that my collection of Atmel/AvrAssembler2/Appnotes/*
files was so stone-age outdated, that the file for atmega32u4
was there but not good enough!

I replaced them with the content of the Archive found at
https://sourceforge.net/projects/amforth/files/Atmel-AVR8-Assembler/Atmel-Assembler.tgz/download
and hey presto! leonardo builds now without a hitch!


So, I have to inspect the box with the arduino boards ... no,
unfortunately no leonardo in the box. But I did find the
butterfly.

Off to new time sinking adventures!

Cheers,
Erich

PS: so yes, I'm able to build the hexfiles found in the release
archives. One off the list.


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Gory Details: How to properly create a release?

[Erich Wälde]

Hello Brian,

after the stunt getting leonardo to build a similar stunt makes
the butterfly building again :-)

> Erich Wälde writes:
>> Brian writes:
>> I am running the latest version of amforth on an avrbutterfly.
>
> Oh, cool! You made me curious. This is a atmega169 controller
> featuring 16k flash, so it is possible. I still have such a
> thing in a box, so I should be able to recreate it.

In my /outdated/ version of the Atmel files, there is
the file "m169def.inc".

In the /new/ version of the Atmel files from the archive found
here
https://sourceforge.net/projects/amforth/files/Atmel-AVR8-Assembler/Atmel-Assembler.tgz/download
this file is unfortunately missing! So I just copied

m169def.inc (note there is no A P PA in this game!)

over to the new tree and the file for the butterfly can be
built! Yay! I have not yet tried to run it on the board.

If it works, I'm going to
- add "m169def.inc" to Atmel-Assembler.tgz (provided I can
  figure out how to place this file in the correct location)
- add avr-butterfly back to appl/
- fix the Makefile in there


This still applies:
>
> Would you care to share your application? Something like a
> nametag maybe???

I'm aware that there is a description, how to use the LCDisplay
in Vierte Dimension 2007/1 (german text)
https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2007-01.pdf


Thank you very much for pointing this out!

Cheers,
Erich

>snip<


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AmForth Weekend 3 + Leonardo

[Erich Wälde]

Hello Tristan,

thanks for your message.

Tristan Williams writes:

> Hello Erich, AmForthers,
>
>> After that all the remaining hex files could be built.
>> ONLY arduino/leonardo.hex is missing.
>
> I am not sure if the Leonardo was excluded because AmForth cannot make
> use the of the Leonardo's USB connection, but it builds without error
> on r2450.
Aha, good to know. I admit that I did not read all error
messages. Something in my environment could /easily/ be ...
well, /customized/ :-)

I'll have another look.

Cheers,
Erich

> I have not tested r2450 on a device as I don't have my Leonardo
> to hand, but for reference, it ran on a Leonardo with AmForth 6.8
>
> https://sourceforge.net/p/amforth/mailman/message/36608525/
>
> Best wishes,
> Tristan
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Gory Details: How to properly create a release?

[Erich Wälde]

Hello Brian,

thanks for your message!

Brian writes:

> I am running the latest version of amforth on an avrbutterfly.

Oh, cool! You made me curious. This is a atmega169 controller
featuring 16k flash, so it is possible. I still have such a
thing in a box, so I should be able to recreate it.

Would you care to share your application? Something like a
nametag maybe???

Cheers,
Erich


>
> Brian
>
> On 8/30/20 1:09 PM, Erich =?utf-8?Q?W=C3=A4lde?= wrote:
>> More details on Point 4 (see below).
>> Cheers,
>> Erich
>>
>> Erich Wälde writes:
>>
>>> Dear AmForthers,
>>>
>>> I asked:
>>>>   - How do I actually create a new release? Copying the files is
>>>> one thing, but where do I need to change the version? There
>>>> is more than one place, I'm afraid. I also happen to know
>>>> that after 6.9 there cannot be 6.10 due to a limitation
>>>> created very early. Matthias told me that, otherwise I would
>>>> be clueless.
>>> see https://sourceforge.net/p/amforth/mailman/message/37048278/
>>>
>>>
>>>
>>> How to create an official release?
>>>
>snip<

>>>
>>> 4. create all .hex files for target boards in appl/
>>> arduino,atmega2561,eval-pollin,hifive1,launchpad-arm,launchpad430,
>>> template
>>>
>>> I had forgotten that these exsisted. They are in the release archive
>>> only, not in the source tree. Now I understand, why people
>>> sometimes ask about them.
>>>
>>> This step is detailed in a few .xml files. Matthias used ant to
>>> build them. I have not built these before, but this looks doable,
>>> provided I get all relevant toolchains up and running.
>> Digging through the ./appl/ subdirectory I think I understand the
>> following:
>>
>> - There are currently 8 target directories.
>>
>> - all of them have either build.xml or Makefile files
>>
>> - of the AVR8 targets all can be build with the exception of
>>"arduino/leonardo" --- this runs into the "8k is too small"
>>limitation. There used to be an avr-butterfly target (up to
>>6.4), which suffers from the same limitation, iirc.
wrong. see above.

>snip<

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] AmForth Weekend 3 (2020-08-29/30)

[Erich Wälde]

Dear AmForthers,

as previously announced I made this weekend the official

AmForth Weekend 3 / 2020-08-29,30

So what happened?

- Commits

  r2450: one line whitespace fix in amforth-shell.py (2020-08-04)
 https://sourceforge.net/p/amforth/code/2450/

  r2451: one line python2->3 fix provided by Tristan Williams. Thanks!
 https://sourceforge.net/p/amforth/code/2451/


- Progress

  - I did some code archeology about how to create an official
release. see separate email
https://sourceforge.net/p/amforth/mailman/message/37096517/

  - some more digging on how to create all the .hex files (point 4)
https://sourceforge.net/p/amforth/mailman/message/37097180/

  - turns out that installing the toolchains is not difficult (on Debian)
: apt install binutils-riscv64-linux-gnu binutils-arm-linux-gnueabi 
binutils-arm-none-eabi
and naken_asm I still had around in some obscure directory.

After that all the remaining hex files could be built.
ONLY arduino/leonardo.hex is missing.
Not bad for a rainy afternoon :-)

  While working on this, sourceforge went into "disaster recovery
  mode" --- not for the first time. :/

  So, this weekend was not as busy from the point of this project, I
  think. However, I spent countless hours in the past weeks to find a
  bug in my data collection system. It makes the communication die for
  no apparent reason, but it still has evaded my attempts to uncover
  it. Such is life.


- Open Issues

  as far as I'm aware:

  - WDT (Martin Nicholas) patch

Martin has provided a small patch (.asm) regarding the
startup of the WDT (watch dog timer) on atmega2560
controllers. I have honestly no idea, whether or not this
will break something else, and under which conditions exactly
this is needed.
link to email archive (Martin Nicholas, June 2019)
https://sourceforge.net/p/amforth/mailman/message/36682958/

  - Multitasker documentation

This needs to be tested and enhanced in a few ways. It might
be that the current example in the Cookbook section is simply
broken. There have been questions about how to better
populate the task local user area. Maybe this could be
answered by a more complex example. There has been the
question about producing output from a task (not the cmd
loop), its collision with the shared HLD/TAB area, and
possible ways to solve this (semaphores, task local HLD/TAB).
link to email archive (Jan Kromhout Feb 2019)
https://sourceforge.net/p/amforth/mailman/message/36596842/

  - " du< " is missing
link to email archive (Martin Nicholas August 2019)
https://sourceforge.net/p/amforth/mailman/message/36748496/



- AmForth Weekend 4

  Shall take place in October, I think, but I hesitate to fix a date.


Thank you very much for your precious time!

Take care and happy hacking,

Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Gory Details: How to properly create a release?

[Erich Wälde]

Dear AmForthers,

I asked:
>  - How do I actually create a new release? Copying the files is
>one thing, but where do I need to change the version? There
>is more than one place, I'm afraid. I also happen to know
>that after 6.9 there cannot be 6.10 due to a limitation
>created very early. Matthias told me that, otherwise I would
>be clueless.
see https://sourceforge.net/p/amforth/mailman/message/37048278/



How to create an official release?

I spent some time to do some code archeology. I still do not know,
how to properly make a release. This is, what I currently
see/expect:

1. check all version numbers in trunk

   - doc/Makefile being one place. This seems to be used in all
 generated documentation, which is nice.
   - common/words/env-forthversion.asm is another place with different
 syntax!
   Judging by commit r2271, these are all places indeed. Yay!

2. update doc/source/index.rst and optionally history.rst in
   trunk and commit

3. "svn copy" trunk to releases/$VERSION; commit message collects
   the accumulated one line change descriptions
   This is the most visible change in the source tree
   e.g. see commit r2244 (rel 6.5)

4. create all .hex files for target boards in appl/
   arduino,atmega2561,eval-pollin,hifive1,launchpad-arm,launchpad430,
   template

   I had forgotten that these exsisted. They are in the release archive
   only, not in the source tree. Now I understand, why people
   sometimes ask about them.

   This step is detailed in a few .xml files. Matthias used ant to
   build them. I have not built these before, but this looks doable,
   provided I get all relevant toolchains up and running.

5. create the documentation
   - htdocs, the web page
   - books, did you know that all the content of the webpage shows up
 in amforth.pdf (made with pdflatex) and AmForth.epub (made with
 sphinx-build)? Amazing! These books are part of the download .zip
 archive.

 This step is a "cd doc; make all" --- provided sphinx pdflatex
 and all the good stuff is installed.

6. create a new temporary tree to collect everything, that goes into
   the release archive:
   - sources
   - some of the scripts, tools, meta-files
   - the generated documentation from releases/$VERSION, without the
 document sources, but including the "books"

   I have not found anything that looks like doing this.

7. create the .zip and .tar.gz archives (the easy part), and upload
   them to their correct location in the sourceforge.net file tree
   (the not so obvious part).

   I found out that these release archives were built by Matthias.
   The files for 6.8 are about 7 MB in size.

   Whereas if you download "the latest sources", sourceforge will
   generate a snapshot of "trunk". This is a plain copy, without all
   the niceties included in the archives mentioned here. This archive
   is currently 35 MB in size.

8. sync the generated documentation with the online website

   I have done this a few times now, but I'm still asking myself, if I
   see all relevant pieces or not.

9. Increment the version numbers in trunk and commit


So nine easy steps to code nirvana? Hmmm.

If anyone has some insight or detail I'm missing, I would be
happy to hear about it. I propose to rework this into a .rst
document and add it to the source tree, once missing bits have
emerged (points 4, 6, 7).

Cheers,
Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] amforth-shell.py

[Erich Wälde]

Hello Tristan,

Tristan Williams writes:

> A one line patch for amforth-shell.py to correct a python2/python3
> syntax error. It occurs when using the --no-error-on-output
> option. Below is a unified diff against r2450/trunk/tools/amforth-shell.py
>
> --- amforth-shell.py
> +++ new-shell.py
> @@ -857,7 +857,7 @@
>  self.progress_callback("Sent", lineno, full_line)
>  if response[-3:] == " ok":
>  if len(response) > 3:
> -for l in StringIO.StringIO(response[:-3]):
> +for l in StringIO(response[:-3]):
>  self.progress_callback("Output", lineno, l.rstrip())
>  r = self._config.current_behavior.expected_output_regexp
>  if r:
>
>
I committed your patch as revision r2451 (without further
testing). Thank you for the patch!


Cheers,
Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] download.zip strangeness

[Erich Wälde]

Hello Mark,

Mark Roth writes:

> Because the zip is the Release package and the SVN is the Dev package I
> would guess. The end user that isn't going to do anything more than grab
> the zip, add the AVR stuff, quick scan the readme, go to the
> APPL directory, make a copy of the template, hit make install (hopefully
> after reading what needs to be changed to get the correct hex files) and
> never do anything else but upload extra FRTs as needed.
That may well be. I said to Martin: look in doc/Makefile.
Answer: there is no doc/Makefile :-(

> To build the docs you need a lot (a real lot) of extra packages. The real
> question is, "How are the zips created?"
Yes, agreed, and probably part of the bigger question:
How (in detail) did Matthias roll up an official release?
Well, I'll find out.

Cheers,
Erich

> All the best,
> Mark
>
> On Thu, Aug 27, 2020 at 10:50 PM Erich Wälde  wrote:
>
>>
>> Hello all,
>>
>> Martin B. found out that the content of the download.zip files
>> is  different from the content of the svn checkout. For example
>> ./doc/Makefile is not present. However, the zip file has more
>> files alltogether:
>>
>>
>> $ find releases/6.8 -type f | wc -l
>> 2389
>>
>> $ find ./amforth-6.8 -type f | wc -l # from download-6.8.zip
>> 2537
>>
>> So the content is different somehow.
>>
>> Anyone have any insight/ideas?
>>
>> This seems to be an item for the upcoming AmForth weekend,
>> /me thinks ...
>>
>>
>> Cheers,
>> Erich
>>
>> --
>> May the Forth be with you ...
>>
>>
>> ___
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amforth-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] download.zip strangeness

[Erich Wälde]

Hello all,

Martin B. found out that the content of the download.zip files
is  different from the content of the svn checkout. For example
./doc/Makefile is not present. However, the zip file has more
files alltogether:


$ find releases/6.8 -type f | wc -l
2389

$ find ./amforth-6.8 -type f | wc -l # from download-6.8.zip
2537

So the content is different somehow.

Anyone have any insight/ideas?

This seems to be an item for the upcoming AmForth weekend,
/me thinks ...


Cheers,
Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] AmForth Weekend 2 (2020-08-01/02)

[Erich Wälde]

Dear AmForthers,

as previously announced I made this weekend the official

AmForth Weekend 2 / 2020-08-01,02

So what happened?


- Commits

  r2447: tools/amforth-shell.py ported to python3
 the corresponding patch was kindly contributed by Tristan
 Williams, thank you!

  r2448: added Tristan to contributors list

  r2449: tools/amforth-upload.py fixed logic error in
 search_and_open_file

  Synced website.

- Progress

  - both amforth-upload.py and amforth-shell.py are using
"python", which means python2. Since python2 is being
discontinued, these should be ported to python3. Anyone
interested?

[2020-08-01 Sat]
Tristan Williams send a patch to port amforth-shell.py to python3.
This work is committed.
amforth-upload.py remaining ... but see next point.
https://sourceforge.net/p/amforth/mailman/message/37075138/

  - amforth-upload.py is broken for me, I use the file from 4.0.
But I have not bothered to find out exactly what breaks on
me/my code.

[2020-08-01 Sat]
Fix attempted, needs someone elso to confirm that it works.
I also attempted to port this script to python3 but failed
miserably :-)
https://sourceforge.net/p/amforth/mailman/message/37075266/

  - The refcard generator is broken probably since release 5.6
link to email archive (Martin Nicholas June 2020)
https://sourceforge.net/p/amforth/mailman/message/37047630/

[2020-08-01 Sat]
Mark Roth has contributed a few things to make this work again.
See thread starting here:
https://sourceforge.net/p/amforth/mailman/message/37060533/
and especially here:
https://sourceforge.net/p/amforth/mailman/message/37063662/
Things are more involved, however, see this thread:
https://sourceforge.net/p/amforth/mailman/message/37075410/


- Open Issues

  as far as I'm aware:

  - WDT (Martin Nicholas) patch

Martin has provided a small patch (.asm) regarding the
startup of the WDT (watch dog timer) on atmega2560
controllers. I have honestly no idea, whether or not this
will break something else, and under which conditions exactly
this is needed.
link to email archive (Martin Nicholas, June 2019)
https://sourceforge.net/p/amforth/mailman/message/36682958/

  - Multitasker documentation

This needs to be tested and enhanced in a few ways. It might
be that the current example in the Cookbook section is simply
broken. There have been questions about how to better
populate the task local user area. Maybe this could be
answered by a more complex example. There has been the
question about producing output from a task (not the cmd
loop), its collision with the shared HLD/TAB area, and
possible ways to solve this (semaphores, task local HLD/TAB).
link to email archive (Jan Kromhout Feb 2019)
https://sourceforge.net/p/amforth/mailman/message/36596842/

  - " du< " is missing
link to email archive (Martin Nicholas August 2019)
https://sourceforge.net/p/amforth/mailman/message/36748496/



- AmForth Weekend 3

  Shall take place on 2020-08-29,30 --- four weeks from now.


Thank you very much for your precious time!

Take care and happy hacking,

Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Bootloader + AmForth

[Erich Wälde]

Hello Tristan,


Tristan Williams writes:

> Is it possible to build the current AVR AmForth so that it can
> co-exist with a bootloader?
>
> There is a reference in the documentation to changes that would be
> required 
>
> http://amforth.sourceforge.net/TG/AVR8.html?highlight=bootloader
>
> and some older discussions in the mailing list 
>
> https://sourceforge.net/p/amforth/mailman/message/32235234/
>
> but nothing since. I was wondering whether this might be a way to use
> AmForth with the ATmega32u4 and USB.

Someone else asked me the same question more recently ... odd.

Well. As far as I understand (anything I wrote below might be
only partially correct or even outright wrong):


The function, which stores a new value in flash, must reside in
the NRWW section of the flash. At least on larger Atmega
controllers the size of this section can be changed.

atmel_atmega644pa_doc42717.pdf
section 27 Bootloader Support
Size can be 512, 1024, 2048 to 4096 words (word == 16 Bit,
iirc). The size is set with the BOOTSZ[01] fuses in HIGH Fuse
Byte.


A bootloader needs to reside in NRWW. Then it can read Bytes
from /somewhere/ (e.g. serial connection) and write them to
flash outside the NRWW section.

Writing Flash outside of NRWW needs to account for erasing in
blocks, saving and rewriting blocks accordingly, unless writing
the new value involves changes from 1 to 0 only (for any
individual bit). This makes i! somewhat /interesting/.


Currently "i!" lives in the NRWW section together with a number
of "core" words, thus overwriting any bootloader that existed on
the board.


So to make AmForth (or any Forth) coexist with the bootloader,
there are at least these options:

1. Forth compiles to RAM only --- normally not what you want.

2. The bootloader living in NRWW exports its "write-to-flash"
function as an interface to any interested party outside the
bootloader. Most probably such an interface would use a call
frame and not the Forth data stack. I have not checked whether
there is such a bootloader, which offers this. From the point of
view of the bootloader: "you (the user) want to load an
application which is rewriting itself? Are you nuts?"

I had looked at this many years ago (arduino bootloader) and
decided that this was over my head.

3. You could of course write your own bootloader. I have met a
person who has done just that. He wrote a small machine monitor,
but I'm not aware that he did publish it.


Hope this helps,
Erich

>
> Tristan 
>


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Ref Card Generation quo vadis?

[Erich Wälde]

thread hijacked intentionally.

Hello Mark,
dear AmForthers,

today I spent some time trying to understand the "make-refcard*"
scripts in some detail.

The script works roughly like this:

- it reads the .asm files in "one" "hard coded" directory
  ("../common/words").

- for every file the function "readASM" goes to some length to digest
  the content.

- the first three lines are comments expected to produce
  1. the stack effects (data, return, compile stacks)
  2. the category to which this word belongs
  3. a one line description, what this word is supposed to do.

- the name of the word is searched for in the '^VE_...' to '^XT_...'
  section of the code (^ being the beginning of the line).

- the strings found during this procedure are stored into several
  hash-tables, where the XT_LABEL of the word is used as the key into
  these tables.

- after all files are digested and the hash-tables are filled
  accordingly, the function printLaTeX will walk through these tables
  and print their content accordingly.

Mark has spent some time to fix the comment headers and make the
script work again. Thank you for your time!

See thread starting here:
https://sourceforge.net/p/amforth/mailman/message/37060533/
and especially here:
https://sourceforge.net/p/amforth/mailman/message/37063662/


--

Now I could commit Marks patches and not look further. However, there
are several shortcomings with the current state.

- The script will currently only digest AVR style .asm files, whereas
  we have different asm styles (see next point).

- The script will currently only read "one" directory, whereas we have
  several directories with /different/ asm styles!
  - arm/words/-- gnu asm style
  - avr8/words/   -- avr asm style
  - common/words/ -- avr, msp430 asm style with .if directives
  - msp430/words/ -- msp430 asm style
  - risc-v/words/ -- riscv asm style
  - shared/words/ -- looks like some macro style for generators

- The generated output (LaTeX, ReST) is done with two different
  scripts.

- The generated output does currently not have any indication, on
  which ports a particular word is available.

- The script will currently not read any forth code. And words like
  "value" or "c," should show up in the refcard as well, shouldn't
  they? And should the refcard not have the information that you have
  to include one of these files:
  :avr8/lib/forth2012/core/c-comma.frt
  : msp430/lib/forth-2012/core/c-comma.frt

  I kind of remember that Matthias decided to move some code from the
  pre-assembled form /back/ to pure Forth. This was in order to help
  dealing with the new, additional architectures.

- in the .asm files I would also like to see a pure Forth equivalent
  as a comment. I have missed this in the past already.


Apart from that the perl scripts are somewhat clunky and would deserve
some more modern style upgrade. Perl style i.e. I have no interest in
moving anything to Python, as you might guess.

So. Things are a whee bit muddy, unfortunately.

I currently do not see, where we would want to go. What would a good
"Reference Card" look like? Once that becomes clearer, I'm sure there
are ways to get there.


Happy forthing!
Erich,
still undecided on this



-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] [PATCH] tools/amforth-upload.py broken? yes.

[Erich Wälde]

Dear AmForthers,

I had pointed out that I use an old version of amforth-upload.py,
because newer ones did not work for me. So I spent some time with
this.

Short version for "trunk":

The expanded path of the filename given as argument is not passed on
to be opened. Please find two patches below, one for version 4.9,
one for trunk.

The changes fix uploading one or two (hopefully more) files, however,
I have not tested any #include trickery.

So if someone else would please be so kind as to test the patch for
trunk on their environment, it would be much appreciated.


Happy forthing,
Erich



--- the gory details -

1.

using md5sum and a little shell acrobatics one can find there are
seven different versions of this script:

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

I happen to use the one from release 4.0.

2.

using more shell acrobatics

# --- doit.sh --
#!/bin/bash

CONSOLE=/dev/ttyUSB1
TOP=$HOME/Forth/amforth
export R=""
for R in 2.7 3.4 4.0 4.1 4.7 4.9 5.7
do
echo "--- $R ---"
cat < ./t_up-${R}.fs
\ Blafasel ${R}
marker --up${R}--
: msg ." this is uploader rev $R" cr ;
msg

EOF
cat ./t_up-${R}.fs
$TOP/releases/$R/tools/amforth-upload.py -v -t $CONSOLE ./t_up-$R.fs
done
# --

and a controller shows that versions up to and including 4.7 work for
me. This narrows the questionable change down to version 4.8->4.9.

3.

"printf-Style" debugging lead me into function "search_and_open_file".

And into the low-lands of a triple for-loop. Where once the item in
question was found, the loops did not stop. So a "break" in the
innermost loop would fix it. At least for uploading "one" file. Or two
files. I did not test any #include trickery.

#+begin_src diff
ew@ceres:~/eGeek/sourceforge.net/amforth-code/releases/4.9/tools 30 > svn diff 
--extensions --ignore-space-change
Index: amforth-upload.py
===
--- amforth-upload.py   (revision 2442)
+++ amforth-upload.py   (working copy)
@@ -55,6 +55,7 @@
   filedirs[f].append([root])
 else:
   filedirs[f]=[root]
+  break
 if len(filedirs[f])==1:
print "using ", f," from", filedirs[f][0]
filehandle = file(os.path.join(filedirs[f][0], f))
#+end_src

This works for the script in Version 4.9. not for trunk!

4.

The script in version "trunk" is even more involved in the same triple
for-loop area. However, it seems the the beautifully crafted filename
is in the end not handed on to open the file.

#+begin_src diff
ew@ceres:~/Forth/atmega2/17_amforth_maint/03_amforth-upload 114 > diff -wu 
amforth-upload-trunk.py.orig amforth-upload-trunk.py
--- amforth-upload-trunk.py.orig2020-08-01 15:39:27.148283400 +0200
+++ amforth-upload-trunk.py 2020-08-01 16:04:50.262624068 +0200
@@ -59,9 +59,10 @@
   if fpath: filedirs[f].append(fpath)
 else:
   filedirs[f]=[fpath]
+  break
 if len(filedirs[basefilename])==1:
-   print "\nusing ", filename," from", filedirs[filename][0]
-   filehandle = file(filedirs[filename][0])
+   print "\nusing ", fpath
+   filehandle = file(fpath)
return filehandle
 else:
   # oops, too many files or no one at all no file found?
#+end_src

Again, I have not tested any #include trickery.

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] [PATCH] amforth-shell.py and python3

[Erich Wälde]

Hello Tristan,


Tristan Williams writes:

> Hello,
>
> I have modified amforth-shell.py to run under python3 and put up a
> patch here
>
> https://tjnw.co.uk/new-shell/doc/
>
> as the patch seemed a little too large for a mailing list.

Thanks for the patch. Commit r2447 is yours.

The patch is nicely readable (even by a mostly python-illiterate
maintainer :) and condenses to a few cases of syntax change:

- print -> print()

- OBJ.has_key(X) -> X in OBJ

- except X, e: -> except X as e:

- add encode() decode() to character handling

I applied the patch mostly verbatim and checked that the line
changed in r2443 did not disappear. It didn't :-)

This being said, the patch was something short of 300 lines. It
is NOT too big for the mailing list. And in fact, the mailing
list is our public archive ... so I add the committed version of
the patch below for everyones inspiration.

>
> Best wishes,
> Tristan

Happy Forthing,
Erich


--- patch --
ew@ceres:~/eGeek/sourceforge.net/amforth-code/trunk 45 > svn diff -r2446 
tools/amforth-shell.py
Password: 
Index: tools/amforth-shell.py
===
--- tools/amforth-shell.py  (revision 2446)
+++ tools/amforth-shell.py  (working copy)
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 #
 # pySerial based upload & interpreter interaction module for amforth.
 #
@@ -87,7 +87,7 @@
 #
 #   #include 
 #   Upload the named  before proceeding further.
-# 
+#
 #   #require 
 #   Like #include but would skip if  was already uploaded
 #   during the shell session.
@@ -258,7 +258,7 @@
 import re
 import readline
 import serial
-import StringIO
+from io import StringIO
 import subprocess
 import sys
 import traceback
@@ -388,7 +388,7 @@
 interact_directives = [
 "#cd", "#edit", "#require", "#include", "#directive", "#ignore-error",
 "#error-on-output", "#string-start-word", "#quote-char-word",
-"#timeout", "#timeout-next", "#update-words", "#exit", 
+"#timeout", "#timeout-next", "#update-words", "#exit",
 "#update-cpu", "#update-files"
 ]
 # standard words are usually uppercase, but amforth needs
@@ -487,7 +487,7 @@
 "EDITOR","STATE","[ELSE]","[IF]","[THEN]",
 # *** Wordset TOOLS-EXT-obsolescent
 "FORGET",
-# *** Tester wordset 
+# *** Tester wordset
 "T{", "}T",
 ]
 def __init__(self, serial_port="/dev/amforth", rtscts=False, speed=38400):
@@ -511,7 +511,7 @@
 self._last_error = ()
 self._last_edited_file = None
 self._config = BehaviorManager()
-if os.environ.has_key("AMFORTH_LIB"):
+if "AMFORTH_LIB" in os.environ:
 self._search_list = os.environ["AMFORTH_LIB"].split(":")
 else:
 self._search_list=["."]
@@ -592,9 +592,9 @@
 except AMForthException:
 return 1
 except KeyboardInterrupt:
-print "\nBye bye"
-except Exception, e:
-print "\n Unexpected exception "
+print( "\nBye bye")
+except Exception as e:
+print( "\n Unexpected exception ")
 traceback.print_exc()
 return 1
 finally:
@@ -605,10 +605,10 @@
 
 def parse_arg(self):
 "Argument parsing used when module is used as a script"
-parser = argparse.ArgumentParser(description="Interact with AMForth", 
+parser = argparse.ArgumentParser(description="Interact with AMForth",
  epilog="""
-The environment variable AMFORTH_LIB can be set with to a colon (:) separated 
-list of directories that are recursivly searched for file names. If not set, 
+The environment variable AMFORTH_LIB can be set with to a colon (:) separated
+list of directories that are recursivly searched for file names. If not set,
 the current work directory is used instead.
 
 The script assumes to be located in the standard amforth installation under
@@ -698,7 +698,7 @@
  timeout, False,
  self.serial_rtscts,
  None, False)
-except serial.SerialException, e:
+except serial.SerialException as  e:
 raise AMForthException("Serial port connect failure: %s" % str(e))
 
 def serial_disconnect(self):
@@ -728,7 +728,7 @@
 try:
 self.send_line("\n") # Get empty line echo to make sure ready
 self.read_response() # Throw away the response.
-except serial.SerialException, e:
+except serial.SerialException as e:
 self.progress_callback("Error", None, str(e))
 raise AMForthException("Failed to get prompt: %s" % str(e))
 finally:
@@ -745,18 +745,18 @@
   fpath=filename
   self.progress_callbac

Re: [Amforth] avr8

[Erich Wälde]

Hello Brian,

thanks for your message!

> ... to the arm based systems where the  'real' work can be
> done.
Well observed imho. I read a book on PIC microcontrollers many
years back, where the authors made a case that if need be,
counted loops (in asm, no matter which way through the if
statements the code executes, it will always take exactly the
same time) are your tool to make the 8 bitter
- sing a song
- dim a 50/60 Hz lamp
- do one more job i forgot by now
- all at the same time and organize these three jobs well.

Eye opening and jaw droping at the same time. It has made a
lasting impression on me.


> So I ask that you don't eliminate the ability
> to build from source, even if it means using wine and the atmel
> (micochip) assembeler.

Rest assured. First of all *I* want to build from source any
time, because I still play with stuff written in assembly. And I
don't want this project to die, just because I happen to use it
myself! Who would have thought :-)

And most importantly: this is GPL software. The source ist the
fundamental representation of the whole project. It always must
be possible to build from source. I'm just a whee bit uneasy
that this fine project depends on non-free components for this
very step. And I had good discussions with Matthias about this.
There is just no /easy/ way out, I'm afraid.

But: lurking folks on the list resorted to writing emails!
Even sending patches! Definitely progress around here.
Thank you!

Cheers,
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Reference Card page now missing

[Erich Wälde]

Hello Mark,

short answer: I'm impressed!

I'm still fairly fluent in perl, so I expect this can be fixed
to produce a refcard again. And yes I also expect to fix up the
source .asm files. Regarding those headers: IFF the files were
indeed generated from forth code, then I would like to include
said forth code in the comment section, and add a line, how it
was generated (I think this is a must for generated files
anyhow).

So, if you would please be so kind as to send your changed
script along the mailing list, that would be grand!

Thank you very much for looking into this.
And then my secret plan also worked out: give the folks
something to chew on :-)))

Cheers,
Erich

Mark Roth writes:

> Hopefully this will get sent to the right place...
>
> I have been poking around the Perl script that creates the Refcard and
> managed to get it to spit out a new (well, not quite but...) refcard.rst
> which can then be build into the webpage when using make to create the
> htdocs. It works if I change the asm source directory to the avr8 one but
> not with the common/words. The problem is that the Perl regexes are so
> tightly bound with the file having 4 line in exactly the right place. It
> looks for the "VE_" + name + ":" line then uses the three prior lines to
> fill the name, stack effect and description. The files in the common/words
> don't have the same layout since they contain the ".if cpu_" etc lines to
> handle the msp430 and avr8 flavors.
>
> Now for the good news. It seems that every file in the common/words has a
> variant for both the msp430 and avr8. Any of those could just be
> tagged with a new hash called %TYPEOF or something to that effect. Then the
> avr8/words could be parsed since they have the same top 3 lines and be
> tagged for the avr8. As I mentioned, those already work just fine. I've
> created a new refcard.html for those. Now, the msp430 is a whole other bag
> of worms. The information that is being parsed is all mashed up in the
> first line and doesn't contain a section name.
>
> So, to start out with. The msp430 asm files could be fixed by hand to have
> the proper information in the top 3 lines, but only if they are not
> generated somehow that will undo the work. Perhaps whatever spits out those
> asm files could be convinced to put that info there? I have no idea. I know
> that with g4 I could easily convince it to place those 3 lines as needed
> just by putting them as comments in the file. It works quite nicely. So,
> since I don't know anything about the 430 stuff I'll leave that for now.
>
> The bigger issue is the way the asm files are searched to create the
> refcard. That could be fixed without too much of a problem I think. Well,
> apart from having to figure out the right place to add in for the new type
> thing. Perl is Perl. I didn't have any idea about how to read it before
> this and at least can now follow the internal logic. It reminds me of a
> project to find solutions from every permutation of some packing puzzles I
> made. I wrote one bash script that fed off another and another etc. It
> works, but I don't hardly dare breathe too hard on it. ;)
> This has the same feel. It works but only because it works. I can keep
> playing with it this week and try to make some progress on it. Perl is easy
> enough to pick up enough. However, if I spoke Python I'd probably just
> rewrite the whole mess and fix the comments in the common/words to conform
> with the rest of them. Most of it is just scut work with the addition of
> tagging the crossover words with their proper flavor.
>
> So, if anyone is still this far along. I can use the scripts to create the
> stuff to make the htdocs for the site and the epub file. I tried to do the
> pdf but after adding package after package after package of the texlive
> stuff I gave up and just wrote a new rule to create the epub but not the
> pdf. It shouldn't matter except I can't test the pdf output. I will gladly
> continue to pursue this as I do find Perl interesting enough to muck with.
> It's pretty amazing apart from the fact that it is like reading a book that
> is printed entirely in stereogram.
>
> That's that for now. It seems that AmForth Weekend 1 is still bearing fruit
> (such as it is).
>
> Mark
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] AmForth Weekend 1 (2020-06-27/28)

[Erich Wälde]

Dear AmForthers,

due to some unlikely fluctuation in probability space (or some
other excuse) I declared this weekend to be "AmForth weekend 1"
--- for me at least. While being working on this I decided to let
you know, what is happening, and what is going around in my head
regarding AmForth.


- Contributions

  I am very grateful for everyone who is sending anything to the
  mailing list. Thank you! This is imho an important way to show
  that this project is not dead. I am also very grateful that
  Tristan W. and Martin N. have been helping out answering
  questions. I will not be able to keep this project alive on my
  own, so "Thank you!"

  Along the same lines: "Welcome to all newcomers!"

  That being said: I have been asked whether I accept email to my
  private address. Yes I do. HOWEVER, every email not going
  through the list, for whatever reason, does not add to the
  "this project is alive" feature, does not inform all the others
  on the list. I admit that I have been guilty of this myself
  much too often. I herewith sincerely apologize --- while being
  practical and easy it will be wrong in the long run.


- Commits

  r2443: added one-line patch to amforth-shell.py, provided by
 Tristan Williams. Will now report filenames which occur
 more than once.

  r2444: AVR8: restored avr8/words/no-jtag.asm from release 5.5;
 removed not functional avr8/devices/*/words/no-jtag.asm
 files.

  r2445: added comment about last commit to index.rst

  r2446: Added refcard manually generated from 5.5 with a
 warning! This is outdated!

 Commented Projects/ClockWorks: added version from
 2018-12-15; they were apparently lost or never published
 on the website. This version features a clock reading
 the DCF77 time radio signal.


- Open Issues

  as far as I'm aware:

  - WDT (Martin Nicholas) patch

Martin has provided a small patch (.asm) regarding the
startup of the WDT (watch dog timer) on atmega2560
controllers. I have honestly no idea, whether or not this
will break something else, and under which conditions exactly
this is needed.
link to email archive (Martin Nicholas, June 2019)
https://sourceforge.net/p/amforth/mailman/message/36682958/

  - Multitasker documentation

This needs to be tested and enhanced in a few ways. It might
be that the current example in the Cookbook section is simply
broken. There have been questions about how to better
populate the task local user area. Maybe this could be
answered by a more complex example. There has been the
question about producing output from a task (not the cmd
loop), its collision with the shared HLD/TAB area, and
possible ways to solve this (semaphores, task local HLD/TAB).
link to email archive (Jan Kromhout Feb 2019)
https://sourceforge.net/p/amforth/mailman/message/36596842/

  - " du< " is missing
link to email archive (Martin Nicholas August 2019)
https://sourceforge.net/p/amforth/mailman/message/36748496/

  - amforth-upload.py is broken for me, I use the file from 4.0.
But I have not bothered to find out exactly what breaks on
me/my code.

  - both amforth-upload.py and amforth-shell.py are using
"python", which means python2. Since python2 is being
discontinued, these should be ported to python3. Anyone
interested?

  - The refcard generator is broken probably since release 5.6
link to email archive (Martin Nicholas June 2020)
https://sourceforge.net/p/amforth/mailman/message/37047630/


- Open Questions

  Apart from the code/documentation issues above there are more
  open questions for me:

  - How do I /reliably/ create the content of the webpage? How do
I synchronize my local version effortlessly with the official
copy? How can I diagnose changes, when sphinx upon generation
changes /every/ file somehow? Did I say I'm not a web person?
%^>

  - How do I actually create a new release? Copying the files is
one thing, but where do I need to change the version? There
is more than one place, I'm afraid. I also happen to know
that after 6.9 there cannot be 6.10 due to a limitation
created very early. Matthias told me that, otherwise I would
be clueless.

  - How to run the testcases? How many test files are there? Can
they be run reliably? Will errors show up in such a way that
they will not be lost? Where should the test cases go? How
about msp430, arm, risc-v? Folks, I break into cold sweat
when I work on the source code and hit "commit".


- Whacky Ideas

  - git? -- With all the cool kids using git repositories, should
I attempt do convert the existing repositories, webpage, etc?
does sourceforge.net provide git repositories? Can the
existing svn repository be converted on the server side?

  - Should we use a ticket system rather than mailing list?

  - Who of you is using which target controller? Wo

Re: [Amforth] Reference Card page now missing

[Erich Wälde]

Hello,

after an hour of digging:

The refcard was not regenerated by me when updating the web
page. So that explains why the link entry is missing on the
page.

The refcard page itself, namely
>> http://amforth.sourceforge.net/TG/refcard.html
is still there, because I did not dare to start with an empty
directory. Strictly speaking his page is a "leftover".

There is a script trunk/tools/make-refcard-rst which looks
suspiciously like it had been used to generate this particular
page. However, this script is not referenced anywhere :-(

There is a piece of dokumentation
> http://amforth.sourceforge.net/TG/Tools.html
which mentions "makerefcard" and "make-htmlwords" scripts.
The first I cannot find in the available repository. The second
is still there.

Found in trunk/tools, the scripts make-refcard-rst,
make-refcard, and make-htmlwords are perl scripts. All three
define this:
> my $asmdir="../core/words";
The trunk/core directory was moved elsewhere in release 5.6.
make-refcard defines:
> my $version="5.4";
and make-refcard-rst defines:
> my $version="5.1";
So I suspect that these tools have been broken for a long time.

Release 5.6 added the msp430 target and thus the tree layout was
rearranged.


So this does not look like "easily fixable" at all, I'm afraid.



- the refcard needs to accomodate the "common" case and words
  specific to 4 target controllers.

- the refcard must be generated from the source files, anything
  else is asking for trouble and errors. The existing script did
  cover the asm sources only, not any available forth commands.

- the refcard needs to be generated as .rst, and then converted
  to html for the web page. There are also latex and epub files
  in the tree, which are probably generated from the .rst files.


Possible paths forward?

Can we understand in detail, how the scripts did work before
release 5.6? Probably.

Can we understand, how the tree layout and the code has changed?
And what we need to do in order to generate the refcard from
sources? Probably, it just sounds like quite a bit of work.

After that we can see, how to accomodate the generation of the
refcard across targets.


If anyone feels like spending some time on this, please go ahead
and please report your findings here on this list.


Cheers,
Erich



Erich Wälde writes:

> Hello Martin,
>
>
> Martin Nicholas via Amforth-devel writes:
>
>> Somehow this has gone from the RH menu:
>> http://amforth.sourceforge.net/TG/refcard.html
>
> Good point, thanks for the report.
>
> Some time back I had a conversation with Matthias about the
> reference card.
> - it has grown unbelievably
> - it should be generated automatically from the source files
>   /somehow/
> - it might be out of date at any place.
>
> So, please folks, feel free to report anything that looks wrong.
>
> Cheers,
> Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Reference Card page now missing

[Erich Wälde]

Hello Martin,


Martin Nicholas via Amforth-devel writes:

> Somehow this has gone from the RH menu:
> http://amforth.sourceforge.net/TG/refcard.html

Good point, thanks for the report.

Some time back I had a conversation with Matthias about the
reference card.
- it has grown unbelievably
- it should be generated automatically from the source files
  /somehow/
- it might be out of date at any place.

So, please folks, feel free to report anything that looks wrong.

Cheers,
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Stack pointer

[Erich Wälde]

Hello,

tur bine writes:

> Hi just wished to expand my knowledge base with forth, the stack pointer
> increases during runtime and does not decrease unless using certain
> commands if etc, can somebody explain what happens when sp and thus the
> stack gets full please

Martin has answered your question already. I would like to add a
a few bits.

1.

The exact region, how memory (RAM) is used, is documented in
> http://amforth.sourceforge.net/TG/AVR8.html
(similar for the other targets). More precisely
> http://amforth.sourceforge.net/TG/AVR8.html#ramfigure
shows that in this partcular case, the datastack grows towards
the HLD/PAD area. This might be quite some distance, but Martins
answer holds: if you overwrite something "important", then most
likely your programm will crash.

I cannot yet explain the purpose of the two different layouts,
but I assume that the latter is needed to accomodate one or more
of the other hardware targets. I have not tried to understand
this so far. I do have a hifive1 board, so it is on the list to
understand better, what the boundary conditions are (beside
using a different asm format).


2.

When using the multitasker, you will run into finite stack space
conditions much sooner. To define a task, you specifiy the size
of the data/return stacks explicitly. If your nice programm
crashes once in a while, I would strongly recommend to increase
stack sizes as a first experiment. Been there, done that. :-)

The command " .res " does actually output some information about
stack usage. And it's worthwile to study its code.
> .../avr8/lib/dot-res.frt


3.

When using the multitasker, the above mentioned HLD/PAD area is
interesting as well, because currently there is only one such
area shared between all tasks. I have been bitten by this: Task
A runs the command loop on usart0; Task B runs a function, which
writes to an LCDisplay via spi or i2c. Please note: two tasks
using different hw periphery with distinct versions of " emit ".
However, both tasks used pictured numeric output (this is
actually quite hard to avoid :-) And once in a while, the
formated output bound for the LCD would overwrite the output
bound for the serial interface. It "looked" like amforth was
doing calculation errors once in a while ...

As I have mentioned a while back, I would like to either provide
task-local areas for HLD/PAD  or play with semaphores to solve
this.

However, my days are much too short --- as I'm sure everyone
elses are as well :-)


-

While rereading your question, it occurs to me that you might
talk about FLASH rather than RAM.

When compiling a word, the new word will consume some flash
space. DP points to the next available position. The dictionary
grows from low flash addresses towards higher ones.

On AVR8 it will eventually hit the NRWW section boundary. I
expect that compiling will fail at this point, because the NRWW
section is kind of protected. I have not tried this.

In order to reclaim FLASH memory without erasing/flashing the
controller, you can use the word " marker " (which you need to
load first) Example:

> my_code.frt
>| \ maybe more includes needed here ...
>| include lib-avr8/forth2012/core-ext/marker.frt
>| 
>| marker --main--
>| 
>| \ ... your code goes here


Now when you don't like your code anymore, you can call

> --main-- ok
>
on the serial connection. This word will reset book-keeping in
such a way, that everything from " --main-- " and onward is not
available any more. Please note that " --main-- " itself
vanishes as well and needs to be set anew.

There is one symptom related to this. If you load a lengthy
programm for the first time, it takes so long. If you load it
again, without reclaiming flash by calling the marker before ---
then it will take a little longer every time. This is noticable.
This is caused by the increasing length of the wordlist. To
find a word at the low end of the list, it will take
increasingly longer, because the length of the wordlist
increases. And guess what, all the important words stay at the
low end of the wordlist.



Thanks for reading,
and welcome to the list!

Cheers,
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Multitasking/emit/hold

[Erich Wälde]

Hello Tristan,

back to mulitasking on AmForth.

I spend an afternoon to create a background task, which does some
output by itself (see code below). There is nothing really new in
this. If I equip the background tasks with base and pointers to emit
(and emit?), it does work, including pictured output of numbers. 

I gained a few insights along the way:

1.
the background task has any form I want. So noone can stop me from
writing 
> | : run-demo
> |   \ some init stuff
> |   #10 base !
> |   \ loop
> |   begin
> | \ repeated work goes here
> |   again
> | ;
This "init" space can be used to set missing bits without any need to
change init-task.

2.
however: the real XT found in emit is hidden behind a defer.
> | ' emit defer@
will not work in run-demo. 

First solution: store this value in a constant before defining
run-demo.

> | ' emit defer@ constant emit.orig
> | 
> | : run-demo
> |   emit.orig is emit
> |   ...
> | ;

This works for the io functions emit emit? key key?. I expect this to
work for the prompts .ok .ready .error .input as well.

But storing these values separately seems kind of odd.

Second solution: There is an area in EEPROM holding all these values.
Much to my surprise these values are stored at some odd location. Look
for "EE_INITUSER:" in main.lst (the assembler list file). It will
reveal this location:
> |  ; default user area
> |  EE_INITUSER:
> | 74 00 00 .dw 0  ; USER_STATE
> | 76 00 00 .dw 0  ; USER_FOLLOWER
> | 78 ff 10 .dw rstackstart  ; USER_RP
In this case $74. So we can pick things from $74 plus some offset.

If I want to do this in run-demo, then a Forth constant holding that
offset would be nice (change to AmForth asm).

Third solution (not tested) instead of 
> | : task-init ( tib -- )
> |   dup tib>tcb over tib>size  0 fill \ clear RAM for tcb and stacks
> |   ...
we could write something like
> | : task-init ( tib -- )
> |   dup tib>tcb over tib>size  \ -- r-addr length
> |   ee_user rot rot\ -- e-addr r-addr length
> |   \ possibly 2/ to correct for cells
> |   ee>ram
> |   ...
instead. So we get all the missing stuff delivered. This needs the
same Forth constant as in 2.

I expect this to break on targets other than avr8 --- at least for my
current lack of understanding, how/where this information is stored on
the other platforms.


Still reading? No, I have not even tried to go beyond what we did know
already. 


However.

I wrote:
> Now back to your original problem. I rephrase: "Wouldn't it be
> nice if I have one or more background tasks running along and
> printing their output as they go --- independantly of each
> other"?

My experiments reminded me very clearly, that more than one task
emitting output on the same destination can only be a bad idea. In the
end you get garbled output. Unless of course, you lock access to this
one resource using semaphores. Thats one more thing to work out.

"this one resource" starts pointing to a better understanding. This is
the classical "several clients/tasks compete for a single resource"
problem. This is what an operating system kernel must organize all the
time. Any access to (any) resource must go through one instance.

So we enter the world of locks and queues and privileges and
priorities and what not.

Use case:

Task-1 acquires the "output on uart0"-lock.
{ Task-1 prepares the output
  Task-1 emits the output } possibly more than once
Task-1 releases the lock.

This also includes the fact, that emitting e.g. on uart, takes long.
You copy one byte to the output register, and then basically you call
pause. A task switch occurs at this point. Probably several task
switches later, the next byte can be emitted. For some applications
this might work. For other maybe not. 

Making the HOLD area (and possibly TerminalInputBuffer) task local,
can be solved, no doubt. But I'm not convinced that this is the way to
go unless different tasks operate on separate output destinations.

Having cooperative multitasking basically offers that one task holds
the cpu and calls pause only after it is done. But you need to check
carefully, that pause isn't called in unexpected places.

Having one task to emit output, and all the other report to this one?
Enter the world of queues, dynamic memory allocation and locks. :-/


Well well. I hate to say that, but this seems like a slippery slope.
And no, I'm neither a good system programmer nor living in kernel
space. So my understanding of this sort of problems is very limited.

I want to see if semaphores can help in some cases.


One more thing: in my rs485-bus project, I hit a similar problem, of
course: several sensor stations sending their values whenever their
local clock says "it's time", to the one resource called rs485 bus. No
thanks. My solution thus far is: The bus master is soliciting data
from each station, when the bus master's clock says "it's time". And I
have spend some effort to silence the s

Re: [Amforth] Multitasking/emit/hold (was: Redirect EMIT from within a task)

[Erich Wälde]

Hello Tristan,


Tristan Williams writes:

> Hello Erich,
>
> Within task-init from multitask.frt I think a task's entire tcb/user
> area is filled with zeros and then only the values from the task's
> (flash) tib are copied across to the task's tcb/user area. A value for
> BASE is not stored within the tib. Only sp0, sp0-- and rp0 are stored
> in the task's tib.   
>
> : tib>tcb  ( tib -- tcb )  @i ;
> : tib>rp0  ( tib -- rp0 )  i-cell+ @i ;
> : tib>sp0  ( tib -- sp0 )  i-cell+ i-cell+ @i ;
> : tib>size ( tib -- size )
>   dup tib>tcb swap tib>sp0 1+ swap -
> ;
>
> : task-init ( tib -- )
>   dup tib>tcb over tib>size  0 fill \ clear RAM for tcb and stacks
>   dup tib>sp0 over tib>tcb #6 + !   \ store sp0in tcb[6]
>   dup tib>sp0 cell- over tib>tcb #8 + ! \ store sp0--  in tcb[8], tos
>   dup tib>rp0 over tib>tcb #4 + !   \ store rp0in tcb[4]
>   tib>tcb task-sleep\ store 'pass' in tcb[0]
> ;

You have clearly spend more time on this, I see! Populating base
won't be difficult, but I wonder what other candidates are
there.

>
> I believe the interpreter user area is fully populated from eeprom
> at boot time, but all other tasks rely on the programmer to fill in
> what is relevant to their tasks. I did not appreciate that included a
> value for BASE, but I do now.

That's what I had in mind.
COLD avr8/words/cold.asm does jump to PFA_WARM.
WARM common/words/warm.asm does call XT_INIT_RAM
init-ram avr8/words/init-ram.asm does the copy loop
> | XT_INIT_RAM:
> |   .dw DO_COLON
> | PFA_INI_RAM:  ; ( -- )
> | .dw XT_DOLITERAL
> | .dw EE_INITUSER
> | .dw XT_UP_FETCH
> | .dw XT_DOLITERAL
> | .dw SYSUSERSIZE
> | .dw XT_2SLASH
> | .dw XT_EE2RAM
> | .dw XT_EXIT
something like "  eeinituser up@ sysusersize 2/ ee>ram "
where " : ee>ram   0 do over @e over ! cell+ swap loop 2drop ; "
no garantees. But there is ee>ram, which could be called in
task-init, too, before storing sp0 rp0 ...


>
>> Having said that I feel inclined to add another: "Wouldn't it be
>> nice, if I could run a second commandline task (quit) on an
>> existing second serial connection (thing atmega644pa or
>> similar)"? Thus effectively creating a *Two User AmForth on one
>> AtMega644pa*? Actually I do have a use case for this. And I have
>> started to implement something in small steps[2]:
>
> Would the two users have separate dictionaries?
Good question! I haven't really thought about that.
But I had in mind to prepend a new (limited) dictionary for that
second serial connection, in order to make it deal correctly
with the incoming data (well data wrapped in forth syntax).


Thank you for your input.
Cheers,
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Multitasking/emit/hold (was: Redirect EMIT from within a task)

[Erich Wälde]

Hello Tristan,

thanks for your message.

My below answers/comments only regard AVR8. I have currently no
idea, how this is similar or different in the other 3 targets.


> I revisited "Redirecting emit from within a task in AmForth",
> as I still like the idea of having a self contained task that can
> perform its own io, but without having to write my own version of
> pictured numeric output.

It sure would be nice, if this worked without a hitch. Agreed!


> It turned out that redirecting emit was not the problem. The xt for
> the new emit was correctly being stored in the task's user area
> (user+14) and was being called correctly by emit within the task. What
> I had not appreciated at the time was that (user+12) which holds the
> task's base value is zero by default.

A base of value '0' is not good. However, it seems a little more
convoluted:

The USER area is filled from a snippet stored in EEPROM. The
EEPROM values are defined in "avr8/amforth-eeprom.inc". In trunk
the relevant snippet looks like this:

> | ; default user area
> | EE_INITUSER:
> | .dw 0  ; USER_STATE
> | .dw 0  ; USER_FOLLOWER
> | .dw rstackstart  ; USER_RP
> | .dw stackstart   ; USER_SP0
> | .dw stackstart   ; USER_SP
> | 
> | .dw 0  ; USER_HANDLER
> | .dw 10 ; USER_BASE
> | 
> | .dw XT_TX  ; USER_EMIT
> | .dw XT_TXQ ; USER_EMITQ
> | .dw XT_RX  ; USER_KEY
> | .dw XT_RXQ ; USER_KEYQ
> | .dw XT_SOURCETIB ; USER_SOURCE
> | .dw 0; USER_G_IN
> | .dw XT_REFILLTIB ; USER_REFILL  
> | .dw XT_DEFAULT_PROMPTOK
> | .dw XT_DEFAULT_PROMPTERROR
> | .dw XT_DEFAULT_PROMPTREADY
> | .dw XT_DEFAULT_PROMPTINPUT

So base is set to #10. When setting up a user area, these values
are copied over. If you end up with the value zero in USER_BASE,
it either was overwritten afterwards, or it wasn't copied
correctly to begin with. For that I need to investigate, how
exactly a task area is setup. And propably read a lot of
documentation along the way :-)



> This meant that after . or u. ,
> emit was never called as the mcu had crashed in the pictured numeric
> output routines (in #s I think, though it is # that fetches base) which
> use base.
>
> Ironically, to establish this I did end up re-writing versions of the
> pictured numeric output routines in Forth so that they wrote to part
> of an extended task user area - so providing task specific pad and
> numeric picture buffers that I could be (more) sure were not being
> modified elsewhere. When this still crashed the mcu, I re-read
>
> http://amforth.sourceforge.net/TG/Architecture.html?highlight=user 
> http://amforth.sourceforge.net/TG/recipes/Multitasking.html
>
> and I realised that I was responsible for providing a newly created
> task with more than just an xt for emit. task-init only does so much.
> Once 10 was written to the task's base location (user+12), my versions
> of . u. wrote correctly to the task's local buffers and the redirected
> emit was called by type (from my numeric picture routines). AmForth's
> . and u. also wrote correctly to the (shared) numeric picture buffer below
> the (shared) pad. 
>

> http://amforth.sourceforge.net/TG/recipes/Multitasking.html
This piece of documentation was written by me a long time ago.
It does need some brush up.


Now back to your original problem. I rephrase: "Wouldn't it be
nice if I have one or more background tasks running along and
printing their output as they go --- independantly of each
other"?

I think, it would. Now, what can we do about it? What is /the/
problem? One problem I mentioned is that the HOLD area (the
place where pictured output is stored before emitting it) is
shared between all tasks, as of this time[1]. A similar problem
occurs, if more than one task print to the same output,
character by character: we probably end up with a little mess.
Sometimes this is not a problem, other times it is.


Option 1: create a semaphore to ensure, that only one task is
accessing HOLD, until it's finished. I was convinced there is an
example in the cookbook. But there isn't. What I found is this:
> | common/lib/multitask-semaphore.frt
> | common/lib/multitask-messages.frt
That can serve as inspiration.


Option 2: create a separate hold area for each task.
Well. It surely can be done, and others have surely done so. I
need to spend some time on the exact layout of the RAM space.



Having said that I feel inclined to add another: "Wouldn't it be
nice, if I could run a second commandline task (quit) on an
existing second serial connection (thing atmega644pa or
similar)"? Thus effectively creating a *Two User AmForth on one
AtMega644pa*? Actually I do have a use case for this. And I have
started to implement something in small steps[2]:

- add a second interrupt service routine on incoming data on
  that second serial interface. 
  solved.
  
- add a second input ring buffer (below rx/key/key?)
  solved.
  
- add a second set of rx/key/key? tx/emit/emit?

[Amforth] fixed D0>, updated website

[Erich Wälde]

Dear AmForthers,

so I "jumped" and actually wrote new content to the amforth
repository and project web site.

D0> has been fixed.

I added a new section "Opinion" to the website, sort of a blog.
There I added a entry describing how I went about fixing "D0>".


If you find errors, things not working as expected, or other
"observations", please do not hesitate to report them on this
list. Thank you.


Happy Forthing,
Erich

--
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Sad News

[Erich Wälde]

Dear AmForthers,


I'm quite certain, that many of you have noticed Matthias'
unusual silence. Since July 2019 he was fighting a serious
health issue. His wife has informed me that Matthias has
left this planet for good on Wednesday evening (2020-03-25).

We wish him an exceptionally pleasant journey!


Matthias has contributed remarkable pieces to the Forth
community. Not only is he the creator of AmForth, which I have
used from an early stage. Not only has he increased the range of
target controllers to msp430, arm, and risc-v. He has always
been keen to make his work conform to the Forth Standard.
Moreover, he has gone even further by advancing the concept of
"recognizers" (originally proposed by Anton Ertl) through
several stages of implementation to a "Commettee supported
proposal", something that has not been seen before. If someone
wants to implement recognizers for her/his Forth, then this is
the interface to be written. The list of articles in the "Vierte
Dimension" dealing with or mentioning AmForth is simply
impressive.

I do feel privileged to have met him im person a few times.



Several weeks ago I had decided to at least try to keep the
website/repository updated, fixing bugs and documentation as
much as I can, and maybe a little more with your help.
Very fortunately I have been granted access to the web site.


I'm willing to take on this task as an expression of my deepest
respect for Matthias' work. I know that he spend countless hours on
AmForth. He has always been willing to listen to my many bug reports
and suggestions --- many more than the ones visible in the mailing
list archive. He had countless ideas to expand the system and keep it
useful for others. He is already sorely missed.



If I (or anyone) can learn anything from this situation: grant access
to your most important (digital) information or files to a trusted
person while you can. You might be unable to do so later.


Despite the sad facts:
Happy Forthing nonetheless! Keep going!
Maybe even get wild occasionally!

Greetings,
Erich


If you would like to express your feelings to his wife, I'm more
than happy to forward anything verbatim, if you send it my way.
If you would like a snail mail address from me, contact me via
ew.fo...@nassur.net ---


--
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] -jtag broken, workaround

[Erich Wälde]

Dear AmForthers,

to my knowledge noone has ever complained that " -jtag " ceased to
work after version 5.5. Is it only me using this command?

Short version:

Since version 6.2 the content of the files
> releases/*/avr8/devices/*/words/no-jtag.asm 
is essentially an empty function. This can be fixed by copying 
> releases/5.5/core/words/no-jtag.asm 
to your project, and reassembling AmForth.


Longer version:

While porting an /old/ program from version 4.6 to 6.8 on an
atmega644p, it surprisingly failed to work. After some searching it
became clear that pin C.2 did not work as expected. Suspiciously, this
pin is part of the JTAG port. Moving to a non-jtag pin made the
program work.

Some code archeology found the following details:

- File "words/no-jtag.asm" was added in version 2.7
- it has changed a few times until version 5.5
- in version 5.6 it disappeared
- it reappeared in version 6.2 --- possibly because someone complained
  (may have been me). However, it reappeared in the devices subtree,
  separate for each controller. And it was and still is an empty
  function. 

I have no idea, why Matthias has distributed this function. To my
knowledge it is the same everywhere --- whereas sleep.asm had to be
distributed per controller before.


So, maybe this information saves some head scratching.

Cheers,
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Missing DU

[Erich Wälde]

Hello Martin,

> Also, a bug in D0>:
> Hmmm, something wrong here I feel:
>
>> (ATmega2560)> decimal  1553994000. d0> .   1572137999. d0> .
>> -1 0  ok

yes there is.

Short answer:

The assembly version produces the wrong result,
when the MostSignificantBit of the lower *word* is set.
> trunk/avr8/words/d-greaterzero.asm

The forth version is ok.
> trunk/common/lib/forth2012/double/d-greater-zero.frt

Workaround: use the forth code.


Sightly longer answer:
> | > $7FFF. d0> .
> | -1  ok
> | > $8000. d0> .
> | 0  ok

The exakt value of the high word (here $) is irrelevant.
The Forth version works as advertised:

> | > : new.d0> 2dup or >r  d0< 0=  r> and 0= 0= ;
> |  ok
> | > $7FFF. new.d0> .
> | -1  ok
> | > $8000. new.d0> .
> | -1  ok


The gory details:

So after a dive into the assembly code, reading the docs and a
fair amount of head scratching I think I see cause of the
problem:


#+name: trunk/avr8/macros.asm
#+begin_src asm
.macro loadtos
ld tosl, Y+
ld tosh, Y+
.endmacro
#+end_src

#+name: trunk/avr8/words/d-greaterzero.asm
#+begin_src asm
; ( d -- flag )
; Compare
; compares if a double double cell number is greater 0
VE_DGREATERZERO:
.dw $ff03   ; flags,length
.db "d0>",0 ; name
.dw VE_HEAD ; link to previous voc entry
.set VE_HEAD = VE_DGREATERZERO ; advance pointer to first voc entry
XT_DGREATERZERO:; XT eXecution Token is here
.dw PFA_DGREATERZERO; branch to PFA, this is an assembly word
PFA_DGREATERZERO:   ; so PFA is right here!

cp tosl, zerol  ; comparetop-of-stack-low,  zero-low
cpc tosh, zeroh ; compare-with-carry top-of-stack-high, zero-high

; The result at this point is stored as flags in the STATUS
; register. The original values are left unchanged.

loadtos ; *I guess at this point*
; TOS resides in a register pair
; Y points to the remainder of the stack
;   in RAM. So loadtos moves the former
;   TOS-1 element into register pair tos
; does ld change the status register flags? nope.

cpc tosl, zerol ; compare-with-carry top-of-stack-1-low,  zero-low
cpc tosh, zeroh ; compare-widh-carry top-of-stack-1-high, zero-high

; at this point we have consumed 4 Register values and compared
; them with zero. Reading up on the exact workings of "cp" and
; "cpc" I conclude
;
; cp Rd, Rr
; calculates R = Rd - Rr
; and stores the flags derived from the result R in the status
; register. In particular
;
; Flag Z is set if all bits of the result R are cleared.
;
; Flag S (Signed) = N xor V
;
; Flag N (Negative) is set when R7 (MSB in R) ist set, clear
;otherwise
;
; Flag V (oVerflow) is set if calculating the result produces a
;2 complements overflow.
;since Rr is zero, there should never be such an
;overflow. So in this case V=0.
;
; The S flag is set, if any of the 4 Bytes (== 2 words) have
; their MSB set. That's what we see in the example above.
;

brlt PFA_ZERO1  ; Branch if Less Than, Signed
; Tests the signed flag and branches, if S is set
; at this point, the S flag is used. I currently think that only
; the MSB of the highest Byte should be inspected for this
; decision.

brbs 1, PFA_ZERO1   ; Branch if Status Flag Set, bit 1 (Z) is used
; however, at this point the Z flag is used! Therefore the lower
; Bytes must have been inspected as well!

rjmp PFA_TRUE1  ; jump, (tail call opt.)

; --
PFA_ZERO1:
movw tosl, zerol; copy 0,0 to tosl,h
jmp_ DO_NEXT

; --
PFA_TRUE1:
ser tosl; ser set all bits in register
ser tosh
jmp_ DO_NEXT
#+end_src

I'm not sure I have yet understood the problem in all details.
E.g. the error should show up as well, if only the MSB of a
lower Byte is set.
> | > $0080. d0> .
> | -1  ok
> | > $8000. d0> .
> | 0  ok
> | > $0080. d0> .
> | -1  ok
> | > $8000. d0> .
> | -1  ok
But that is not the case.

Moreover I'm uncertain, how to fix this, or whether the assembly
version should just be removed. Inspecting the code tree
reveals, that this file was added in Version 5.2 and was
unchanged ever since. So it never has worked, it seems.


Any suggestions?
Happy Hacking.

Cheers,
Erich

--
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Redirect EMIT from within a task

[Erich Wälde]

Hello Tristan,

I just spent some time on your problem.

1. I can reproduce this problem with your code! Your code looks
innocent to my eyes, with the possible exeption of changing "
emit? " as well. But leaving that out does not change the
problem.


2. stack size

I replaced
> 1 +noop . -noop
with
> N @ drop
and it did not work. This code comes to life when increasing
the memory sizes for the task
> $40 $40 0 task: task1
I remember being bitten by this as well a long time ago.


3. Nonetheless the problem persists.


So.

I think you found a bug. Allthough I do not understand why emit
or dot triggers a reset ... at least at this time.

On the other hand I believe this stuff has worked before, so
going back to Version 4.6 or something such could be worthwhile.


One other thing: I strongly discorage using "emit" or its kin
from within a task. I have done this before. Had a few tasks,
each one reading some sensor and printing the value (on serial
or to display, doesn't matter) while at the same time asking the
foreground task for data. I don't print anything from inside a
task anymore, because these different task do share the buffer,
where number output is formatted. PAD? I forgot its name. I got
errors in formatted numeric output --- which of course looks
like calculation errors.


Cheers,
Erich






Tristan Williams writes:

> Hello Erich,
>
> Thank you for your email.
>
> The example I posted was the simplest I could think of that would
> illustrate the what I was trying to achieve - the redirection of EMIT
> within a task. What I actually have is various sensors attached to an
> AVR. Rather than poll each of them in a loop I decided (as an
> experiment) to put each of them in their own task. Each task would
> then respond to (or poll) its sensor and also output the result. This
> I could do by writing directly (not via EMIT) to their output medium
> (display, leds, sound) for each sensor. I think doing this by
> redirecting EMIT within the task would be a better solution - but not
> one I achieved.
>
> Kind regards,
> Tristan
>
>
> On 19Sep19 20:32, Erich Wälde wrote:
>>
>> Hello Tristan,
>>
>> I need to look into my stuff, but that won't happen before next
>> week. If I understand you correctly, you want to "shut down the
>> output of the task, no matter what." I think, I have done this
>> somewhere ... but I do not remember the details. You need to
>> place " ' drop " in the correct field in the task control block.
>> Something like this ... I'll check this out next week. :-)
>>
>>
>> Cheers,
>> Erich
>>
>>
>> Tristan Williams writes:
>>
>> > Hello,
>> >
>> > I have been trying to redirect emit from within a task in a forth
>> > multitasking setup. Redirection works perfectly for me in a word run
>> > from the interpreter but when I try to do it from a task I fail to get
>> > it to work. Below is a stripped down example which aims to redirect
>> > emit to drop - so nothing should be output. The result of go! is
>> > either a mcu reset or a hang. Without the redirection line, the task
>> > runs and I can use the interpreter. Any ideas as to where I am going
>> > wrong very gratefully received.
>> >
>> > Regards,
>> > Tristan
>> >
>> > \ include ms.frt \ with pause
>> > \ include avr-values.frt
>> > \ include multitask.frt
>> >
>> > ' emit  defer@ Evalue emit.amforth
>> > ' emit? defer@ Evalue emit?amforth
>> >
>> > : +noop ['] drop is emit ['] true is emit? ;
>> > : -noop emit.amforth is emit emit?amforth is emit? ;
>> >
>> > $20 $20 0 task: task1
>> >
>> > : tx1.ex
>> >
>> > task1 tib>tcb activate
>> >
>> > begin
>> >   +buzz 1000 ms
>> >   \ uncomment one of three lines below
>> >   \ 1 +noop . -noop  \ works in the interpreter
>> > 1 +noop . -noop  \ resets the mcu in task
>> >   \ +noop  -noop \ does not reset mcu in task
>> >   -buzz 1000 ms
>> > again
>> > ;
>> >
>> > : go!
>> >
>> > buzz.init
>> >
>> > task1 task-init
>> >
>> > tx1.ex
>> >
>> > onlytask
>> > task1 tib>tcb alsotask
>> > multi
>> >
>> > ;
>> >
>> >
>> >
>> >
>> >
>> > ___
>> > Amforth-devel mailing list for ht

Re: [Amforth] Redirect EMIT from within a task

[Erich Wälde]

Hello Tristan,

I need to look into my stuff, but that won't happen before next
week. If I understand you correctly, you want to "shut down the
output of the task, no matter what." I think, I have done this
somewhere ... but I do not remember the details. You need to
place " ' drop " in the correct field in the task control block.
Something like this ... I'll check this out next week. :-)


Cheers,
Erich


Tristan Williams writes:

> Hello,
>
> I have been trying to redirect emit from within a task in a forth
> multitasking setup. Redirection works perfectly for me in a word run
> from the interpreter but when I try to do it from a task I fail to get
> it to work. Below is a stripped down example which aims to redirect
> emit to drop - so nothing should be output. The result of go! is
> either a mcu reset or a hang. Without the redirection line, the task
> runs and I can use the interpreter. Any ideas as to where I am going
> wrong very gratefully received. 
>
> Regards,
> Tristan
>
> \ include ms.frt \ with pause  
> \ include avr-values.frt
> \ include multitask.frt
>
> ' emit  defer@ Evalue emit.amforth
> ' emit? defer@ Evalue emit?amforth
>
> : +noop ['] drop is emit ['] true is emit? ;
> : -noop emit.amforth is emit emit?amforth is emit? ;
>
> $20 $20 0 task: task1
>
> : tx1.ex
> 
> task1 tib>tcb activate
>
> begin
>   +buzz 1000 ms
>   \ uncomment one of three lines below  
>   \ 1 +noop . -noop  \ works in the interpreter 
> 1 +noop . -noop  \ resets the mcu in task
>   \ +noop  -noop \ does not reset mcu in task  
>   -buzz 1000 ms 
> again
> ;
>
> : go!
>
> buzz.init 
> 
> task1 task-init
>
> tx1.ex
>
> onlytask
> task1 tib>tcb alsotask
> multi
>
> ;
>
>
>
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Read/write from safe known fixed EEPROM address

[Erich Wälde]

Hello Tristan,

> Thanks again for your help.
You are welcome!

> I managed to modify applturnkey to read from internal EEPROM,
> which was the missing part of my project to have AmForth use
> the RC oscillator as a clock source.
Glad I could help. It is often only a tiny piece of information,
which opens the door.

Happy hacking!
Please consider to share more details of your project,
we are all eager to learn from others, aren't we?

Cheers,
Erich


--
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Read/write from safe known fixed EEPROM address

[Erich Wälde]

Hello Tristan,


>
> In avr8/amforth-eeprom.inc the top line is
>
> .dw -1   ; EEPROM Address 0 should not be used
>
> Does this mean that $0 is reserved and used by AmForth internally or
> $0 is not to be used because historically it has been used by other
> programs e.g. storing calibrated OSCCAL value? If it is the latter,
> then it would be very opportune.

If my memory serves me well, some toolchains keep track of the
number of erase cycles they did, or something such. I do not
know why Matthias has chosen to not use addr 0. But I do not use
it either. Once I have defined an new label at the end, and
used it somewhere else, I tend to forget, where it was. Because
I never have do deal with this address again.

So, imho not important.

Cheers, and good luck!
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Read/write from safe known fixed EEPROM address

[Erich Wälde]

Hello Tristan,


Tristan Williams writes:

> Hello,
>
> I would like to modify my AVR build of AmForth to read/write a byte
> from a known fixed EEPROM address, perhaps from applturnkey. This byte
> may be written outside of AmForth. Is there a safe area of EEPROM
> from which to do this or a way making one? Any pointers as to where to
> look appreciated.


Words like "eallot" "Evalue" "e@" "e!" and the like are
available, let's see ...

  | @e  | ./avr8/words/fetch-e.asm
  | !e  | ./avr8/words/store-e.asm
  | ehere   | ./avr8/words/ehere.asm
  | eallot  | ./avr8/lib/eallot.frt
  | Evalue  | ./avr8/lib/forth2012/core/avr-values.frt
  | 2@e 2!e 2Evalue | ./avr8/lib/2evalue.frt
  | Eallot Ebuffer  | ./avr8/lib/forth2012/core/eeprom-buffer.frt


So I think, creating an Evalue could help you. There is some
more text here
http://amforth.sourceforge.net/TG/recipes/Values.html

You can then wrap such stuff together with applturnkey
(example):

>  : run-turnkey
>applturnkey \ call the original turnkey first
>  
>init\ add one time stuff here
>  
>starttasker \ start the loop!
>  ;




However, if you want to modify AmForth to be assembled with this
value already, then avr8/amforth-eeprom.inc is the place to
start. Add another label and value in this file, verify that
ehere points to the correct (first empty) location after
assembling, and be sure to add a word, which will retrieve this
EEprom content and place it on the stack.

Well, I have done this before ... /me searches the archives ...

in a project-local copy of amforth-eeprom.inc I added 2 lines to
define a location in eeprom

>  EE_UBRRVAL:
>  .dw UBRR_VAL ; BAUDRATE
> +EE_PROMPT_RDY:
> +.dw XT_PROMPTREADY_INT

This label (EE_PROMPT_RDY) is used in a word defined in asm:

>  cat words/prompt-ready.asm
>  ; make prompt_ready a deferred word
>   
>  VE_PROMPTREADY:
>  .dw $ff04
>  .db "p_rd"
>  .dw VE_HEAD
>  .set VE_HEAD = VE_PROMPTREADY
>  XT_PROMPTREADY:
>  .dw PFA_DODEFER1
>  PFA_PROMPTREADY:
>  .dw EE_PROMPT_RDY  ; < used here
>  .dw XT_EDEFERFETCH
>  .dw XT_EDEFERSTORE

The content of this location is retrieved (edefer@) and should
be on top of the stack then (it is consumed again by edefer! in
this case.)  The defined "p_rd" is used in Forth code later:

: +stationid
  ['] prompt_rd to p_rd
;
: init
  +stationid
  ...
; 

In this particular case I made the ready prompt to be a deferred
word, because I wanted it to print some information (the
stationID). Nowadays all prompt functions are deferred and I
don't need to do this any more. But it should give you an idea
on how to proceed.

There is one more option: the Evalue can live in an external i2c
EEPROM, too. See
http://amforth.sourceforge.net/TG/recipes/I2C-Values.html#i2c-values


So many options!
Hope this helps,

Erich

--
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] how to use bitmask:

[Erich Wälde]

Dear Jan,

thanks for your message.

see my answer below the text.


Jan Kromhout via Amforth-devel writes:

> Hello,
>
>
> After trying for a while, I failed to get these three words together.
> Do not master the bitmask. Despite the examples and the email. Can someone 
> please help me with this.
> This is my simple code. The source is from flashForth.
> The tree words are setBitmask,clearBitmask and testBitmask.
>
> Thanks for any help.
> With kindly regards,
>
> Jan
>
> $24 constant ddrb
> $25 constant portb
> $4c constant spcr
> $4d constant spsr
> $4e constant spdr
>
>
> \ bit masks
> %000100 constant mSS  ( PB2 - pin 10 )
> %001000 constant mMOSI( PB3 - pin 11 )
> %01 constant mMISO( PB4 - pin 12 )
> %10 constant mSCK ( PB5 - pin 13 )
> $80 constant mSPIF
> $40 constant mWCOL
>
>
> : setBitmask ; ( bitmask port -- )
>
> : clrBitmask ; ( bitmask port -- )
>
> : testBitmask ; ( bitmask port -- flag )
>
> : spi.init ( -- )
>   mSCK ddrb setBitmask\ SCK as output
>   mSCK portb clrBitmask   \ clock idles low
>   mMOSI ddrb setBitmask   \ MOSI as output
>   mMISO ddrb clrBitmask   \ MISO as input
>   mMISO portb setBitmask  \ activate pull -up on MISO
>   mSS ddrb setBitmask \ SS as output
>   mSS portb setBitmask\ deselect
>   $51 spcr c! \ enable as master with 
> cpolarity 0, cphase 0, fosc /16
>   $00 spsr c! \ SPI2X =0 for fosc /16
>   spsr c@ drop spdr c@ drop   \ will clear SPIF
> ;
>
> : spi.wait ( -- )
>   begin mSPIF spsr testBitmask until 
> ;
>
>


your line
>  mSCK ddrb setBitmask   \ SCK as output

expands to
>  $20  $24  setBitmask

so your question is: what is "setBitmask" supposed to be? At first
sight you might want to set

> : setBitmask ( mask addr -- ) c! ;  \ no good!

But that would not work well. Setting exaktly 1 bit in 1 register
would work, but setting the second bit in the same register would
overwrite the first set bit. So what would help? Well we need to
1. read the actual content of the register
2. fiddle with the wanted bit
3. write the new content back to the register

> : setBitmask ( mask addr -- )
> \ mask addr
>   dup   \ mask addr addr
>   c@\ mask addr content   1.
>   rot   \ addr content mask
>   or\ addr new_content2.
>   swap  \ new_content addr
>   c!\ 3.
> ;

likewise for

> : clearBitmask ( mask addr -- )
> \ mask addr
>   dup   \ mask addr addr
>   c@\ mask addr content   1.
>   rot   \ addr content mask
>   invert\ addr content !mask
>   and   \ addr new_content2.
>   swap  \ new_content addr
>   c!\ 3.
> ;

UNTESTED CODE!

Now, the pattern "read modify write" and "content mask or" and
"content mask invert and" are needed very often. So this is, what
the bitnames library abstracts away for us.

If you look into "amforth/trunk/avr8/lib/bitnames.frt" you find

> \ Turn a port pin on, dont change the others.
> : high ( pinmask portadr -- )
> dup  ( -- pinmask portadr portadr )
> c@   ( -- pinmask portadr value )
> rot  ( -- portadr value pinmask )
> or   ( -- portadr new-value)
> swap ( -- new-value portadr)
> c!
> ;
> 
> \ Turn a port pin off, dont change the others.
> : low ( pinmask portadr -- )
> dup  ( -- pinmask portadr portadr )
> c@   ( -- pinmask portadr value )
> rot  ( -- portadr value pinmask )
> invert and ( -- portadr new-value)
> swap ( -- new-value port)
> c!
> ;

which look suspiciously similar to what I wrote above. The difference
is that this code is tested!

So

> : setBitmask ( mask addr -- ) high ;
> : clearBitmask ( mask addr -- ) low ;

should work in my opinion.


Now, there is one more thing that "bitnames.frt" can do for you.
Instead of writing

> $24 constant ddrb
> %10 constant mSCK ( PB5 - pin 13 )
> ...
> mSCK ddrb setBitmask  \ SCK as output

you could write instead

> #include bitnames.frt
> $25 constant portb
>
> portb 5 portpin: mSCK
> ...
> mSCK high

Now what happens is this:

This line
> portb 5 portpin: mSCK

defines a new word "mSCK". When you call this word it will
place two items on the stack:
1. the bitmask corresponding to 5, namely %0010_
2. the address of the portb register, namely $24   (top of stack)

This is exactly what the functions "high" or "low" expect. They will
do the "read modify write" thing for you and all there is left to
write is this:

> mSCK high

isn't this wonderfully short and easy to read? Well, maybe not
at first sight.

So looking at my own spi start code from way back:


> \ 2010-05-24  EW   ewlib/spi.fs
> \ spi, using hw inte

Re: [Amforth] how to use bitmask:

[Erich Wälde]

Hello Jan,

> I need to do a  bitmask on register.
>
> These are the constants, and mask
>
> $24 constant ddrb
> $25 constant portb
>
> \ bit masks
> %000100 constant mSS ( PB2 )
> %10 constant mSCK ( PB5 )
>
> I wont 
> 1. to set the bits in ddrb with the bitmask mSS
> 2. to clear bits in portb with the bitmask mSCK
>
> In bitnames.frt there is a word bitmask: How can I use it to do
> the two actions above?
>
> This is mor as a learning to understand working with bitmask.
>
> Thanks for any help.

There are only 4 lines of text in amforth/trunk/avr8/lib/bitnames.frt

> \ multi bit operation
> \ PORTD F bitmask: PD.F  ( define the lower nibble of port d )
> \ PD.F pin@  ( get the lower nibble bits )
> \ 5 PD.F pin!( put the lower nibble bits, do not change the 
> others )


There is a functional example on this page
http://amforth.sourceforge.net/Projects/ClockWorks/08_timezones.html

see "Code Details" and therein "Pins to select timezone"

Well, in the end there are only 3 important lines:


#include bitnames.frt
\ define bits 0 and 1 of PORTA as a bitmask named _tz
PORTA $03 bitmask: _tz

\ set the pins as "input"
_tz pin_input


\ read the pins --- they are conncted to pullup resistors
\ through switches
_tz pin@

the result is either 0 1 2 or 3 in this particular case,
depending on which of the two bits read as "1".

Hope this helps,
Erich



-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Need some help with the SPI

[Erich Wälde]

Dear Jan,

allow me to observe the following things:

> // enable SPI.Master
>   SPI.setDataMode(SPI_MODE0);
>   SPI.setBitOrder(MSBFIRST);
>   SPI.setClockDivider(SPI_CLOCK_DIV4);
>   SPI.begin();

The words and the concepts behind them are documented in great
detail in the datasheet of your controller. You mentioned
"arduino" at the beginning of this thread, so I *guess*
you are using a "atmega328p" controller.

> http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf

yes I know, this is a big thing with >600 pages. And no, noone
expects you (or anyone else) to learn all of this by heart.
However, I do expect you to read the relevant sections.

The table of contents will suggest you look at chapter 19. SPI
--- Serial Peripheral Interface.

SPI is a piece of hardware, which will do the clocking and byte
transfers for you, no need to bit bang (i.e. setting pins high
and low) it yourself. The price for this nicety is that you need
to configure it properly.

- is the first bit in transfer the *most* or *least* significant
  bit?
- is the data valid at rising of falling edges of the clock?
  (19.4 Data Modes)
- which speed should the interface be clocked with?
- is a transfer currently ongoing or can I write the next Byte
  to register SPDR
and so on.

I can give you my routines, but I guess you will be unable to
use them if you do not understand these details, I'm afraid.


So any spi transfer goes through these steps:

setup bitorder, data mode, speed, maybe more (once)
turn the spi module on (once or before every tx session)

for every byte to transfer
- fetch the next byte from a meaningful place
- write the next byte to SPDR
- wait until tx has completed
- read the answer byte from SPDR (yes the same register!)
- store the answer byte in a meaningful place
repeat until no bytes are left to transmit.

c!@spi will do one transfer: it sends the lower byte of the top
of stack element to spi and places the result byte on the stack
afterwards. It handles the body of the loop outlined above.

!@spi will transfer 2 bytes == 1 word instead.

it is "!" store "@" fetch spi, every transmit ("!") will provide
an answer ("@").

That is why you want "!@spi" and "c!@spi" compiled into your
AmForth.

The example at
> http://amforth.sourceforge.net/TG/recipes/SPI.html
might be a bit terse, however, it does point you to

trunk/avr8/lib/hardware/spi.frt
which defines words and constants for all the details.

trunk/avr8/lib/hardware/mmc.frt and
trunk/common/lib/hardware/mmc-test.frt
create an elaborate example, how to use the spi interface.


As others have said: the datasheet is your friend, and once you
understand, how to configure a certain piece of the controller
for your project, setting the appropriate bits in its Control
Register are not a big deal any more. The big deal is to find
out, which bits to set. The C libraries do all of this for you,
but you need to read the source and the datasheet to understand,
why it is working. Once you understand this for SPI you will
find that all the other parts of the controller are operated
similarly: there is one or a few control registers, a set of
data registers, a few flag bits here and there, and possibly a
connection to one or few interrupts, to make all of this work.


Also, the amforth source is full of examples and use cases. If
you are on Linux, grep and find are your friends to find
relevant places. If you are on MacOS or Windows, there are other
tools to search file names or content, I'm sure.


So, don't give up too soon. We have all been through this stage.

Cheers,
Erich


>
> What to do with
>
> \ check SPI device datasheet for mode settings
> : spi.setmode ( spi-mode -- )
>  spi.mode pin!
> ;
>
> With kindly regards,
>
> Jan
>
>
>
>
>
> Op 8 jun. 2019, om 20:45 heeft Matthias Trute 
> mailto:mtr...@web.de>> het volgende geschreven:
>
> Hi,
>
> You can also use the following words to avoid c!@spi, which is
> missing from the preassembled package for the Arduino:
>
>
> \ send a byte, ignore received byte
> : c!spi ( c -- )
>SPDR c! ( c addr -- )
> ;
>
>  \ receive a byte, send a dummy one
> : c@spi ( -- c)
>0 SPDR c! 1 ms SPDR c@
> ;
>
> SPDR is a constant holding the address of the SPI data register (&78)
>
> Thanks, I've added some comments to the spi.frt file.
>
> Matthias
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


--
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lis

Re: [Amforth] Need some help with the SPI

[Erich Wälde]

Hello Jan,

Jan Kromhout via Amforth-devel writes:

> Hello Tristan,Erich
>
> This is far over my knowledge, but will give it a try.
>
> But when I try to load the spi.frt I get an error here
>
> |C|   97|\ send a byte, ignore recieved byte
> |S|   98|: c!spi ( c -- )
> |S|   99|c!@spi drop
> |E=3D ?? -13 6

In avr8/words you will find 3 files:
> 2spirw.asm  n-spi.asm  spirw.asm
which in turn will define 4 words:
> !@spi  n@spi n!spi  c!@spi
all of these come to life if you include their .asm files and
reassemble.

Rebuilding your project: yes, it might look intimidating the
first time. However, think about the gains:

- you can chose another board with a different controller

- you can change the clock crystal to another frequency, e.g. I
  strongly prefer baud rate crystals, e.g. 11059200 Hz.

- you can change the baud rate of the serial interface (within
  limits).

- you can extend your AmForth system with a large number or words
  to fit your project.

- you are not locked to use somehow prebuild .hex files

The sky is the limit! So: Don't give up too soon, please!

This might help if you are linux based:
http://amforth.sourceforge.net/UG/linux.html
A very long time ago I wrote this:
http://amforth.sourceforge.net/pr/Fosdem2011-proceedings-amforth.pdf

If you are Windows based, have a look at=20
http://amforth.sourceforge.net/UG/windows.html

Cheers,
Erich

>
> Is this also a assembler word?
>
> Kindly regards,
>
> Jan
>
>
>
>
>> Op 7 jun. 2019, om 19:50 heeft Erich Wälde  het 
>> volgende geschreven:
>> 
>> Hello Jan,
>> 
>> 
>> Jan Kromhout writes:
>> 
>>> Hi Tristan,
>>> 
>>> What to load in the right sequence to fellow the examples in 
>>> http://amforth.sourceforge.net/TG/recipes/SPI.html ?
>>> If I have the right sequence of loading the screens I will start as you 
>>> mentiod.
>>> 
>>> Kind regards,
>>> 
>>> Jan
>>> 
>>> 
>>> 
>>> Op 7 jun. 2019, om 19:25 heeft Tristan Williams 
>>> mailto:h...@tjnw.co.uk>> het volgende geschreven:
>>> 
>>> Hi Jan,
>>> 
>>> No don’t have. Why?
>>> 
>>> Because words/spirw.asm provides c!@spi which makes using the
>>> hardware spi easier, and it is used in the recipes
>> 
>> you see the filename? "words/spirw.asm"? Please note: .asm
>> suffix. This means that in your project directory, you need to
>> add one line to the file "dict_appl.inc". Then you need to
>> reassemble the project and load the resulting .hex files to your
>> controller. I strongly recommend learning this workflow, if you
>> didn't already.
>> 
>> Cheers,
>> Erich
>> 
>> 
>>> 
>>> http://amforth.sourceforge.net/TG/recipes/SPI.html
>>> 
>>> Separately, if you haven't read it already
>>> 
>>> https://en.wikipedia.org/wiki/Serial_Peripheral_Interface
>>> 
>>> will help a lot, as will starting with a simple SPI device (e.g. io
>>> expander, digital potentiometer) first.
>>> 
>>> Kind regards,
>>> 
>>> Tristan
>>> 
>>> 
>>> Verstuurd vanaf mijn iPad
>>> 
>>> Op 7 jun. 2019 om 17:25 heeft Tristan Williams 
>>> mailto:h...@tjnw.co.uk>> het volgende geschreven:
>>> 
>>> Hello Jan,
>>> 
>>> A quick question first.
>>> 
>>> You have built your AmForth hex files with words/spirw.asm ?
>>> 
>>> Kind regards,
>>> 
>>> Tristan
>>> 
>>> On 07Jun19 17:06, Jan Kromhout via Amforth-devel wrote:
>>> Hello
>>> 
>>> I have take a close look into SPI routines.
>>> I really not understand them.
>>> 
>>> I need simple make a connection withe the arduino in amForth.
>>> The basics I understand how to make a pin high or low etc.
>>> But I don’t know how to start to initialize the SPI etc.
>>> Can someone help me with this or give a simple example?
>>> The interface is using the standard pins for the SPI.
>>> 
>>> I mark the part of the code with <===? where I have trouble to 
>>> convert to amForth.
>>> 
>>> Thanks for any help.
>>> 
>>> Cheers,
>>> 
>>> Jan
>>> 
>>> 
>>> #include "SPI.h"
>>> 
>>> #define SCK_PIN   13
>>> #define MISO_PIN  12
>>> #define MOSI_PIN  11
>>> #define SS_PIN10
>>> 
>>> void umFPU_begin(void)
>

Re: [Amforth] Need some help with the SPI

[Erich Wälde]

Hello Jan,


Jan Kromhout writes:

> Hi Tristan,
>
> What to load in the right sequence to fellow the examples in 
> http://amforth.sourceforge.net/TG/recipes/SPI.html ?
> If I have the right sequence of loading the screens I will start as you 
> mentiod.
>
> Kind regards,
>
> Jan
>
>
>
> Op 7 jun. 2019, om 19:25 heeft Tristan Williams 
> mailto:h...@tjnw.co.uk>> het volgende geschreven:
>
> Hi Jan,
>
> No don’t have. Why?
>
> Because words/spirw.asm provides c!@spi which makes using the
> hardware spi easier, and it is used in the recipes

you see the filename? "words/spirw.asm"? Please note: .asm
suffix. This means that in your project directory, you need to
add one line to the file "dict_appl.inc". Then you need to
reassemble the project and load the resulting .hex files to your
controller. I strongly recommend learning this workflow, if you
didn't already.

Cheers,
Erich


>
> http://amforth.sourceforge.net/TG/recipes/SPI.html
>
> Separately, if you haven't read it already
>
> https://en.wikipedia.org/wiki/Serial_Peripheral_Interface
>
> will help a lot, as will starting with a simple SPI device (e.g. io
> expander, digital potentiometer) first.
>
> Kind regards,
>
> Tristan
>
>
> Verstuurd vanaf mijn iPad
>
> Op 7 jun. 2019 om 17:25 heeft Tristan Williams 
> mailto:h...@tjnw.co.uk>> het volgende geschreven:
>
> Hello Jan,
>
> A quick question first.
>
> You have built your AmForth hex files with words/spirw.asm ?
>
> Kind regards,
>
> Tristan
>
> On 07Jun19 17:06, Jan Kromhout via Amforth-devel wrote:
> Hello
>
> I have take a close look into SPI routines.
> I really not understand them.
>
> I need simple make a connection withe the arduino in amForth.
> The basics I understand how to make a pin high or low etc.
> But I don’t know how to start to initialize the SPI etc.
> Can someone help me with this or give a simple example?
> The interface is using the standard pins for the SPI.
>
> I mark the part of the code with <===? where I have trouble to 
> convert to amForth.
>
> Thanks for any help.
>
> Cheers,
>
> Jan
>
>
> #include "SPI.h"
>
> #define SCK_PIN   13
> #define MISO_PIN  12
> #define MOSI_PIN  11
> #define SS_PIN10
>
> void umFPU_begin(void)
> {
>   digitalWrite(SS_PIN, HIGH);
>   pinMode(SS_PIN, OUTPUT);
>   umFPU_reset();
> }
>
> //--- reset -
>
> void umFPU_reset()
> {
> digitalWrite(SS_PIN, LOW);
>
> // disable SPI.Master
> SPI.end();   <===?
>
> // reset the FPU
> digitalWrite(MOSI_PIN, HIGH);
> for (byte i = 0; i < 80; i++)
> {
>   digitalWrite(SCK_PIN, HIGH);
>   digitalWrite(SCK_PIN, LOW);
> }
> digitalWrite(MOSI_PIN, LOW);
>
> delay(10);
>
> // enable SPI.Master
> SPI.setDataMode(SPI_MODE0);
> SPI.setBitOrder(MSBFIRST);
> SPI.setClockDivider(SPI_CLOCK_DIV4);
> SPI.begin();  <===?
>
> digitalWrite(SS_PIN, HIGH);
> }
>
> byte umFPU_read(void)
> {
> byte bval;
> digitalWrite(SS_PIN, LOW);
> umFPU_readDelay();
> bval = SPI.transfer(0); <===?
> digitalWrite(SS_PIN, HIGH);
> return bval;
> }
>
> void umFPU_write_1(byte b1)
> {
> digitalWrite(SS_PIN, LOW);
> SPI.transfer(b1);  <===?
> digitalWrite(SS_PIN, HIGH);
> }
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Turnkey

[Erich Wälde]

Hello Jan,

Jan Kromhout writes:

> I have create a turnkey project, how can I remove the turnkey
> so it will not start at start-up? 

:-)

Well, let's see. How did you "register" the turnkey application?

forth> ' my-turnkey to turnkey

maybe with "is" instead of "to". So the question reduces to:
What is the number that was in the deferred word before? You
could have checked with

forth> turnkey defer@ .

but probably you didn't. Well, we all have been there :-)

Fortunately it is not difficult to find the default. It resides
in words/applturnkey.asm in your project (cloned from
appl/template) and is called "applturnkey". So

forth> ' applturnkey to turnkey

should get you there.

Hope this helps.

Cheers,
Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Error in example multitasking at amforth.sourceforge.net

[Erich Wälde]

Hello Jan,

the example was done in some version of AmForth.
Later Matthias has changed the name from tid to tcb (task
control block, probably).

So, yes your observation is correct, and you found the correct
solution!

Cheers,
Erich

Jan Kromhout via Amforth-devel writes:

> Hello,
>
> When I look to the example of multitasking I think something is wrong. This 
> is the code at amforth.sourceforge.net :
>
> : starttasker
>   task_demo task-init
>   \ create TCB in RAM
>   start-demo
>   \ activate tasks job
>   onlytask
>   task_demo tcb>tid alsotask
>   multi
> ;
>
> I think this is the right one
>
> : starttasker
>   task_demo task-init
>   \ create TCB in RAM
>   start-demo
>   \ activate tasks job
>   onlytask
>   task_demo tib>tcb alsotask  \ <===
>   multi
> ;
>
>
> Cheers
> Jan
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] double-precision number to string conversion

[Erich Wälde]

Hello Fred,


f.zelders--- via Amforth-devel writes:

> I created a word that converts a positive double-precision number to an 8 
> character string like this:
>
> : dpNumberToString ( d -- address count )
>   <# # # # # # # # # #> ; 
> This works fine for positive numbers.
> However I want to convert negative double-precision numbers too.
>
> Any idea how I can make that work?

Check out the definitions of "d." "d.r".

common/words/d-dot.asm
common/words/d-dot-r.asm

At the end of these files there is equivalent forth code.

Also be sure to check out Leo Brodie's "Starting Forth", chapter
7 on numbers:
http://home.iae.nl/users/mhx/sf.html


Cheers,
Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Soft Serial Port

[Erich Wälde]

Hello,


Peter C. Hauser writes:
> If you want hardware serial you cannot really use the Arduino
> Uno as the ATmega328 microcontroller only has one UART, which
> is used by Forth for its communication.

atmega644p has 2 serial interfaces. It is the same package as
the 328p. I have toyed around with two serial interfaces, but
with not much success. That was a problem of how to utilize this
second uart, more than anything else. I'm sure, it can work.

Cheers,
Erich


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Error

[Erich Wälde]

Hello Jan,

> Where can I find some description of the used error numbers?
>
> I have now -4

read the fine document at
http://amforth.sourceforge.net/TG/Architecture.html#exceptions

:-)
Erich

-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Doc: Clockworks Model 4

[Erich Wälde]

Hello,



for those who like to read other peoples Forth code, I have added
another clock to the commented projects/clockworks. It features a DCF77
radio receiver and reads the time information from there. However, this
code is lengthy.

http://amforth.sourceforge.net/Projects/ClockWorks/index.html#ingredients-and-clocks
Model 4

Errors, corrections and suggestions are welcome!
Thanks to Matthias for hosting these documents.

Cheers,
Erich





-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Assembler listing of some words

[Erich Wälde]

Hello Jan,

Jan Kromhout via Amforth-devel writes:

> Hello,
>
> I was looking into some words (.asm).
> Can someone explain me why the content of the first data word is different.
> PLUSSTORE => .dw $ff02
> RSHIFT => .dw $ff06
> PLUS => .dw $ff01

I'm sure this is explained somewhere, maybe in the technical guide. But
I did not find it in 20 seconds, so here we go:


> $ cat ./avr8/words/plusstore.asm
> VE_PLUSSTORE:
> .dw $ff02
> .db "+!"
> .dw VE_HEAD
> ...

The first .dw entry is "some number", where the low part "02" is the length
of the string to come. That string is "+!", 2 bytes.

The high part "ff" is a flags thing. "immediate" words are different:

> $ cat ./common/words/then.asm
> ...
> VE_THEN:
> .dw $0004
> .db "then"
> ...

There might be other values, but I'm not sure.

This stuff is implementation dependant and may be all different in other
Forth implementations.



Cheers,
Erich

--
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] get-recognizer & set-recognizer

[Erich Wälde]

Hello Jan,


> Found the missing words!!
Cool.

> The package is now loading complete.
> But it is not working.
> When  input a float or a double the system is crashing.
not cool.
>
> Has someone some experience with this package?
Not me. But see below.


> I have read there is also a FP package in assembler, where could I
> find that?
There is another repository with "community contributed" files.
On the amforth homepage
http://amforth.sourceforge.net/

Click on "Community" (the first entry in the title area), this will
point you to
https://sourceforge.net/p/amforth/community/HEAD/tree/

where you find a subdirectory  "floatingpoint"

This is old and possibly outdated material, so do not despair.


---

I would like to make you aware, that floating point calculations can
often be replaced by "scaled integer" operations.

Examples:

1. handle a Temperature in 1/10 or 1/100 degrees

Say a thermometer sensor is providing readings with 1/10 degree
resolution. That means, a reading of 245 really means 24.5 C.
Then there is no need to convert this to floating point, because you can
create a function to "print" the value with 1 digit behind the decimal
point.

> > ver
> amforth 6.6 ATmega644P ok
> > : .f1  <# # [char] . hold #s #> type ;
>  ok
> > 245 s>d .f1
> 24.5 ok

(I had to remember that <# ... #> formatting handles double values :-)



2. to handle calculations in scaled integer, the programmer decides, how
many bits of a given value are considered to be the fractional part. For
a complex example look here:
https://sourceforge.net/p/amforth/community/HEAD/tree/ewlib/sht75.fs

The word sht.H.raw>lin converts the sensor reading from its raw value to
the "linear" value by applying a correction.

\ H_25 [%] = c1 + c2*Hraw + c3*Hraw^2
\ 12bit:c1=-4 c2=0.0405  c3=-2.8e-6

I have scaled the calculation by 10^7 and thus eliminated the need to
work with floating point.


I'm not saying you must always use scaled integer. I'm just saying: if
you don't know this technique, check it out, and maybe it fits your
needs.

See
Leo Brodie -- Starting Forth:
http://home.iae.nl/users/mhx/sf.html
Chapter 7.



Cheers,
Erich




>
> Cheers,
>
> Jan
>
>
>> Op 21 dec. 2018, om 10:55 heeft Jan Kromhout  het 
>> volgende geschreven:
>>
>> Hello,
>>
>> Try to load the Floating point package.
>> How do, or find I the words get-recognizer and set-recognizer?
>>
>> What is the meaning of the word "place-rec" and what is the input?
>>
>> Thanks for any help.
>>
>> Cheers
>>
>> Jan
>>
>>
>> |S|  930|: place-rec ( xt -- )
>> |S|  931|  get-recognizer
>> |E= ?? -13 14
>>  /Users/jankromhout/Documents/amforth-6.7/tools
>> Error: Error in line sent
>>
>>
>>
>> : place-rec ( xt -- )
>>  get-recognizer
>>  dup >r
>>  1-  n>r
>>  swap
>>  nr> drop r> 1+
>>  set-recognizer
>> ;
>>
>> ___
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amforth-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


--
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Floating point

[Erich Wälde]

Hello Jan,

>
> Found the float.fth file. 
> After loading the neccesary files tried to compile the filed
>
> Two things are missing and can’t find them in the AmFort-6.7 directory.
> 1. What is the definition of d>s
That was answered before:

: d>s drop ;

@martin: just adding a 0 to TOS on "s>d" will not get signedness right.


> 2: Could not found these asm files.
>   ; needed for recognizer
>   .include "words/get-recognizer.asm"
>   .include "words/set-recognizer.asm"
>
>  Please can someone help me out with this?

ew@metis:..orth/amforth/trunk 3 > grep -rl 'get-recognizer' .
./common/lib/recognizer.frt
./common/lib/dot-recs.frt
...

ew@metis:..orth/amforth/trunk 5 > cat common/lib/recognizer.frt 
\ common recognizer words
\
\ platform specific code, selected via include directory
\ #include recognizer-arch.frt
\
\ build the methods table for a recognizer
: rectype: ( interpret-xt compile-xt postpone-xt "name" -- )
   create swap rot , , , 
;

\ get and set the stack content
: set-recognizers forth-recognizer set-stack ;
: get-recognizers forth-recognizer get-stack ;

\ usage see Recognizer Recipes


---
So, you need to load common/lib/recognizer.frt

*.frt* not .asm

*load* the .frt file into your running amforth (using amforth-upload or
-shell).



Where is your fragment from? This looks like a leftover from before
"going back to .frt" :-)

Cheers,
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Flashing AmForth to Arduino Leonardo

[Erich Wälde]

Hello Jan,

Jan Kromhout writes:

> Hi,
>
> Flashing the Arduino Uno is giving no problems.
>
> Try to flash the Leonardo.
> I’m using the Pololu AVR programmer v2.1
> This is my command.
>
> MacBook-Pro-van-Jan-10:avrdude jankromhout$ avrdude -p m32u4 -c avrispv2 -P 
> /dev/tty.usbmodem00230362 -U efuse:w:0xFF:m -U hfuse:w:0xD9:m -U 
> lfuse:w:0xFF:m -U flash:w:leonardo.hex:i -U eeprom:w:leonardo.eep.hex:i
>
> It isn’t working
> Can someone help me with this problem.

looking into old files of mine ... 2013-05-01

I have not succeeded with a leonardo either. Attaching did create a
serial interface (/dev/ttyACM0), however, after erasing leonardo's
flash, this disappeared. So maybe usb connection is not through a FTDI
chip? THIS is a highly questionable idea, be warned. But might be worth
to check the schematics.

https://www.arduino.cc/en/Main/Arduino_BoardLeonardo
https://www.arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf

There is no FTDI, as far as I can see, however, how erasing the
atmega32u4 flash results in not responding to the ISP programmer, is not
obvious to me. I succeeded in erasing once. Nothing after that.


Please note that the _atmega_32_u4_ is a quite different beast from the
atmega_328p. So fuse settings would be another candidate to check.

I didn't find my leonardo just now ... so I can't play with it.


Cheers,
Erich


--
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] d>s in amforth (double number > single number)

[Erich Wälde]

Hello Fred,


> The word s>d is in the common/words/ folder but d>s ins't :-(

: d>s ( d -- s ) drop ;

Assuming that the high number (2 Bytes) resides on top-of-stack, the low
number below that.

Cheers,
Erich

>
>
> Groet!
>
>
> Fred
>
>
>> Op 11 dec. 2018, om 13:24 heeft Matthias Trute  het volgende 
>> geschreven:
>> 
>> Am Dienstag, den 11.12.2018, 13:02 +0100 schrieb f.zelders--- via
>> Amforth-devel:
>>> In gforth the word d>s (It couverts a signed double drecision number
>>> to a signed single precision number) is part of the default word set.
>>> This word is not available in the default amforth word set.
>> 
>> d>s is simple: DROP since the higher cell shall be 0 for this, you
>> may want to make sure and throw an exception otherwise, a task
>> that I happily leave to the reader ;)
>> 
>>> 
>>> Can't find a amforth word definition of s>d. 😞
>> 
>> It's in the file common/words/s_to_d.asm. The definition
>> itself is short, but somewhat surprising
>> 
>> : s>d dup 0< ;
>> 
>> Matthias
>> 
>> 
>> 
>> ___
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amforth-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] My first I2C connection with amForth

[Erich Wälde]

Hello Jan,

you were faster than I could think of your problem.
Yes, /everything/ needs to be initialized on reset.
And yes, very strange things can happen, if you
miss one little thing.

Glad you found it!
Erich

Jan Kromhout writes:

> Hi,
>
> Also find the problem.
> In my program I use buffers: to create an array. Never thought that these 
> will be cleared at a reset, and also the variables
> used in my program .
> After make an init and start this after a reset my application is working as 
> it should.
>
> Cheers,
>
> Jan
>
>
>
>> Op 12 nov. 2018, om 19:30 heeft Jan Kromhout  het 
>> volgende geschreven:
>> 
>> Hi,
>> 
>> After a few days of trial and error, I finally managed to control the 
>> 12c-LCD mine.
>> A stupid interpretation caused the delay, eventually solved.
>> My tests are running well.
>> 
>> But now it comes. When I give a reset of the Arduino and afterwards I want 
>> to write a value to the LCD then it simply does not work.
>> After reset I init the I2C again. When I check with $38 i2c.ping? I get back 
>> the true (-1) value. The i2c.status is $f8, but I can’f fint the
>> meaning of this value.
>> 
>> When I check the I2C bus with logic analyser no activity.
>> 
>> Only when I re-load the application it does run again.
>> 
>> 
>> Any idea what that could cause?
>> 
>> Cheers,
>> 
>> Jan
>> 
>> 
>> 
>> ___
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amforth-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] I2C Generic

[Erich Wälde]

Hello Jan,

> The i2c scanner is seeing $38, should i still shift to $70?
Don't be afraid of just trying this. There is nothing that
breaks, if you happen to use a different i2c address.

So I dont' think so, but let me check

> | $ ls -l /dev/ttyUSB0 
> | crw-rw 1 root dialout 188, 0 2018-11-10 18:33 /dev/ttyUSB0
> | $ minicom -wo -b 115200 -D /dev/ttyUSB0
> |  ok
> | > +i2c
> |  ok
> | > hex i2c.scan
> |  50
> |  ok
> | > i2c_addr_rtc .
> | 50  ok
> | > i2c.detect
> |   0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
> |  0:   -- -- -- -- -- -- -- -- --
> | 10:  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> | 20:  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> | 30:  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> | 40:  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> | 50:  50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> | 60:  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> | 70:  -- -- -- -- -- -- -- --
> |  ok

In that case the address is good. At least as long as you
use your-amforth/trunk/common/lib/hardware/i2c.frt and its
includes.

Dealing with unresponsive hardware is always a little
challenging, because you don't /see/ anything for a long time.
A few ideas:
- does the hw work with another program? (then the hw is good)
- can you successfully talk to another component on the i2c?
- can you add an LED to SCL and SDA and see, whether both are
  blinking when accessing the bus? Kind of poor mans
  oscilloscope ...
- did you check that the TWI unit is initialized correctly?
- did you try a different bus speed, eg. 100 kHz instead of 400?
- does your code read the ACKs on the bus correctly (yes, if you
  use the above mentioned libs)
- none of the above ...

Things like that. Don't despair! And don't panic either :-)

It took me something like a month to get a 434 MHz radio link to
work. Mainly because i didn't /see/ anything! In the end a 20 Eu
TV USB dongle and gnuradio made me see the signal.


Cheers,
Erich




___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Clock Works

[Erich Wälde]

Hello Jan,

> Where can I download the software of the articles of Clock Works.
> The link https://wiki.forth-ev.de/doku.php/projects:clockworks ...

Thanks for reminding me, that there is a broken link in the
game. This one is better:

https://wiki.forth-ev.de/doku.php/projects:clockworks:clockworks

Note the additional ":clockworks"

But at the end it /should/ point to

http://amforth.sourceforge.net/Projects/ClockWorks/index.html

anyway. This is where the complete source code ist available.

So I need to fix the page on wiki.forth-ev.de a little.



Cheers,
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] I2C Generic

[Erich Wälde]

Hello Jan,

your i2c address: "$38", is this the 7bit address? You might
need to shift it by one position to "$70".

Just an idea.
Cheers,
Erich

Jan Kromhout writes:

> Hi,
>
> This is my first step on the I2C road.
> I have a Gravitech shield for the Arduino, that work well.
> The code is very simple, and I have translate it to Forth.
> The display is not working.
> I include the Forth code. What is wrong?
> Thangs for any help.
>
> Cheers,
>
> Jan
>
> \ Gravitech display, I2C Generic
>
> marker --gravitech--
>
> $38 constant 7SEG  \ I2C address for 7-Segment
>
> / Configure 7-Segment to 12mA segment output current, Dynamic mode,
> / and Digits 1, 2, 3 AND 4 are NOT blanked
>
> : init7SEG
>   7SEG i2c.begin
> 0 7SEG i2c.c!
> %01000111 7SEG i2c.c!
>   i2c.end
> ;
>
> : Send7SEG  ( Digit Number )
>   7SEG i2c.begin
> swap 7SEG i2c.c! \ Digit
> 7SEG i2c.c!  \ Number
>   i2c.end
> ;
>
>
> /* Configure 7-Segment to 12mA segment output current, Dynamic mode,
>  and Digits 1, 2, 3 AND 4 are NOT blanked */
>
>   Wire.beginTransmission(_7SEG);
>   Wire.write(0);
>   Wire.write(B01000111);
>   Wire.endTransmission();
>
>
> /***
>  Function Name: Send7SEG
>
>  Purpose:
>Send I2C commands to drive 7-segment display.
> /
>
> void Send7SEG (byte Digit, byte Number)
> {
>   Wire.beginTransmission(_7SEG);
>   Wire.write(Digit);
>   Wire.write(Number);
>   Wire.endTransmission();
> }
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Need some help

[Erich Wälde]

Hello Jan,

Jan Kromhout writes:

> Hi,
>
> I have this simple Arduino program thats put a PWM signal to port 9 of the 
> Arduino.
> Checked with my RIGOL and the PWM is changed when I change the value of ppm.
>
> #define PWM_A  9 /* Pin-9 on Arduino Board */
>
> void setup() {
>   Serial.begin(115200);
>
>   int pwm = 200;  /* duty 50% */
>   pinMode(PWM_A,  OUTPUT);
>   /* PWM speed is at 20 kHz  */
>   /*Set the timers   */
>   TCCR1A = 0b1010;
>   TCCR1B = 0b00010001;
>   ICR1 = 400;
>
>   /* value of 400 = 100 % ppm */
>
>   OCR1A = pwm;
> }
>
> void loop() {
> }
>
>
> Convert it to amForth.
>
> \ Address of Timer/Counter Arduino UNO
> \ Adresses are taken from device.py
> \ Partname ATmega328P
>
> $80 constant TCCR1A \ Timer/Counter1 Control Register A
> $81 constant TCCR1B \ Timer/Counter1 Control Register B
> $86 constant ICR1   \ Timer/Counter1 Input Capture Register
> $88 constant OCR1A  \ Timer/Counter1 Output Compare Register A
> $8a constant OCR1B  \ Timer/Counter1 Output Compare Register B
>
> PORTB 1 portpin: PWM_A \ alias for digital pin 9 (PB1)
>
> : PWM_init
>   PWM_A pin_output   \ Set pin 9 (PB1) to output
>   %1010 TCCR1A c!\ Store constant
>   %00010001 TCCR1B c!\ Store constant
>   &400 OCR1A c!   \ Store constant
> ;

400 is larger than 255, so "c!" will not do, what you think.

I have this snippet in my code (check amforth commented projects
clockworks) for your inspiration.

\ enable ticks
\ crystal:   11059200 /sec
\ prescaler: 256
\43200 /sec
\ TOP+1: 1350
\32 /sec
: +ticks
  0 ct.ticks!
  0 ct.ticks.follow !
  0 last.tick[4]!
  0 last.tick[5]!

  \ --- timer1 ! ---
  [ % \ WGM1[10] CTC mode
%0100 or  \ COM1A[10] toggle OC1A on compare match
  ] literal TCCR1A c!
  #1350 1-  OCR1A   ! \ TOP or compare match value rather
  DDRD c@ $80 or DDRD c!  \ pin OC2A output  
  [ %0100 \ CS1[210] clock_ts2/256
%1000 or  \ WGM1[32] CTC mode
  ] literal TCCR1B c! 
  \ register isr
  ['] tick_isr TIMER1_COMPAAddr int! 
  TIMSK1 c@ $02 or TIMSK1 c!  \ enable OCIE1A interupt
;

Cheers, Erich



>
> : PWM_set  ( value -- )  \ PWM is between 0..400
>   OCR1A c!   \ Store into OCR1A
> ;
>
>
>> PWM_init
>> 200 PWM_set
>
>
>
> It will not work. What do I wrong.
> Thanks for any help
>
> Cheers,
>
> Jan
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] amforth becomes stuck in loop(?) after first word definition (328p)

[Erich Wälde]

Hello Dimitri,

> It's always nice to introduce oneself together with a silly
> problem.
We would not have known about you without that :-)
Welcome to the club!

And happy Forthing,
Erich


-- 
May the Forth be with you ...

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] "multi", "multitaskpause" hang system

[Erich Wälde]

Hello Frank,

welcome on the list!

Eye ball inspection and comparing to a project of mine and
mulittask-test.frt did not show a problem to me, however

instead of

> $20 $20 $10 task: task_demo

try

> $40 $40 $10 task: task_demo

just in bloody case. Allthough 16 cells sound like a lot, its
maybe a little short ... this is just guessing.


Good luck!
Erich

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] AmForth Projects (was: Building AMforth 6.5 under windows ...)

[Erich Wälde]

Hi Richard,

thanks for your message.

> I'm updating the earlier version of amforth I used to control a Si4133 PLL
> chip on a satellite tuner board. With a 2 line LCD it allows me to generate
> test signals from about 800MHz to 1600 MHz in steps as small as 10kHz. A
> very crude instrument but better than nothing.

Sounds interesting. DIY test equipment! Cool! At some point I
did generate a signal simply using a pin on a atmega32 --- and
yes, this is *much better* than having nothing. :-)


> My current challenge is to drive the ESP8266 with AT commands. I can do
> what I want from a terminal program on the PC so I know what the required
> commands are. Struggling to get amforth to talk over the serial port so
> maybe it's a dud micro.

Sounds like the beginnings of a journey into remote sensor
network stuff ... see below.

---

*1*

The german "Forth Gesellschaft e.V." runs a web page at
http://www.forth-ev.de/

While most of the content is in German, there are a number of
articles written in English in our quarterly publication "Vierte
Dimension". All issues are free for download at "Download" >
"Vierte Dimension" > "PDF Archive"
http://www.forth-ev.de/filemgmt/viewcat.php?cid=2

for example:

- 4d2016-01.pdf page 9
  "Use of Forth to enable Distributed Processing on Wireless
  Sensor Networks"
  by Salvatore Gaglio et al.
  This is a highly inspirational paper from people in Italy.

- 4d2014-01.pdf page 17
  "Arduino Controlled Digital FM Radio"
  by Craig Lindley

Maybe this helps. Needless to say: if you feel inclined to write
something yourself, we can help you getting it in shape.


*2*

Along the same lines: there is a section called "Commented
Projects" on the AmForth webpage:
http://amforth.sourceforge.net/Projects/index.html

This is a good place to "publish" projects in English.


*3*

And then there is a relatively new site to publish working code.
The site attempts to provide a workable solution for any Forth,
even on any microcontroller.
http://theforth.net/


Hopefully this information is useful for all readers on the
list.


Hello readers: please show off your projects! Or at least
mention them on the list. I have learned a lot reading other
peoples code. I'm always curious and impressed about what others
do, and I know, Matthias Trute is too.



Cheers,
and happy forthing!

Erich

--
The purpose of computing is insight --- not numbers
R. Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Building AMforth 6.5 under windows - path errors

[Erich Wälde]

Hi Richard,

> I tried this twice for two projects and no errors in the assembly were
> noted. Once again thanks for putting me on the right track.

Congratulations! And thanks for reporting back on this.

I do know, that setting up stuff to play with microcontrollers,
can be a source of endless frustration, so I'm glad it is
working for you.

Just being nosy: what are you thinking of implementing? Be sure
to check out the "Cookbook" section of the website, it has lots
of puzzle pieces. Feel free to ask, if you need advice.

Cheers,
Erich

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Building AMforth 6.5 under windows - path errors

[Erich Wälde]

Hello Richard,

disclaimer: I do not use Windows myself ...

> I create a batch file, make.bat, containing the following line:
> avrasm2.exe -fI -o myproj.hex -e myproj.eep -l myproj.lst -I .\ -I
> amforth\common -I amforth\avr8 -I include  -v0 myproj.asm
>
> My project structure now looks like
> Directory of E:\amforth
>
> 21/07/2017  01:40 PM  .
> 21/07/2017  01:40 PM  ..
> 01/05/2017  02:09 AM  appl
> 21/07/2017  12:41 PM  Appnotes2
> 01/05/2017  02:13 AM  avr8
> 18/06/2012  09:47 PM   410,112 avrasm2.exe
> 01/05/2017  02:09 AM  common
> 26/07/2012  02:50 AM 2,233 device.asm
> 26/07/2012  02:50 AM15,724 device.inc
> 06/12/2014  02:56 AM   197 dict_appl.inc
> 19/05/2014  11:47 PM60 dict_appl_core.inc
> 01/05/2017  02:12 AM  doc
> 01/05/2017  02:09 AM  examples
> 29/10/2014  04:17 AM35,147 LICENSE.txt
> 21/07/2017  01:39 PM   124 make.bat
> 21/07/2017  01:15 PM   577 Myproj.asm
> 21/07/2017  01:40 PM 1,200 myproj.lst
> 27/06/2016  02:46 AM 1,944 readme.txt
> 01/05/2017  02:09 AM  tests
> 01/05/2017  02:12 AM  tools
> 19/05/2014  02:29 AM   361 uno.asm
> 21/07/2017  01:33 PM  words
>
> When I run make.bat from the command prompt I get:
> E:\amforth>make
>
> E:\amforth>avrasm2.exe -fI -o myproj.hex -e myproj.eep -l myproj.lst -I .\
> -I amforth\common -I amforth\avr8 -I include -v0 myproj.asm
> avr8\preamble.inc(2): error: Cannot find include file: macros.asm
> myproj.asm(16): error: Cannot find include file: words\usart_0.asm
> avr8\amforth.asm(9): error: jmp_: Unknown instruction or macro
> avr8\amforth.asm(9): error: PFA_COLD: Unknown instruction or macro
> avr8\amforth.asm(12): error: Cannot find include file:
> drivers/generic-isr.asm
> avr8\amforth.asm(14): error: Cannot find include file: dict/rww.inc
> dict_appl.inc(4): error: Cannot find include file: dict/compiler2.inc
> avr8\amforth.asm(23): error: Cannot find include file:
> amforth-interpreter.asm
> avr8\amforth.asm(24): error: Cannot find include file: dict/nrww.inc
> avr8\amforth.asm(36): error: Cannot find include file: amforth-eeprom.inc
>

avrasm2.exe does not find macros.asm.

macros.asm lives in ".../avr8/".

According to your structure that should be
"e:/amforth/avr8/macros.asm"

However, the -I (include) directives in your batch file do not
reflect this location. Since make.bat is located in "e:/amforth"
the include paths should probably read

> avrasm2.exe -fI -o myproj.hex -e myproj.eep -l myproj.lst -I .\ -I> .\common 
> -I .\avr8 -I .\include  -v0 myproj.asm


That being said, I do not see any advantage in rearranging the
tree. If you checkout amforth (or extract it from a tar ball)
the you should have this tree

+-- e:/amforth
+-- LICENSE.txt
+-- appl/
|   +-- arduino/
|   +-- ...
|   +-- template/
|   +-- my_project <-- copy of arduino
+-- avr8/
+-- common/
+-- doc/
+-- examples/
+-- msp430/
+-- readme.txt
+-- tests/
+-- tools/

I would highly recommend to create a copy of "arduino" or
"template" called my_project_1 (or whichever name seems
appropriate) and then change things in this new directory. The
-I directives should then read similar to

> avrasm2.exe ... -I ../../avr8/ -I ../../common/

because your project directory is two levels below "e:/amforth"


Hope this helps.

Cheers,
and welcome to AmForth!

Erich

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Amforth & WINE & Linux (WANRING! NEWBIE-Alert! :)

[Erich Wälde]

Hello Meino,

tu...@posteo.de writes:

> Hi,
>
> Before I install a lot of software on my GENTOO-Linux only
> to recognize I had done the wrong assumptions I would like
> ask, whether I have the needed prerequisites for AmForth:
>
> I am running a 64bit-GENTOO Linux and I am quite familiar with
> Linux.
> I want to run AmForth on a Arduino Pro Mini Atmega328p/3.3V.
> With my USB-to-serial adapter I flash my ProMinis with the
> Arduino-IDE successfully.

Please note: "programming" an Arduino uses a bootloader flashed
to the arduino controller before it is shipped. This bootloader
is unfortunately not compatible with amforth. To flash amforth
to your arduino you *must* have a proper programmer. There are
many different ones available. I have successfully used several
including this one: mySmartUSB light by www.myAVR.de. With this
programmer you are able to reinstall the arduino bootloader as
well.

> I am a AmForth-newbie.
> I am a Wine-newbie.
>
> Do I need to install the 32bit-version or the 64bit-version of
> wine?

AvrAssembler2 ist a 32 bit executable. Looking at my Debian I
have installed
. wine
. wine-binfmt
. wine32:i386
. wine32-preloader:i386
. wine64
in other words, the multiarch system is used to enable :i386
(==32 bit) packages, wine and wine32:i386 are installed. Then
this should work. Be sure to search for corresponding
instructions on gentoo.

> Do I need to install wine at all -- can I use a different software
> to assemble things (I would prefer this way even it would imply more
> work) ?

There is "avra" at http://avra.sourceforge.net. A long time ago
I was able to assemble amforth with avra as well (amforth
versions 4.2 .. 4.6 maybe). However: I had to patch avra to make
it output the correct hex file for my beloved 644p. And some of
the assembly directives did not work (.overlay may be, but not
sure). Very unfortunately avra seems to be abandoned. So I
personally have given in to use wine+AvrAssembler2.

It would, of course, be very exciting, if someone would pick up
the leftovers of avra. I would definitely help by using it. And
I'm sure, I'm not the only one waiting for a motivated developer
to move on. As mentioned, I have looked at the sources. It looks
doable, but I have dedicated my time to other things.

Maybe interesting to note: since wine+AvrAssembler2 is working,
it gives a prospective maintainer of avra a possibility to
check, whatever changes were made do not break the output. In
the end avra should be able to produce identical output.

Another route could be to shape up naken_asm. Note that the
msp430 Version of amforth ist build using naken_asm
(http://www.mikekohn.net/micro/naken_asm.php)
I'm not in a position to judge, whether this is a possible
route.

If I remember correctly, then gcc-as is not a possible route,
since the format of the assembly used by gcc-avr is different
from that used to feed AvrAssember2.

>
> Thank you very much in advance for any help!
> Have a nice weekend!
> Cheers
>  Meino


Hope, this helps, and welcome to amforth!

Another source of information is the .pdf Version of the "Vierte
Dimension", a german (and somewhat english) publication by the
"Forth Gesellschaft e.V.", found at
http://www.forth-ev.de/filemgmt/viewcat.php?cid=2

Also, Jean Claude Wippler of jeelabs.org fame is experimenting
with Forth.

Have the appropriate amount of fun!

Cheers,
Erich

--
The purpose of computing is insight --- not numbers
R. Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Tester wanted

[Erich Wälde]

Hello all,


Matthias Trute writes:

> Hi,
>
> I need some independent tests, so I'd like to ask for volunteers.
>
> The command prompt got its characters via a simple interrupt
> routine. That works quite well for years now. However some users
> wanted to replace this routine with some other (forth hll) code
> and were unpleasantly surprised that the word INT! did not do what it
> does for all other ISR's. Not surprisingly since that (and only that)
> one interrupt was not dealt with the way all other interrupts got
> handled.
>
> That has changed now. Now every character is processed the "standard"
> way and the INT! word can easily change the actions. I did some
> tests, but for the high speed ones I lack some resources. So I ask
> you to test and give feedback whether the new code works for serial
> line speed like 56k (or more) - my boards don't have the necessary
> baud rate clock quartzes...
>
> Please get the sources from the repository trunk after version 2141
> and recompile them. To check if everything works good enough,
> it is sufficient that you can enter commands at all


The question was: does receiving data work if serial receive is
done via deferred ISR, not the hard coded one. Especially does
it work at higher baud rates?

So I set out today to run some tests.
Surprisingly, it's not all that clear cut ...

Experiment on atmega644p:
- amforth trunk (6.3), revision 2156
- set WANT_ISR_RX = 1  (default)
  WANT_ISR_TX = 0  (default)
- set BAUD_MAXERROR to 10 (default) --- which corresponds to 10%
  error allowed, if I read the docs correctly.
- set F_CPU to 18432000
- set BAUD to 4800 ... 115200, 230400, 460800, and maybe higher

For a given baud rate I did
- assemble (wine+AVRASM2) and flash (avrdude) the controller
- connect via minicom, list the dictionary with "words"
- upload a large program file
  - from main.fs
  - resolve all includes with a small script
  - strip (almost) all comments and empty lines with another
small script
  - results in 2735 words
  - upload with (an old, stupid version of) amforth-upload.py

There should be no receive errors whatsoever! Loading the file
lasted 162 seconds at higher baud rates.


 | f_cpu[Hz] | baud[1/s] | load[s] | |
 |---+---+-+-|
 |   1843200 |   | | |
 |   |  4800 | 216 | loads ok, works |
 |   |  9600 | 181 | dto.|
 |   | 19200 | 164 | dto.|
 |   | 38400 | 163 | dto.|
 |   | 57600 | 162 | dto.|
 |   |115200 | 162 | dto.|
 |   |230400 | 162 | dto.|
 |   |460800 | | assembly error! |

Results:

1. The assembler refused to configure a baudrate of 460800.
   Increasing baud_maxerror did not help. When it compiled (at
   200 or so) the serial connection displayed garbage.

   I checked the data sheet. It seems to suggest that indeed a
   speed larger than 230400 is hard to achieve. But I have not
   looked into details let alone tried any tricks.

2. RX: The time needed to upload the file seems to be dominated
   by compile time rather than transfer time for baudrates of
   19200 and larger. To me this boundary seems surprisingly low
   ...

3. TX: The time needed to fully list the current dictionary (
   words ) does change noticably with higher baud rates. Surely
   this was one reason why I switched to 115200 baud.

4. Ever since I switched to using baud rate crystals (11.059200
   MHz) and a baud rate of 115200 I have not seen any hickups
   while uploading program files --- except occasionally when
   using rs485 rather than rs232. But that might have other
   causes unrelated to the software on the microcontroller and I
   did not investigate further.

5. The tests using a 11.059200 MHz crystal are very similar, the
   upload time was 225 seconds. Interestingly:
   18432000/11059200 = 1.66 whereas
   225/162 = 1.40
   Interestingly, the upload time does not scale the same way as
   the crystal frequency.

Hope this helps.
Cheers,
Erich

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Thankyou and turnkey

[Erich Wälde]

Hello Tristan,

welcome to the club :-)

Tristan Williams writes:

> Hello, 
>
> I have only recently found AmForth, and have, over the last month or
> so, been making led flash, getting the time from rtc, displaying
> things on an lcd etc. It really has been a most enjoyable and
> educational couple of months for me. I thank Matthias and the AmForth
> developers for making AmForth available. I wish I had found it
> earlier.
>
> I want to put my Arduino uno to some practical use and so wish to
> implement a turnkey solution. To some extent I have done this as the
> code I've written below runs on powering up the uno, turns on the led
> and then I can connect via a serial connection to the interpreter.
>
> Is this the/a correct way to set up a turnkey solution? Is there a
> better way?
>
> Initially I tried the Cookbook code example
>
> http://amforth.sourceforge.net/TG/recipes/Turnkey.html 
>
> but I could not get it to work. Uploading the code onto a freshly
> flashed uno would result in a hanging interpreter, requiring
> re-flashing. I would be very grateful for any pointers as to what I am
> doing wrong.
>
> Many thanks,
> Tristan
> 
> \ turnkey example
>
> #include avr-values.frt
> #include is.frt
> #include ms.frt
> #include defers.frt
>
> $24 constant DDRB
> $25 constant PORTB
>
> 1 5 lshift constant uno.led 
>
> ' turnkey defer@ Evalue tk.amforth
>
> : tk.custom
>   
> tk.amforth execute
>
> 1000 ms
>
> \ init and set high uno led on pin 13   
>
> uno.led DDRB c@ or DDRB c!
> uno.led PORTB c@ or PORTB c!
> ;
>
> ' tk.custom is turnkey

You need to call the original content of turnkey, too. Something
like

: tk.custom
  applturnkey

  \ your code goes here

;

' tk.custom is turnkey

The code of "applturnkey" resides in .../words/applturnkey.asm
in the template application directory.

Cheers,
Erich


>  
> \ end turnkey example
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
The purpose of computing is insight --- not numbers
R. Hamming

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] misalignment warnings

[Erich Wälde]

Hello Andrew,

Andrew Read writes:

> Dear AmForth developers,
>
>
> Whilst compiling AmForth for the atmega644 I receive a number of misalignment 
> warnings of the form:
>
>>>".cseg .db misalignment - padding zero byte"
>
>
> for example:
>>> amforth-6.1\avr8\words/nfa2cfa.asm6
>
>  that line defines an odd-length string
>>> .db "nfa>cfa"
>
>
> Should I be concerned about these warnings and if so what
> steps can I take?
Concerned? Imho no. The compiler does the padding. However, you
can of course help the compiler by writing

> .db "nfa>cfa",0

Hope this helps.
Erich

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] tester-amforth.frt: first test fails?

[Erich Wälde]

Hi Matthias,

Matthias Trute writes:

> Hi
>
>
>> interestingly, this behaviour repeats when running the same test
>> again.
>> Looking at the code makes "depth" or the handling of depth a
>> candidate
>> for misbehaving, however, I did not look too deep.
>> 
>> Can anyone confirm?
>
> freshly flashed and loaded
>
> (ATmega16)> -1 VERBOSE !
>  ok
> (ATmega16)> t{ -1 -> -1 }t
>  ok
> (ATmega16)> 1 2 3
>  ok
> (ATmega16)> t{ -1 -> -1 }t
> WRONG NUMBER OF RESULTS: t{ -1 -> -1 }t
>  ok
> (ATmega16)> 
>
> The problem is triggered with the additional numbers on the
> data stack (1 2 3). That confuses the tester. Since the
> tester code is not mine, it may take some time to debug it.
>
I found that revision 2030 fixes the behaviour above except for
a very minor "case-sensitive" glitch. Patch below.
Thanks for this fast resolution :-)

Cheers,
Erich

svn diff common/lib/forth2012/tester/tester-amforth.frt
Index: common/lib/forth2012/tester/tester-amforth.frt
===
--- common/lib/forth2012/tester/tester-amforth.frt  (revision 2030)
+++ common/lib/forth2012/tester/tester-amforth.frt  (working copy)
@@ -41,7 +41,7 @@
 : -> \ ( ... -- ) RECORD DEPTH AND CONTENT OF STACK.
depth dup ACTUAL-DEPTH !\ RECORD DEPTH
START-DEPTH @ > if  \ IF THERE IS SOMETHING ON STACK
-   DEPTH START-DEPTH @ - 0 do ACTUAL-RESULTS i cells + ! loop \ SAVE THEM
+   depth START-DEPTH @ - 0 do ACTUAL-RESULTS i cells + ! loop \ SAVE THEM
then
 ;
 


--
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] tester-amforth.frt: first test fails?

[Erich Wälde]

Hello all,

when testing a bunch of code with AmForth 6.1/trunk and
trunk/common/lib/forth2012/tester/tester-amforth.frt

it seems to me that the first test in any run fails:

> amforth-upload.py  -t /dev/ttyUSB0 ../../05_amforth_recipes/unixtime_test.fs 
> marker --unix-time--
>  ok
> ~60> \ include lib/forth2012/tester/tester-amforth.frt
>  ok
> ~60> decimal
>  ok
> ~60> -1 VERBOSE !
>  ok
> ~60> 1 2 3
>  ok
> ~60> t{ -1 -> -1 }t
> WRONG NUMBER OF RESULTS: t{ -1 -> -1 }t
>  ok
> ~60> TESTING leapyear
> TESTING leapyear
>  ok
> ~60> t{ 1970 leapyear? ->  0 }t
>  ok
> ~60> t{ 1972 leapyear? -> -1 }t
>  ok

interestingly, this behaviour repeats when running the same test again.
Looking at the code makes "depth" or the handling of depth a candidate
for misbehaving, however, I did not look too deep.

Can anyone confirm?

Along the way I found this:
> $ cat trunk/common/lib/forth2012/tester.frt
> \ 'tester.frt' generated automatically, do not edit
> #include  anstests.zip
> #include  core.fr
> #include  doubletest.fth
> #include  searchordertest.txt
> #include  tester-amforth.frt

which does not look right to my eyes.


Cheers,
Erich

-- 
The purpose of computing is insight --- not numbers
R. Hamming

--
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel