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: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of William Rivet > Sent: Sunday, September 09, 2007 11:53 AM > To: Michael Hennebry > Cc: [email protected] > 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/avr-libc-dev > _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
