[Oberon] Batch processing of Oberon commands

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Sat Jun 13 11:24:14 CEST 2020


Thanks for the providing the rationale for putting in the final REQ/ACK
handshake. I have essentially adopted this now - although I have actually
never experienced that the send buffer of my development system filled up,
as you had reported below. But that may have been because I mostly work
with an emulator where the “host” and the “target” are connected by.. well..
two Unix pipes (one for each direction) instead of an actual RS232 line.

So, if I understand your code correctly, the two procedures
h2oSingleFile and o2hSingleFile in your source file

    https://git.thm.de/hg53/THM-Oberon/blob/master/serlink/serlink.c

now are more or less what ORC.Send and ORC.Receive at

   https://github.com/andreaspirklbauer/Oberon-extended/blob/master/Sources/ORC.Mod

do (after having adopted the final REQ/ACK handshake).

PS: Nice work!

-ap


—————— <Hellwig Heise> ——————————

IIRC, the processing time required for the file operations
was too big (and these were not properly guarded against the
next data sent). My protocol runs like that (a "data packet"
consisting of a count  - 255 max - and as many bytes as the
count says):

File transfer from host to target
host             target
-----------------------
REC          -> 
             <-  ACK
filename     ->
             <-  ACK
REPEAT
data packet  ->
             <-  ACK
UNTIL count < 255
REQ          ->
             <-  ACK

File transfer from target to host:
host             target
-----------------------
SND          ->
             <-  ACK
filename     ->
             <-  ACK
REPEAT
             <-  data packet
ACK          ->
UNTIL count < 255
REQ          ->
             <-  ACK

"ACK" really means "ACK|NAK", but retries are not implemented.

Furthermore, I inserted sending an ACK from the target system
after the end of bootloading (e.g.) Oberon0. The problem was
that the send buffer of my development system filled up rapidly,
the communication program "thought" that the target system was
operational and started working on its script, while the send
buffer was only slowly becoming empty.

All the details can be seen here:

https://git.thm.de/hg53/THM-Oberon

The project is publicly accessible, so I hope that you can look
into it. If you cannot (perhaps because our IT department blocks
accesses), please send me a note. I will happily transfer the
project to GitHub then.

Best,
Hellwig



More information about the Oberon mailing list