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

[Joel Sherrill]

Knut Schwichtenberg wrote:
> 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!
>
>   
"Joel's Window" is a first step in providing a way to simulate a real
external device at a higher level of abstraction.  It is great to be able
to manually interact at a low level with the inputs but I want to ultimately
write an "external stimulator" which pretends to be the world around
a real system. 
> 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.
>   
I was off this task for a few days and I am going to revisit it.  I think
there when you want the high/low transitions, you should attach to
the CPU pin.  But when you want to have some help, there are
SerialTXBuffer and SerialRX classes that appear to be intended to
do this type of glue help.  I think SerialTXBuffer is a logical place to
add this extra simulation helper "pin" because it is already a virtual
adapter point anyway.

So I am throwing away most of my changes to src/* in the morning.  :)

--joel
> 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."
> >     
>
>