Jump to content

rlang

EstablishedMember
  • Content Count

    46
  • Joined

  • Last visited

Community Reputation

0 Neutral

About rlang

  • Rank
    Regular
  1. The types of changes that I had to make included were: 1. How fixed memory is allocated. 2. How binary constants are defined. 3. How bit variables are defined. I did not know there were any options to turn on/off optimization in BOOSTC. Could you tell me what they are? I noticed that you did not have any USB examples in BOOSTC examples. Feel free to use the source I sent you on 2/13 (usbtestcc.c) as a working example.
  2. I have finished debugging my USB to MIDI interface for the PIC18F2455 chip with BOOSTC. I decided to recompile using the C18 compiler from Microchip. Converting the source to C18 reqired a lot of changes. I had the following results: PROGRAM SPACE USED (OUT OF 24K) BOOSTC 9445 C18 7616
  3. I'm sorry, I condensed too much of the program. The actual problem is shown below. Note that byte2 is never set. // microprocessor is 18F2455 #include "system.h" //pic definition files required by boostc typedef struct { unsigned char cable; unsigned char byte0; unsigned char byte1; unsigned char byte2; unsigned char running_status; unsigned char expected_bytes; unsigned char wait_bytes; unsigned char sysex_ctr; }midi_rec; midi_rec mymidi; void itsasub(midi_rec *midi) { // when this program is executed midi->byte2 is never set equal to 'A' // even though midi->wait_bytes is equal to 0 the second time through. unsigned char mybyte; unsigned char i; mybyte='A'; midi->wait_bytes=1; for (i=0;i<2;i++) { if(midi->wait_bytes) // if wait bytes > 0 midi->byte1 = mybyte; // store in byte 1 else // if wait_bytes=0 midi->byte2 = mybyte; // store in byte 2 midi->wait_bytes=midi->wait_bytes -1; } } void main() { itsasub(&mymidi); }
  4. Bug description: Structure variable testing produces incorrect results. Program compiled and executed with IDE 5.9 and BOOSTC 2.0.1 Steps to reproduce: 1 Compile the following program and execute in debug mode watching variables midi->wait_bytes and midi->byte2. // microprocessor is 18F2455 #include "system.h" //pic definition files required by boostc typedef struct { unsigned char cable; unsigned char byte0; unsigned char byte1; unsigned char byte2; unsigned char running_status; unsigned char expected_bytes; unsigned char wait_bytes; unsigned char sysex_ctr; }midi_rec; midi_rec midi; void main() { // when this program is executed midi->byte2 is never set equal to 'A' // even though midi->wait_bytes is equal to 0 the second time through. unsigned char mybyte; unsigned char i; mybyte='A'; midi->wait_bytes=1; for (i=0;i<2;i++) { if(midi->wait_bytes) // if wait bytes > 0 midi->byte1 = mybyte; // store in byte 1 else // if wait_bytes=0 midi->byte2 = mybyte; // store in byte 2 midi->wait_bytes=midi->wait_bytes -1; } } Expected behavior: The second execution of the for loop would place ‘A’ in midi->byte2. Is the problem 100% reproducible: Yes BoostC Optimizing C Compiler Version 2.0.1 Beta (for PIC18 architecture) success BoostLink Optimizing Linker Version 2.0.1 Beta Warning: Unable to successfully create 'delay_us' for target with clock freq 4000000 Hz Warning: argument of 'delay_10us' calls must have a value of 1 or more Building CASM file Memory Usage Report =================== RAM available:2048 bytes, used:11 bytes (0.6%), free:2037 bytes (99.4%) ROM available:24576 bytes, used:103 bytes (0.5%), free:24473 bytes (99.5%) Successful Done OS: Windows 98 Comments: Is there a workaround?
  5. Memory allocation I have used the following statements unsigned char * tobuffer; tobuffer = (unsigned char *) (0x550); in a subroutine to to allocate a buffer at 0x550 in General Purpose Register/USB Ram for use by USB. I would like to globally allocate a buffer at 0x600 to be used as a serial buffer by all the subroutines in a program. Do I have to allocate the same buffer and address in every subroutine that uses it? A more general question is if I just allocate a global buffer with unsigned char * mybuffer; at the beginning of the program what prevents mybuffer from being allocated memory locations like 0x551 to store its data?
  6. Internal Error: Unable to resolve label ID:0x100002F6 Failed Exit code was -1. [No error.] Through trial and error I determined what was causing the above linkage error. I had incorrectly used a logical AND when I should have used a bitwise AND. if (portc && 0x01) {} instead of if (portc & 0x01) {} Maybe a better error message could be developed. Thanks for your help. Rob
  7. I installed the missing TDF file you sent however I still get the error above during link and do not know what it is telling me.
  8. I changed two lines that were causing all the constant errors. I changed while (!btxif); // wait until tx register is empty to while (btxif == 0); // wait until tx register is empty (note that line is in your serial driver example) I now get the following error during link BoostLink Optimizing Linker Version 2.0 Beta Reading:C:\SBOOST\config\PIC18F2455.TDF failed Failed I noticed that the PIC18F2455.TDF was missing from the 5.9 IDE release, so I made a copy of PIC18F4455.TDF and renamed it PIC18F2455.TDF. Now I get some sort of internal linker error BoostLink Optimizing Linker Version 2.0 Beta http://www.picant.com/c2c/c.html Warning: Unable to successfully create 'delay_us' for target with clock freq 4000000 Hz Warning: argument of 'delay_10us' calls must have a value of 1 or more Internal Error: Unable to resolve label ID:0x100002F6 Failed Exit code was -1. [No error.] Any help appreciated.
  9. Bug description: Program that compiled and executed with IDE 5.8 and BOOSTC 1.9.3 will not compile with IDE 5.9 and BOOSTC 2.0 Steps to reproduce: 1 Program that previously generated on compile time errors now generates the following: BoostC Optimizing C Compiler Version 2.0 Beta (for PIC18 architecture) usbtest.c(233:10): warning: '!' operation has no effect usbtest.c(885:12): error: l-value specifies const object usbtest.c(885:12): error: failed to generate expression usbtest.c(886:10): error: l-value specifies const object usbtest.c(886:10): error: failed to generate expression usbtest.c(888:10): error: l-value specifies const object usbtest.c(888:10): error: failed to generate expression usbtest.c(888:2): error: error in the body of 'if' expression usbtest.c(898:12): error: l-value specifies const object usbtest.c(898:12): error: failed to generate expression usbtest.c(899:10): error: l-value specifies const object usbtest.c(899:10): error: failed to generate expression usbtest.c(901:10): error: l-value specifies const object usbtest.c(901:10): error: failed to generate expression usbtest.c(901:2): error: error in the body of 'if' expression usbtest.c(916:12): error: l-value specifies const object usbtest.c(916:12): error: failed to generate expression usbtest.c(917:10): error: l-value specifies const object usbtest.c(917:10): error: failed to generate expression usbtest.c(919:10): error: l-value specifies const object usbtest.c(919:10): error: failed to generate expression usbtest.c(919:2): error: error in the body of 'if' expression usbtest.c(923:12): error: l-value specifies const object usbtest.c(923:12): error: failed to generate expression usbtest.c(924:10): error: l-value specifies const object usbtest.c(924:10): error: failed to generate expression usbtest.c(926:10): error: l-value specifies const object usbtest.c(926:10): error: failed to generate expression usbtest.c(926:2): error: error in the body of 'if' expression usbtest.c(930:12): error: l-value specifies const object usbtest.c(930:12): error: failed to generate expression usbtest.c(931:10): error: l-value specifies const object usbtest.c(931:10): error: failed to generate expression usbtest.c(933:10): error: l-value specifies const object usbtest.c(933:10): error: failed to generate expression usbtest.c(933:2): error: error in the body of 'if' expression usbtest.c(1035:12): error: l-value specifies const object usbtest.c(1035:12): error: failed to generate expression usbtest.c(1036:10): error: l-value specifies const object usbtest.c(1036:10): error: failed to generate expression usbtest.c(1039:10): error: l-value specifies const object usbtest.c(1039:10): error: failed to generate expression usbtest.c(1039:2): error: error in the body of 'if' expression usbtest.c(1056:12): error: l-value specifies const object usbtest.c(1056:12): error: failed to generate expression usbtest.c(1057:10): error: l-value specifies const object usbtest.c(1057:10): error: failed to generate expression usbtest.c(1060:10): error: l-value specifies const object usbtest.c(1060:10): error: failed to generate expression usbtest.c(1060:2): error: error in the body of 'if' expression usbtest.c(1348:10): warning: '!' operation has no effect failure Exit code was 1. Removing target: usbtest.obj Failed to locate output file 'usbtest.obj' Done Failed 2.) Some of the old lines that are now causing problems include: 233 while (!btxif); // wait until tx register is empty 885 EP0_start = DeviceDescriptor; 886 EP0_end = DeviceDescriptor + sizeof(DeviceDescriptor); Expected behavior: Program would not have to be rewritten for new compiler version Is the problem 100% reproducible: Yes SourceBoost version: 5.9 Compiler: BoostC Compiler version: Compiler Version 2.0 beta (for PIC18 architecture) OS: Windows 98 Comments: Any idea what is going on? Looks like something that used to be ok is now verboten. What is I value?
  10. rlang

    Boost 1.92

    The fix implemented by Pavel in BOOSTC 19.3 for the array bug worked like a charm. Thank you for your quick response. The PIC18F2455 USB mouse example now works with BOOSTC. I can send if to you to use as an example if you wish. Rob
  11. rlang

    Boost 1.92

    I need code where I can reproduce the problem. Yous code looks too big and I assume it includes ather stuff as well. Will I be able to see the problem running it under simulator? Regards, Pavel <{POST_SNAPBACK}> I sent a short version of the project files called bug6 to the support email address as a zip file. Rob
  12. Since only strings are supported in rom in BOOSTC, I was wondering if there a way to put hex data into a string? I don't want to translate to decimal. unsigned char * mystring="\15\16\17"; works but unsigned char *mystring="\xF\x10\x12"; does not
  13. rlang

    Boost 1.92

    It is about 24 pages of code but I can send it to you at the support email address if you wish. Rob
  14. rlang

    Boost 1.92

    Bug description: BOOSTC 1.92 array data not recoverable Steps to reproduce: 1.) I create a 50 byte array with the following lst file 1A78 0E05 MOVLW 0x05 1A7A 6E3A MOVWF gbl_ReportDescriptor1 1A7C 0E01 MOVLW 0x01 1A7E 6E3B MOVWF gbl_ReportDescriptor1+D'1' 1A80 0E09 MOVLW 0x09 1A82 6E3C MOVWF gbl_ReportDescriptor1+D'2' … 1B00 0E30 MOVLW 0x30 1B02 6E5D MOVWF gbl_ReportDescriptor1+D'35' 1B04 0E09 MOVLW 0x09 1B06 6E5E MOVWF gbl_ReportDescriptor1+D'36' 1B08 0E31 MOVLW 0x31 1B0A 6F5F MOVWF gbl_ReportDescriptor1+D'37', 1 1B0C 0E15 MOVLW 0x15 1B0E 6F60 MOVWF gbl_ReportDescriptor1+D'38', 1 … 1B2C 0E81 MOVLW 0x81 1B2E 6F68 MOVWF gbl_ReportDescriptor1+D'46', 1 1B30 0E06 MOVLW 0x06 1B32 6F69 MOVWF gbl_ReportDescriptor1+D'47', 1 1B34 0EC0 MOVLW 0xC0 1B36 6F6A MOVWF gbl_ReportDescriptor1+D'48', 1 1B38 0EC0 MOVLW 0xC0 1B3A 6F6B MOVWF gbl_ReportDescriptor1+D'49', 1 2.) Attempt to recover data past element 36 results in garbage. Expected behavior: Data initialized would be same as data retrieved. Is the problem 100% reproducible: Yes SourceBoost version: 5.8 Compiler: BoostC Compiler version: Compiler Version 1.92 Alpha (for PIC18 architecture) OS: Windows 98 Comments: Seems like I saw some traffic about exceeding 256 byte boundaries. If that is the problem how can I prevent and is there any way to know this is happening without looking at the list file. It took a week to figure this out.
  15. Bug description: BOOSTC 1.8 defines unimplemented configuration memory Steps to reproduce: 1.) Compile program for PIC18F2455 #include <system.h> #pragma DATA _CONFIG1L, 00100100b #pragma DATA _CONFIG1H, 00001111b #pragma DATA _CONFIG2L, 00111111b #pragma DATA _CONFIG2H, 00011110b #pragma DATA _CONFIG3H, 10000000b #pragma DATA _CONFIG4L, 10000001b // DEBUG AND LVP off #pragma DATA _CONFIG5L, 00001111b #pragma DATA _CONFIG5H, 11000000b #pragma DATA _CONFIG6L, 00001111b #pragma DATA _CONFIG6H, 11100000b #pragma DATA _CONFIG7L, 00001111b #pragma DATA _CONFIG7H, 01000000b void interrupt( void ) { portb++; clear_bit( intcon, TMR0IF ); //clear TMR0 overflow flag } void main() { trisb = 0; //configure port B portb = 0; clear_bit( t0con, T0CS ); // select internal clock clear_bit( t0con, T0PS3 ); // select pres-scaler set_bit( t0con, T0PS0 ); // set pres-scaler to 1:256 set_bit( t0con, T0PS1 ); set_bit( t0con, T0PS2 ); set_bit( intcon, GIE ); // enable interrupts set_bit( intcon, TMR0IE ); //enable TMR0 overflow bit while( 1 ) {} } 2.) Examine listing ORG 0x00300000 300000 0F24 DW 0x0F24 300002 1E3F DW 0x1E3F ORG 0x00300004 300004 80FF DW 0x80FF 300006 FF81 DW 0xFF81 ORG 0x00300008 300008 C00F DW 0xC00F 30000A E00F DW 0xE00F 30000C 400F DW 0x400F Expected behavior: Config locations 300004 and 300007 do not exist on the microprocessor but FF is defined for that location. When a non-existent config location is read 0 is returned. This may cause a problem in verification. It would be nice if 0 were loaded in these two locations. Is the problem 100% reproducible: Yes SourceBoost version: 5.7 Compiler: BoostC Compiler version: Compiler Version 1.8 Alpha (for PIC18 architecture) OS: Windows 98 Comments: None
×
×
  • Create New...