You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(6) |
Mar
(41) |
Apr
(23) |
May
(11) |
Jun
(2) |
Jul
|
Aug
|
Sep
(9) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2008 |
Jan
(6) |
Feb
(1) |
Mar
(23) |
Apr
(18) |
May
(21) |
Jun
(13) |
Jul
(34) |
Aug
(5) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(4) |
| 2009 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(10) |
May
(1) |
Jun
(11) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
(13) |
| 2010 |
Jan
(10) |
Feb
(4) |
Mar
(28) |
Apr
(3) |
May
(38) |
Jun
(22) |
Jul
(92) |
Aug
(154) |
Sep
(218) |
Oct
(45) |
Nov
(20) |
Dec
(1) |
| 2011 |
Jan
(33) |
Feb
(15) |
Mar
(32) |
Apr
(33) |
May
(48) |
Jun
(35) |
Jul
(7) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
|
Dec
(7) |
| 2012 |
Jan
(56) |
Feb
(11) |
Mar
(6) |
Apr
|
May
(128) |
Jun
(59) |
Jul
(21) |
Aug
(16) |
Sep
(24) |
Oct
(39) |
Nov
(12) |
Dec
(12) |
| 2013 |
Jan
(14) |
Feb
(61) |
Mar
(97) |
Apr
(46) |
May
(13) |
Jun
(23) |
Jul
(12) |
Aug
(25) |
Sep
(9) |
Oct
(81) |
Nov
(73) |
Dec
(45) |
| 2014 |
Jan
(36) |
Feb
(57) |
Mar
(20) |
Apr
(41) |
May
(43) |
Jun
(11) |
Jul
(14) |
Aug
(32) |
Sep
(9) |
Oct
(27) |
Nov
(21) |
Dec
(6) |
| 2015 |
Jan
(14) |
Feb
(23) |
Mar
(1) |
Apr
(19) |
May
(40) |
Jun
(11) |
Jul
(1) |
Aug
(2) |
Sep
(14) |
Oct
(10) |
Nov
(9) |
Dec
(13) |
| 2016 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
|
May
(4) |
Jun
(13) |
Jul
(8) |
Aug
(3) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(7) |
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(3) |
Jul
(6) |
Aug
|
Sep
(2) |
Oct
(54) |
Nov
(47) |
Dec
(53) |
| 2019 |
Jan
(23) |
Feb
(24) |
Mar
(19) |
Apr
(15) |
May
(5) |
Jun
(34) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(7) |
Apr
(7) |
May
(5) |
Jun
(15) |
Jul
(22) |
Aug
(28) |
Sep
(13) |
Oct
(9) |
Nov
(17) |
Dec
(13) |
| 2021 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
(9) |
May
(21) |
Jun
(9) |
Jul
|
Aug
(6) |
Sep
(16) |
Oct
|
Nov
(1) |
Dec
(6) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(21) |
Oct
(5) |
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(9) |
Oct
|
Nov
(4) |
Dec
|
|
From: Martin N. <amf...@mg...> - 2022-05-16 08:04:12
|
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 <ew....@na...> 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: mg...@mg.... |
|
From: George H. <jac...@gm...> - 2022-05-07 11:02:43
|
Thanks for your efforts. On Fri, May 6, 2022, 3:37 PM Erich Wälde <ew....@na...> 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 > > -- > May the Forth be with you ... > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Erich W. <ew....@na...> - 2022-05-06 07:36:47
|
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 ... |
|
From: George H. <jac...@gm...> - 2022-04-17 11:16:28
|
The big advantage with the Arduino Mega is lots of 8 bit ports available for parrallel i/o. The Arduino Uno pretty much forces all i/o to be serialized one way or another. On Sun, Apr 17, 2022 at 3:33 PM Martin Nicholas via Amforth-devel < amf...@li...> wrote: > On Sun, 17 Apr 2022 07:47:15 +0100 > Tristan Williams <ho...@tj...> 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: rep...@mg... (Address will be valid throughout 2022). > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Martin N. <amf...@mg...> - 2022-04-17 07:33:13
|
On Sun, 17 Apr 2022 07:47:15 +0100 Tristan Williams <ho...@tj...> 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: rep...@mg... (Address will be valid throughout 2022). |
|
From: George H. <jac...@gm...> - 2022-04-17 07:01:02
|
Hello, I believe only 50% of the Arduino Mega flash is available to Forth for dictionary use. This is simply a hardware barrier that exists. The additional 126kb theoretically can be put to use in other ways, but I've not seem actually solutions. On Sun, Apr 17, 2022, 2:48 PM Tristan Williams <ho...@tj...> wrote: > Hi Christian, > > Glad it worked. > > > How much of 256KB flash is effectively usable with AmForth on the 2560? ? > > 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. > > > If so, may I share your links with a friend who has an > ATmega2560ProMini? > > Yes. > > Kind regards, > > Tristan > > On 16Apr22 16:34, Christian Hinse wrote: > > Hi Tristan. > > > > Your r2457AmForth version is working fine on my Arduino MEGA with > ATmega2560, except for a few garbled character after the reset. But that is > probably normal. It occurs on the UNO as well. > > > > > amforth 7.0 ATmega2560 16000 kHz > > > words > > int-trap int@ int! -int +int #int irq[]# postpone (marker) end-code > code forth-wordlist wordlist set-current >body s>d bounds init-ram ee>ram > #tib tib source-tib refill-tib 2swap cmove dnegate dabs j * icompare > nfa>cfa name>string traverse-wordlist search-wordlist (defer) defer@ > defer! Udefer! Udefer@ Rdefer! Rdefer@ Edefer! Edefer@ i-cell+ to unused > noop ver ?stack rectype-null rectype-xt rec-find rec-num rectype-dnum > rectype-num recognize forth-recognizer interpret depth rp0 sp0 warm cold > pause quit .input .error .ready .ok find-xt parse-name /string source parse > >number number char refill accept cscan cskip throw catch handler ' type > spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r sign #> > #s # <# hold hld tolower toupper within max min abs mod / negate u/mod /mod > turnkey bl hex decimal bin allot here ehere dp key? key emit? emit pad >in > tuck 2drop 2dup cell+ cells base state f_cpu environment fill s" ." pick > words show-wordlist u.r u. dinvert d- d+ d2/ d2* nr> n>r -1 2 1 = 2literal > @i (i!) !i @e !e 2r> 2>r up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +! > rshift lshift ?negate 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log2 > > < u> u< 0 true d0< d0> 0> 0< 0= <> r@ >r r> nip rot drop over swap ?dup > dup !u @u c@ c! ! @ (value) execute exit applturnkey nfa>lfa compare > cfg-recs cfg-order get-current map-stack set-stack get-stack ?abort abort > abort" [char] immediate recurse user constant variable [ ] ; :noname : > does> reveal wlscope header create lp lp0 >l l> endloop ?do leave +loop > loop do again until repeat while begin then else if ahead sliteral literal > ['] , compile ( \ (create-in) (create) latest newest 1ms name>flags umin > umax ud* m+ sleep !wdc wdr c!@spi bm-toggle bm-clear bm-set b> >b b!- b!+ > nb! b! b@- b@+ nb@ b@ a> >a a!- a!+ na! a! a@- a@+ na@ a@ +usart ubrr > tx?-poll tx-poll rx?-buf rx-buf isr-rx >rx-buf ok > > > > > > > Some question: > > > > * How much of 256KB flash is effectively usable with AmForth on the > 2560? > > * Will this work as well on a Chinese ATmega2560ProMini (with FTDI > USB chip for terminal input) ? > > * If so, may I share your links with a friend who has an > ATmega2560ProMini? > > > > Thanks a lot for your help. > > > > Christian Hinse > > ________________________________ > > From: Tristan Williams <ho...@tj...> > > Sent: 16 April 2022 06:05 > > To: amf...@li... < > amf...@li...> > > Subject: Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No > reponse at console > > > > Hello Christian, > > > > Below is a link to AmForth hex files I built for my Arduino MEGA using > the > > (then) most recent source (r2457). The console baud rate is 38400 and > > build details are in the atmega2560.asm file. > > > > https://tjnw.co.uk/amforth-bin/ > > > > Some background info is contained in this message thread. > > > > https://sourceforge.net/p/amforth/mailman/message/37296323/ > > > > Hope this helps and let me know if you get it up and running. > > > > Kind regards, > > > > Tristan > > > > On 16Apr22 07:08, Christian Hinse wrote: > > > Hi to your support team. > > > > > > I have AmForth working properly on an Arduino UNO. > > > > > > I am now trying to use it with an Arduino MEGA using the Atmega2560 > but I get no console response after programming the files atmega256.hex > and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of > downloaded file amforth-6.9.zip. > > > > > > I still consider myself as a beginner hobbyist and I do not yet have > the ability to assemble my one code from source. > > > > > > * Are these Hex file effectively compatible with the Arduino MEGA > using the ATmega2560 ? > > > * What are the fuses that I should use with the Arduino MEGA.using > the ATmega2560 ? > > > > > > I am currently using the followings fuses: > > > > > > Reading fuses... > > > >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U > hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h > > > SUCCESS: Read high fuse > > > SUCCESS: Read low fuse > > > SUCCESS: Read extended fuse > > > > > > My serial port COM7 is transmitting to the Arduino MEGA because I can > see the RX LED flashing. I don not see an response on the TX LED or the > console. > > > > > > * Am I using HEX files that are not compatible with the Arduino > MEGA using an ATmega2560 MCU ? > > > * If not, what can I do to make these files work with the Arduino > MEGA using the ATmega2560. > > > > > > I would appreciate your help to resolve this problem. > > > > > > Thanks. > > > > > > Christian Hinse > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Amforth-devel mailing list for http://amforth.sf.net/ > > > Amf...@li... > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Tristan W. <ho...@tj...> - 2022-04-17 06:47:37
|
Hi Christian, Glad it worked. > How much of 256KB flash is effectively usable with AmForth on the 2560? ? 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. > If so, may I share your links with a friend who has an ATmega2560ProMini? Yes. Kind regards, Tristan On 16Apr22 16:34, Christian Hinse wrote: > Hi Tristan. > > Your r2457AmForth version is working fine on my Arduino MEGA with ATmega2560, except for a few garbled character after the reset. But that is probably normal. It occurs on the UNO as well. > > > amforth 7.0 ATmega2560 16000 kHz > > words > int-trap int@ int! -int +int #int irq[]# postpone (marker) end-code code forth-wordlist wordlist set-current >body s>d bounds init-ram ee>ram #tib tib source-tib refill-tib 2swap cmove dnegate dabs j * icompare nfa>cfa name>string traverse-wordlist search-wordlist (defer) defer@ defer! Udefer! Udefer@ Rdefer! Rdefer@ Edefer! Edefer@ i-cell+ to unused noop ver ?stack rectype-null rectype-xt rec-find rec-num rectype-dnum rectype-num recognize forth-recognizer interpret depth rp0 sp0 warm cold pause quit .input .error .ready .ok find-xt parse-name /string source parse >number number char refill accept cscan cskip throw catch handler ' type spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r sign #> #s # <# hold hld tolower toupper within max min abs mod / negate u/mod /mod turnkey bl hex decimal bin allot here ehere dp key? key emit? emit pad >in tuck 2drop 2dup cell+ cells base state f_cpu environment fill s" ." pick words show-wordlist u.r u. dinvert d- d+ d2/ d2* nr> n>r -1 2 1 = 2literal @i (i!) !i @e !e 2r> 2>r up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift ?negate 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log2 > < u> u< 0 true d0< d0> 0> 0< 0= <> r@ >r r> nip rot drop over swap ?dup dup !u @u c@ c! ! @ (value) execute exit applturnkey nfa>lfa compare cfg-recs cfg-order get-current map-stack set-stack get-stack ?abort abort abort" [char] immediate recurse user constant variable [ ] ; :noname : does> reveal wlscope header create lp lp0 >l l> endloop ?do leave +loop loop do again until repeat while begin then else if ahead sliteral literal ['] , compile ( \ (create-in) (create) latest newest 1ms name>flags umin umax ud* m+ sleep !wdc wdr c!@spi bm-toggle bm-clear bm-set b> >b b!- b!+ nb! b! b@- b@+ nb@ b@ a> >a a!- a!+ na! a! a@- a@+ na@ a@ +usart ubrr tx?-poll tx-poll rx?-buf rx-buf isr-rx >rx-buf ok > > > > Some question: > > * How much of 256KB flash is effectively usable with AmForth on the 2560? > * Will this work as well on a Chinese ATmega2560ProMini (with FTDI USB chip for terminal input) ? > * If so, may I share your links with a friend who has an ATmega2560ProMini? > > Thanks a lot for your help. > > Christian Hinse > ________________________________ > From: Tristan Williams <ho...@tj...> > Sent: 16 April 2022 06:05 > To: amf...@li... <amf...@li...> > Subject: Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console > > Hello Christian, > > Below is a link to AmForth hex files I built for my Arduino MEGA using the > (then) most recent source (r2457). The console baud rate is 38400 and > build details are in the atmega2560.asm file. > > https://tjnw.co.uk/amforth-bin/ > > Some background info is contained in this message thread. > > https://sourceforge.net/p/amforth/mailman/message/37296323/ > > Hope this helps and let me know if you get it up and running. > > Kind regards, > > Tristan > > On 16Apr22 07:08, Christian Hinse wrote: > > Hi to your support team. > > > > I have AmForth working properly on an Arduino UNO. > > > > I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get no console response after programming the files atmega256.hex and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file amforth-6.9.zip. > > > > I still consider myself as a beginner hobbyist and I do not yet have the ability to assemble my one code from source. > > > > * Are these Hex file effectively compatible with the Arduino MEGA using the ATmega2560 ? > > * What are the fuses that I should use with the Arduino MEGA.using the ATmega2560 ? > > > > I am currently using the followings fuses: > > > > Reading fuses... > > >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h > > SUCCESS: Read high fuse > > SUCCESS: Read low fuse > > SUCCESS: Read extended fuse > > > > My serial port COM7 is transmitting to the Arduino MEGA because I can see the RX LED flashing. I don not see an response on the TX LED or the console. > > > > * Am I using HEX files that are not compatible with the Arduino MEGA using an ATmega2560 MCU ? > > * If not, what can I do to make these files work with the Arduino MEGA using the ATmega2560. > > > > I would appreciate your help to resolve this problem. > > > > Thanks. > > > > Christian Hinse > > > > > > > > > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Christian H. <hin...@ou...> - 2022-04-16 16:34:34
|
Hi Tristan. Your r2457AmForth version is working fine on my Arduino MEGA with ATmega2560, except for a few garbled character after the reset. But that is probably normal. It occurs on the UNO as well. > amforth 7.0 ATmega2560 16000 kHz > words int-trap int@ int! -int +int #int irq[]# postpone (marker) end-code code forth-wordlist wordlist set-current >body s>d bounds init-ram ee>ram #tib tib source-tib refill-tib 2swap cmove dnegate dabs j * icompare nfa>cfa name>string traverse-wordlist search-wordlist (defer) defer@ defer! Udefer! Udefer@ Rdefer! Rdefer@ Edefer! Edefer@ i-cell+ to unused noop ver ?stack rectype-null rectype-xt rec-find rec-num rectype-dnum rectype-num recognize forth-recognizer interpret depth rp0 sp0 warm cold pause quit .input .error .ready .ok find-xt parse-name /string source parse >number number char refill accept cscan cskip throw catch handler ' type spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r sign #> #s # <# hold hld tolower toupper within max min abs mod / negate u/mod /mod turnkey bl hex decimal bin allot here ehere dp key? key emit? emit pad >in tuck 2drop 2dup cell+ cells base state f_cpu environment fill s" ." pick words show-wordlist u.r u. dinvert d- d+ d2/ d2* nr> n>r -1 2 1 = 2literal @i (i!) !i @e !e 2r> 2>r up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift ?negate 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log2 > < u> u< 0 true d0< d0> 0> 0< 0= <> r@ >r r> nip rot drop over swap ?dup dup !u @u c@ c! ! @ (value) execute exit applturnkey nfa>lfa compare cfg-recs cfg-order get-current map-stack set-stack get-stack ?abort abort abort" [char] immediate recurse user constant variable [ ] ; :noname : does> reveal wlscope header create lp lp0 >l l> endloop ?do leave +loop loop do again until repeat while begin then else if ahead sliteral literal ['] , compile ( \ (create-in) (create) latest newest 1ms name>flags umin umax ud* m+ sleep !wdc wdr c!@spi bm-toggle bm-clear bm-set b> >b b!- b!+ nb! b! b@- b@+ nb@ b@ a> >a a!- a!+ na! a! a@- a@+ na@ a@ +usart ubrr tx?-poll tx-poll rx?-buf rx-buf isr-rx >rx-buf ok > Some question: * How much of 256KB flash is effectively usable with AmForth on the 2560? * Will this work as well on a Chinese ATmega2560ProMini (with FTDI USB chip for terminal input) ? * If so, may I share your links with a friend who has an ATmega2560ProMini? Thanks a lot for your help. Christian Hinse ________________________________ From: Tristan Williams <ho...@tj...> Sent: 16 April 2022 06:05 To: amf...@li... <amf...@li...> Subject: Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console Hello Christian, Below is a link to AmForth hex files I built for my Arduino MEGA using the (then) most recent source (r2457). The console baud rate is 38400 and build details are in the atmega2560.asm file. https://tjnw.co.uk/amforth-bin/ Some background info is contained in this message thread. https://sourceforge.net/p/amforth/mailman/message/37296323/ Hope this helps and let me know if you get it up and running. Kind regards, Tristan On 16Apr22 07:08, Christian Hinse wrote: > Hi to your support team. > > I have AmForth working properly on an Arduino UNO. > > I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get no console response after programming the files atmega256.hex and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file amforth-6.9.zip. > > I still consider myself as a beginner hobbyist and I do not yet have the ability to assemble my one code from source. > > * Are these Hex file effectively compatible with the Arduino MEGA using the ATmega2560 ? > * What are the fuses that I should use with the Arduino MEGA.using the ATmega2560 ? > > I am currently using the followings fuses: > > Reading fuses... > >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h > SUCCESS: Read high fuse > SUCCESS: Read low fuse > SUCCESS: Read extended fuse > > My serial port COM7 is transmitting to the Arduino MEGA because I can see the RX LED flashing. I don not see an response on the TX LED or the console. > > * Am I using HEX files that are not compatible with the Arduino MEGA using an ATmega2560 MCU ? > * If not, what can I do to make these files work with the Arduino MEGA using the ATmega2560. > > I would appreciate your help to resolve this problem. > > Thanks. > > Christian Hinse > > > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amf...@li... https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Tristan W. <ho...@tj...> - 2022-04-16 10:26:37
|
Hello Christian, Below is a link to AmForth hex files I built for my Arduino MEGA using the (then) most recent source (r2457). The console baud rate is 38400 and build details are in the atmega2560.asm file. https://tjnw.co.uk/amforth-bin/ Some background info is contained in this message thread. https://sourceforge.net/p/amforth/mailman/message/37296323/ Hope this helps and let me know if you get it up and running. Kind regards, Tristan On 16Apr22 07:08, Christian Hinse wrote: > Hi to your support team. > > I have AmForth working properly on an Arduino UNO. > > I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get no console response after programming the files atmega256.hex and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file amforth-6.9.zip. > > I still consider myself as a beginner hobbyist and I do not yet have the ability to assemble my one code from source. > > * Are these Hex file effectively compatible with the Arduino MEGA using the ATmega2560 ? > * What are the fuses that I should use with the Arduino MEGA.using the ATmega2560 ? > > I am currently using the followings fuses: > > Reading fuses... > >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h > SUCCESS: Read high fuse > SUCCESS: Read low fuse > SUCCESS: Read extended fuse > > My serial port COM7 is transmitting to the Arduino MEGA because I can see the RX LED flashing. I don not see an response on the TX LED or the console. > > * Am I using HEX files that are not compatible with the Arduino MEGA using an ATmega2560 MCU ? > * If not, what can I do to make these files work with the Arduino MEGA using the ATmega2560. > > I would appreciate your help to resolve this problem. > > Thanks. > > Christian Hinse > > > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Christian H. <hin...@ou...> - 2022-04-16 07:41:06
|
Hi to your support team. I have AmForth working properly on an Arduino UNO. I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get no console response after programming the files atmega256.hex and atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file amforth-6.9.zip. I still consider myself as a beginner hobbyist and I do not yet have the ability to assemble my one code from source. * Are these Hex file effectively compatible with the Arduino MEGA using the ATmega2560 ? * What are the fuses that I should use with the Arduino MEGA.using the ATmega2560 ? I am currently using the followings fuses: Reading fuses... >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h SUCCESS: Read high fuse SUCCESS: Read low fuse SUCCESS: Read extended fuse My serial port COM7 is transmitting to the Arduino MEGA because I can see the RX LED flashing. I don not see an response on the TX LED or the console. * Am I using HEX files that are not compatible with the Arduino MEGA using an ATmega2560 MCU ? * If not, what can I do to make these files work with the Arduino MEGA using the ATmega2560. I would appreciate your help to resolve this problem. Thanks. Christian Hinse |
|
From: Stephen S. <dee...@gm...> - 2021-12-15 10:23:39
|
I did load the *'amforth-6.9\appl\eval-pollin\p644.*'* hex and eep files to check things. It works and I can make new words. But, when I loaded (via realterm, all ok): - to-name.frt - see.frt see always returns 'not found' on any word I try. > ' see see not found ok > ' reveal see not found ok > ------------------------------ In addition ----------------------- For whatever reason the "sanguino" does not work. See previous for UART setup, I used what was there in the assembly file. I did check all of the hardware and settings you mentioned. The 644 that I am using is the same as above. Same baud rate (preamble.inc). It does not appear to me, on the surface, that there is a difference between this and the p644 (from a hardware/setup perspective), just a USART. I have been busier than usual, but will work on things this weekend, dig into the template file and start from scratch. Regards & thanks. |
|
From: Erich W. <ew....@na...> - 2021-12-12 17:29:33
|
Hello Stephen, Stephen Simmons <dee...@gm...> 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 = 16000000 | .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 ... |
|
From: Erich W. <ew....@na...> - 2021-12-09 20:15:49
|
Hello Stephen, welcome to the list! Stephen Simmons <dee...@gm...> 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 ... |
|
From: Stephen S. <dee...@gm...> - 2021-12-09 18:39:01
|
I did see posts/problems with different implementations of AmForth hanging. Not sure they are related to my issues, but they do seem similar by description. *One additional note:* *The EEPROM has to be reprogrammed for the 328PB to recover, a power cycle actually does not work!* I did load the 644 version from the *eval-pollin* directory to my board and it works fine, so I know it can be built. Will try the 328 version later on my Microchip 328PB board. Regards |
|
From: Stephen S. <dee...@gm...> - 2021-12-09 17:10:08
|
*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 + .* *amforth 6.9 ATmega328P Forthduino* |
|
From: Stephen S. <dee...@gm...> - 2021-12-09 17:02:16
|
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. 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. Any hints or suggestions would be appreciated. Regards |
|
From: Stephen S. <dee...@gm...> - 2021-11-21 13:38:35
|
There does not seem to be any UART defined for this family. There is a LINxxx/UART component that can either be used for a LIN bus or a UART, but it does not have the usual UDRxx structure. I was wondering if anyone had actually ported to the chip, there seems to be nothing in the mailing list. I am trying to mimic the UDRxxx implementation, but have not had much success so far. Regards |
|
From: CVBruce <cv...@gm...> - 2021-09-12 16:00:41
|
Hi all, I finally gave up on finding a download of avrasm2.exe and associated files and downloaded Studio 7. For those of your that have installed/run Studio 7 on non-intel Linux is there a preference between Wine and Box86 environments? Does one work better than the other? Second question, If I remember the last time I did this, there were instructions on what to copy out of the Studio installed files to set up a command line tool chain for building AmForth that were, shall we say, less than perfect. Are the current instructions “correct”? Better yet does someone have a batch/shell script that will do the job for me. Thanks, Bruce |
|
From: Helge K. <Hel...@gm...> - 2021-09-12 08:28:08
|
On 09.09.2021 09:37, Tristan Williams wrote: > Hi Helge, > > A mystery, but given that, as far as I know, every (modern) build > eventually uses avrasm2.exe to create the hex files, one that should > be solvable. I absolutely agree. And the Studio 7 comes with avrasm2. There is a version update from 2.1.52 as you can find in appl\atmega2561\atmega256.lst to the current version 2.2.8. But this is not important. > Given that you have an UNO build working, I can only > think that your atmega2560 build is not finding all the needed files > (or finding some it shouldn't) or that the build target is not > actually an atmega2560. The target is an atmega2560. The device signature is 0x1e9801, and C programs run fine. > I use a Makefile based build (on macos) that is based on the one that > is part of the distribution. I can send you an archive with the > Makefile, list file, etc. for you to check over. I don't have access > to a Windows machine or I would try to replicate what you are doing. It was not a question of the build environment (make/Studio) or the OS. The main difference between the ATmega328P and the ATmega2560 is the is that the file appl_8k.inc is included, if the flash size is > 8000. The asmforth.asm can't be used in that case as it is described in http://amforth.sourceforge.net/UG/windows.html Instead of "amforth.asm" the file "asmforth-low.asm" must be included. This can also be found at appl\atmega2561\atmega256.asm. But this example is not for Arduino ATMEGA256. It uses a different USART for the terminal. Here is my working example: ; First is to include macros and default settings from the amforth ; directory. .include "preamble.inc" ; amforth needs two essential parameters ; CPU clock in hertz, 1MHz is factory default .equ F_CPU = 16000000 ; and the actual USART port. .include "drivers/usart_0.asm" ; Include the whole source tree. .include "amforth-low.asm" And here are the avrdude parameter to flash the device -c usbasp -p m2560 -V -u -U flash:w:my.hex -U eeprom:w:my.eep \ -U efuse:w:0xFD:m -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m I am happy that I can now start Forth on my ATMEGA2560 Arduino. Best regards, Helge |
|
From: Tristan W. <ho...@tj...> - 2021-09-09 07:38:06
|
Hi Helge, A mystery, but given that, as far as I know, every (modern) build eventually uses avrasm2.exe to create the hex files, one that should be solvable. Given that you have an UNO build working, I can only think that your atmega2560 build is not finding all the needed files (or finding some it shouldn't) or that the build target is not actually an atmega2560. I use a Makefile based build (on macos) that is based on the one that is part of the distribution. I can send you an archive with the Makefile, list file, etc. for you to check over. I don't have access to a Windows machine or I would try to replicate what you are doing. Kind regards, Tristan On 08Sep21 19:40, Helge Kruse wrote: > > On 08.09.2021 17:45, Tristan Williams wrote: > > Hi Helge, > > > > Glad you got AmForth to build with an atmega328p. > > > > Can you make avrasm2.exe output a list file, re-build and then check > > the list file for lines containing store-i ? > > > > For the atmega2560 I would expect > > > > .include "words/store-i.asm" > > .include "words/store-i_big.asm" > > > > For the atmega328p I would expect > > > > .include "words/store-i.asm" > > .include "words/store-i_nrww.asm" > > Well, the .lss doesn't show the source lines for the atmega2560. But I see > > atmega2560: > dict/nrww.inc(93): Including file 'words/store-i_big.asm' > > atmega328p: > dict/nrww.inc(95): Including file 'words/store-i_nrww.asm' > > as you expected. Further the core_8k.inc is included for the 256 instead > of the core_4k.inc for 328p. > > Should I send the .lss file (121k) or make it somewhere available? > > > Best regards, > Helge > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Helge K. <Hel...@gm...> - 2021-09-08 17:41:10
|
On 08.09.2021 17:45, Tristan Williams wrote: > Hi Helge, > > Glad you got AmForth to build with an atmega328p. > > Can you make avrasm2.exe output a list file, re-build and then check > the list file for lines containing store-i ? > > For the atmega2560 I would expect > > .include "words/store-i.asm" > .include "words/store-i_big.asm" > > For the atmega328p I would expect > > .include "words/store-i.asm" > .include "words/store-i_nrww.asm" Well, the .lss doesn't show the source lines for the atmega2560. But I see atmega2560: dict/nrww.inc(93): Including file 'words/store-i_big.asm' atmega328p: dict/nrww.inc(95): Including file 'words/store-i_nrww.asm' as you expected. Further the core_8k.inc is included for the 256 instead of the core_4k.inc for 328p. Should I send the .lss file (121k) or make it somewhere available? Best regards, Helge |
|
From: Tristan W. <ho...@tj...> - 2021-09-08 15:45:57
|
Hi Helge,
Glad you got AmForth to build with an atmega328p.
Can you make avrasm2.exe output a list file, re-build and then check
the list file for lines containing store-i ?
For the atmega2560 I would expect
.include "words/store-i.asm"
.include "words/store-i_big.asm"
For the atmega328p I would expect
.include "words/store-i.asm"
.include "words/store-i_nrww.asm"
Kind regards,
Tristan
On 08Sep21 10:54, Helge Kruse wrote:
> On 08.09.2021 08:06, Tristan Williams wrote:
> > Hi Helge,
> >
> > I don't use studio, but from the command line you give below
> >
> > > avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
> > > (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
> > > -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
> > > -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
> > > "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
> > > (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
> >
> > it looks like it is including files from the devices\atmega32
> > directory and using m32def.inc which are associated with the atmega32
> > chip rather than the atmega328p. Somewhere the target device needs to
> > be set to an atmega328p.
>
> This is a good point! With the correct include path I get a working,
> self-compiled amForth. Further I removed the -im32def.inc. The file is
> included in the amForth sources anyway.
>
> Thank you.
>
> Now I want to take the second step, build for ATmega2560. I use nearly
> the same avrsam2 command line, but changed the include path from
> amforth-6.9\avr8\devices\atmega32
> to
> amforth-6.9\avr8\devices\atmega2560
>
> avrasm2.exe -fI -o my2560.hex -e my2560.eep -S my2560.tmp -W+ie
> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega2560"
> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -d
> "Debug\my2560.obj" "main.asm" -I "D:\Program Files
> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
>
> Now I get several errors like:
> error: Overlap in .cseg: addr=0x1f000 conflicts with 0x1f000:0x1f396
> error: Overlap in .cseg: addr=0x1f001 conflicts with 0x1f000:0x1f396
> ...
> error: Overlap in .cseg: addr=0x1f03e conflicts with 0x1f000:0x1f396
>
> Shouldn't this compile out of the box?
> I am also curious about this range 0x1f000:0xf1396.
>
> Best regards,
> Helge
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
|
|
From: Helge K. <Hel...@gm...> - 2021-09-08 08:54:10
|
On 08.09.2021 08:06, Tristan Williams wrote:
> Hi Helge,
>
> I don't use studio, but from the command line you give below
>
>> avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
>> (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
>> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
>> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
>> "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
>> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
>
> it looks like it is including files from the devices\atmega32
> directory and using m32def.inc which are associated with the atmega32
> chip rather than the atmega328p. Somewhere the target device needs to
> be set to an atmega328p.
This is a good point! With the correct include path I get a working,
self-compiled amForth. Further I removed the -im32def.inc. The file is
included in the amForth sources anyway.
Thank you.
Now I want to take the second step, build for ATmega2560. I use nearly
the same avrsam2 command line, but changed the include path from
amforth-6.9\avr8\devices\atmega32
to
amforth-6.9\avr8\devices\atmega2560
avrasm2.exe -fI -o my2560.hex -e my2560.eep -S my2560.tmp -W+ie
-I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega2560"
-I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -d
"Debug\my2560.obj" "main.asm" -I "D:\Program Files
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
Now I get several errors like:
error: Overlap in .cseg: addr=0x1f000 conflicts with 0x1f000:0x1f396
error: Overlap in .cseg: addr=0x1f001 conflicts with 0x1f000:0x1f396
...
error: Overlap in .cseg: addr=0x1f03e conflicts with 0x1f000:0x1f396
Shouldn't this compile out of the box?
I am also curious about this range 0x1f000:0xf1396.
Best regards,
Helge
|
|
From: George H. <jac...@gm...> - 2021-09-08 06:19:14
|
typo correction - " If you don't *know if* your ATmega2560 binaries are correctly compiled, AmForth does have precompiled ready to load ATmega328p binaries that you can load to an ArduinoUNO as a way of learning to understand AVRDUDE and proper FUSE settings." On Wed, Sep 8, 2021 at 2:15 PM George Herzog <jac...@gm...> wrote: > Hi Helen, > I strongly advise you to* avoid *use of Atmel Studio or the Microchip > successor. > > Using the standalone Atmel assembler in Windows is a much easier solution > to control. The Microsoft VisualStudio software bogs down and has a very > challenging learning curve with getting good results. > > *It sounds as though you successfully compiled binaries in hex files, but > you may very likely hit a snag in AVRDUDE. * > > It is very common when installing Forth to deploy the wrong fuse setting > and end up with no serial port response. So you might consider using an > online Atmel Fuse calculator to confirm your fuse settings. > > HERE IS A LINK ==> https://www.engbedded.com/fusecalc/ > > THERE ARE OTHERS IF THIS ONE DOESN'T APPEAL TO YOU. > > +++++++++++++++++++++++++ > Also, make sure that you understand what the AVRDUDE output is saying. > There are 3 separate parts to a successful download. The .hex file for the > flash, the .hex file for the eeprom, and the FUSE settings. > > If you don't your ATmega2560 binaries are correctly compiled, AmForth does > have precompiled ready to load ATmega328p binaries that you can load to an > ArduinoUNO as a way of learning to understand AVRDUDE and proper FUSE > settings. > > I hope this will help. > George Herzog > > > > On Wed, Sep 8, 2021 at 3:33 AM Helge Kruse <Hel...@gm...> wrote: > >> I am a newby to amForth. I want to use it at ATmega 2560. For the first >> steps I want to use the more common board Arduino UNO. >> >> I flashed the files uno.hex and uno.eep.hex from the directory >> amforth-6.9\appl\arduino to my Arduino UNO. This gives me a greeting >> >> amforth 6.9 ATmega328P Forthduino >> > >> >> I think, the mega328p fuses and the USB/serial connection are verified. >> Now I want to build the amForth from the sources. The documentation at >> http://amforth.sourceforge.net/UG/quick-windows.html is a bit dated (for >> amForth 6.6). The Atmel studio is not available anymore. I found only >> the Microchip Studio 7 as the successor of the Atmel studio at the >> Microchip website. (Atmel has been purchased by Microchip.) >> >> I set up a main.asm file as >> >> .include "preamble.inc" >> .equ F_CPU = 16000000 >> .include "drivers/usart.asm" >> .include "amforth.asm" >> >> and configured the include directories: >> $(PackRepoDir)\atmel\ATmega_DFP\1.6.364\avrasm\inc >> amforth-6.9\avr8 >> amforth-6.9\avr8\devices\atmega328p >> amforth-6.9\appl\arduino >> amforth-6.9\common >> Without these directories some .asm files had not been found. The >> Microchip Studio 7 compiles without errors: >> >> avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files >> (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc" >> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32" >> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d >> "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files >> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include" >> >> >> Segment Begin End Code Data Used Size Use% >> ------------------------------------------------------------- >> [.cseg] 0x000000 0x007f82 1838 11508 13346 32768 40.7% >> [.dseg] 0x000060 0x00011f 0 191 191 2048 9.3% >> [.eseg] 0x000000 0x000086 0 134 134 1024 13.1% >> Assembly complete, 0 errors. 8 warnings >> >> I can also provide the complete assembler stdout stream. But I hesitate >> to send such a large mail to the list without request. >> >> But after flashing my.hex and my.eep to the Arduino UNO I can see >> nothing. Therefore I assume something's wrong with my build. >> >> Can somebody provide an minimum example for a basic amForth project with >> the Microchip Studio 7? >> Is there any updated documentation for the build process that handles >> the Studio 7 environment? >> Any hints how I find and remove the problem? >> >> I hope this can be easily solved. I've seen in the mailing list archive >> that a build with mega2560 was successful lately. >> >> Best regards, >> Helge >> >> >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > |
|
From: George H. <jac...@gm...> - 2021-09-08 06:15:24
|
Hi Helen, I strongly advise you to* avoid *use of Atmel Studio or the Microchip successor. Using the standalone Atmel assembler in Windows is a much easier solution to control. The Microsoft VisualStudio software bogs down and has a very challenging learning curve with getting good results. *It sounds as though you successfully compiled binaries in hex files, but you may very likely hit a snag in AVRDUDE. * It is very common when installing Forth to deploy the wrong fuse setting and end up with no serial port response. So you might consider using an online Atmel Fuse calculator to confirm your fuse settings. HERE IS A LINK ==> https://www.engbedded.com/fusecalc/ THERE ARE OTHERS IF THIS ONE DOESN'T APPEAL TO YOU. +++++++++++++++++++++++++ Also, make sure that you understand what the AVRDUDE output is saying. There are 3 separate parts to a successful download. The .hex file for the flash, the .hex file for the eeprom, and the FUSE settings. If you don't your ATmega2560 binaries are correctly compiled, AmForth does have precompiled ready to load ATmega328p binaries that you can load to an ArduinoUNO as a way of learning to understand AVRDUDE and proper FUSE settings. I hope this will help. George Herzog On Wed, Sep 8, 2021 at 3:33 AM Helge Kruse <Hel...@gm...> wrote: > I am a newby to amForth. I want to use it at ATmega 2560. For the first > steps I want to use the more common board Arduino UNO. > > I flashed the files uno.hex and uno.eep.hex from the directory > amforth-6.9\appl\arduino to my Arduino UNO. This gives me a greeting > > amforth 6.9 ATmega328P Forthduino > > > > I think, the mega328p fuses and the USB/serial connection are verified. > Now I want to build the amForth from the sources. The documentation at > http://amforth.sourceforge.net/UG/quick-windows.html is a bit dated (for > amForth 6.6). The Atmel studio is not available anymore. I found only > the Microchip Studio 7 as the successor of the Atmel studio at the > Microchip website. (Atmel has been purchased by Microchip.) > > I set up a main.asm file as > > .include "preamble.inc" > .equ F_CPU = 16000000 > .include "drivers/usart.asm" > .include "amforth.asm" > > and configured the include directories: > $(PackRepoDir)\atmel\ATmega_DFP\1.6.364\avrasm\inc > amforth-6.9\avr8 > amforth-6.9\avr8\devices\atmega328p > amforth-6.9\appl\arduino > amforth-6.9\common > Without these directories some .asm files had not been found. The > Microchip Studio 7 compiles without errors: > > avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files > (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc" > -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32" > -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d > "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files > (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include" > > > Segment Begin End Code Data Used Size Use% > ------------------------------------------------------------- > [.cseg] 0x000000 0x007f82 1838 11508 13346 32768 40.7% > [.dseg] 0x000060 0x00011f 0 191 191 2048 9.3% > [.eseg] 0x000000 0x000086 0 134 134 1024 13.1% > Assembly complete, 0 errors. 8 warnings > > I can also provide the complete assembler stdout stream. But I hesitate > to send such a large mail to the list without request. > > But after flashing my.hex and my.eep to the Arduino UNO I can see > nothing. Therefore I assume something's wrong with my build. > > Can somebody provide an minimum example for a basic amForth project with > the Microchip Studio 7? > Is there any updated documentation for the build process that handles > the Studio 7 environment? > Any hints how I find and remove the problem? > > I hope this can be easily solved. I've seen in the mailing list archive > that a build with mega2560 was successful lately. > > Best regards, > Helge > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |