Re: [Amforth] successful compilation with avra
Perhaps a howto on the site not as an email thread would be in order. This may not be a big deal for windows users, but people that want to use free-libre software will be drawn to use amforth if the entire build toolchain is FLOSS. Brian-in-ohio On Mon, Aug 28, 2023 at 7:47 AM Jan Kromhout via Amforth-devel < amforth-devel@lists.sourceforge.net> wrote: > Hello, > > Seems simple to use the avra compiler. > Is it posible to show example how the build is doing? > > Cheers, > > Jan > > Verstuurd vanaf mijn iPad > > > Op 28 aug. 2023 om 09:02 heeft Mark Roth het > volgende geschreven: > > > > You are using the same repo I was for avra Tristan. I just cloned the > > issue-54 branch and built it here. Apart from a couple of 'zero byte in a > > .DB' warnings things do seem to be working fine here as well. > > > >> On Mon, Aug 28, 2023 at 9:54 AM tristan wrote: > >> > >> Hello, > >> > >> I flashed the hex files created by avra to an uno and, to the extent > >> that getting a serial prompt, defining a word and executing it > >> constitutes a test, it worked perfectly. > >> > >>> 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. > >> > >> No changes to the source tree were needed to create the uno hex files. > >> The only change made was to edit the Makefile to use avra. > >> > >> Best wishes, > >> Tristan > >> > >> > >>> On 2023-08-27 06:29, Tristan Williams wrote: > >>> Hello Mark, Brian, Erich, George > >>> > >>> Thank you! A very welcome set of messages on a bank holiday > >>> weekend. For non-windows users having avra as the assembler in the > >>> build chain would go along way in making AmForth more approachable and > >>> maintainable. > >>> > >>> I think this is the repo for avra that does not have the macro/ > >>> parenthesis issue you mention[1] > >>> > >>> https://github.com/srtlg/avra/tree/development > >>> > >>> I downloaded it and built it on macOS (requiring only typing 'make') > >>> and updated the AmForth Makefile to run arva. The updated makefile > >>> built the hex files for an uno with AmForth 6.9. I did not experience > >>> any issues with d0< but I recall there were some changes in that > >>> area between 6.8 and 6.9. I've not flashed it yet as I have to dig out > >>> an uno from storage but the hex files are the same size and with zero > >>> diffs when compared with my previous wine/avrasm32 builds. > >>> > >>> -rw-r--r-- 1 tw staff 29346 26 Aug 17:53 uno.hex > >>> -rw-r--r-- 1 tw staff 29346 26 Aug 16:29 save.hex > >>> -rw-r--r-- 1 tw staff239 26 Aug 17:53 uno.eep.hex > >>> -rw-r--r-- 1 tw staff239 26 Aug 16:29 save.eep.hex > >>> > >>> > >>> Best wishes, > >>> Tristan > >>> > >>> [1] https://github.com/Ro5bert/avra/issues/54 > >>> > >>> > >>> On 25Aug23 17:12, George Herzog wrote: > >>>> Thanks for your efforts. > >>>> > >>>> People don't often appreciate how much knowledge and effort goes into > >>>> successful compilation of code. > >>>> > >>>> > >>>> > >>>> On Fri, Aug 25, 2023, 3:15 PM Erich Wälde > wrote: > >>>> > >>>>> 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 > >>>>>> $
Re: [Amforth] successful compilation with avra
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
Re: [Amforth] AmForth Project open for adoption
Is the fork of amforth available anywhere? brian-in-ohio On 5/16/22, Martin Nicholas via Amforth-devel wrote: > Erich, > > Thanks for all your work. > > You may wish to advertise the vacancy on the USENET comp.lang.forth. A > G account will do the job. > > On Fri, 06 May 2022 09:17:23 +0200 > Erich Wälde wrote: > >> Dear AmForthers, >> >> I am herewith stepping down from the maintainer role of AmForth. For >> details, read on. If anyone is interested to take over, get in touch >> with me. >> >> >> In 2020 I received the logins of amforth.sourceforge.net, basically >> because I was lucky enough to have met Matthias personally a few >> times. At that time I had a lot of ideas on how to proceed. And while >> I managed to create an official release, there are a few obstacles in >> this path. >> >> First and foremost I am facing a health issue. It is subtle, but it >> seriously limits, what I can do. I still have to make several >> difficult decisions regarding my daily life. I have started to >> decrease the number of things on my list by cancelling items. I have >> to accept the fact, that I'm not in a position any more to advance >> the AmForth project in a meaningful way. >> >> Secondly, AmForth has become complex over time. Matthias added >> support for three more target platforms (msp430, arm, riscv32). >> Allthough access to these is easily achievable, I use only avr. And I >> use it less these days. >> >> Thirdly, AmForths tools are depending heavily on python code, a >> language I consider myself illiterate in. I have written a few small >> perl scripts around AmForth to serve my needs. I heavily depend on >> those and on a Makefile. >> >> Add the fact, that in 2020 I spent countless hours to port my data >> acquisition stuff at home from amforth 4.6 to 6.9 and it just did not >> become stable. To this day I still have no clue, why the thing hangs >> itself after some time, sometimes hours, sometimes several days. In >> other words: unusable. >> >> >> Step back: what would I have done, if I didn't know Matthias, and the >> project would just have become silent? Simplify. Simplify heavily. >> >> Very recently I have made a fork of AmForth release 5.0. That version >> is before support for msp430 was officially added (5.5). That version >> happens to compile with avra rather than wine/avrasm2.exe. Along the >> way I found, that avra has seen new releases, which add support for >> my beloved atmega644p and lots of fixes, which is nice! This removes >> the dependancy from wine and allows for smaller systems for >> development. >> >> So I have picked up my data acquisition project again with the fork >> mentioned above. Any Interrupt Service Routines are written in >> assembly to avoid the thing that I uncovered in 2017, namely a race >> condition 1 bit wide and 1 instruction cycle long. I pick missing >> bits and pieces from later releases. I would like to add a few >> features regarding sensors with different needs. A first experiment >> has run more than 10^6s (12d) without any failure. So I am moderately >> optimistic to continue along this simplified path. >> >> >> Thanks to all, who have answered the list, contributed code, ideas, >> documentation in one form or other. It has been an interesting >> experience. And should you still care to listen: if you have one or a >> few more important plans, do not delay them, you might be unable to >> pursue them later. >> >> Happy hacking, and use the Forth! >> >> Cheers >> Erich >> > > > > -- > Regards, > > Martin Nicholas. > > E-mail: m...@mgn.org.uk. > > > ___ > 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
Re: [Amforth] Newbie getting started with AVR128DA48
Perhaps the Arduino controlled by Eforth would be a good help. It has the full assembly code explained for eforth might be a good jumping off point its available at http://www.forth.org/OffeteStore/OffeteStore.html. A good read no matter what. Brian-in-ohio On 12/29/20 4:05 AM, Stephen D wrote: Hi all, would like to try running amforth on one of the new AVR processors, the AVR128DA48 to be exact. A Curiosity Nano board turned up this week and I'm keen to give it a try. Am a total newb with regards to amforth and forth in general but have plenty of AVR programming experience, both in C and assembler. Have looked through the User and Technical Guides but not found an answer to my question: How do you define a new AVR8 chip within amforth? I have looked through the files under /avr8/devices/atmega* e.g. device.asm, device.inc etc. They all claim to be "generated automatically". I have not been able to find where the automatic generation is performed. Is anyone able to point me in the right direction please? Thanks, Stephen ___ Amforth-devel mailing list for http://amforth.sf.net/ 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
Re: [Amforth] Gory Details: How to properly create a release?
I am running the latest version of amforth on an avrbutterfly. 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? 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. 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. AVR needs the wine/avrasm2.exe toolchain. - the remaining targets need different toolchains, which I have not installed at this moment. - hifive1 riscv64-linux-gnu-as In the download section Matthias has provided a toolchain, see: https://sourceforge.net/projects/amforth/files/Risc-V-Tools/ However, this toolchain is very hip today, so it is available at den Debian repositories as well: gcc-riscv64-linux-gnu/stable I actually have such a board collecting dust in the corner :-/ - launchpad-arm arm-none-eabi-as This toolchain is available at the debian repositories as well: gcc-arm-none-eabi/stable - launchpad430naken_asm This tool is available, maintained and probably quite mature: http://www.mikekohn.net/micro/naken_asm.php In 2015 I have made experiments with this toolchain, so this part is probably doable. - inux-armarm-linux-gnueabi-as This toolchain is available at the debian repositories as well: gcc-arm-linux-gnueabi/stable I do not have any msp430 or arm boards any more. I have given them away. So all in all, the toolchains are available. Matthias has probably built a bunch of docker containers to run them :-) A little while later: Installing the missing toolchains on Debian turns out to be fairly simple (thank you, Debianistas!): # apt install binutils-riscv64-linux-gnu \ binutils-arm-linux-gnueabi \ binutils-arm-none-eabi I had a copy of naken_asm (from 201(5) in some corner and with that executable on the PATH, I could build launchpad430 So with the exception of arduino/leonardo.* I managed to build everything that shows up in the release archive. ew@ceres:~/Forth/amforth/trunk/appl 119 > ls -l */*.hex */amforth -rw-r- 1 ew ew 239 2020-08-30 11:28 arduino/duemilanove.eep.hex -rw-r- 1 ew ew 26843 2020-08-30 11:28 arduino/duemilanove.hex -rw-r- 1 ew ew 239 2020-08-30 11:28 arduino/mega128.eep.hex -rw-r- 1 ew ew 27959 2020-08-30 11:28 arduino/mega128.hex -rw-r- 1 ew ew 239 2020-08-30 11:28 arduino/uno.eep.hex -rw-r- 1 ew ew 27157 2020-08-30 11:28 arduino/uno.hex -rw-r- 1 ew ew 239 2020-08-30 11:31 atmega2561/atmega256.eep.hex -rw-r- 1 ew ew 27481 2020-08-30 11:31 atmega2561/atmega256.hex -rw-r- 1 ew ew 239 2020-08-30 11:27 eval-pollin/p1284-16.eep.hex -rw-r- 1 ew ew 28096 2020-08-30 11:27 eval-pollin/p1284-16.hex -rw-r- 1 ew ew 239 2020-08-30 11:27 eval-pollin/p16-8.eep.hex -rw-r- 1 ew ew 27518 2020-08-30 11:27 eval-pollin/p16-8.hex -rw-r- 1 ew ew 239 2020-08-30 11:27 eval-pollin/
Re: [Amforth] template.hex can't be build with MCU=atmega8
I'm using a butterfly (atmega169) with the latest version, runs great. Brian-in-ohio On 8/16/20 4:49 AM, Malte Frank Gerdes wrote: Okay, i see. I'll use a bigger controller then. Malte ___ 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] avr8
Sending this again Hello, I'm an avr8 user and love amforth. This is the best system for an eight bit micro that lets you have interactive use of the chip. Things like circuit python and ulisp are cool but so resource intensive or tied to the arduino ecosystem that they become fun toy environments (on the 8 bit platforms) meant to move you on to the arm based systems where the 'real' work can be done. 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. These tools allowed me to build and run the current amforth on the avrbutterfly. I think this is a great project. I would love to help, especially in the documentation. I'll keep my eyes open to how to submit patches. Thanks for everything. brian-in-ohio On 7/1/20 2:17 AM, Tristan Williams wrote: Hello, Who of you is using which target controller? I use AVR atmega328p, atmega1284p, atmega2560 Can we get rid of the Atmel/Microchip Avrasm Assembler? Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine that would be a lot of work and wine does run it very well. Having "fuller" hex files in the distribution that have assembly words like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would delay the need to build AmForth. AVR flash and ram are not the limited resource they once were. It might be worth updating the documentation to say which hex files are available. Would it be feasible to drop msp430, arm, risc-v in order to simplify the whole thing? yes/no? I think that depends on the collective response to the first question. amforth-shell.py and python3 amforth-shell.py is a great tool for AmForth. I have modified it to run under python3 and it works well for me. I will put up a patch but it really needs testing in a python os/environment other than mine. ticket system or mailing list ? I would prefer a mailing list. Thank you Erich for AmForth Weekend #1 - I look forward to #2 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
[Amforth] documentation error
begin ASSR c@ 1 2 lshift \ TCN2UB 1 0 lshift or \ TCR2UB 1 1 lshift or \ OCR2UB and until I am new to the forth world and i'm loving it. I was on the newark ( an electronics parts distributor ) a few months ago and they were selling avrbutterflys for 8 US dollars. So I bought a few and while thinking about what to do with them I found forth and fell into the rabbit hole. That being said, in the cookbook section/popular boards/avr butterfly section it gives an rtc example code. The problem is that the above loop should wait until those three registers are 0. If you leave a 0 on the stack you end up in an infinite loop, and yet surprisingly the +32kHz function that loop comes from works. Well if you dump the ASSR register value ( using .s ) you see that the first look at the register that the TCRTUB flag is set so the value on the stack is one and the loop ends. This is not what the exit condition you want for this loop. Those last three bits in ASSR should be 0 according to the data sheet for the atmega169 (and I also for the atmega328) before moving on. A simple fix is: begin ASSR c@ 1 2 lshift \ TCN2UB 1 0 lshift or \ TCR2UB 1 1 lshift or \ OCR2UB and 0= \ add this line until How would I submit this as a patch for the documentation? Thanks, Brian-in-ohio ps used this loop to see the values on the stack begin ASSR c@ 1 2 lshift \ TCN2UB 1 0 lshift or \ TCR2UB 1 1 lshift or \ OCR2UB bin .s cr hex and 0= until ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
