Jump to content

apfei01

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About apfei01

  • Rank
    Newbrie
  1. Pavel, thanks for the answers and the the quick response. I've choosen your suggested "workaround" and the code is partly running ... 73, Andy.
  2. Sorry, but I do not agree: 1/ I try to use the floating point libraries provided by MicroChip. In the header file they assign - let's say - AARGB7 to 0x20 as well as ACCB7. There's also an application note available to embedd the librariers into C. (see AN669; well, I know they don't use C2C) 2/ So when this is not a bug and the statement makes no sense, why there's no error/warning generated? 3/ Defining the variable/address overlap with #define - statements makes the code hard to debug in case of a problem. Changing the library code is time consuming ... 4/ Maybe you can handle this as a feature request?
  3. The following short code will compile/assemble wrong: #pragma CLOCK_FREQ 20000000 // Define device config block asm { list p=16F628 __config H'3FFE' ;UNPROTECT&HS&WDTEN&PWRTDIS&BOREN&LVPEN&DUNPROT&WRTEN&DEBU GDIS } unsigned char var_a; unsigned char var_b@var_a; // assign var_b to the same address like var_a void main () { } The .lst-file looks like that: 00004 ;Variables ***************************************** 00000070 00005 _var_a equ 0x70 ;1 00000000 00006 _var_b equ 0x00 ;1 <--- should be 0x70 too 0000 00007 ORG 0 Is it a bug or misunderstanding? How to overcome? Using: C2C-Compiler 5.4e
×
×
  • Create New...