[avr-libc-dev] Re: simulavrxx build problems

[William Rivet]

Ahh...now I remembere. 

I don't have time to give a proper response, however I can say that you
should not look at the Makefile first, you should look at the
corresponding Makefile.am as it is the input that leads to the actual
Makefiles.  src/Makefile.am shoudl be helpful.

I'd recommend learning more about the GDB and simulavrpp interface
first. i.e. run your own code in simulavrpp and control it throguh GDB.
The examples have the basics for that.

If you really need to code to get at the rigiht breakpoints, then I see
why you are interested in the build...again, the ".am" files are what
you need to look at.





On Sun, 2007-09-09 at 12:11 -0500, Michael Hennebry wrote:
> On Sat, 8 Sep 2007, William Rivet wrote:
> 
> > On Sat, 2007-09-08 at 16:20 -0500, Michael Hennebry wrote:
> > > One of the problems that I'm having is that for
> > > the most part, I can't even read the make files.
> > >
> >
> > What is it you are trying to do?
> 
> I have some multi-ATmega168 boards.
> They are poorly connected for debugging.
> Even when the problem manifests on a processor I can connect to,
> timing issues usually defeat the effort.
> 
> I would like to be able to simulate interprocessor
> communication and charlieplexed LEDs.
> 
> I would like to be able to set "breakpoints" based
> on criteria complex enough to require code.
> 
> To do these things, I will need to edit the source.
> I started to write atmega168.h and atmega168.cpp
> based on atmega128.h and atmega128.cpp,
> but it occured to me that even if I accomplished
> that, I wouldn't know what to do with the result.
> 
> > > It would be nice to have overviews of
> > > what makes what from what and what runs what.
> > >
> > This is true. The root directory includes the conventional INSTALL file
> > that describes configuring, building and installing. I'm not saying they
> > are great, but it can get things started.
> 
> I did get it built.
> Bill helped me with that,
> but I still had to fix things.
> What I remember offhand:
> Flags for position-independent code.
> The directory for python.h
> The hexadecimal version number for python.
> 
> > In the examples directory there is a readme about the example targets.
> > It's not much, but that's what exists ATM.
> 
> I've run dogdb and do_python.
> I'm not clear on what to do to run my own avr code.
> 
> > > I'm reading up on swig,
> > > but I've never used it before.
> > > Does swig make simulavr.py and simulavr_wrap.cpp?
> > > If so, I've been unable to find the Makefile command that does it.
> > > Is _simulavr.so made from simulavr_wrap.cpp?
> > >
> > Yes. Swig makes interfaces between high level languages and C/C++ code.
> 
> What is the input to swig?
> I've not been able to find the swig command in the make files.
> 
> > > What is the startup sequence?
> > > That is, who invokes whom on the way to the main loop?
> > > During the  main loop,
> > > who sends what information to the outside world? How?
> > > Who gets information from the outside world? How?
> >
> > I'm just guessing here though, I'm sorry if I'm off target.
> 
> As noted above, I'm going to need to add code to the simulator.
>