Jump to content

harrt

EstablishedMember
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

About harrt

  • Rank
    Newbrie
  1. 6.31 generates this garbage if(eerd(i) != ~i) { 0050 082B MOVF eetest_00000_1_i, W 0051 00AE MOVWF eerd_00000_arg_a 0052 2029 CALL eerd_00000 0053 01AD CLRF CompTempVar10 0054 092B COMF eetest_00000_1_i, W 0055 00AC MOVWF CompTempVar9 0056 09AD COMF CompTempVar10, F 0057 0828 MOVF CompTempVarRet0, W 0058 062C XORWF CompTempVar9, W 0059 1903 BTFSC STATUS,Z 005A 082D MOVF CompTempVar10, W 005B 1903 BTFSC STATUS,Z 005C 285F GOTO label268435774 005F label268435774 AUTOI_LED = 1; 005D 1707 BSF gbl_AUTOI_LED,6 } else { 005E 2860 GOTO label268435778 0060 label268435778 AUTOI_LED = 0; 005F 1307 BCF gbl_AUTOI_LED,6 eerd returns unsigned char and i is unsigned char. If the result of the XORWF comparison is zero it loads CompTempVar10 which is always 0xff so the second BTFSC always skips regardless of the comparison result.
  2. harrt

    Bit Bug

    Bug or not depends on how you expect undocumented compiler features to work. By experimentation I have determined (in BoostC) that bits are treated as 1 bit integers and bools are treated as, well, bools. If the OP had used a bool instead of a bit he would have got his expected result along with an arguably dubious warning. Personally I don't see much utility in 1 bit integers (are they signed or unsigned? lol) while I frequently (like the OP) want to assign a port or register bit as though it were a boolean. The difference between bits and bools needs to be documented.
  3. Likely unrelated but I moved a 16F628 project from HT PIC lite to BoostC and had problems with __CONFIG and __IDLOC macros, I didn't find equivalent syntax for __IDLOC in BoostC. Syntax for bit defines, not too big a problem to fix. Anonymous enums for example static enum {A, B, C} anenum; has to be replaced in BoostC with enum anenum_tag {A, B, C}; static enum anenum_tag anenum; Probably the same problem with anonymous structs and unions which is strange considering BoostC has a smattering of C++ syntax. Interrupt function syntax. A whole bunch of compiler warnings like int a; int b; bit f; f = a == b; and if I remember correctly trying to fix the warning with f = (bit)(a == ; gives a compiler error. You would think the result of a boolean operation could be assigned to a boolean variable without warning? I didn't actually try to run the ported program, I did browse the generated code and it looked like it was probably ok.
  4. Got it working now but I don't understand quite what was going on. Initially copied the source file into a new directory where I created the MPLAB project but by mistake I added the file in its original location to the project. Boostc was compiling the file in its original location and creating a .obj file in the project directory but somehow that was not enouigh to keep MPLAB happy.
  5. I set up a project in MPLAB 7.30 using BoostC 6.25 for PIC16. Build in MPLAB fails after compiling the single C file. The compiler creates a .OBJ file and reports success but MPLAB reports BUILD FAILED. Invoking boostC from the command line with the same parameters appears to correctly return a zero exit code. I have had BoostC 6.21 working in MPLAB 7.10 or maybe 7.20 ok, and an old HT PIClite compile seems to work OK in MPLAB 7.30. Any ideas what else to try?
  6. Yes it is a bug and I notice you say it will be fixed in the next release, however, I suggest you make it optional or provide source for startup code which may be modifed. Some systems may want to retain variable values after a brown out or watchdog reset.
×
×
  • Create New...