Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by BeanBrain

  1. Another thought, is Clk cast to unsigned char prior to shifting right , if so this will explain your problem? Need to consider C language and examine Compiler output to verify. If so you could use an intermediary allocation to ensure high order bits are shifted prior to assignment; unsigned int Clktmp = Clk >> 2; Clk2=(unsigned char) Clktmp; Beany
  2. I think I may see the problem? Global Clk is unsigned in but local Clk2, Clk3, Clk4 are unsigned char, therefore the maximum value is 255 for those. Beany
  3. Is this a bug? Bug description: Return type of function taking pointer to structure as an argument can not be enum type. They compile oky but generate a linker error message. Steps to reproduce: Two files, one calling the function and the other the function. They compile okay but generate an error when linking. First file, main.c // File main.c // BoostC Compiler options -v -W2 -t PIC18F4550 #include <system.h> /* BoostC v6.40 bug. If a function takes a -> struct as an argument, the return type cannot be a typedef - generally get missing extern when linking to g
  4. Hi Dave, This looks like the same problem I reported in posting #7711 Regards B
  5. I looked at porting this code to source boost a few months ago. However after reading the terms and conditions of the Microchip licence agreement and pursuing it with Microchip I came to the conclusion it was not viable to do this to be able to share code with other forum members. Any attempt to share code with other team members in a usable way would be in violation of the Microchip licence agreement. <{POST_SNAPBACK}> As Phil has said, "Oh Dear!". What a nuisance. I wonder if porting the code between compilers really is a problem?
  6. Hi Pavel, Sorry about the lack of easy reading, but it was necessary in ordet to demonstrate and to test the error. Regards, G
  7. Bug description: Anonymous reference with union / structure generates error - should it? Steps to reproduce: Compile the example code as is, it will generate errors. If you uncomment the #define BOOSTC line it will compile OK because the unions / structure are no longer anonymous nor are the accesses to them. // BoostC Compiler options -v -W2 -t PIC18F4550 #include <system.h> typedef unsigned char b_ytes; typedef unsigned int word; // uncomment next line to compile successfully //#define BOOSTC typedef union _BYTE { b_ytes _byte; struct { #ifdef BOOSTC b_yte
  8. Bug description: Compiler reports errors with some operations when you typedef a type, ie: typedef unsigned char byte; and you also have an identifies which starts with all characters of that typedef, ie: byte byte_data; Steps to reproduce: Please see the CODE box. As it stands the compiler will generate erros. If you then delete the 'b' of 'byte' from #define STORAGE_B byte, a different error occurs. If you then delete the 'w' of 'word' from #define STORAGE_W word , the code will compile and link WITHOUT ERRORS! Your comments please. Is it an compiler problem withs resolving the ide
  9. BoostC doesn't support bit fields. It did not handle anonymous unions and structures but this problem has been fixed a few releases back. If this feature still doesn't work for you can you send us a simple project that demonstrates the problem. If there is one we'll try to fix it by the next release. Regards, Pavel <{POST_SNAPBACK}> I will retry with a small example and post the code if I find problems. Regards, G
  10. I will try and send in a few minutes ... though I may need to install a zipping program:( G
  11. Hi Phil, I have been editing and now have a modified Microchip source which compiles with BoostC in the SourceBoost IDE. If you wish me to e-mail / pass you a copy of the modified sources, please let me know. I think I may be able to do so via the forum's personal message system? It may save you a monster of an edit! ------------------------------------------------ First set of results are for the USB firmware and some of the demo user stuff, but none of the temperature stuff, just to get an idea of the memory requirements With aggressive optimistation in both compiler and lin
  12. Hi Phil, I found the same problem with BoostC not catering for anonymous unions and structures. I have modified and compiled the Microchip sources for use with BoostC and the SourceBoost IDE. There is possibly a compiler bug too, I will see if I can produce a failing example for Dave or Pavel, it is connected with the byte and word typedefs and the BYTE and WORD unions / structures. I have also sorted the bit field test and modifications where needed. If you wish me to e-mail / pass you a copy of the modified sources, please let me know. I think I may be able to do so via the for
  13. Hi Dave, Thank you for the quick reply. I will use the method you suggest. Regards, G
  14. Bug description: I have started to port the Microchip Technology USB firmware for CDC RS-232 design reference from Microchip C18 compiler to BoostC compiler. The example code which I have cut and pasted produces the following compiler error message: error: incompatible types 'unsigned char' and 'struct USB_DEV_DSC' I am not too sure what is happening, but it looks like the compiler is treating at least the first member of the struct variable 'device_dsc' as the same type as the structure itself. Additionally the output shows both success and failure! Is 'main.c success' the output from
  15. Hi Phil, I too am getting started on a PIC based USB project. I have read Microchip's USB demo code. Their provided Windows USB API functions (using their DLL) and IOCTL functions (direct driver control) have helped in my understanding. I will try and read through their PIC code again to see if we can be of mutual assistance. Regards, G
  16. Bug description: BoostC v6.35 header files for PIC18F2455, PIC18F2550, PIC18F4455, PIC18F4550 do not have the macro definitions for SPI port pin names. These definitions are required for SCK, SDI, SDO, SS and NOT_SS (last two are an identical value). Steps to reproduce: Referencing any SPI port pin names. Expected behaviour: In each of the four header files need to add the macro definitions for pin bit numbers under the definitions of the relevant port. I obtained the pin bit position from Microchip's PIC18F2455/2550/4455/4550 Data Sheet - DS39632C I added the folloowing five de
  17. Bug description: Inline Assembler generates "nop" (0x0000) opcodes for the "push" (0x0005) and "pop" (0x0006) mnemonics. Steps to reproduce: asm { push } can simulate the correct operation by asm { data 0x0005 } Expected behaviour: Should generate 0x0005 for a "push" and 0x0006 for "pop". Is the problem 100% reproduceable: 100% IDE version: SourceBoost IDE version Compiler: BoostC Compiler Compiler version: 6.32 for PIC18 Target device: PIC18F4680 OS: : XP Pro SP2
  18. Dave / Pavel, I have found another odd quirk. Nearest message I can find to this problem, which may be related, is: "Cannot Compare Pointers" posted on Feb 10 2006 in this forum. I have a working fix for the problem, which I've annotated for your easy testing using the macro FIX_LEVEL , and I would appreciate your comments. Problem 1. Comparison of two pointers of the same type fails. See macro BOOSTC_CAST_PTRS Problem 2. Assignment of the pointer to another pointer of the same type fails. See macro BOOSTC_FIX_ASSIGN struct stST { struct stST * pNext; // -> Next
  19. Dave, You are quite correct! (I need an embarrassed looking smiley here!) I apologise for wasting your time and not RTFM and remembering it all. I obviously could not see the trees for the forest.
  20. I'm not sure if this is a bug or if I have done a bad installation (ie into wrong directory) Although I can compile successully, I can not link this small piece of code (though I can link other projects, but I probably don't reference any libraries. This code snippet references the string function strcmp. #include <system.h> char * pStrs[4]={"abc","def","ghi","jkl"}; void main() { signed char i; signed char Element=-1; for(i=0;i<4;i++) if(!strcmp(pStrs[i],"ghi")) Element=i; } The following MPLAB output is produced, please note the unresolved externals in t
  21. I'm not sure if you would classify this as a bug or a feature request? If variables are declared with the const modifier and are not initialised the compiler does not generate a warning or an error message. Perhaps a warning message should be generated? Example code which compiles without warning or error: CODE #include <system.h> char Vch; const int Conint; const char Cch; const char * pVch; const char * const pCch; void main() { } All variables with const modifier should be initialised as follows: CODE #include <system.h> char Vch; const in
  22. I think this is a bug? Very long compilation time when the preprocessor directive #pragma CLOCK_FREQ is used with #include <system.h> . Why does it take so long. I've tried with larger projects and have the same result. The following code takes under approx 5 seconds to compile //#pragma CLOCK_FREQ 40000000 #include <system.h> void main() { } The following code takes under 2 seconds to compile #pragma CLOCK_FREQ 40000000 //#include <system.h> void main() { } The following code takes 1 minute 15 seconds to compile! Why? #pragma CLOCK_FREQ 400
  23. When an array of structures is accessed by pointer (see below), compilation fails if the size of structure is > 4 bytes (32 bits). #include <system.h> typedef struct BigStruct { int x; int y; // the next code line causes a compilation failure if // the commenting is removed // long z; } t_BigStruct; #define ELEMS 10 t_BigStruct MyStruct[ELEMS]; void main () { t_BigStruct * pSt=MyStruct; int i; for(i=0;i<ELEMS;i++) { pSt->x=-i; pSt->y=i; // next code line will generate a compilation error if // long z; is uncommented in the typedef above, // is it because
  24. Two problems with elf-referencing structre access by pointer, both compiler fine in Borland C++ Builder 6 with a C language console app and compilation model of ANSI selcted. following self-referenced struct code generates a compiler exception(?) trap under MPLAB IDE v7.31: Error: Access violation at 0x0047028D (tried to read from 0x5C73747E), program terminated. Soucre code is: -X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X- // structure self-references using stucts #include <system.h> #include <boostc.h> struct stOne { struct stOne * pSelf;
  • Create New...