Hi Martin
All chips support port simulation. The only differences between the types is the name of the ports - some are called PORT-1, PORT-2 etc. and some PORT-A, PORT-B etc. The correct syntax for the device should be logical though depending on how the ports are names on that device.
A couple of examples (from Coldfire project where the port is UB and 8 bits wide)
+100 PORT-UB-3 0 // set next low
+1000 PORT-UB 0c // set all bits to pattern
UARTs can be simulated from a file as follows:
+0 UART-0 = "TEST INPUT" 0d 0a // string with line feed
Here the string is injected into UART0 (UART-1, UART-2 would be used for other UARTs).
Either strings or hex can be used (and mixed as in the example)
+500 CTS-3 = 0; // assert CTS
This is an example of simulating UART control lines (this may not work for all chips though)
The following shows USB input simulation (a setup token neing injected on endpoint 0 followed by a data token on the same endpoint)
+0 SUSB-0 = a1 21 00 00 00 00 07 00 // CDC class request IN (request present settings)
+100 USB-0 // zero data token to terminate (required since the previous answer is sent later from task)
The present list of commands can be found in PortSim.c:
static char *cCommands[] = {
"UART",
"SPI",
"ETH",
"PORT",
"CAN",
"USB",
"CTS",
"BREAK",
"SUSB",
0
};
Not all may be supported for all chips but most can quite easily be added as required, as can further quite easily be added...
The biggest problem with the simulation for files is that the explorer dialog to select the file often crashes when it is opened when UART operation is in progress. I have no idea why and how it can happen since it is deep down in the dialog library code. But experience has shown that it tends to happen when UARTs are operational because disabling the serial interface allows it to successfully open the file. In emergency one can do this and then execute the simulator, which saves the file. Then one can re-activate the serial interface and command a repeat of the last simulation (since the file was saved). This works well since the dialogue doesn't need to be opened and simulation can be comfortably repeated.
It would be nice to find out why the dialog can crash (and solve it) but I really don't know where to begin. Also the dialog is rather slow to open which is rather annoying - a simpler method to search for a file could possibly be used...
Regards
Mark