Hi Michael,
[email protected] schrieb:
I've downloaded and examined code from both your git repository and Onno's,
but I'm not sure what I should be looking for.
my and Onno's git repo: I have agreed with Onno, that we want to use in
future only Onno's repo for development, because such fork, like mine
from Onno's repo has it's own problems. But in the moment we have this
both. Normally the "master" branch should hold the main trunk with the
current stable changes. In my repo you'll find a branch called
"tomk-devel", that's my own development branch, which will be merged
from time to time to master (if I and Onno - or others - are agree, that
this changes are ok)
The current state is: because Onno is bussy with other things, that my
"master" branch is more actual than Onno's, it holds also the changes
from CVS repo with your rewrite of ATMega48/88/168/328. I think, this
state should be usable. But I have found a bug (double free crash on
shutdown simulavr), which I have fixed on my branch "tomk-devel". In
this branch are also a big change on hwtimer (rewrite and usage of
common timer class), ATMega48 and similar have now all 3 timers. More
changes there are the possibility to build simulavr also on
MingW/Windows (in the moment ONLY simulavr, not the python module) and a
few other things (some also on tests!). If you want to get this changes,
then I'll update my master branch with my changes from "tomk-devel"
branch, so that you're able to use the "master" branch with my most
current state. If Onno has more time, then I'll synchronise my "master"
branch to Onno's, so that we can use only Onno's repo in future.
I still don't understand what gets called when when one does a make check.
It's not so really difficult. ;-) The main chain will be built on
Makefile.am, starting from this in root directory down to all
Makefile.am in subdirectories. The chain will be connected by SUB_DIRS
definitions in the Makefile.am. automake will then generate all the
frame makefile code to call ALL generated Makefiles in subdirs, starting
from root. The sub-makefiles will be called recursive. If you, for
example, want to run a special test, if somebody calls "make check" from
this subdirectory or any other above, then the easies variant is, to
create a target "check-local" with a dependency to your test target, see
regress/avrtest/Makefile.am for example.
Also, after some thought, I realized that my toggle
code would fail for SBI and CBI instructions.
It's probable that the original SBI and CBI
code would fail on the atmega{48,88,168}s.
On the atmega128, SBI and CBI are read byte, modify byte, write byte.
On the newer targets, SBI and CBI are read bit, modify bit, write bit.
The difference will show up when a relevant bit
is a flag bit that is cleared by writing a one.
We need tests for SBI, CBI, IN, and OUT.
Good idea, more good tests will improve the code. I have found the
double-free bug on extending the tests in regress/avrtest not only to
ATMega128, but also to other devices (AT90.., ATMega48)! :-) Maybe it's
not usefull to integrate tests for this menmonics into code tests from
regress.py. There are now some other test mechanisms: by python module
like in examples/python or over vcd dump like in regress/timertest
(there is only one test in the moment, I work hard to extend this and
make it more usefull ;-) )
Some of them need to depend on the CPU.
Really? In my oppinion it's a variant of the port system? (but different
cpu's have different port systems link other hardware) I'll look in
datasheets, maybe I'm mistaken.
So, I hope, that helps you. For me it's enough today. :-) cu, Thomas
_______________________________________________
Simulavr-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/simulavr-devel
