Re: [Simulavr-devel] Help with New Example

[Joel Sherrill]

Knut Schwichtenberg wrote:
> Joel Sherrill wrote:
>   
> > That's what I get also.  But shouldn't I see characters that
> > are written to the UART in the feedback window?
> >     
> Well, with the GUI the characters are moved into the related object and if the
> feedback window is the character equivalent for the GUI, I would expect one set
> of characters in the feedback window and one in the starting window.
>   
I would also but shouldn't they print a non-zero value corrsponding
to what was placed in the UART?

All the set serial commands I see are like this:

FDBK RECV: --->set serialRx0 0x0<---
FDBK SET: serialRx0 ChangeValue 0x0

They all have 0 and that doesn't seem right. :(

> > I agree I need to document this but I am thrilled you can use
> > it and you see the potential. Even bigger smile.  My goal is that
> > this is a way to avoid having a lot of duplicated Tcl and users
> > can build custom things on it easily.
> >     
> If one can program TCL (sorry but I never became a friend of TCL - my world is
> perl).
>   
I am more proficient as plain old shell and sed and other friends.
I hadn't written Tcl in 10 years.  The copyright on the book
I grabbed off my shelf was 1996 but it started coming back quickly.

> > Would it make sense to have commands like "atmega128_addUart0"?
> >     
> This is very close to a ticking list or a full grown simulator like vmlab - give
> it a trial - former versions run under wine. It depends what you want to / can
> do before you start your real-world application.
>
>   
OK.  I will look at it.
> The manual wiring via Net-commands is like wire-wrapping a board. Integrated
> commands is like soldering a PCB. Both have advantages and disadvantages.
>
>   
Agreed.  But if the low level wire-wrapping commands are there,
there is nothing wrong with proving integrated commands on
top of them to make implementing common connections easier.
We can call it an autorouter if you like.
> Currently simulavr.tcl is not able to handle multi-CPU simulations what the
> kernel can do. That game is even more complex! Until the GUI is not running
> properly I'll provide an example for this.
>   
No.  My goal was simply to provide the same functionality of
the current main.cpp in Tcl so there was a baseline for the
examples without duplicating the same initialization.

I am not sure how to tackle that but willing to discuss it
and capture a design.  If things go well on getting the
testing on this first board done, I might be able to justify
implementing when I approach the second board in their
system.  Doing a multi-CPU simulation might be handy
in that case.

--
Joel Sherrill, Ph.D.             Director of Research & Development
address@hidden        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985