Re: [Amforth] Compiling for a headless target

2021-09-06 Thread Helge Kruse 

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


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

2021-09-05 Thread Erich Wälde 
Hello Helge,

Helge Kruse  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< _finish on error 
(zero flag=0)

   lds xl,usart_rx_in  ; xl = i_in
   ldi zl, low(usart_rx_data)  ; Z = [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 = _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

Re: [Amforth] Compiling for a headless target

2021-09-05 Thread Helge Kruse 

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



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

2021-09-04 Thread Erich Wälde 
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  writes:

> Instead of dumping the contents from the target I found another
> approach. The 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 ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

2021-09-04 Thread Helge Kruse 



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  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


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

2021-08-31 Thread Helge Kruse 

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


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

2021-08-31 Thread BK Navarette 
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 <
amforth-devel@lists.sourceforge.net> wrote:


On Tue, 31 Aug 2021 06:27:50 +0200
Helge Kruse  wrote:


Hello, I am new to amForth.

amForth is an interactive Forth. The compiler runs on the target and
writes to the flash memory of the device. This requires to send all
the source code through the UART interface.

I want to develop a Forth application for a target that uses the
ATmeage256 USART for the application data. In that case it would be
desired to compile the application, create a hex file and use USBasp
to flash it to the target.

How can I compile the Forth words, probably with the AVR assembler,
for a target without a free UART? Is there any idea of a cross
compiler or generating of assembler source code that could be place
in a file lilke appltrunkey.asm.

Are there other ways to approach?

Best regards,
Helge



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel



ATmegas have at least two USARTs, I'd use one of them for your extra
interface. The advantages of Forth's interactivity is lost if you can
no longer interact with it via the terminal - you might as well write
in C.

--
Regards,

Martin Nicholas.

E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2021).


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

2021-08-31 Thread George Herzog 
Martin Nichols has offered the simplest solution.

On Tue, Aug 31, 2021 at 5:03 PM Martin Nicholas via Amforth-devel <
amforth-devel@lists.sourceforge.net> wrote:

> On Tue, 31 Aug 2021 06:27:50 +0200
> Helge Kruse  wrote:
>
> > Hello, I am new to amForth.
> >
> > amForth is an interactive Forth. The compiler runs on the target and
> > writes to the flash memory of the device. This requires to send all
> > the source code through the UART interface.
> >
> > I want to develop a Forth application for a target that uses the
> > ATmeage256 USART for the application data. In that case it would be
> > desired to compile the application, create a hex file and use USBasp
> > to flash it to the target.
> >
> > How can I compile the Forth words, probably with the AVR assembler,
> > for a target without a free UART? Is there any idea of a cross
> > compiler or generating of assembler source code that could be place
> > in a file lilke appltrunkey.asm.
> >
> > Are there other ways to approach?
> >
> > Best regards,
> > Helge
> >
> >
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> >
>
> ATmegas have at least two USARTs, I'd use one of them for your extra
> interface. The advantages of Forth's interactivity is lost if you can
> no longer interact with it via the terminal - you might as well write
> in C.
>
> --
> Regards,
>
> Martin Nicholas.
>
> E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2021).
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

2021-08-31 Thread Helge Kruse 

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


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

2021-08-31 Thread Martin Nicholas via Amforth-devel 
On Tue, 31 Aug 2021 06:27:50 +0200
Helge Kruse  wrote:

> Hello, I am new to amForth.
> 
> amForth is an interactive Forth. The compiler runs on the target and
> writes to the flash memory of the device. This requires to send all
> the source code through the UART interface.
> 
> I want to develop a Forth application for a target that uses the
> ATmeage256 USART for the application data. In that case it would be
> desired to compile the application, create a hex file and use USBasp
> to flash it to the target.
> 
> How can I compile the Forth words, probably with the AVR assembler,
> for a target without a free UART? Is there any idea of a cross
> compiler or generating of assembler source code that could be place
> in a file lilke appltrunkey.asm.
> 
> Are there other ways to approach?
> 
> Best regards,
> Helge
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 

ATmegas have at least two USARTs, I'd use one of them for your extra
interface. The advantages of Forth's interactivity is lost if you can
no longer interact with it via the terminal - you might as well write
in C.

-- 
Regards,

Martin Nicholas.

E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2021).


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

2021-08-31 Thread Tristan Williams 
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



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Compiling for a headless target

2021-08-30 Thread Helge Kruse 

Hello, I am new to amForth.

amForth is an interactive Forth. The compiler runs on the target and
writes to the flash memory of the device. This requires to send all the
source code through the UART interface.

I want to develop a Forth application for a target that uses the
ATmeage256 USART for the application data. In that case it would be
desired to compile the application, create a hex file and use USBasp to
flash it to the target.

How can I compile the Forth words, probably with the AVR assembler, for
a target without a free UART? Is there any idea of a cross compiler or
generating of assembler source code that could be place in a file lilke
appltrunkey.asm.

Are there other ways to approach?

Best regards,
Helge



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel