Jump to content

thiemann

EstablishedMember
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

0 Neutral

About thiemann

  • Rank
    Newbrie
  1. OK, I see what you are getting at now. Thanks for clearing it up. Eric
  2. Pavel, The dothis() is declared before it is used. It is declared as void dothis() in main.c before it is used in the main() function. Its definition is, however, located in another module, test.c, but this should not be a problem as this is a common thing to do. I am not sure what is incorrect about the code. Please let me know what aspect you may be talking about so that I can clear that up. Thanks, Eric
  3. Even with the new 1.7.2 BoostC compiler, the linker generates an error if an inline function definition is located in another c module, but used in another c module. Example: Make a new project with two files (main.c and test.c) In main.c, put the following code: void dothis(); void interrupt() { dothis(); } void main() { dothis(); } In test.c, put the following code: inline void dothis() { } Compile and link the project. Notice that the linker says that dothis() is an unresolved external symbol. FYI: In main.c, I tried using "inline void dothis();" as the function prototype as well, but the compiler says that an inline function must be declared with a body.
  4. Bug description: The BoostC compiler is making unions tool large. It makes them the same size as a structure. Steps to reproduce: 1.) Create a new project 2.) Add a main.c file to the project with the following code union TEST { int x1; int x2; int x3; int x4; int x5; }; union TEST w; void main() { } 3.) Compile and link the project using BoostC 4.) Notice the compiler reports that 10 bytes of RAM are used when only 2 bytes should be used. Expected behavior: Only 2 bytes of RAM should be used. Is the problem 100% reproducible: Yes SourceBoost version: 5.7 Compiler: BoostC Compiler version: 1.7 Alpha OS: Windows XP Comments: None
  5. Bug description: The linker produces an error if the following code is compiled and linked. Steps to reproduce: 1.) Create a new project 2.) Add a main.c file to the project with the following code inline void serialSendChar(char value); void DoThis() { serialSendChar('a'); } void serialSendChar(char value) { } void interrupt() { } void main() { } 3.) Compile and link the project using BoostC 4.) Notice the var not found error. Expected behavior: There should be no linker error. Is the problem 100% reproducible: Yes SourceBoost version: 5.7 Compiler: BoostC Compiler version: 1.7 Alpha OS: Windows XP Comments: None
  6. The bootloader that I am now using is called the "Shane Tolmie PIC bootloader v9-30". You can download it at the following site: http://www.microchipc.com/PIC16bootload/index.htm#download
  7. After further investigation, I found out that the problem was that BoostC did not produce a "clrf PCLATH" instruction as the first instruction, which for some reason confused my bootloader. I tried another bootloader and it worked fine. Thus, there is no bug in BoostC, my bootloader was not robust. Consider this discussion topic completed. Sorry for the confusion. Eric
  8. Pavel, the target is the 16f876a, however, I found the problem, I was doing #define instead of #pragma for the config word, my bad. However, now that this is figured out, perhaps you can help me with the grand problem that I am having (which I first thought this config word was the reason for my grand problem). Is there anything strange with the BoostC compiler that will not allow the code it generates to work with bootloaders? I know I asked you this before and you said there was a problem. Is the problem, or any other problems of this nature, resolved? I ask this because code that is generated by BoostC does not work when I use my bootloader (tiny boot loader) when the same code works when compiled with the C2C plus compiler. For example, the following code when compiled with BoostC does not work when loaded using the bootloader. #include <system.h> #pragma CLOCK_FREQ 20000000 #pragma DATA 0x2007, _CP_OFF & _DEBUG_OFF & _WRT_OFF & _CPD_OFF & _LVP_ON & _BODEN_ON & _PWRTE_ON & _WDT_OFF & _HS_OSC void main() { intcon = 0; trisc = 0; while (1) { portc = 0; } } If you take out the "#pragma DATA" statement, because it is not supported by the C2C Plus compiler, and compile it with C2C plus, the code works fine when loaded by the bootloader. Do you have any ideas why this is? Thanks, Eric
  9. Bug description: The compiler is not generating the correct config word. Steps to reproduce: 1.) Create a new project 2.) Add a main.c file to the project with the following code #include <system.h> #define DATA 0x2007, _CP_OFF & _DEBUG_OFF & _WRT_OFF & _CPD_OFF & _LVP_ON & _BODEN_ON & _PWRTE_ON & _WDT_OFF & _HS_OSC void main() { while (1) { } } 3.) Compile and link the project using BoostC 4.) Check to see what the generated config word is (I do this by opening the hex file using the ICprog program). 5.) Notice that the generated configuration word is 0x3fff, which is incorrect. Expected behavior: The generated configuration word should be 0x3ff2. Is the problem 100% reproducible: Yes SourceBoost version: 5.7 Compiler: BoostC Compiler version: 1.7 Alpha OS: Windows XP Comments: None
  10. Has the problem that came back been fixed?
  11. Yes, its looks like it is fixed, however, a form of the extern problem is back. Note: the following should compile fine (and did in Boostc 1.3), but now doesn't: extern char x; char x; void main() { }
  12. Bug description: The compiler does not warn when a variable is redefined or when a variable is set to a constant that does not fit within the variable. Steps to reproduce: 1.) Create a new project 2.) Add a main.c file to the project with the following code void main() { char x = -129; // -129 is too big to fit into char unsigned char x = 3; // x is already defined char w; w = x; } 3.) Compile and link the project using BoostC 4.) Notice that the code compiles fine and no warnings or errors are generated. Expected behavior: The compiler should fail to compile the code. Is the problem 100% reproducible: Yes SourceBoost version: 5.6.1 Compiler: BoostC Compiler version: 1.3 Alpha OS: Windows XP Comments: MSVC++ fails to compile the code, if that is worth anything.
  13. Bug description: If you compile and then link the following code, you will get a linker error. Steps to reproduce: 1.) Create a new project 2.) Add a main.c file to the project with the following code #include <system.h> inline void test(char value); void test(char value) { char x = value; } void testfunc(char a) { test(a); } void main() { } 3.) Compile and link the project using BoostC 4.) Notice the linker error message. ("Var not found") 5.) Note: if you delete the keyword "inline" and then recompile and link the project, you will receive no errors. Expected behavior: This code should not fail to link. Is the problem 100% reproducible: Yes PicAntIDE version: PicAndIDE version Compiler: BoostC Compiler version: 1.3 Alpha OS: Windows XP Comments: None
  14. Bug description: The BoostC linker fails with "No Error" if you declare an extern variable, but never define it. Steps to reproduce: 1.) Create a new project 2.) Add a main.c file to the project with the following code extern char x; void interrupt() { } void main() { } 3.) Compile the project using BoostC 4.) Notice the linker error message. Expected behavior: The linker should allow an undefined extern variable (as long as it is not used). MSVC++ allows an undefind extern. Is the problem 100% reproducible: Yes PicAntIDE version: PicAndIDE version Compiler: BoostC Compiler version: 1.1 Alpha OS: Windows XP Comments: None
  15. Gotcha, however, if this is the case, how come the following code does not link because the linker says that there are duplicate variables. Make a main.c source file with the following code: #include <system.h> void main() { } Then, make another test.c source file with the following code: #include <system.h> void test() { } Add both files to a new project and compile. It compiles fine, but will not link without errors. If I understand you correctly, the linker should not fail because the variables within the system.h file are fixed address variables. However, the linker does fail. Here is the linker output: BoostLink Optimizing Linker Version 1.0 Alpha Copyright© 2004 Pavel Baranov Copyright© 2004 David Hobday Duplicate global var:indf Duplicate global var:tmr0 Duplicate global var:pcl Duplicate global var:status Duplicate global var:fsr Duplicate global var:porta Duplicate global var:portb Duplicate global var:portc Duplicate global var:pclath Duplicate global var:intcon Duplicate global var:pir1 Duplicate global var:pir2 Duplicate global var:tmr1l Duplicate global var:tmr1h Duplicate global var:t1con Duplicate global var:tmr2 Duplicate global var:t2con Duplicate global var:sspbuf Duplicate global var:sspcon Duplicate global var:ccpr1l Duplicate global var:ccpr1h Duplicate global var:ccp1con Duplicate global var:rcsta Duplicate global var:txreg Duplicate global var:rcreg Duplicate global var:ccpr2l Duplicate global var:ccpr2h Duplicate global var:ccp2con Duplicate global var:adresh Duplicate global var:adcon0 Duplicate global var:option_reg Duplicate global var:trisa Duplicate global var:trisb Duplicate global var:trisc Duplicate global var:pie1 Duplicate global var:pie2 Duplicate global var:pcon Duplicate global var:sspcon2 Duplicate global var:pr2 Duplicate global var:sspadd Duplicate global var:sspstat Duplicate global var:txsta Duplicate global var:spbrg Duplicate global var:cmcon Duplicate global var:cvrcon Duplicate global var:adresl Duplicate global var:adcon1 Duplicate global var:eedata Duplicate global var:eeadr Duplicate global var:eedath Duplicate global var:eeadrh Duplicate global var:eecon1 Duplicate global var:eecon2 Failed Exit code was -1. [No error.] Removing target: test.hex Failed to locate output file 'test.hex' Done Failed Please shine some light on this, thanks.
×
×
  • Create New...