Re: [Simulavr-devel] Help with New Example

[Joel Sherrill]

Knut Schwichtenberg wrote:
> Joel,
>
> Joel Sherrill wrote:
>   
> > 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. :(
> >     
> Keep cool ;-). I copied only the first part of that window into the mail. The PC
> I'm write this response does not have the actual version of simulavrxx and today
>  I need to make some trace files for another project. So there are more lines
> and I'll send them to you.
>
>   
OK.  I am just frustrated. It seems like it should be easy.
I have looked at my feedback.tcl and am pretty sure
I copied too much from stdiodemo but still am apparently
not doing something right.
> > 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.
> >     
> Sounds good. There are Serial connections and LCD stuff which might become
> targets for the autorouter.
>
>   
It would make hooking up the standard peripherals
much easier and avoid people repeating what you are
helping me through.
>  > 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.
> >     
> Okay, that's fine. For this purpose Klaus had a special main and the
> checkdebug.tcl is easily able to handle multiple CPU's.
>
>   
Yes and we might be able to generalize some framework.
Just takes some thought.
> > ...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.
> >     
> There are some patchjes around for the verilog-IF. Currently I'm not sure if the
> TCL approach is better than verilog or if I compare apples and peaches. But e.g.
> the Scope function of simulavrxx is empty and if verilog is able to handle a
> dynamic scope without programming it might be better to take that direction. For
> a multi-CPU simulation you might also need a RS485 driver. That might be easier
> to implement in verilog than programming simulavrxx. This is also a subject of
> discussion. Also an external "function generator" is around for verilog.
>
>   
I don't know the best approach either.    That's part of what I
am trying to figure out here.   :)
> Cheers
> Knut
>   

--joel