[Top][All Lists]

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

Re: [Simulavr-devel] Simulavr error

From: Klaus Rudolph
Subject: Re: [Simulavr-devel] Simulavr error
Date: Wed, 16 Apr 2008 08:54:00 +0200
User-agent: Thunderbird (Windows/20080213)

Knut Schwichtenberg schrieb:

William Rivet wrote:
I'll just pipe in that I'm currently working on replacing the build
system for simulavrxx with something more sane via CMake...thanks to a
little nudging by Michael Buesch :-)
Early this year I tried to build simulavrxx and got it running under Linux with ordinary make and without problems. Make was annoying and did not change for the last 15 years but GNU make is running under cygwin as well as under any *nix. What is the benefit for me as a user of simulavrxx in using CMake?

Abolutly the right question!

I use "my" old Makefile since the start of the project and it works well on ubuntu, SuSE Linux 8.0!!! and 10.1. I have installed different versions of tcl/tk and every time on other places. Simple to write the needed infos in one file for compilation (only path info for binutils and tcl/tk stuff).

No tricky search for mysterious installation requirements, no need for testing the whole system for thousands of constants.

I am tired about the "build system" discussions and many user requests here. Look for gcc in the 4.3.0 version. No trick to get the needed math libs to find, simply add them on the configure line. And as simulavrxx has nothing to configure... simply compile it with the stupid old make.

> Personally I want to use an AVR simulator,
> which forces me to install a tool chain to build it!? It's quiet bad
> that there are no simulavrxx-RPMs for the major *nix distributions.

To have rpms you have the need to have it for a lot of distros and versions of them. As I said many times: simulavrxx is a tool for developers. Each of them must! have binutils installed for avr. And if! they want to use tcl/tk scripting they have to install tcl/tk. Thats it, no more requirements! And a developer! is able to give a path to an installation directory. From my point of few it is now the point to go back to the roots.

Klaus sent me his plain makefile without any config things. The result was that the TCL-graphic interface lib was build and the anacomp example did work on this GUI. Is the current Python port working correctly for you? With the Python GUI PORTB did not change visually. Changing the analog levels in the GUI the corresponding lines in the source code were processed, but the GUI did not show the differences. With TCL everything worked fine.
Thanks :-)

If there is interest in simulavrxx, pipe up. I tend to spend time on
this when I get people asking questions (like this :-) )

Yes, I would like to have a mostly complete AVR simulator running under LINUX. As described by my documentation update there is space to improve the simulator kernel (Sleep, Bootloader, ADC, ...) and also a reduction of the host CPU requirements would be beautiful. Of course it could be a great step forward if the simulator kernel would be complete. After that it would be also a serious step forward to create the missing CPUs by a tricky preprocessing based on the ATMEL partdescription XML-files.

Yes, but there is a lot of work todo! As all the new devices have so much hardware inside... look for xmega... hard stuff.

BTW: Some month ago I asked the readers of this list to comment on a documentation update. Either my English is perfect - which I can't believe - or nobody read it - which can be interpreted as a level of interest in simulavrxx, but I did not get any feedback from the list until now.

I have actually no idea how many people are working with simulavr or simulavrxx. I think! that many people using avr studio, which is not able to do real analysis of software and also is not able to have external hardware connected. As I see also in my professional environment, nearly nobody do a full test of software, not on pc systems and also not for embedded. So there is "no need" for all the features of simulavrxx in the real world :-) It is easier for the people to run in the bugs and find them by hand... As I developed my interrupt timing analysis part of simulavrxx I had a need to answer the questions on real runtime analysis. Maybe other people using port pins and scopes for getting the runtime of interrupts?
But what I am talking about... :-)

So first I'll go on holiday and afterwards - end of next week I'll submit the documentation patch - if there is no additional update work.

Thanks for that!

And again something addressed to atmel company:
Why I asked so many times for a development tree of the hardware parts of the avr family. Which uart is equal, which differs in which bits, which is full compatible which is not?

I spoke with atmel people on the "embedded world" in nuernberg and they gave me a good fealing... but actually, 2 month after that, they did not anything... no mail, no contact, no information!

I have actually no open avr projects, so I have no personal interest for doing so much work. :-) Sorry for that!

And another sentence which I wrote many times here:
If there are problems with simulavrxx, feel free to ask :-)


reply via email to

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