Re: [Simulavr-devel] Simulavr error

[Klaus Rudolph]

Knut Schwichtenberg schrieb:
> Bill,
>
> 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 :-)

 Klaus