Re: [Amforth] Ref Card Generation quo vadis?
Hello Mark, Erich, AmForthers, Mark - I have chopped and reordered selected parts of your message to form my reply. I hope this is OK. > It seems that the intent of the refcard was to document the things that > are compiled into the system. +1 For me, the scope of the/each refcard is defined by the distribution build for each architecture (AVR8, msp430, etc.). If the refcard script were part of the hex build process then a custom refcard could be a product of the build process also. > Since the Forth source code could be nearly anything AND has to be > uploaded after the hex files are uploaded to the device you are now > entering into the realm of full generated documentation. +1 I think AmForth's documentation is very good, but as Mark's draft 6.8+ refcard pointed out to me, there are words I did not know existed. There is more to AmForth than made it to the existing documentation. Complete, exhaustive and automated documentation would clearly be great, but as has already been noted, doing this across AVR8/msp430/risc-v/arm + various assembler formats + common/uncommon Forth is challenging. As previously mentioned, part of the challenge being agreeing on what a refcard should be. My vote would be to 1. Limit the refcard to the words written in assembler that contribute to the distribution build of the hex files. 2. Limit the refcard improvements for AmForth 6.9 to AVR8 only 3. Take this as an opportunity to review the distribution builds for AVR8 (which words to include) and make the existence and location of the hex files more prominent in the documentation. > I think that we will really need a roadmap to head for v6.9 and more > importantly v7.0. I think the distinction between 6.9 and 7.0 is a very helpful one. My opinion is that AVR8 has been and currently is the core platform for AmForth. From the from the mailing list archive it is certainly the one that generates the most activity. Whilst I probably have more than enough AVR8 development boards in the parts box to see out my list of projects, I think Matthias saw a longer term future for AmForth beyond AVR8. Perhaps answers to these two questions go someway towards defining a roadmap for 7.0 1) which, if any, of the other mcus AmForth can run on do AmForthers think is the one to focus on? 2) is there a desire/will for AmForth on AVR8 to be extended to run on newer AVR8 such as the ATMEGA4809[1] ? Best wishes, Tristan [1] http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega4808-09-DataSheet-DS40002173B.pdf On 02Aug20 09:53, Mark Roth wrote: > On Sat, Aug 1, 2020 at 10:50 PM Erich Wälde wrote: > > > thread hijacked intentionally. > > > 'Thar be pirates! > > > > > > today I spent some time trying to understand the "make-refcard*" > > scripts in some detail. > > > > The script works roughly like this: > > > > > > > - 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. > > > > > Indeed. It also happens to be the reason the perl script works so well, as > well as being so easy to break. It's just too rigid. One thing that the > original has as well is that the 4th line needs to be the "VE" or "XT" > part. If it isn't it will fail. That was the reason for poking around with > the 3 prior lines part of the the script and hardwiring it for the first 3 > lines. > > > > > > Now I could commit Marks patches and not look further. However, there > > are several shortcomings with the current state. > > > > Yeah, don't do that. I really just put up the diff as a reference for > someone that knows Perl. At best right now I would say you could replace > the very outdated refcard.html with the one my changes generate. It is an > improvement just because of the age difference (5.5 to 6.8). For the long > term however, this tool needs to either be fixed entirely or replaced with > something that the build system can use. Having a refcard generated > directly from the source tree is fantastic IMHO. > > > > > > - 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. > > > > This gets to the guts of how to march from here (Google's rendition of the > Latin in the title). Each of the flavors could be determined from their > location in the source tree. The additional information would
Re: [Amforth] Bootloader + AmForth
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] AmForth Weekend 2 (2020-08-01/02)
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
