Re: [Simulavr-devel] Net/TxData Magic Pin Thoughts

[Knut Schwichtenberg]

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


address@hidden schrieb:
> On Wed Apr  1 17:27 , Joel Sherrill  sent:
> 
>> address@hidden 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
> address@hidden
> "War is only a hobby."