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
  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,
  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 #ifd
  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
  5. 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 co
  6. 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
  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 signifi
  8. 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 "as
  9. 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. 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 r
  11. 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 prob
  12. 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
  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 _st
  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 add
  15. BTW, same problem exists for movlp, andlw, xorlw, etc. Seems like there is a movlw hard-coded in the code generator somewhere. don
×
×
  • Create New...