Jump to content

LasseT

EstablishedMember
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About LasseT

  • Rank
    Newbrie

Profile Information

  • Gender
    Male
  • Location
    Sweden
  1. I added a new testprogram to the original posting. Maybe it will help some. Regards, Lasse T
  2. I have been using the SB V7.0 for a few days and it looks very promising ! I found some small problems when I used the large array feature. The first time I observed this was when I used a 'struct' spanning 300 'something' bytes in total. I created some small test programs with int and long variables and found some problems when using the option -idx 2. This was the easy way to describe the observation. If the test programs where compiled with the default -idx 1 everything works ok but if I use the option -idx 2 I will have a linker error and it looks like the compilation runs ok (I only guess on the last statement). My target chip is a 18F67J60 so I have quit a lot of memory. The use of large arrays will make my life easy (at least when it comes to programming :-) ). I have some more comments in the test programs but I think they are very self explained :-) /Lasse T == This is the output from the test1.c using option -idx 2======= =========================================== Building... "C:\Program Files\SourceBoost\boostc_pic18.exe" SB7_test1.c -t PIC18F67J60 -idx 2 -obj Debug -d _DEBUG BoostC Optimizing C Compiler Version 7.00 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2010 Pavel Baranov Copyright© 2004-2010 David Hobday Licensed to "me Lasse T" under Single user Full License for 2 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only SB7_test1.c success "C:\Program Files\SourceBoost\boostlink_pic.exe" /ld "C:\Program Files\SourceBoost\lib\large" libc.pic18.lib Debug\SB7_test1.obj /t PIC18F67J60 -idx 2 /d "C:\PIC_SB_v7\Debug" /p SB7_test1 Error: Failed to allocate memory for var 'd113' at address:0x000001FF crosses RAM banks BoostLink Optimizing Linker Version 7.00 http://www.sourceboost.com Copyright© 2004-2010 Pavel Baranov Copyright© 2004-2010 David Hobday failure error: failed Done ================== Then we run the same "program" but the option is now the default -idx 1 ===================================== Building... "C:\Program Files\SourceBoost\boostc_pic18.exe" SB7_test1.c -t PIC18F67J60 -idx 1 -obj Debug -d _DEBUG BoostC Optimizing C Compiler Version 7.00 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2010 Pavel Baranov Copyright© 2004-2010 David Hobday Licensed to "me Lasse T" under Single user Full License for 2 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only SB7_test1.c success "C:\Program Files\SourceBoost\boostlink_pic.exe" -idx 1 /ld "C:\Program Files\SourceBoost\lib" libc.pic18.lib Debug\SB7_test1.obj /t PIC18F67J60 /d "C:\PIC_SB_v7\Debug" /p SB7_test1 BoostLink Optimizing Linker Version 7.00 http://www.sourceboost.com Copyright© 2004-2010 Pavel Baranov Copyright© 2004-2010 David Hobday Building CASM file Memory Usage Report =================== RAM available:3808 bytes, used:519 bytes (13.7%), free:3289 bytes (86.3%), Heap size:3192 bytes, Heap max single alloc:127 bytes ROM available:131064 bytes, used:2092 bytes (1.6%), free:128972 bytes (98.4%) success Done =========Comment added October 7th by LasseT Just another testprogram for -idx 2 The long array works perfect! No problems with that what so ever. I let a long array start and span a lot of RAM banks. Testing all RAM bank crossings. If you are tired of this skip down to the BUT statement below. =============== Building... SourceBoost7\boostc_pic18.exe" SB7_test77.c -t PIC18F67J60 -idx 2 -obj Debug -d _DEBUG BoostC Optimizing C Compiler Version 7.00 (for PIC18 architecture) SourceBoost7\boostlink_pic.exe" /ld "C:\Program Files\SourceBoost7\lib\large" libc.pic18.lib Debug\SB7_test77.obj /t PIC18F67J60 -idx 2 /d C:\Users\uablto\Documents\workspace\Debug /p SB7_test77 BoostLink Optimizing Linker Version 7.00 Building CASM file Memory Usage Report =================== RAM available:3808 bytes, used:2048 bytes (53.8%), free:1760 bytes (46.2%), Heap size:1662 bytes, Heap max single alloc:127 bytes ROM available:131064 bytes, used:2054 bytes (1.6%), free:129010 bytes (98.4%) The memory layout is as follows: Adr variable 0x001 char i 0x002 bulk[94] start 0x05F bulk[94] ends 0x060/61 int e0 0x062 -- 0x178 int e1 to e139 0x179/17A int e140 0x17B/17C int d0 0x17D -- 0x17C int d1 to d64 0x1FD/1FE int d65 0x1FF start of large[LONG] array just before a RAM bank end 0x7FD end of large [LONG] array just before a RAM bank end 0x7FE/7FF is used by the for loop as a address pointer =============================== BUT: If you change the large[LONG] array length one byte (in this test from 1535 to 1536) this will push for loop address pointer one byte up and the compiler/linker will try to use 0x7FF and 0x800 for the pointer. The compilation runs OK but the linker will have some problem with this as can be seen in the printout. Error: Failed to allocate memory for var '' at address:0x000007FF crosses RAM banks BoostLink Optimizing Linker Version 7.00 http://www.sourceboost.com Copyright© 2004-2010 Pavel Baranov Copyright© 2004-2010 David Hobday failure error: failed Done ========================================================================= I can not help with a solution but I can clearly see the problem. And I'm very sure that if I had the compiler/linker sourcecode I could not help anyway :-) ======================================================================= // Lasse T SB7_test1.c SB7_test2.c SB7_test77.c
  3. Bug description: I'm reusing a C-program that is compiled with a GNU C compiler and the program works ok in that environment. No problems what so ever. When I try to compile the same program in BoostC IDE design environment it seems to work alright because I will not receive any warnings or errors. The program does not work ok when it runs on a PIC circuit. After some debugging sessions I have identified som addressing problems of "structs in structs" (or what I shall call it? pointers to structs in structs maybe). I use this quite often in my program: (&pointer_to_mainstructure->another_struct)->local_1 = "data"; and I hope this is alright according to the C language :-). No warning/no error from compiler so this is hopefully OK ? :-) comment: I have a hard time to explain this in writening but I think you can follow this in my very simple test program. ======= T E S T P R O G R A M B L O C K ===================== #include <system.h> #include <boostc.h> == Program description /* * The intention is to fill the "mainstruct" defined below with this data * $0/1 = object_first = 0x1111 * $2/3 = "struct a" local_1 = 0x5555; * $4 = "struct a" local_2 = 0x66; * $5/6 = "struct b" local_1 = 0x7777; * $7 = "struct b" local_2 = 0xEE; * $8/9 = object_1 = 0x1234; * $A/B = object_2 = 0x5678; * $C/D = object_3 = 0x9ABC; * $E/F = "struct c" local_1 = 0xCCCC; * $10 = "struct c" local_2 = 0xDD; * $11/12 = object_last = 0xAAAA; * But the result is like this * $0/1 = object_first = 0x1111 * $2/3 = "struct a" local_1 = 0x0000; * $4 = "struct a" local_2 = 0x00; * $5/6 = "struct b" local_1 = 0x0000; * $7 = "struct b" local_2 = 0x00; * $8/9 = object_1 = 0x1234; * $A/B = object_2 = 0x5678; * $C/D = object_3 = 0x9ABC; * $E/F = "struct c" locall_1 = 0x0000; * $10 = "struct c" local_2 = 0x00; * $11/12 = object_last = 0xAAAA; ==============================================================*/ struct smallstruct { int local_1; char local_2; }; struct mainstruct{ int object_first; struct smallstruct a; struct smallstruct b; int object_1; int object_2; int object_3; struct smallstruct c; int object_last; }; struct mainstruct first; //create the first struct of mainstruct type :-) struct mainstruct *First; //Pointer //======================================================================== void main(void) { First = &first; for (;{ First->object_first = 0x1111; First->object_last = 0xAAAA; (&First->a)->local_1 = 0x5555; // No warning from compiler and target wrong memory address (&First->a)->local_2 = 0x66; // No warning from compiler and target wrong memory address (&First->->local_1 = 0x7777; // No warning from compiler and target wrong memory address (&First->->local_2 = 0xEE; // No warning from compiler and target wrong memory address First->object_1 = 0x1234; First->object_2 = 0x5678; First->object_3 = 0x9ABC; (&First->c)->local_1 = 0xCCCC; // No warning from compiler and target wrong memory address (&First->c)->local_2 = 0xDD; // No warning from compiler and target wrong memory address // Test another way to access the structure objects ========================== First->a.local_1 = 0xa1a1; //Correct address in struct, OK First->b.local_1 = 0xb1b1; //Correct address in struct, OK First->c.local_1 = 0xc1c1; //Correct address in struct, OK First->c.local_2 = 0xc2; //Correct address in struct, OK First->b.local_2 = 0xb2; //Correct address in struct, OK First->a.local_2 = 0xa2; //Correct address in struct, OK } } // END OF TESTPROGRAM ======================================= Steps to reproduce: Run the testprogram and look into the memory area to see the result. (I will try to upload the project and c code file later today) Expected behaviour: If this is "bad C programming" please issue a warning or error when (&pointer->pointer)->object is used OR if it is "ok" to use this addressing ...consider it as a candidate for a future release. Is the problem 100% reproduceable: Yes! IDE version: SourceBoost IDE version 6.91 Compiler: BoostC Optimizing C Compiler Version 6.91(for PIC18 architecture) Target device: PIC18F4685 OS: Windows XP and Windows Vista (tested on both platforms) Regards, LasseT I have been trying to upload the projec file and the c code file but it does not work for me :-(. I hope that you can run my simple test program to verify the problem/bug anyway!
  4. LasseT

    18f67j60 Debug Problem

    I'm not sure if this is a bug but I have a hard time to figure out how to debug the 18F67J60. It might be a complete missunderstanding from my side of the 18F67J60 way of working :-), anyway I need some help, please. I'm back to a very simple setup program for port B that works ok for a target chip like 18F452. When I recompile the program for the 67J60 chip it behaves different. I connect a "plugin led" on port B pin 1 just to have a visual indication. IDE 6.87 and BoostC on a WinXP PC. Feedback needed :-)! /LasseT ********************************************* My very simple testprogram ============================== #include <system.h> #include <boostc.h> /* Connect a "plugin led" to portb pin 1 then try to make it turn on and off. Simple enough :-))))))))))))) */ /* Test setup for 18F452 and 18F67J60 It works for the 452 but I can not make it work in debug mode for the J60 chip. And YES I recompile when changing targets :-) */ char i; void main() { trisb = 0b00000000; //Set port B all output for(i=0;i<3;i++) //Just a simple loop to feed some data to the port { latb = 0xff; //latb will control portb even for the 18F458 latb = 0x00; latb = 0xff; portb = 0x00; portb = 0xFF; portb = 0x00; } //Lets try a new setup asm //according to Microchip :-) { clrf _portb //; Initialize PORTB by //; clearing output //; data latches clrf _latb //; Alternate method //; to clear output //; data latches movlw 0xF0 //; Value used to //; initialize data //; direction movwf _trisb //; Set RB<3:0> as inputs //; RB<7:4> as inputs } for (; { set_bit(portb,1); clear_bit(portb,1); set_bit(portb,1); clear_bit(portb,1); } } =========================== end of simple test program
  5. Some more information ================= I have been running with SourceBoost 6.31 until my HD gave up :-( a few days ago. (Yes I have a backup) But I got some problem upgrading to revision 6.33 and 6.32. Program compilation is reporting "success" but linker is reporting "fail". See below my very stripped down software for testpurpose. I think the union/struct design give the later two revisions a hard time, BUT I´m not sure !!!!!!!!!!!!!!! Everything is ok with revision 6.31. I have a lot of union/struct designs like this below in my "large protocol software" and it is running OK with releases up to 6.31. Regards Lasse T #################################################### // Very simple testprogram that has been compiled with // Revision 6.31, 6.32 and 6.33 of SourceBoost IDE // #include <system.h> #include <boostc.h> //THIS PART IS NORMALLY IN MY GENERAL IO CODE BLOCK //==================================================== // union used by show memory function //==================================================== union { unsigned int Val; struct { unsigned char low_byte; unsigned char high_byte; } bytes; } tempAddress; // // stripped down show memory program :-) for test purpose // void show_memory(unsigned int address, unsigned int mempos) { tempAddress.Val = address; unsigned int p; unsigned char a_test; unsigned char b_test; for (p=0; p< mempos; p+=8) { a_test = tempAddress.bytes.low_byte; b_test = tempAddress.bytes.high_byte; tempAddress.Val += 0x08; } } //=================================================== //================================================== // S I M P L E M A I N //================================================== void main() { char i = 1; show_memory (0x1234 ,80); while (i); } ################################################## // T E S T R E S U L T S //////////////////////////////////////// Test with Release 6.33 ====================== Building... BoostC Optimizing C Compiler Version 6.33 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Single user Lite License (Unregistered) for 0 node(s) Limitations: PIC18 max code size:8192 bytes, max RAM banks:2, Non commercial use only LTO_Compiler_Link_tst.c success BoostLink Optimizing Linker Version 6.33 http://www.sourceboost.com Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Failure Exit code was -2. Removing target: LTO_Compiler_Link_tst.hex Error: ID referenced doesn't exist yet, original ID:0x0000018F in File: 'LTO_Compiler_Link_tst.obj' Failed to locate output file 'LTO_Compiler_Link_tst.hex' Done Failed //0000000000000000000000000000000000000000000000000000000000000000 Test with Release 6.32 ====================== Building... BoostC Optimizing C Compiler Version 6.32 (for PIC18 architecture) http://www.picant.com/c2c/c.html Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Single user Lite License (Unregistered) for 0 node(s) Limitations: PIC18 max code size:8192 bytes, max RAM banks:2, Non commercial use only LTO_Compiler_Link_tst.c success BoostLink Optimizing Linker Version 6.32 http://www.picant.com/c2c/c.html Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Failure Exit code was -2. Removing target: LTO_Compiler_Link_tst.hex Error: ID referenced doesn't exist yet, original ID:0x0000018F in File: 'LTO_Compiler_Link_tst.obj' Failed to locate output file 'LTO_Compiler_Link_tst.hex' Done Failed //00000000000000000000000000000000000000000000000000000000000000000 Test with Release 6.31 ====================== Building... BoostC Optimizing C Compiler Version 6.31 (for PIC18 architecture) http://www.picant.com/c2c/c.html Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Single user Lite License (Unregistered) for 0 node(s) Limitations: PIC18 max code size:8192 bytes, max RAM banks:2, Non commercial use only LTO_Compiler_Link_tst.c success BoostLink Optimizing Linker Version 6.31 http://www.picant.com/c2c/c.html Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Building CASM file Memory Usage Report =================== RAM available:1536 bytes, used:12 bytes (0.8%), free:1524 bytes (99.2%), Heap size:500 bytes, Heap max single alloc:127 bytes ROM available:32768 bytes, used:89 bytes (0.3%), free:32679 bytes (99.7%) Successful Done //00000000000000000000000000000000000000000000000000000000000000000
  6. I have some problems with the "linker" when I upgraded from 6.31 to 6.33. This is most likely some misstake that I have done. I have no problem with the programs when I used revision 6.31 but the same code will not link with the release 6.33. Is it possible to download 6.31 again? I can not find it at the "downloading" web page. BR Lasse T
  7. LasseT

    Comparing Two 32 Bit Words

    Hi! I have done some more testing and you can find my testprogram attached. I think this problem also can be found for 16F chip. I tested this program compiled for 16F877A and found the same problem there ( == and !=). I have tested the program for 16F877A (16F in table below) and 18F458 (18F in table below). Hera are my comments on the tests and you can find the testnumbers in the program. ( queston mark indicates that it looks ok but the test is not done in a correct way. It fooled at least me when I first tested this :-) ) EQ1 Correct for 16F and 18F. EQ2 Correct for 16F and 18F. EQ3 16F ?? test always OK? / 18F error EQ4 16F ?? test always OK? / 18F error EQ5 16F ?? test always OK? / 18F error EQ6 Correct for 16F and 18F. EQ7 Correct for 16F and 18F. EQ8 16F error / 18F ?? test always not ok? EQ9 16F error / 18F ?? test always not ok? EQ10 16F error / 18F ?? test always not ok? NOT_EQ1 Correct for 16F and 18F NOT_EQ2 Correct for 16F and 18F NOT_EQ3 16F ?? test always not ok? / 18F error NOT_EQ4 16F ?? test always not ok? / 18F error NOT_EQ5 16F ?? test always not ok? / 18F error NOT_EQ6 Correct for 16F and 18F NOT_EQ7 Correct for 16F and 18F NOT_EQ8 16F error / 18F ?? test always ok? NOT_EQ9 16F error / 18F ?? test always ok? NOT_EQ10 16F error / 18F ?? test always ok? I have checked the assembler output from the compiler (18F) and think you can use the same correction for != as you used for == . I have not checked the assembler for the 16F. =============================== TESTPROGRAM =============================== #include <system.h> #include <boostc.h> typedef struct _STRUCT1 { char s1_alfa; int s1_bravo; long s1_charlie; int s1_delta; char s1_foxtrot; } STRUCT1; typedef struct _STRUCT2 { char s2_alfa; int s2_bravo; long s2_charlie; int s2_delta; char s2_foxtrot; } STRUCT2; void main() { char cmp_taken = 0x00; STRUCT2 ptest2; ptest2.s2_charlie = 0x33445566; STRUCT2 *s; s = &ptest2; STRUCT1 ptest1; ptest1.s1_charlie = 0x99887766; STRUCT1 *p; p = &ptest1; p->s1_alfa = 0x12; p->s1_bravo = 0x3456; p->s1_delta = 0x7889; p->s1_foxtrot = 0x34; //========================================================================= // // COMPARE TEST STARTS HERE // //========================================================================= // // TEST of 32bit word == 32 bit word // //========================================================================== //*********************************** // Testcode VALUE // value s1_charlie is equal value s2_charlie //*********************************** p->s1_charlie = 0x11223344; s->s2_charlie = 0x11223344; if (ptest1.s1_charlie == ptest2.s2_charlie) cmp_taken = 0x51; //TEST EQ1 cmp_taken = 0; if (ptest1.s1_charlie == s->s2_charlie) cmp_taken = 0x52; //TEST EQ2 cmp_taken = 0; if (p->s1_charlie == ptest2.s2_charlie) cmp_taken = 0x53; //TEST EQ3 cmp_taken = 0; if (p->s1_charlie == s->s2_charlie) cmp_taken = 0x54; //TEST EQ4 cmp_taken = 0; if (s->s2_charlie == p->s1_charlie) cmp_taken = 0x55; //TEST EQ5 cmp_taken = 0; //*********************************** // Testcode VALUE // value s1_charlie is NOT equal value s2_charlie //*********************************** p->s1_charlie = 0x11223344; s->s2_charlie = 0x11221144; if (ptest1.s1_charlie == ptest2.s2_charlie) cmp_taken = 0x56; //TEST EQ6 cmp_taken = 0; if (ptest1.s1_charlie == s->s2_charlie) cmp_taken = 0x57; //TEST EQ7 cmp_taken = 0; if (p->s1_charlie == ptest2.s2_charlie) cmp_taken = 0x58; //TEST EQ8 cmp_taken = 0; if (p->s1_charlie == s->s2_charlie) cmp_taken = 0x59; //TEST EQ9 cmp_taken = 0; if (s->s2_charlie == p->s1_charlie) cmp_taken = 0x5A; //TEST EQ10 cmp_taken = 0; //========================================================================= // // TEST of 32bit word != 32 bit word // //========================================================================== //*********************************** // Testcode VALUE // value s1_charlie is equal value s2_charlie //*********************************** p->s1_charlie = 0x11223344; s->s2_charlie = 0x11223344; if (ptest1.s1_charlie != ptest2.s2_charlie) cmp_taken = 0xA1; //TEST NOT_EQ1 cmp_taken = 0; if (ptest1.s1_charlie != s->s2_charlie) cmp_taken = 0xA2; //TEST NOT_EQ2 cmp_taken = 0; if (p->s1_charlie != ptest2.s2_charlie) cmp_taken = 0xA3; //TEST NOT_EQ3 cmp_taken = 0; if (p->s1_charlie != s->s2_charlie) cmp_taken = 0xA4; //TEST NOT_EQ4 cmp_taken = 0; if (s->s2_charlie != p->s1_charlie) cmp_taken = 0xA5; //TEST NOT_EQ5 cmp_taken = 0; //*********************************** // Testcode VALUE // value s1_charlie is NOT equal value s2_charlie //*********************************** p->s1_charlie = 0x11223344; s->s2_charlie = 0x11221144; if (ptest1.s1_charlie != ptest2.s2_charlie) cmp_taken = 0xA6; //TEST NOT_EQ6 cmp_taken = 0; if (ptest1.s1_charlie != s->s2_charlie) cmp_taken = 0xA7; //TEST NOT_EQ7 cmp_taken = 0; if (p->s1_charlie != ptest2.s2_charlie) cmp_taken = 0xA8; //TEST NOT_EQ8 cmp_taken = 0; if (p->s1_charlie != s->s2_charlie) cmp_taken = 0xA9; //TEST NOT_EQ9 cmp_taken = 0; if (s->s2_charlie != p->s1_charlie) cmp_taken = 0xAA; //TEST NOT_EQ10 cmp_taken = 0; } ========================== I hope this helps to explain the problem better! Regards, Lasse
  8. LasseT

    Comparing Two 32 Bit Words

    The same kind of problem can be found when using != instead of ==. I guess that it is more or less the same code part in the compiler so it will be corrected at the same time. Regards, Lasse By the way! The SourceBoostC is a very nice "tool" to work with :-)! I have a lot of fun designing with this environment.
  9. LasseT

    Comparing Two 32 Bit Words

    Problem description: ============== Compare problems for 32 bit words. (Possible bug) Please notice that my test works fine when running the compiler for a target like 16F877A and 16F648. NO PROBLEM THERE. My problem can be found when running the compiler for a target like 18F458 or 18F4580 (those I have tested). I use SourceBoost IDE Version 6.25 Compare like ptest1.s1_charlie == ptest2.s2_charlie WORKING OK :-) ptest1.s1_charlie == s->s2_charlie WORKING OK :-) p->s1_charlie == ptest2.s2_charlie NOT OK :-( p->s1_charlie == s->s2_charlie NOT OK :-( s->s2_charlie == p->s1_charlie NOT OK :-( Please see my testprogram below to clarify some of this. When I try to singelstep in assembler it looks like the "second byte" compare is the problem. The first byte compare works ok, no problem there, so the "first byte" of long s1 is compared with the "first byte" of long s2. Next step shall compare the second byte of s1 and s2 but, the "first byte" of long s1 is compared with the "second byte" of long s2. When I fake the second compare everything runs ok. I modified the compiler output below and removed two lines of code and it "worked" as far as I could test it. But I will not say that this is the best (or correct) solution. This might violate something else for the compiler, I can not check that :-). Assembler code output from compiler ========================================== p->s1_charlie == s->s2_charlie MOVF main_1_s+D'1', W MOVWF FSR0H MOVF main_1_s, W ADDLW 0x03 MOVWF FSR0L MOVF INDF0, W MOVWF CompTempVar76 MOVF PREINC0, W MOVWF CompTempVar76+D'1' MOVF PREINC0, W MOVWF CompTempVar76+D'2' MOVF PREINC0, W MOVWF CompTempVar76+D'3' MOVF main_1_p+D'1', W MOVWF FSR0H MOVF main_1_p, W ADDLW 0x03 MOVWF FSR0L MOVF CompTempVar76, W SUBWF INDF0, W BNZ label268436489 first value byte compare ---------------------------------------------- MOVF CompTempVar76+D'1', W DECF FSR0L, F <=========REMOVE ?????? SUBWF PREINC0, W BNZ label268436489 second value byte compare --------------------------------------------------------------- MOVF CompTempVar76+D'2', W INCF FSR0L, F <=========REMOVE ?????? MOVF PREINC0, W MOVWF CompTempVar77 DECF FSR0L, F DECF FSR0L, F SUBWF CompTempVar77, W BNZ label268436489 third value byte compare --------------------------------------------------------------- MOVF CompTempVar76+D'3', W INCF FSR0L, F INCF FSR0L, F MOVF PREINC0, W MOVWF CompTempVar78 DECF FSR0L, F DECF FSR0L, F DECF FSR0L, F SUBWF CompTempVar78, W BNZ label268436489 fourth value byte compare ------------------------------------------------------------- MOVLW 0xAA MOVWF main_1_ifequal ================================================= Simple Testprogram for 32 bit compares: ------------------------------------------------ #include <system.h> #include <boostc.h> typedef struct _STRUCT1 { char s1_alfa; int s1_bravo; long s1_charlie; int s1_delta; char s1_foxtrot; } STRUCT1; typedef struct _STRUCT2 { char s2_alfa; int s2_bravo; long s2_charlie; int s2_delta; char s2_foxtrot; } STRUCT2; void main() { char ifequal = 0x00; STRUCT2 ptest2; ptest2.s2_charlie = 0x33445566; STRUCT2 *s; s = &ptest2; STRUCT1 ptest1; ptest1.s1_charlie = 0x99887766; STRUCT1 *p; p = &ptest1; p->s1_alfa = 0x12; p->s1_bravo = 0x3456; p->s1_delta = 0x7889; p->s1_foxtrot = 0x34; //========================================================================= // // COMPARE TEST STARTS HERE // //========================================================================= // // // PLEASE NOTICE THAT THIS TEST WORKS FOR PIC16F877A and PIC16F648 // IF THOSE ARE THE TARGET CHIPS !!!!!!!!!!!!!!!!!! // // IT DOES NOT WORK FOR TARGET PIC 18F458 and 18F4580 // //========================================================================== p->s1_charlie = 0x11223344; s->s2_charlie = 0x11223344; if (ptest1.s1_charlie == ptest2.s2_charlie) ifequal = 0x33; //WORKING OK :-) if (ptest1.s1_charlie == s->s2_charlie) ifequal = 0x88; //WORKING OK :-) if (p->s1_charlie == ptest2.s2_charlie) ifequal = 0x55; // NOT OK :-( if (p->s1_charlie == s->s2_charlie) ifequal = 0xAA; // NOT OK :-( if (s->s2_charlie == p->s1_charlie) ifequal = 0x99; // NOT OK :-( } ========================================== Regards, Lasse
×