Jump to content

djulien

EstablishedMember
  • Content Count

    36
  • Joined

  • Last visited

Community Reputation

0 Neutral

About djulien

  • Rank
    Regular
  1. There are various ways to solve this, depending on how much extra code you want to write. One way to do it using the built-in delay function would be to compile 2 copies of the code (one at each clock speed) into separate obj files (with different names), and then link both of them in using the linker. Another way would be to write your own delay function or macro that uses a parameter to select the clock speed. This isn't too hard; I've done it a few times. Yet another way would be to use a Timer. If you have a spare one, this technique is actually the most flexible because you can use the same delay loop code, but just preset the Timer to a different value depending on the clock speed you want. don
  2. When a program spans pages, for optimal performance functions must be carefully distributed between code pages to avoid excessive page selects. Currently, a given function can be forced to a specific address using "@<address>", but when there are many functions this is tedious because it takes many repeated compiles and checking the .map file each time in order to choose the correct address. It would be very helpful to be able to tell the linker "put all code after this point into page ###". This would allow the code to be partitioned according to page# a lot easier. For example, allow a statement such as: #pragma location push <address> to be placed between functions to tell the linker to put the code after that into the designated page, and something like: #pragma location pop to tell it to put the code back into whichever page it was using before that. (This would be somewhat analogous to the psect statement in MPLINK). don
  3. I might have missed it, but I don't see a way to force a var to be in the same bank as another var. "@ address" can be used to place a var at a specific address, but that's not what I need; I just need it to be in the same bank as another var. For example, if I have some code that is accessing the serial port on a PIC16F1827, those registers are in Bank 3, so I would like to put my variables in bank 3 to avoid excessive bank selects. However, on a PIC16F688, those registers are in bank 0. This leads to very awkward code like this: #ifdef _PIC16F1827 #define ADDRESS 0x180 #else #ifdef _PIC16F688 #define ADDRESS 0x20 #endif etc. unsigned char myvar @ADDRESS; This code is harder to maintain or understand for others, and takes longer to write. The other problem with this example code is that I have to manually manage all the addresses myself. This gets unwieldy when there are many variables that need to be placed this way (basically, it negates the automatic address assignment job of the compiler). It would be a lot nicer to just be able to write code like: unsigned char myvar @BankOf(rcsta); or maybe use a pragma: #pragma bank <other register> unsigned char myvar; #pragman bank any or something like that. So, I would like to request a "same bank as (other var)" address assignement feature. thanks don
  4. Bug description: The file and line# are not being included within a preprocessor error message. This makes it extremely difficult to find the cause of the error in larger programs. Example code: #include <system.h> #define "forgot to put symbol name here" void main(void) { porta = 1; } Although the compiler does display an error message with line# for the above error, it also displays this error: Error: preprocessing error In a large program with many errors, it is very difficult to find the cause of this error. Expected behavior: Include the file and line# in the error message. Is the problem 100% reproduceable: yes Compiler: BoostC Compiler version: 7.1+ Target device: PIC16F1827, etc. OS: Windows XP don
  5. djulien

    Expressions Within Enum Broken

    Bug description: BoostC is not correctly handling expressions within enum. Example code: #include <system.h> enum { Constant1 = 0x1A0 }; enum { Constant2 = Constant1 + 1*1 }; int debug @0x70; void main(void) { debug = Constant1; //should be 0x1A0; this one works debug = Constant2; //should be 0x1A1, actually is 0x0A1 } The code that is being generated is: MOVLW 0xA0 MOVWF gbl_debug MOVLW 0x01 ;//this is correct MOVWF gbl_debug+D'1' MOVLW 0xA1 MOVWF gbl_debug CLRF gbl_debug+D'1' ;// this is wrong RETURN Expected behavior: Compiler should generate the correct opcodes to assign the value. Is the problem 100% reproduceable: yes Compiler: BoostC Compiler version: 7.1+ Target device: PIC16F1827, etc. OS: Windows XP don
  6. djulien

    Boost C Building Time

    I also experience "slow" compiles. I do not have an older version of BoostC to compare to, so I am just doing a relative comparison to another compiler (for example, CC5X) on the same machine. BoostC takes significantly longer to compile the same source code. boostc_pic16.exe seems to be taking most of the time; boostlink_pic.exe is pretty quick. In the attached screen shot I've marked the relative exeution times. . The example code I used for this test is attached. perftest.c BoostC took about 30 sec, while the other compiler took about 2 sec. The size of code generated by both compilers is almost the same (the example code is pretty simple, so I wouldn't expect any significant differences). BTW, I've noticed that there are 2 copies of boostc_pic16.exe running. If they are doing some kind of inter-process communication that could be slowing them down a lot. Or, if BoostC is optimized for a multi-core machine maybe that is what is slowing it down (I'm running it on a single core in my environment). (I'm currently using version 7.1x) don
  7. It would be very helpful if BoostC would accept "W" as an l-value or as part of an expression. This would cut down on the amount of asm statements needed considerably. For example, if I need to evaluate an expression and pass it via W to a function, currently I need to write code like: asm { movlw 5; addwf _reg, W; xorlw 0x12; } func(); This is very ugly and non-portable. It would be a lot nicer and more portable to write the above as: W = (reg + 5) ^ 0x12; func(); As well as being more portable, this would also improve the readability of the code significantly. Since there are no changes to the syntax rules, this feature would require only minor changes to the code generator. Basically, treat "W" (or maybe "WREG" or some other keyword) like a normal register or variable in the first pass of the compiler, and then simply omit instructions like movf _W, W and movwf _W in the code generator. (There are a few other complications such as making sure "W = W ^ 0x10" reduces to "xorlw 0x10" instead of "movf _W, W; xorwf _W, F", but those are also fairly easy to handle in the code generator) don
  8. djulien

    Asm Comment Parsing Errors

    Bug description: BoostC is not correctly skipping over comments within asm blocks. Example code: #include <system.h> void main(void) { asm { nop; //comment with asm in it nop; //comment with asmprefix in it nop; //comment with suffixasm in it nop; //comment without it } } The first 3 "nop" lines will generate the following error: file(line): error: error in built-in assembly Expected behavior: Compiler should ignore all text on a line after ";" or maybe "//" (depending on how that is supposed to work). If for some reason it must scan comments for the token "asm", then it should at least ignore it when it is part of a larger string (second and third "nop" lines in the example code). Is the problem 100% reproduceable: yes Compiler: BoostC Compiler version: 7.10 Target device: PIC16F1827, etc. OS: Windows XP don
  9. djulien

    Pclath Is Not Being Updated

    Dave, I'm finding other cases where there is not a retlw within the called function, so I think the problem is more widespread than that. don
  10. djulien

    Linker Removing Too Much Code

    Bug description: The BoostC documentation says that "_asm" will remove dead code but "asm" will not (page 64). This does not appear to be the case - dead code is being removed with "asm" also. This is a problem because the "dead" code is actually needed. Example code: #include <system.h> unsigned char var1; inline void func(void) { asm //use asm block to prevent dead code removal { addwf _pcl, F; bcf _var1, 1; goto return2caller; nop; goto return2caller; bcf _var1, 2; goto return2caller; movlw 0x11; ; goto update; //problem line bcf _var1, 3; goto return2caller; bcf _var1, 4; goto return2caller; update: movwf _var1; return2caller: } } void main(void) { asm movf _var1, W; func(); } With the "problem line" commented out, the example code compiles and links correctly (no code is removed). However if the "problem line" is not commented out, the code will still compile but the linker will report the following error: Internal Error: Unable to resolve label ID:268438699 - 0x10000CAB BoostLink Optimizing Linker Version 7.10 It looks like it might have removed the section of code containing the "update" label, even though this was contained within the asm block (or maybe the linker is doing something else instead). Expected behavior: Linker should leave in the "update" label and "movwf", and not report an error. In either case, no "dead" code should be removed. Placing "#pragma OPTIMIZE "0"" ahead of func1 does not help either. Is the problem 100% reproduceable: yes Compiler: BoostC Compiler version: 7.10 Target device: PIC16F1827, etc. OS: Windows XP don
  11. djulien

    Pclath Is Not Being Updated

    Well, okay. Another work-around I found was to just put a "pclath = 0" statement after the call to the function (if it's in the first code page). That only takes 1 cycle instead of 2. I guess I can use one of those work-arounds for now while debugging, but I'm trying to write some very tight code so I may need to shuffle the code around to avoid the extra overhead and the problem altogether. I agree. I usually either set pclath or use an address where the bottom bits are already 0. Sorry, I left that out of the sample code just to show the minimum needed to trigger the problem. Actually, I've noticed that the compiler always uses a multiple of 8 in the movlp instructions. I assume that this is for compatibility with PICs that do not have movlp, but if it were to set the complete value then that would be another way to avoid the need for an extra instruction to set pclath manually (at least for PICs with a movlp instruction). If you are working in that section of code anyway, it would be nice to have a way to give the code generator some hints, like wanting a section of code to all fall on the same code page and move it if it doesn't, override bank selects, etc. (maybe some new #pragmas or keywords for that) My code will probably fall outside your normal usage envelope. I have that happen sometimes. (I also ran into several bugs in MPASM, although I didn't take the time to isolate and write them up). I'm wanting this particular code to work with some older 16F688s as well. If I give up that goal then I will definitely use the extended instructions. thanks for your help. don
  12. djulien

    Boostc_Pic16.exe Infinite Loop

    Bug description: The compiler goes into an infinite loop. Example code: #include <system.h> typedef unsigned char uint8; #define asmref(thing) _##thing #define PORTOF(thing) ((thing)>>4) #define PINOF(thing) ((thing)&0xF) #define LED1_PIN 0xA0 inline void bug(uint8& values) { asm //use asm block to prevent dead code removal { goto return2caller; nop; ;// setbit_asm(asmref(values), LED1_PIN, FALSE); //turn bit off bcf asmref(values)+PORTOF(LED1_PIN), PINOF(LED1_PIN); goto return2caller; return2caller: } } uint8 var1[10]; void main(void) { bug(var1[0]); } The example above is a simple function, but the problem is occurring in a much larger program that I have. I assume that macros are allowed within asm blocks, since it is still the preprocessor at that point. I didn't see anything in the documentation that it was not allowed. Expected behavior: Preprocessor should expand the macros and then the compiler should generate the appropriate instructions for the example code. Is the problem 100% reproduceable: yes Compiler: BoostC Compiler version: 7.10 Target device: PIC16F1827, etc. OS: Windows XP don
  13. For a PIC16F device, I have a section of Asm code that places a value in W, and now I want to compare it or use it in other C expressions. However, to do that seems to require more and more Asm code because I can't treat W like a value directly in C. For example, I'd like to do something like: asm swapf _var, W; //example code: value is now in W if (W == 4) ... //use W in a compare, or ... var = W; //save W, or do something else with it To do this, I need to add more and more Asm code: // (value is in W) //to compare W to 4, the following is needed: asm xorlw 4 btfss _status, Z goto not_equal //to save W to a var: asm movwf _var ie, it takes more and more Asm code to manipulate W, instead of jumping back into C and manipulating it there. Is there a syntactical way to refer directly to W in BoostC instead of adding extra Asm (and typically extra temps to hold it)? don
  14. Bug description: The simulator is not handling eeadrl+h, eedatl+h, and maybe some others correctly for the 16F1827. The values show up correctly in the Memory window, but not in the Registers window. (I have a screen shot, but not sure how to attach it here). This makes it difficult to debug code that reads/writes flash or eeprom memory. I think trisb is also broken. Also, the read/write functions (eecon1.RD, etc) are not working. For example, a couple of cycles after raising eecon1.RD, eedatl+h should change but they do not. Example code: eeadrh = 0xFF; //lower byte of address of desired read location eeadrh = 0x4; //upper address of desired read location eecon1.EEPGD = 1; //select flash (as opposed to EE) memory eecon1.RD = 1; //start EE or flash memory read asm nop; //DO NOT MOVE next 2 lines; required to correctly read flash asm nop; //result should be in eedatl+eedath at this point Expected behavior: eedatl+eedath should change after the sequence above. Is the problem 100% reproduceable: yes Compiler: BoostC Compiler version: 7.10 Target device: PIC16F1827 OS: Windows XP don
  15. djulien

    Wrong Opcode Generated

    BTW, same problem exists for movlp, andlw, xorlw, etc. Seems like there is a movlw hard-coded in the code generator somewhere. don
×