mP 602 test

[janni]

Problems that prevented me so far from using version 6 for larger programs seem to be gone now. For... to loop implementation needs attention but works with simple numerical limits.
And I could finally appreciate how good the IDE is compared to version 5. There are still some quirks, the most unnerving being concentrated in debugger (like reaction to clrwdt instruction), but even there the improvement is considerable.

There is naturally still room for further improvement. For example there are problems with pointers to record fields.

Some errors are ilustrated in the following simple code compiled for 18F4620 processor

Code: Select all

type  ParDat = record
		   ParMin: byte;
		   ParMax: byte;
		   ParVal: byte;
		   ParUni: boolean;
	    end;

var  parr:ParDat; absolute $200;
     ParDatp: ^ParDat;

begin
  ParDatp:=@parr;
  parr.ParMin:=1;
  parr.ParMax:=4;
  parr.ParVal:=128;
  parr.ParUni:=false;

  if ParDatp^.ParMax.0=1 then
   inc(ParDatp^.ParMin);

  if ParDatp^.ParUni then
   ParDatp^.ParUni:=false;

// inc(ParDatp);
... 

Both if... then instructions behave like the boolean expresions in them were always true. In the first one, lower pointer byte is checked instead of the pointer destination, the second does not check the ParUni field, but if the value of the whole pointer is zero.

The commented instruction inc(ParDatp) causes 'Argument is out of range' error.

Returning to debugger, one could live with the reaction to clrwdt command using DEFINE and IFDEF compiler directives, if not for the fact that the DEFINE directive is local so, to block all clrwdt commands while debugging, one has to use it in all units. Commenting and uncommenting them all depending on wheather one is debugging or compiling for downloading to processor is tiresome.

[zristic]

Yes, the if clause has this problem with complex structures. Try this
if (ParDatp^.ParUni <> 0) then
and see what happens.

As for simulator... hmm. Since we released mikroICD, the simulator seems to be less important. More and more users appreciate mikroICD and our management will probably very soon ask us to pay less attention to simulator. In other words, I doubt we will do any complicated repairs, such as support for CLRWDT. Simply, mikroICD does it all better and faster.

I am not the one to decide, if you are trying to convince me in the opposite

[janni]

Hmm! Are you telling me there is a wall I may crack my skull on trying to go through? As I cannot influence the mythical management you're the one to hear complaints.

Anyway, you well know that I don't care about full implementation of clrwdt. Let the debuger just treat clrwdt command as well as clrwdt assembly instruction as nop so the simulation may proceed and the problem is solved.

I'm forced to use the simulator mostly to check what and why the compiler does wrong. That's not criticism, just necessity. I understand that the mE team puts all the effort possible to improve the compiler, but the thruth is, the compiler still has it's deficiences and simulator helps to find workarounds.

So please do some modifications before the management forbids you .

[janni]

Simply, mikroICD does it all better and faster.

mikroICD may do it on universal boards mE produces, but what about final prototypes, or cases where you simply cannot use the universal board (like most of my designs)?