Re: [Amforth] A RISC-V update
On Tue, 16 Apr 2024 19:34:13 +0100 h...@tjnw.co.uk wrote: > Thoughts/fixes very much welcomed. Currently struggling with USB. There is a library for flashforth, see below. It's for an Atmega 32u4, However I quickly came to the conclusion that it had some flaws and shelved attempts to get it working. https://sourceforge.net/p/flashforth/code/ci/master/tree/avr/forth/usbcdc.fs -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2024). ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] A RISC-V update
Thanks for your work. I've just ordered a development board. M. On Sat, 13 Apr 2024 17:08:53 +0100 h...@tjnw.co.uk wrote: > A RISC-V update. > > AmForth-RV is now self-supporting (no C libraries required) for the > WCH CH32V307. Source and a pre-built hex file are here [0] > > Best wishes, > Tristan > > [0] https://tjnw.co.uk/amforth-rv > > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > -- 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
Re: [Amforth] Maintainer(s) for AmForth
On Sun, 10 Sep 2023 17:04:01 +0200 tristan wrote: > Fellow AmForth-ers, > > Perhaps it is time again to consider having a formal maintainer for > AmForth. Back in May 2022 Erich stepped down [1] and put in place > various resources that could be potentially be used to maintain > AmForth (in addition to those that already exist at sourceforge) > > To my knowledge, nobody from the mailing list has volunteered > individually. Additionally, having a single maintainer does have its > own issues. So perhaps a way forward would be to have a small group of > maintainers for AmForth. The revelation from Mark R [2] that the > latest AmForth can be made using avra does make a difference to me, > such that I would volunteer for such a group. So are there others on > the mailing list who would be willing to join such a maintainers > group? I would be happy to make some sort of contribution, but being essentially a hobbyist programmer, I'm not sure how useful I could be. I've never worked in any type of devlopment team. Documentation is something I could contribute to, but not until next year due to on-going commitments in 2023. Certainly an "advert" for maintiners on AmForth's new home would be a good thing; together messages on the socials. Talking of maintenance, I note that avra (on Sourceforge) hasn't been updated since 2019. Maybe it's completed? -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2023). ___ 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
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
Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console
On Sun, 17 Apr 2022 07:47:15 +0100 Tristan Williams wrote: > Hi Christian, > > Glad it worked. > > > How much of 256KB flash is effectively usable with AmForth on the > > 2560? ? > 64k only (which is heaps) - W and IP are 16-bits only. The upper 64k is still available, a little bit is used for the flashing code. I use some of this space for user messages. > Good question. I don't know. The file avr8/words/store-i_big.asm may > give some clues. > > > Will this work as well on a Chinese ATmega2560ProMini (with FTDI > > USB chip for terminal input) ? > > Again, I don't know. However, if the board has an ATmega2560 mcu > running at 16 MHz then there is good chance. I think only by flashing > the board and testing it will you have a better idea. > The clones work fine. Out of the box you might have to blow the fuses first - before flashing the memory. -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2022). ___ 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
On Tue, 31 Aug 2021 06:27:50 +0200 Helge Kruse wrote: > Hello, I am new to amForth. > > amForth is an interactive Forth. The compiler runs on the target and > writes to the flash memory of the device. This requires to send all > the source code through the UART interface. > > I want to develop a Forth application for a target that uses the > ATmeage256 USART for the application data. In that case it would be > desired to compile the application, create a hex file and use USBasp > to flash it to the target. > > How can I compile the Forth words, probably with the AVR assembler, > for a target without a free UART? Is there any idea of a cross > compiler or generating of assembler source code that could be place > in a file lilke appltrunkey.asm. > > Are there other ways to approach? > > Best regards, > Helge > > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > ATmegas have at least two USARTs, I'd use one of them for your extra interface. The advantages of Forth's interactivity is lost if you can no longer interact with it via the terminal - you might as well write in C. -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2021). ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
[Amforth] AVR8: Mega 2560 Wiping Flash Memory
I had problems with my Arduino Mega erasing parts of the flash memory; sometimes the odd byte, sometimes the odd page. I changed 3 things to the flashing code to make the problem go away: 1. Checked the SPMCSR:RWWSB bit. This is a crib from the Atmel example (29.6.13 Simple Assembly Code Example for a Boot Loader). >From the docs: "When the RWWSB bit is set, the RWW section cannot be accessed." Cribbed code: ; return to RWW section ; verify that RWW section is safe to read Return: in temp1, SPMCSR sbrs temp1, RWWSB ; The RWW section is not ready yet ret ; re-enable the RWW section ldi spmcrval, (1
Re: [Amforth] Newbie with a mega2560
On Mon, 24 May 2021 17:57:51 -0700 Michael Picco wrote: > Hello Martin, > Thank you for responding! > In my work directory, which is aptly named 'amforth-6.9', I don't see > a copy of the template.asm file with "amforth-low.asm" mentioned. > The amforth-low.asm file is referenced in the avr8 subdirectory. Is > there something I am missing? > > Kind regards, > Michael > The file is here: appl/template/template.asm I'm wrong as to where "amforth-low.asm" is included. In a vanilla system the include is in: appl/atmega2561/atmega256.asm There is an atmega256 build in: appl/atmega2561/ Probably the most suitable Makefile is: appl/template/makefile or possibly: appl/arduino/Makefile -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2021). ___ 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
The crucial file to include for an ATmega is the confusingly named: "amforth-low.asm" which needs to be un-commented in template.asm. All the code is then in low flash memory apart from the flash burning routine which should be found at NRWW_START_ADDR (0x01f000). Often, with a new device, you need to burn the fuses "make write-fuse", before flashing (and burning fuses for a second time) with "make install". -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2021). ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] template.hex can't be build with MCU=atmega8
In template.asm, a better bet might be: > ; define which usart to use. > .include "drivers/usart.asm" See also: http://amforth.sourceforge.net/TG/recipes/Usart.html On Fri, 14 Aug 2020 13:17:13 +0200 Malte Frank Gerdes wrote: > Hi, > > this is the first time i'm using amforth. I followed > http://amforth.sourceforge.net/UG/linux.html to get amforth and tried > to build the template.hex file for an atmega8. I also tried a > snapshot of r2450, which has the same error. The template.lst file > contains this: > > AVRASM ver. 2.1.52 template.asm Fri Aug 14 13:00:33 2020 > > template.asm(14): Including file '../../avr8\preamble.inc' > ../../avr8\preamble.inc(2): Including file '../../avr8\macros.asm' > ../../avr8\macros.asm(6): Including file '../../avr8\user.inc' > ../../avr8\preamble.inc(6): Including file > '../../avr8/devices/atmega8\device.asm' > ../../avr8/devices/atmega8\device.asm(5): Including file > '../../avr8/Atmel/Appnotes2\m8def.inc' template.asm(53): Including > file '../../avr8\drivers/usart_0.asm' -- 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] Reference Card page now missing
Somehow this has gone from the RH menu: http://amforth.sourceforge.net/TG/refcard.html -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2020). ___ 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
On Mon, 8 Jun 2020 11:58:15 +0100 tur bine wrote: > 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 > Thank you Your program will crash! AmForth, certainly on the AVR, makes no run-time checks on stack bounds. In the firing line are: the return stack (RP), the Terminal Input Buffer (TIB), any variables ALLOTed, User Variables (UP), etc. The Forth approach is that it's up to you to test your words as you write them for offending behaviour. The Forth development environment also makes this dead easy. For example to test '+' type: 3 2 + . . The first dot prints the answer of 5. The second dot THROWs error 4 as the stack has under-flowed. Thus you have proven '+' uses two items from the stack and leaves just one. '?stack' checks the Computation Stack only and is part of 'interpret' which is taking what you typed and executing it a word at a time. -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2020). ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] Watchdog Timer on AVR8s
I should add this is a follow-up to a thread started in 2019. Here's the archive of that thread: https://sourceforge.net/p/amforth/mailman/message/36683433/ -- 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
Re: [Amforth] Watchdog Timer on AVR8s
Hi, I've had this one brewing for some time. Looking at schemes for: AT90CAN128 & ATA6612C. Common variables between chips: WDTCSR (WDTCR), WDTOE (WDCE), WDCE, WDE. WDTCSR & WDTOE are included "For compatibility" in the CAN chip. I include this in cold.asm. It should work with the two WDTs in the chip series above as well as chips with no WDT at all: .if defined(WDTCSR) ; There's a WDT, so we reset it as per the docs. in_ temp0, WDTCSR ori temp0, (1
[Amforth] Missing DU
Not present in 6.8 as far as I can see. > 8.6.2.1270 DU< “d-u-less” DOUBLE EXT > ( ud1 ud2 -- flag ) > flag is true if and only if ud1 is less than ud2. Also, a bug in D0>: Hmmm, something wrong here I feel: > (ATmega2560)> decimal 1553994000. d0> . 1572137999. d0> . > -1 0 ok Cheers! -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2019). ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] Watchdog Timer on AVR8s
This snippet is a bit more like it (I think): lds temp0, WDTCSR ori temp0, (1
[Amforth] Watchdog Timer on AVR8s
Looking into a crashing ATmega2560, I found this clause in the docs: "If the Watchdog is accidentally enabled, for example by a runaway pointer or brown-out condition, the device will be reset and the Watchdog Timer will stay enabled. If the code is not set up to handle the Watchdog, this might lead to an eternal loop of time-out resets. To avoid this situation, the application software should always clear the Watchdog System Reset Flag (WDRF) and the WDE control bit in the initialisation routine, even if the Watchdog is not in use." This suggests that both the MCUSR and the WDTSR should be cleared on reset. I've added a line: out_ WDTCSR, zerol to COLD which covers it. The minimum requirement is to clear both MCUSR.WDRF and WDTCSR.WDE. Cheers! -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2019). ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
[Amforth] Amforth 6.8
Taken me months to notice, but 6.8 still reports a "ver" of 6.7 from env-forthversion.asm -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2019). ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] 16/32 Bit Fetch & Store.
On Wed, 17 Oct 2018 13:27:09 +0100 Tristan Williams wrote: > On 17Oct18 10:25, Martin Nicholas via Amforth-devel wrote: > > Hi, > > > > I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR. > > Although it's possible to code around a variable being changed by an > > interrupt (using C@ C! for example), the 16-bit counter registers > > can't be dealt with in a similar way. Section 17.3 of the datasheet > > "Accessing 16-bit Registers" deals with all this. @ and ! do do the > > byte accesses in the right order, but an interrupt using the 16-bit > > registers associated with a particular counter will overwrite the > > "TEMP (8-bit)" register (see Figure 17-4). > > > > Cheers! > > > > > > Hello Martin, > > This page http://amforth.sourceforge.net/TG/AVR8.html sets out how > AmForth handles interrupts and I think it is relevant to your post. > > Earlier this year I wrote some forth[1] that used the word 1ms and it > was not running as I expected. I had not realised that the execution > of AmForth words written in assembler would not be interrupted. @ ! +! > are assembler words and so will not be interrupted. > > Tristan > > [1] > https://sourceforge.net/p/amforth/mailman/amforth-devel/?viewmonth=201806 > No, thie problem with 1ms is specific to 1ms. I suspect the tight inner loop is uninterruptable. It is: > sbiw Z, 1 > brne pc-1 Interrupts are enabled at all times (by APPLTURNKEY) unless you specifically disable them. Looking at the vanilla build at: amforth-6.7/appl/template/template.lst These words enable interrupts: +INT APPLTURNKEY. These disable: -INT. These temporarily disable interrupts: RP! !E @E (!I-NRWW). They are re-enabled before exit. That's it. Search for "cli" and "sei". When I have time I'll test my theory about 1ms. Atmel documentation is no help on this, although there are dark hints in the documentation for BRNE. Confirm interrupt status with: "hex 5f c@ ." Cheers! -- 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] AVR Fuses
Hi, With "make install" the fuses are burnt after the flash, it's possible the fuses are in such a state the the device is un-burnable. Off-the-shelf parts (Arduinos and the like) are sometimes like this. You can try burning the fuses first with: "make write-fuse" then followed by "make install". Maybe this should be considered a bug, maybe not. -- Regards, Martin Nicholas. E-mail: reply-2...@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] 16/32 Bit Fetch & Store.
Hi, I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR. Although it's possible to code around a variable being changed by an interrupt (using C@ C! for example), the 16-bit counter registers can't be dealt with in a similar way. Section 17.3 of the datasheet "Accessing 16-bit Registers" deals with all this. @ and ! do do the byte accesses in the right order, but an interrupt using the 16-bit registers associated with a particular counter will overwrite the "TEMP (8-bit)" register (see Figure 17-4). Cheers! -- Regards, Martin Nicholas. E-mail: reply-2...@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] Bug in atmega2560 Code.
Hi, Looks like there is a bug in file: /amforth-6.7/avr8/words/store-i_big.asm That is: > out_ rampz, zl should be: > out_ eind, zl EICALL and EIJMP both use this register for the extra bits. -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk -- 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] Bug in i2c-eeprom.frt
Thee should be a NACK as indicated below, I believe. : c...@i2c.ee ( addr hwid -- c ) dup i2c.begin swap i2c.ee.send-addr i2c.start \ repeated start i2c.rd i2c.tx \ hwid for reading i2c.rxn \ BUGFIX i2c.end ; -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk -- 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
