Hi, back from a training I'll add my 2 Cents. 1. Oldage GUI There is a serial receiver and transmitter window that needs to be wired and than displays the characters received or gives the opportunity to enter data. There might be improvements possible but for the first glance it should be okay.
2. Joel's Window For me there Joel's window "UI" is a simplified version of the oldage GUI. So the same functions like a receiver and a transmitter should be around. Looking to the this a system engineer that would like to keep the architecture stable this idea has to be rejected! So I come back to my basic question: What is the benefit of Joel's window solution? If there is a display function around for serial data I don't care if this is a GUI or a character based display. What was "less optimal" was the transition display with 0 and 1. Maybe the display in gui.tcl needs improvement such as interpret ESC-Sequences, show errors,... But that leads to a different question. Currently I see the basic idea of simulavrxx is simulate the AVR's a good as possible and second provide interfaces to external programs to display the behavior of pins. Knut [email protected] schrieb: > On Wed Apr 1 17:27 , Joel Sherrill sent: > >> [email protected] wrote: > >>> If, for example, the UART is set to send 7-bit chunks, >>> but the receiver is expecting 8-bit chunks, >>> the byte-probe simulation might work even >>> if the real thing wouldn't have a chance. >>> IIRC parity and endian mismatches are also possible. >>> >>> >> Using Knut's suggestion, we could extend the >> byte interface to send setup information so this >> was available even in the byte mode. If there were a sanity >> check via a handshake message at the beginning, that >> would be great. Then the feedback could deal with bytes >> past that. > > Perhaps the probe should get a (data, setup) pair. > The setup part would be a pointer to constant and wouldn't change often. > The first part of the receiver's test would > be to see if the pointer had changed. > If unchanged, the byte would be valid. > If changed, *setup would need to be examined. > >> The byte probe is sending the same value being shifted >> out so the parity and 6/7 bit should match from a value >> standpoint. >> >> Remember my goal is to simulate a device sending >> whole messages back and forth. So it is more appropriate >> to writ this level of simulation at a byte level. >>>> I am looking at a set command on the UI something like this > > -- > Michael Hennebry > [email protected] > "War is only a hobby." _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
