avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Weddington
Subject: RE: [avr-libc-dev] Re: simulavrxx build problems
Date: Tue, 11 Sep 2007 10:04:15 -0600

Hi Bill, Michael,

No offense, but can we move the conversation over to the simulavr-devel list
where it's more appropriate than avr-libc-dev? I've CCed the simulavr-devel
list.

Thanks,
Eric Weddington

> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of William Rivet
> Sent: Sunday, September 09, 2007 11:53 AM
> To: Michael Hennebry
> Cc: address@hidden
> Subject: [avr-libc-dev] Re: simulavrxx build problems
>
> 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.
> >
>
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>






reply via email to

[Prev in Thread] Current Thread [Next in Thread]