Menu
▾
▴
amforth-devel
|
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: 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: 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: 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: 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: 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: 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: 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: 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-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-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-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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X