I have found a problem with the C167CRr2 DIP for DAvE. The #defines in MAIN.H generated by DAvE use a bit-field structure to access SFR bits, rather than just using sbit. This causes a statement such as S0TBIC_S0TBIE = 1 to generate code like MOV R4,0F19CH BSET R4.6 MOV 0F19CH,R4 rather than EXTR #01H BSET S0TBIE The problem this was giving me was that if the S0TBIR bit becomes set, it can be lost when the second MOV instruction is executed. I found that the C167 DIP just relies on the reg167.h file, and does not use the bit-field structures. This is how I have worked around the problem, but it will become a pain if I need to use any of the C167CR functionality which does not exist on the basic C167. I have reported this problem to Infineon who are looking into it, but just thought I would mention it in case it helps anyone, or anyone has any alternative suggestions.
Are you using the current C166 Version 6.04?
No, I am using uV2 V2.38 which has C166 at version V4.27. Infineon mentioned that uV3 compiled the DAvE code better, but personally I see this as a problem with the way the C167CRr2 DIP generates the #defines for the SFRs and their associated bits. I also do not understand why the C167CRr2 DIP and the C167 DIP should do this in totally different ways. Regards, Nigel.
This explains it. That version is too old and does not support the new methods used by the current DAvE version.
Am I right in thinking that an upgrade is not free? I still fail to understand why some DAvE DIPs use a 'new' method which seems far less tidy than the 'old' method.
YOu are correct the upgrade is not free. We also did not understand why Infineon changed the method (I think they wanted to make it consistent across all their platforms).
Thanks for your help. I'll continue using the C167 DIP for now, as I cannot get the upgrade just because of this.