Problems found with existing digests:
Package suse131_libSDL
1c4d17a53bece6243cb3e6dd11c36d50f851a4f4 [recorded]
da39a3ee5e6b4b0d3255bfef95601890afd80709 [calculated]
Package suse131_libdbus
de99fcfa8e2c7ced28caf38c24d217d6037aaa56 [recorded]
da39a3ee5e6b4b0d3255bfef95601890afd80709 [calculated]
Package suse131_qt4
94daff738912c96ed8878ce1a131cd49fb379206 [recorded]
886206018431aee9f8a01e1fb7e46973e8dca9d9 [calculated]
Problems found locating distfiles for atari800, compat12, compat 13,
compat14, compat15, compat20, compat30, compat40, compat50,
compat50-x11, compat51, compat51-x11, compat60, compat61,
compat61-x11, fmsx, osf1_lib, vice, xbeeb, xm7.
Otherwise, existing SHA1 digests verified and found to be the same on
the machine holding the existing distfiles (morden). All existing
SHA1 digests retained for now as an audit trail.
simulavr asks for libiberty.a.
With avr-gcc 4.5.3 and avr-binutils-2.23.2, binutils is installing
libiberty.a
But with new binutils-2.24, it won't install libiberty. Instead,
avr-gcc-4.8.3 will provied libiberty.
Makefile (of simulavr) now has pointer to PATH of libiberty now
as:
CONFIGURE_ARGS+= --with-libiberty=${PREFIX}/lib/gcc/avr
(Add patches)
patch-src_systemclock_cpp (rename from patch-src_systemclock.cpp)
patch-src_systemclock_h
patch-src_traceval_cpp
patch-src_traceval_h
clang flags as resize unresolved reference,
backport from git repository (as of 2013-09-15).
patch-examples_atmel_key_StdDefs_c Status: Locally Added
passing argument 1 of 'strlen' differ in signedness [-Wpointer-sign]
Raw simulavr-1.0.0 does not build. Some patches, and SUBST to
convert MACROS etc., are added reflecting git repository
(These will be unnecessary at next release, hopefully).
(Upstream)
Bump the version
simulavr-0.1.2.1 to
simulavr-1.0.0
(From manual-1.0.pdf)
What features are new:
- Run multiple AVR devices in one simulation. (only with interpreter
interfaces or special application linked against simulavr library)
Multiple cores can run where each has a different clock frequency.
- Connect multiple AVR core pins to other devices like LCD, LED and
others. (environment)
- Connect multiple AVR cores to multiple avr-gdb instances. (each on
its own socket/port number, but see first point for running multiple
avr cores)
- Write simulation scripts in Tcl/Tk or Python, other languages could
be added by simply adding swig scripts!
- Tracing the execution of the program, these traces support all
debugging information directly from the ELF-file.
- The traces run step by step for each device so you see all actions
in the multiple devices in time-correct order.
- Every interrupt call is visible.
- Interrupt statistics with latency, longest and shortest execution
time and some more.
- There is a simple text based UI interface to add LCD, switches, LEDs
or other components and can modify it during simulation, so there is
no longer a need to enter a pin value during execution. (Tcl/Tk
based)
- Execution timing should be nearly accurate, different access times
for internal RAM / external RAM / EEPROM and other hardware
components are simulated.
- A pseudo core hardware component is introduced to do "printf"
debugging. This "device" is connected to a normal named UNIX socket
so you do not have to waste a UART or other hardware in your test
environment. (How?)
- ELF-file loading is supported, no objcopy needed anymore.
- Execution speed is tuned a lot, most hardware simulations are now
only done if needed.
- External IO pins which are not ports are also available. (E.g. ADC7
and ADC8 on ATmega8 in TQFP package.)
- External I/O and some internal states of hardware units (link
prescaler counter and interrupt states) can be dumped ot into a VCD
trace to analyse I/O behaviour and timing. Or you can use it for
tests.
texi2dvi and texi2html exist, so that configure believes that
the documentation is wanted. Afterwards just patch the Makefile
to not really use those as intended according.
PR pkg/27596.
The Simulavr program is a simulator for the Atmel AVR family of
microcontrollers. Simulavr can be used either standalone or as a
remote target for gdb. When used in gdbserver mode, the simulator
is used as a backend so that gdb can be used as a source level
debugger for AVR programs.
