Hello Daniel,
thanks for your answer!
On 24/06/17 21:05, Daniel Drotos wrote:
On Sat, 24 Jun 2017, tg9...@gmx-topmail.de wrote:
This means that a program outside of uCsim needs to monitor the reply
from the µC code before the next line of input can be sent
(handshake, half-duplex operation).
Well, I don't have solution for this scenario. What about expect? I've
never used it, but it is for kind of similar problems.
I had looked into using `expect` but I think that it's not flexible
enough for scripting test interaction.
* I need to interact with the same simulator process from different
sides for an extended period of time (command, and serial)
If you have to do it in sync, I don't know how could you do it. Once,
I've planned to implement a command which pushes data directly to
USART input, so every input would be controllable from one command
line. Combined with breakpoints, it could be some (complicate) solution.
Using the Python telnet library leads to surprisingly simple solutions:
```
#!/usr/bin/env python
import sys
import telnetlib
HOST = "localhost"
path = "f/inter.fs"
tn = telnetlib.Telnet(HOST,10000)
tn.read_until("menu\r\n")
with open(path) as source:
for line in source.readlines():
tn.write(line + '\r')
print tn.expect(['(\v|\n)'])[2]
```
In this case the regexp in `tn.expect` line does the synchronization
(either '\v' (pace) or '\n' are expected). The `tn.read_until` line
deals with the `uCsum` telnet "hello message".
I tried using named pipes as an alternative to sockets but that
didn't work.
You know that opening of a pipe is blocked until other side is opened.
When you start ucsim:
mkfifo i o
sstm8 -Suart=1,in=i,out=o
OS blocks it in open of "i". You have to go to an other window/login
etc, and open other side of i:
cat prepared_input.txt >i
(or nc, or your other program), now ucsim can go on and try to open
"o", but it blocks again, so you have to pick an other window and open
other side of o:
cat o >grab.txt
and ucsim can continue.
For most problems this is a good solution. However, I guess that for
tightly coupled I/O the telnet approach works better.
Strangely, writing prepared simulator input to a file and using it
with the "in" attribute didn't work either: the file specified with
the "out" attribute was never written.
Interesting, it works for me. Can you tell me more about it?
My second (quote overload) message to the list (sorry everybody!)
contained the answer:
> found the reason for the "strange" behaviour described below, which
is maybe the key to a solution on my side:
> `netcat` depends on TTY line processing, which means that newline
gets consumed instead of being passed on to the UART simulation through
the socket. A work around is inserting `CTRL-V` (verbatim) before
`CTRL-M` (newline).
> Note that the TTY's control character for "verbatim" can be read from
the output of `stty -a` ("lnext = ^V;").
The Python library also has a solution to this complication.
Daniel
I forgot your problem about CTRL-x. It has a bug indeed, becouse it is
always interpreted, even if usart input file is non-tty. You can
workaround it by changing escape charater to somthing non-used one. If
the communication is non-binary, it probably can be zero. You can
change it with:
expr uart1_esc_char=0
Your work is, as always, highly appreciated! Thanks!
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
