Menu
▾
▴
amforth-devel — Development discussion and user support
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: Tristan W. <ho...@tj...> - 2021-09-08 06:06:27
|
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. Kind regards, Tristan On 07Sep21 21:32, Helge Kruse 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: Helge K. <Hel...@gm...> - 2021-09-07 19:32:44
|
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 |
|
From: Helge K. <Hel...@gm...> - 2021-09-07 05:25:26
|
On 05.09.2021 18:08, Erich Wälde wrote: > Hmmm, you sure??? If I look at my code ... usart-isr-rx.asm ... > see below. No. I was wrong. I wrote the mail without the documentation at hand. I remembered incorrectly that the address is compared by the microcontroller. That was wrong. The MPC checks only the most significant bit. The address is to be checked in the ISR. Sorry, my fault. Best regards, Helge |
|
From: Erich W. <ew....@na...> - 2021-09-05 16:26:43
|
Hello Helge, Helge Kruse <Hel...@gm...> writes: > Am 04.09.2021 um 14:38 schrieb Erich Wälde: > >> Using the serial interface for a rs485 connection ... now, that >> I can understand :-) I have a collection of controllers "online", >> descriptions start here (German text): >> Vierte Dimension 2011/1 >> https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2011-01.pdf >> Judging from your name German text should not be a problem for you. > Thanks for that hint. It's a very interesting article. I will experiment > with it. Yep, German is no problem for me. >> I'm very interested to hear, how you get along. Feel free to ask >> about technical details. > > I read about the MPC and find it very interesting. Unfortunately I won't > be able to use it, since the bus also uses broadcast addresses (126,127) > and the MPC is specific to one address (intentionally). Hmmm, you sure??? If I look at my code ... usart-isr-rx.asm ... see below. When "silent", the usart is set to 7N2. With mpc mode enabled incoming data isr will call into usart_rx_isr WHENEVER the highest bit of the address is set. The other 7 bits are passed in register UDRn --- oh, oh, my reading avr assembly brain isn't really awake ... --- and then the incoming Byte is compared to ram_station_id. If it matches switch usart to 8N1, if not, ignore. Noone stops you from comparing to several such IDs, I think. http://amforth.sourceforge.net/Projects/RS485/RS485Bus.html has this as Forth code. In section 6 (handling an incoming byte according to MPC-mode) you can better see the line, where the decision is made: | : mpc-rx-isr | rx-err? 0= if | UDR0 c@ \ -- udata | mpc? if | stationID = if \ <== add more stationID tests here ... | -mpc7 | then | else | rx-store | then | then | ; Unless I have misunderstood your text ... Cheers, Erich --- usart-isr-rx.asm ------------------------------------------- ;;; AmForth Version 4.5 ;;; usart driver, receiving .set pc_ = pc .org URXCaddr jmp_ usart_rx_isr .org pc_ ; sizes have to be powers of 2! .equ usart_rx_size = $10 .equ usart_rx_mask = usart_rx_size - 1 .dseg usart_rx_in: .byte 1 usart_rx_out: .byte 1 usart_rx_data: .byte usart_rx_size .cseg .if WANT_MPC == 0 ; --- original version --- ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; usart_rx_isr: push xl in xl, SREG push xl push xh push zl push zh lds xh, USART_DATA ; optional: check for certain character(s) (e.g. CTRL-C) ; and trigger a soft interrupt instead of storing the ; charater into the input queue. lds xl,usart_rx_in ldi zl, low(usart_rx_data) ldi zh, high(usart_rx_data) add zl, xl adc zh, zeroh st Z, xh inc xl andi xl,usart_rx_mask sts usart_rx_in, xl usart_rx_isr_finish: pop zh pop zl pop xh pop xl out SREG, xl pop xl reti .else ; --- MPC version --- usart_rx_isr: push xl ; save registers in xl, SREG push xl push xh push zl push zh push temp0 in_ xh, UCSRA ; xh = UCSRnA mov temp0, xh ; temp0 = xh; save value andi xh, (1<<FE) | (1<<DOR) | (1<<PE) ; set zero flag lds xh, USART_DATA ; xh = UDRn brne usart_rx_isr_finish ; test Z flag, --> _finish on error (zero flag=0) lds xl,usart_rx_in ; xl = i_in ldi zl, low(usart_rx_data) ; Z = &buf[0] ldi zh, high(usart_rx_data) ; add zl, xl ; Z += i_in adc zh, zeroh ; . sbrc temp0, MPCM ; if (UCSRnA[MPCM] == 0) rjmp usart_rx_isr_mpcmode ; { st Z, xh ; . buf[i_in] = xh (== UDRn); normal mode inc xl ; . xl += 1 andi xl,usart_rx_mask ; . xl %= siz (Ringbuffer) sts usart_rx_in, xl ; . i_in = xl rjmp usart_rx_isr_finish ; } else { usart_rx_isr_mpcmode: ; multi-processor-communication mode ldi zl, low(ram_station_id) ; . Z = &ram_station_id ldi zh, high(ram_station_id) ; . . ld xl, Z ; . xl = ram_station_id cp xl, xh ; . xl == xh? brne usart_rx_isr_finish ; . if ( ram_station_id == UDRn ) andi temp0, (~(1<<MPCM)) ; . { we are called! out_ UCSRA, temp0 ; . . UCSRA = temp0; clear MPCM ldi temp0, (USART_C_VALUE) ; . . temp0 = USARC_C_VALUE out_ UCSRC, temp0 ; . . UCSRC = temp0; 8N1 mode usart_rx_isr_finish: ; } _finish pop temp0 ; restore registers pop zh pop zl pop xh pop xl out SREG, xl pop xl reti .endif ; ( -- ) Hardware Access ; R( --) ; initialize usart ;VE_USART_INIT_RX: ; .dw $ff06 ; .db "+usart" ; .dw VE_HEAD ; .set VE_HEAD = VE_USART_INIT_RX XT_USART_INIT_RX_ISR: .dw DO_COLON PFA_USART_INIT_RX_ISR: ; ( -- ) .dw XT_ZERO .dw XT_DOLITERAL .dw usart_rx_in .dw XT_STORE .dw XT_EXIT ---------------------------------------------------------------- -- May the Forth be with you ... |
|
From: Helge K. <Hel...@gm...> - 2021-09-05 10:20:48
|
Am 04.09.2021 um 14:38 schrieb Erich Wälde: > Using the serial interface for a rs485 connection ... now, that > I can understand :-) I have a collection of controllers "online", > descriptions start here (German text): > Vierte Dimension 2011/1 > https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2011-01.pdf > Judging from your name German text should not be a problem for you. Thanks for that hint. It's a very interesting article. I will experiment with it. Yep, German is no problem for me. > I'm very interested to hear, how you get along. Feel free to ask > about technical details. I read about the MPC and find it very interesting. Unfortunately I won't be able to use it, since the bus also uses broadcast addresses (126,127) and the MPC is specific to one address (intentionally). There is also a technical problem with the compiling in Microchip Studio, but that's a new mail (thread). Best regards, Helge |
|
From: Erich W. <ew....@na...> - 2021-09-04 15:24:55
|
Hello Helge, welcome to the list! I'm late to the show, but anyways ... I personally would not use the serial console for something else, but rather use a atmega644 or similar, which features two separate serial interfaces. Replicating code is imho most easy, if a controller is read back via avrdude or similar. The resulting files are then flashed to the other devices. Helge Kruse <Hel...@gm...> writes: > Instead of dumping the contents from the target I found another > approach. The g4 <https://github.com/mikalus/g4> converter makes > assembly source code from Forth code. I could use it to convert my code > to assembler code that I could add the the amForth sources. :-) If you look closely, you will find quite some similarity of the AmForth code (esp. with releases up to 5.5) with the output of g4. I do not know for sure, but it seem that Matthias has generated a lot of code with g4. So yes, go for it! Using the serial interface for a rs485 connection ... now, that I can understand :-) I have a collection of controllers "online", descriptions start here (German text): Vierge Dimension 2011/1 https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2011-01.pdf Judging from your name German text should not be a problem for you. More description here: http://amforth.sourceforge.net/Projects/RS485/RS485Bus.html I'm very interested to hear, how you get along. Feel free to ask about technical details. Cheers, Erich -- May the Forth be with you ... |
|
From: Helge K. <Hel...@gm...> - 2021-09-04 08:47:02
|
On 31.08.21 11:29, Helge Kruse via Amforth-devel wrote: > But I want > to create a hex file with a real turnkey application that I can flash on > another ATmega2560 device. After running all Forth source code to my > "development" board I find the flash filled with the code. It should be > possible to clone the flash content to another board without sending all > the source trough a UART. The other idea I mentioned was to "dump" the > added flash memory content and create an assembler source used in the > AVR assembler. Instead of dumping the contents from the target I found another approach. The g4 <https://github.com/mikalus/g4> converter makes assembly source code from Forth code. I could use it to convert my code to assembler code that I could add the the amForth sources. g4 requires that the referred words are defined, so that you have to provide stubs for words that are missing in gforth but known to amForth, e.g. MS. But as long as you can compile in gforth you can create source files for amForth. Including these new files in you amForth skeleton creates a new .hex file capable to be a turnkey application, in a .hex file. > > The reason to differentiate between development board and the target > device is that the target device is that the target device has only one > USART port connected. And this port is used on a RS485 field bus. And you can flash the new .hex file on the ISP port. Best regards, Helge |
|
From: Helge K. <Hel...@gm...> - 2021-09-01 05:22:09
|
On 31.08.2021 18:40, BK Navarette wrote: > May be you could do a memory dump using avrdude terminal mode after > building the application interactively then flash that file to the next > avr. > > This might work. Thanks for this idea. Of cause, it's not absolutely necessary to create the hex file with from source files in the AVR assembler or the running Forth. The ISP interface should do the job to replicate the image. Thanks, Helge |
|
From: BK N. <bkn...@gm...> - 2021-08-31 16:39:02
|
May be you could do a memory dump using avrdude terminal mode after building the application interactively then flash that file to the next avr. This might work. Brian-in-ohio On 8/31/21 05:37, George Herzog wrote: > Martin Nichols has offered the simplest solution. > > On Tue, Aug 31, 2021 at 5:03 PM Martin Nicholas via Amforth-devel < > amf...@li...> wrote: > >> On Tue, 31 Aug 2021 06:27:50 +0200 >> Helge Kruse <Hel...@gm...> 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/ >>> Amf...@li... >>> 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: rep...@mg... (Address will be valid throughout 2021). >> >> >> _______________________________________________ >> 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: George H. <jac...@gm...> - 2021-08-31 09:37:44
|
Martin Nichols has offered the simplest solution. On Tue, Aug 31, 2021 at 5:03 PM Martin Nicholas via Amforth-devel < amf...@li...> wrote: > On Tue, 31 Aug 2021 06:27:50 +0200 > Helge Kruse <Hel...@gm...> 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/ > > Amf...@li... > > 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: rep...@mg... (Address will be valid throughout 2021). > > > _______________________________________________ > 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-08-31 09:29:41
|
On 31.08.2021 10:41, Martin Nicholas via Amforth-devel wrote: >> >> 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? >> > > 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. > Thanks for reply. I like the interactivity at the terminal. But I want to create a hex file with a real turnkey application that I can flash on another ATmega2560 device. After running all Forth source code to my "development" board I find the flash filled with the code. It should be possible to clone the flash content to another board without sending all the source trough a UART. The other idea I mentioned was to "dump" the added flash memory content and create an assembler source used in the AVR assembler. The reason to differentiate between development board and the target device is that the target device is that the target device has only one USART port connected. And this port is used on a RS485 field bus. There is no chance to connect that device to a RS232 port on the PC. Best regards, Helge |
|
From: Martin N. <amf...@mg...> - 2021-08-31 09:03:10
|
On Tue, 31 Aug 2021 06:27:50 +0200 Helge Kruse <Hel...@gm...> 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/ > Amf...@li... > 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: rep...@mg... (Address will be valid throughout 2021). |
|
From: Tristan W. <ho...@tj...> - 2021-08-31 08:40:30
|
Hello and welcome Helge, > 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. This is the usual way AmForth is used. However it is possible to write words in AVR assembler and add them to the build process that creates the two hex files that make up the base AmForth system (these are the two hex files that are initially flashed). Such words would be available to you without having to send Forth code over the UART. > I want to develop a Forth application for a target that uses the > ATmeage256 USART for the application data. By default, AmForth only knows about one UART and is expecting to receive Forth over it. If instead, you want to receive application data over that UART you could write a Forth word(s) to parse that application data received over the UART (write the Forth word to do it, send it over UART, execute the Forth word, disconnect the UART from PC, connect UART to application data source). However, I think this would be painful to develop and (very) limited in terms of rate of data that could be handled. If the UC on which AmForth is running has multiple UARTs then it is possible to use these for application data. This I have done in the past https://tjnw.co.uk/files/uarts/fsm-uart.mp4 but it means writing your own UART handlers (which can be done in Forth). Again, application data rate may be limiting. You mentioned the ATmega256 - were you looking at ATmega256X or the ATmega256RFR2? They all have multiple UARTs I think. Kind regards, Tristan |
|
From: Helge K. <Hel...@gm...> - 2021-08-31 04:28:00
|
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 |
|
From: Michael P. <mp...@pl...> - 2021-06-18 22:53:26
|
Hello Erich, I've dusted off an MSP430 board I have here and might have to load it with noforth just to get an idea of what his code is doing with the BME280. He uses some sort of defining word called 'value', that I need to look up with the MSP430. There are a lot of others that will jump out as I pour over this listing, I'm sure. Getting ready for our Field Day weekend, which starts tomorrow at 11:00 local time and runs through Sunday 11:00. This will be the last year we work under COVID rules, meaning I work from home and log via the internet. We normally head out for a camping weekend on some Forest Service land that we obtain a permit to use. It's located at around 6500 feet and gives us nice coverage. Have you tried experimenting with the MSP430? As I remember, I picked up a few of these boards back when they first were introduced. I bought a few of them (called Launchpads) and played with one for a while, but wanted to more than it was capable of at the time. So many parts ... so little time ... !! :) Kind regards, Michael k6MLE On 6/17/2021 2:38 AM, Erich Wälde wrote: > Hello Michael, > > Michael Picco <mp...@pl...> writes: > >> Hello! >> >> I finally have figured out how to efficiently interact with Amforth on my >> mega2560 and have installed much of the I2C stuff on it. > Good! > >> Question: >> >> Has anyone worked out how to talk to the BME280 sensor using Amforth? Wading >> through the spec sheet tells me it's going to be a challenge. It would be >> nice not to reinvent the 'wheel', if someone has already done the >> heavy-lifting! > I have, much to my dismay, spent more than 20 hours on this. Not > once in my life have I seen such an awkward interface. > Unbelievable. > > The C code on > https://github.com/BoschSensortec/BME280_driver/blob/master/bme280.c > is working. It is just not meaningfully documented. Code using > this can be found here > https://github.com/adafruit/Adafruit_BME280_Library > > You have to very carefully study the datasheet and obey the > "signed" vs. "unsigned" song and dance. I have written C code to > see, whether my intermediate calculations were correct. I have > managed to calculate temperature and humidity. The humidity > values were significantly too low (I do have more sensors). And > on pressure values I gave up after wading through about halfway. > > That being said: I was pointed to a working implementation for > noForth on MSP430, published in "Vierte Dimension" 2020-01 > https://forth-ev.de/wiki/vd-archiv > > > As I said, working the sensor with C is ok, since the adafruit > library is written and working. Working the sensor in Forth is > kind of horrible, because you need to reverse engineer the > calculation. WHY not spending the silicon to do the calculation > "on board" and produce linear, compensated readings is beyond my > imagination. > > I pulled the one BME280 sensor out, I will happily give it away. > And I ordered a handful of expensive Sensirion SHT85 sensors for > temperature, humidity and a mpx6115 sensor for pressure (needs > an ADC). The sensirion sensors worked for me after a couple > hours. I did not figure out, how to check the crc that comes > with the data --- but that is left for another time. > > I can send my code re. BME289 your way, if you are interested. > But do not spend countless hours on a misdesigned interface ... > > > Cheers, > Erich > |
|
From: Erich W. <ew....@na...> - 2021-06-17 09:39:00
|
Hello Michael, Michael Picco <mp...@pl...> writes: > Hello! > > I finally have figured out how to efficiently interact with Amforth on my > mega2560 and have installed much of the I2C stuff on it. Good! > > Question: > > Has anyone worked out how to talk to the BME280 sensor using Amforth? Wading > through the spec sheet tells me it's going to be a challenge. It would be > nice not to reinvent the 'wheel', if someone has already done the > heavy-lifting! I have, much to my dismay, spent more than 20 hours on this. Not once in my life have I seen such an awkward interface. Unbelievable. The C code on https://github.com/BoschSensortec/BME280_driver/blob/master/bme280.c is working. It is just not meaningfully documented. Code using this can be found here https://github.com/adafruit/Adafruit_BME280_Library You have to very carefully study the datasheet and obey the "signed" vs. "unsigned" song and dance. I have written C code to see, whether my intermediate calculations were correct. I have managed to calculate temperature and humidity. The humidity values were significantly too low (I do have more sensors). And on pressure values I gave up after wading through about halfway. That being said: I was pointed to a working implementation for noForth on MSP430, published in "Vierte Dimension" 2020-01 https://forth-ev.de/wiki/vd-archiv As I said, working the sensor with C is ok, since the adafruit library is written and working. Working the sensor in Forth is kind of horrible, because you need to reverse engineer the calculation. WHY not spending the silicon to do the calculation "on board" and produce linear, compensated readings is beyond my imagination. I pulled the one BME280 sensor out, I will happily give it away. And I ordered a handful of expensive Sensirion SHT85 sensors for temperature, humidity and a mpx6115 sensor for pressure (needs an ADC). The sensirion sensors worked for me after a couple hours. I did not figure out, how to check the crc that comes with the data --- but that is left for another time. I can send my code re. BME289 your way, if you are interested. But do not spend countless hours on a misdesigned interface ... Cheers, Erich -- May the Forth be with you ... |
|
From: Michael P. <mp...@pl...> - 2021-06-17 00:26:27
|
Hello! I finally have figured out how to efficiently interact with Amforth on my mega2560 and have installed much of the I2C stuff on it. Question: Has anyone worked out how to talk to the BME280 sensor using Amforth? Wading through the spec sheet tells me it's going to be a challenge. It would be nice not to reinvent the 'wheel', if someone has already done the heavy-lifting! Kind regards, Michael K6MLE |
|
From: Martin N. <amf...@mg...> - 2021-06-07 08:12:12
|
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<<RWWSRE) | (1<<SPMEN) call Do_spm rjmp Return 2. Added a "Crash Trap" after NRWW_START_ADDR and immediately before the flashing code. This performs a reset rather than bumbling on and possibly overwriting some arbitrary FLASH. I chose this snippet: nop ; Some nops to synchronise. nop jmp_ PFA_COLD Certainly a Forth in development can end up executing empty FLASH memory. In the big Megas (store-i_big.asm) in particular, empty memory leads inexorably to the flashing code. All this rather depends on the function of M/C code instruction $FF, which seems undefined, so is probably a noop. 3. Disabled interrupts much earlier. Before any page is erased these should be switched off. Why? The user may be writing to Page 0 or to the page containing "isr:". Since time effectively stands still during flashing, I issue a CLI at the earliest possible moment. The Atmel example above says: "It is assumed that either the interrupt table is moved to the Boot loader section or that the interrupts are disabled." Under these circumstances the CLI in "dospm:" is no longer required. Feel free to dispute any of these points; I'm all ears. Remember: Aunty Atmel always knows best. She is omniscient here. Source files: amforth-6.9/avr8/words/store-i_big.asm amforth-6.9/avr8/words/store-i_nrww.asm -- Regards, Martin Nicholas. E-mail: rep...@mg... (Address will be valid throughout 2021). |
|
From: Tristan W. <ho...@tj...> - 2021-06-04 09:40:00
|
Hi Michael, Glad it is working. I use amforth-shell.py which is in the tools directory. It needs python3 and pySerial to be installed to work. A basic command line looks like this amforth-shell.py --port DEVICE --speed 38400 FILE_TO_UPLOAD but there are many other options and commands (such as the directive #include). The documentation is in the python3 source. Best wishes, Tristan On 03Jun21 21:43, Michael Picco wrote: > Hi Tristan, > > I've got it up and running; even adding 'marker'. > You have probably mentioned it before, but what is the best interface to use > that will allow me to upload source files? > > Thank you for your patience! > > Kind regards, > > Michael > > On 6/2/2021 8:36 AM, Tristan Williams wrote: > > Hi Michael, > > > > I used > > > > FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m > > > > Best wishes, > > Tristan > > > > On 02Jun21 07:14, Placerville.me wrote: > > > Hello Tristan, > > > Thank you for this! I will give it a try later today. What fuse settings did you use? > > > > > > Kind regards, > > > > > > Michael > > > > > > Sent from my iPhone > > > > > > > On Jun 2, 2021, at 01:18, Tristan Williams <ho...@tj...> wrote: > > > > > > > > Hi Michael, > > > > > > > > I hope you got AmForth to build successfully under windows for the > > > > atmega2560, but if not, I have built it for my Arduino MEGA using the > > > > most recent source (r2457). > > > > > > > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/ > > > > > > > > I have uploaded the resulting hex files to > > > > > > > > https://tjnw.co.uk/amforth-bin/ > > > > > > > > I also loaded marker.frt onto the Arduino MEGA and checked that it > > > > does what it should do (see [1]). > > > > > > > > Best wishes, > > > > Tristan > > > > > > > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html > > > > > > > > > On 24May21 17:57, 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 > > > > > > > > > > > > > > > > > > > > > > > > > > On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote: > > > > > > 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". > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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: Mark R. <cab...@gm...> - 2021-06-02 15:54:48
|
On Wed, Jun 2, 2021 at 6:37 PM Tristan Williams <ho...@tj...> wrote: > Hi Michael, > > I used > > FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m > > Best wishes, > Tristan > > That makes sense. It's the same high fuse setting as I suggested but with the jtag interface activated. I don't use that so I turned it off. Where did you get the 0xDC setting for that fuse from? It really does seem to be incorrect for a chip with 4k bootloader. Having just looked back into the atmega2561 appl directory I just realized there isn't a makefile (or I suppose, a bat file for windows) with the amforth defauts in it. I was just getting ready to burn this into old 3D printer mega when I saw Tristan had already done just that. Good luck with the project! Mark > On 02Jun21 07:14, Placerville.me wrote: > > Hello Tristan, > > Thank you for this! I will give it a try later today. What fuse > settings did you use? > > > > Kind regards, > > > > Michael > > > > Sent from my iPhone > > > > > On Jun 2, 2021, at 01:18, Tristan Williams <ho...@tj...> wrote: > > > > > > Hi Michael, > > > > > > I hope you got AmForth to build successfully under windows for the > > > atmega2560, but if not, I have built it for my Arduino MEGA using the > > > most recent source (r2457). > > > > > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/ > > > > > > I have uploaded the resulting hex files to > > > > > > https://tjnw.co.uk/amforth-bin/ > > > > > > I also loaded marker.frt onto the Arduino MEGA and checked that it > > > does what it should do (see [1]). > > > > > > Best wishes, > > > Tristan > > > > > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html > > > > > >> On 24May21 17:57, 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 > > >> > > >> > > >> > > >> > > >>> On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote: > > >>> 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". > > >>> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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...> - 2021-06-02 15:36:43
|
Hi Michael, I used FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m Best wishes, Tristan On 02Jun21 07:14, Placerville.me wrote: > Hello Tristan, > Thank you for this! I will give it a try later today. What fuse settings did you use? > > Kind regards, > > Michael > > Sent from my iPhone > > > On Jun 2, 2021, at 01:18, Tristan Williams <ho...@tj...> wrote: > > > > Hi Michael, > > > > I hope you got AmForth to build successfully under windows for the > > atmega2560, but if not, I have built it for my Arduino MEGA using the > > most recent source (r2457). > > > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/ > > > > I have uploaded the resulting hex files to > > > > https://tjnw.co.uk/amforth-bin/ > > > > I also loaded marker.frt onto the Arduino MEGA and checked that it > > does what it should do (see [1]). > > > > Best wishes, > > Tristan > > > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html > > > >> On 24May21 17:57, 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 > >> > >> > >> > >> > >>> On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote: > >>> 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". > >>> > >> > >> > >> > >> _______________________________________________ > >> 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: Placerville.me <mp...@pl...> - 2021-06-02 14:15:05
|
Hello Tristan, Thank you for this! I will give it a try later today. What fuse settings did you use? Kind regards, Michael Sent from my iPhone > On Jun 2, 2021, at 01:18, Tristan Williams <ho...@tj...> wrote: > > Hi Michael, > > I hope you got AmForth to build successfully under windows for the > atmega2560, but if not, I have built it for my Arduino MEGA using the > most recent source (r2457). > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/ > > I have uploaded the resulting hex files to > > https://tjnw.co.uk/amforth-bin/ > > I also loaded marker.frt onto the Arduino MEGA and checked that it > does what it should do (see [1]). > > Best wishes, > Tristan > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html > >> On 24May21 17:57, 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 >> >> >> >> >>> On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote: >>> 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". >>> >> >> >> >> _______________________________________________ >> 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...> - 2021-06-02 08:18:35
|
Hi Michael, I hope you got AmForth to build successfully under windows for the atmega2560, but if not, I have built it for my Arduino MEGA using the most recent source (r2457). https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/ I have uploaded the resulting hex files to https://tjnw.co.uk/amforth-bin/ I also loaded marker.frt onto the Arduino MEGA and checked that it does what it should do (see [1]). Best wishes, Tristan [1] http://amforth.sourceforge.net/TG/recipes/Forget.html On 24May21 17:57, 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 > > > > > On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote: > > 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". > > > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Martin N. <amf...@mg...> - 2021-05-25 06:01:34
|
On Mon, 24 May 2021 17:57:51 -0700 Michael Picco <mp...@pl...> 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: rep...@mg... (Address will be valid throughout 2021). |
|
From: Michael P. <mp...@pl...> - 2021-05-25 00:58:09
|
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 On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote: > 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". > |
8 messages has been excluded from this view by a project administrator.
