Re: [Simulavr-devel] test mechanism

[ThomasK]

Hi Michael,

address@hidden 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