Jump to content

BeanBrain

EstablishedMember
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

0 Neutral

About BeanBrain

  • Rank
    Regular
  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 get round this, use unsigned char types #ifndef BOOLEAN_VALUES #define BOOLEAN_VALUES #define BOOLEAN unsigned char #define FAILURE 0 #define SUCCESS 1 #endif */ /* !!!! When BoostC is sorted we can use the following */ #ifndef BOOLEAN_VALUES #define BOOLEAN_VALUES typedef enum { FAILURE=0, SUCCESS=1 } BOOLEAN; #endif struct _str { char Char; int Int; }; extern BOOLEAN DoSomething(struct _str * p); struct _str MyStructure; BOOLEAN bRes; void main() { bRes=DoSomething(&MyStructure); } // end of main.c Second file, function.c // File function.c // BoostC Compiler options -v -W2 -t PIC18F4550 #include <system.h> typedef enum { FAILURE=0, SUCCESS=1 } BOOLEAN; struct _str { char Char; int Int; }; BOOLEAN DoSomething(struct _str * p); BOOLEAN DoSomething(struct _str * p) { p->Char='A'; p->Int = 65; return SUCCESS; } // end of function.c Build output: Building... BoostC Optimizing C Compiler Version 6.40 (for PIC18 architecture) http://www.sourceboost.com Copyright(C) 2004-2006 Pavel Baranov Copyright(C) 2004-2006 David Hobday Licensed to ... under Single user Full License for 1 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only main.c Starting preprocessor: "I:\Program Files\SourceBoost\pp.exe" "I:\BoostC Compiler\main.c" -i "I:\Program Files\SourceBoost\include" -d _PIC18F4550 -la -c2 -o main.pp -v -d _BOOSTC -d _PIC18 main.c success success BoostC Optimizing C Compiler Version 6.40 (for PIC18 architecture) http://www.sourceboost.com Copyright(C) 2004-2006 Pavel Baranov Copyright(C) 2004-2006 David Hobday Licensed to ... under Single user Full License for 1 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only Function.c Starting preprocessor: "I:\Program Files\SourceBoost\pp.exe" "I:\BoostC Compiler\Function.c" -i "I:\Program Files\SourceBoost\include" -d _PIC18F4550 -la -c2 -o Function.pp -v -d _BOOSTC -d _PIC18 Function.c success success BoostLink Optimizing Linker Version 6.40 http://www.sourceboost.com Copyright(C) 2004-2006 Pavel Baranov Copyright(C) 2004-2006 David Hobday Optimisation level:0 - Off Error: function and prototype differ in return type:'DoSomething(struct _str*)' Error: function and prototype differ in return type:'DoSomething(struct _str*)' Internal Error:Unable to find function ID:0x10000390 Failure "I:\Program Files\SourceBoost\boostc.pic18.exe" main.c -t PIC18F4550 -W2 -v -W2 -O0 "I:\Program Files\SourceBoost\boostc.pic18.exe" Function.c -t PIC18F4550 -W2 -v -W2 -O0 "I:\Program Files\SourceBoost\boostlink.pic.exe" /ld "I:\Program Files\SourceBoost\lib" libc.pic18.lib main.obj Function.obj /t PIC18F4550 /d "I:\BoostC Compiler" /p main -O0 Exit code was -2. Removing target: main.hex Done Expected behaviour: Successful link. Is the problem 100% reproduceable: With this example, yes IDE version: SourceBoost IDE version 6.40 Compiler: BoostC Compiler Compiler version: 6.40 Target device: PIC18F4550 OS: : XP Pro SP2
  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_ytes bits; } anony0; #else b_ytes bits; }; #endif } BYTE; typedef union _WORD { word _word; struct { b_ytes byte0; b_ytes byte1; #ifdef BOOSTC } anony1; #else }; #endif struct { BYTE Byte0; BYTE Byte1; #ifdef BOOSTC } anony2; #else }; #endif struct { BYTE LowB; BYTE HighB; #ifdef BOOSTC } anony3; #else }; #endif struct { b_ytes v[2]; #ifdef BOOSTC } anony4; #else }; #endif } WORD; WORD W1; WORD W2; unsigned int i1=123; unsigned int i2=456; b_ytes b0='a'; b_ytes b1='z'; //------------------------------------------------------ void main() { #ifdef BOOSTC W1._word=i1; W2.anony1.byte0=b0; W2.anony1.byte1=b1; W2=W1; W2.anony2.Byte0._byte=b0; W2.anony3.HighB.anony0.bits=0xaa; #else W1._word=i1; W2.byte0=b0; W2.byte1=b1; W2=W1; W2.Byte0._byte=b0; W2.HighB.bits=0xaa; #endif } // END Expected behaviour: To compile the example with #define BOOSTC commented out. Is the problem 100% reproduceable: Yes IDE version: SourceBoost IDE version 6.35 Compiler: BoostC Compiler Compiler version: 6.35 Target device: PIC18F4550 OS: : XP Pro SP2 Comments: Anonymous references make for prettier code - if you could implement it would be nice, perhaps with a compiler switch to enable if necessary
  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 identifiers from the symbol table? The typedefs are substrings (first part == prefix) of the other declarations - storage and functions. // BoostC Compiler options -v -W2 -Oa -Su -t PIC18F4550 #include <system.h> //------------------------------------------------------ // As is generates an "error: missing semicolon" and an // "error: failure" for line byte_to_send--; // in function byte_byte // If the 'b' of 'byte' is deleted in the line // #define STORAGE_B byte // a different error is generated. // If the 'w' of 'word' is deleted in the line // #define STORAGE_W word // this program will compile WITHOUT ANY ERRORS !!!! // Is there an internal problem within the compiler when // a symbol lookup is performed? ie. what happens // with: // byte // byte_byte // byte_to_send // i think 'byte' may be returned first??? #define STORAGE_B byte #define STORAGE_W word typedef unsigned char STORAGE_B; // 8-bit typedef unsigned int STORAGE_W; // 16-bit //------------------------------------------------------ STORAGE_B len=64; void byte_byte(void); void word_byte(void); //------------------------------------------------------ void byte_byte() { STORAGE_B byte_to_send=len; while(byte_to_send) byte_to_send--; } //----------------------------------------------------- void word_byte() { STORAGE_W byte_to_send=len; while(byte_to_send) byte_to_send--; } //------------------------------------------------------ void main() { byte_byte(); word_byte(); } // END Expected behaviour: I would expect the example code to compile without error. Is the problem 100% reproduceable: Errors and subsequent errors from fixing one problem occur in other places or reveal further warnings and error - this was found as I converted Microchip's USB firmware to compile with BoostC. IDE version: SourceBoost IDE version 6.35 Compiler: BoostC Compiler Compiler version: 6.35 Target device: PIC18F4550 OS: : XP Pro SP2 Comments: I think I found that changing the byte_to_send-- to a --byte_to_send may produce a different error or no error at all?? G
  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 linker Memory Usage Report =================== RAM available:2048 bytes, used:475 bytes (23.2%), free:1573 bytes (76.8%), Heap size:1573 bytes, Heap max single alloc:127 bytes ROM available:32768 bytes, used:3427 bytes (10.5%), free:29341 bytes (89.5%) ------------------------------------------------ Second set of results are for the same as above except the calls to the stuff in user.* and temperature.* have been commented out, although compileed and included in the link, but optimised out by the linker, which gives: With aggressive optimistation in both compiler and linker RAM available:2048 bytes, used:474 bytes (23.2%), free:1574 bytes (76.8%), Heap size:1574 bytes, Heap max single alloc:127 bytes ROM available:32768 bytes, used:3031 bytes (9.3%), free:29737 bytes (90.7%) ------------------------------------------------ I have not had sufficient time to proceed further. I think the following are the main files to modify for a new project usbdsc.c Declares the descriptors and initialises them as required. modified for each project. Huge comment section to be read!!! usbmap.c Defines all necessary endpoints from ep0 up until the maximum number of endpoints specified in usbcfg.h as macro MAX_EP_NUMBER, have been declared. Huge comment section to be read!!! usbcfg.h Definitions for operational configuration (I think). I need to expand my short notes below. 0x00 , ep2 is CDC COMM ep2Bi of length 8 bytes is CDC INT 0x01 , ep3 is CDC DATA ep3B0 of length 64 bytes is CDC BULK OUT ep3Bi of length 64 bytes is CDC BULK IN Regards, G
  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 forum's personal message system? It may save you a monster of an edit! Regards, G
  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 the preprocessor and the 'failure' from the compiler? Steps to reproduce: Compile the example code. Expected behaviour: The compiler should initialise the structure correctly. Is the problem 100% reproduceable: With this example code yes. IDE version : Any Compiler : BoostC Compiler Compiler version : 6.35 Target device : PIC18F4550 OS: : XP Pro SP2 Code example: #include <system.h> #define DSC_DEV 0x01 #define CDC_DEVICE 0x02 #define EP0_BUFF_SIZE 8 /* 8, 16, 32, or 64 */ typedef unsigned char byte; typedef unsigned int word; typedef struct _USB_DEV_DSC { byte bLength; byte bDscType; word bcdUSB; byte bDevCls; byte bDevSubCls; byte bDevProtocol; byte bMaxPktSize0; word idVendor; word idProduct; word bcdDevice; byte iMFR; byte iProduct; byte iSerialNum; byte bNumCfg; } USB_DEV_DSC; USB_DEV_DSC device_dsc= { sizeof(USB_DEV_DSC), // Size of this descriptor in bytes DSC_DEV, // DEVICE descriptor type 0x0200, // USB Spec Release Number in BCD format CDC_DEVICE, // Class Code 0x00, // Subclass code 0x00, // Protocol code EP0_BUFF_SIZE, // Max packet size for EP0, see usbcfg.h 0x04D8, // Vendor ID 0x000A, // Product ID: CDC RS-232 Emulation Demo 0x0000, // Device release number in BCD format 0x01, // Manufacturer string index 0x02, // Product string index 0x00, // Device serial number string index 0x01 // Number of possible configurations }; Compiler output: Executing: "I:\Program Files\SourceBoost\boostc.pic18.exe" main.c -O0 -W1 -v -t 18F4550 BoostC Optimizing C Compiler Version 6.35 (for PIC18 architecture) http://www.sourceboost.com Copyright(C) 2004-2006 Pavel Baranov Copyright(C) 2004-2006 David Hobday Licensed to me under Single user Full License for 1 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only main.c Starting preprocessor: "I:\Program Files\SourceBoost\pp.exe" "I:\Documents and Settings\Darkroom\My Documents\Projects\Microchip\Structs\main.c" -i "I:\Program Files\SourceBoost\include" -d _PIC18F4550 -la -c2 -o main.pp -v -d _BOOSTC -d _PIC18 I:\Documents and Settings\Darkroom\My Documents\Projects\Microchip\Structs\main.c(25:2): error: incompatible types 'unsigned char' and 'struct USB_DEV_DSC' main.c success failure BUILD FAILED: Tue Apr 18 21:10:35 2006
  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
×
×
  • Create New...