Hi Daniel,
thanks for the answer!
However, the STM8 code I intend to test implements an interactive
console. An important detail is that , and I've got the following
problems with the proposed solution:
* The processing of serial input data by the simulator code takes time.
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).
* I need to interact with the same simulator process from different
sides for an extended period of time (command, and serial)
I tried using named pipes as an alternative to sockets but that didn't
work. 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.
Best Regards,
Thomas
On 24/06/17 12:27, Daniel Drotos wrote:
On Fri, 23 Jun 2017, tg9...@gmx-topmail.de wrote:
I'd like to use the uC simulation uCsim for test automation, and my
use-case requires the uCsim serial port simulation to exchange
information through a script.
You can find some examples for this usage in ucsim source code, see
example, s51.src/test, stm8.src/test directories. Becouse they are
hard to follow, I'll try to summarize a mini-HOWTO.
Main rule is that you sould not use interactive terminals but use
files instead. If ucsim detects non-tty files, it assumes
non-interactivity and will not issue telnet commands, so that
"garbage" will not appear.
Using file for serial comminication is easy. Prepare input content in
a file and start ucsim with:
-Suart=1,in=prepared.txt
option, or:
-Suart=1,in=prepared.txt,out=grabbedout.txt
Automation of command console is more problematic but there are some
tricks for it.
Do not use -Z option, but prepare commands in a file and pass this to
simulator. If you do not need to execute commands after simulation,
you can use -C option to pass command file:
-C commands.txt
Becouse it should not contain "run" command, you should use -g (or -G)
as well:
-C commands.txt -G
ucsim will execute content of "commands.txt" and start the simulation
after. If you use -G instead of -g, it will quit when the simulation
stops somehow (see later).
If you need commands after run, it is better to use redirection:
cat "commands.txt"|sstm8 ...
or
sstm8 ... <commands.txt
On windows, I recommend redirection instead of using pipe.
Command script can contain preparation commands, run command, and
status check commands after the simulation.
Every command script which has "run" command, must be executed on a
non-interactive console, otherwise the very first command line after
the run will be recognized as "enter press" and stop the simulation.
Redirection is a way to make the console non-interactive. Other way
can be a command placed in the script itself:
set console interactive off
If you use status check commands (dump, etc.) and want to check the
results later, redirect output as well:
sstm8 <commands.txt >result.txt
You can separate output of status check commands to different files,
using ucsim command redirection:
dc ... >out_of_dc.txt
dump ... >dump.txt
dump command accepts file format specifier:
dump /format params >out_file.txt
format can be s (string), h (hex, this is the default), i (intel hex),
b (binary).
If you do not use other consoles (do not use -Z) simulator will quit
after executing command script, so quit/kill command is not needed.
Started simulation can be stopped in several ways: using fetch
breakpoint, event breakpint, or simulator interface.
Using fetch breakpoint needs some preparation:
- compile with sdcc
- use -debug to generate debug info
- use -debug when link, to produce cdb file
- define a function to place a breakpoint on it
- call that function to stop the simulation
when start ucsim, do not use .ihx file extension:
sstm8 hex_file_name
ucsim will load ihx file, and will automaticaly load cdb file with the
same name. You can prepare the breakpoint using function name:
break stopper_function_name
when the program calls this function, breakpoint will stop the
simulation, run command finishes, and script execution continues.
Using event breakpoint is probably simpler, this method is used in
sdcc regression tests.
Select a memory location which is acessible but do not used by the
real hardware. In simulator script, define an event breakpoint on the
selected location, for example:
break rom read 0x27fff
in simulated program perform a read on that location to stop the program:
volatile char c= *(char *)0x27fff;
Using the simulator interface is the most flexible way. Select a
memory location which is not used by the real hardware. Place the
interface behind that location by turning it on. It can be turned on
in two ways. Using -I option:
-I rom[0x27fff]
or in simulator script:
set hw simif rom 0x27fff
Simulated program can use this location to interact with the
interface. "Stop" feature can be activated by sending "stop" command:
unsigned char * volatile sif;
sif= (unsigned char *)0x27fff;
*sif= 's';
Daniel
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
