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