Jump to content

rlang

EstablishedMember
  • Content Count

    46
  • Joined

  • Last visited

Everything posted by rlang

  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
  16. Does anyone have a workaround for the above problem. No room in RAM or EEPROM. Thanks/ Rob
  17. I have a need to store some data in program memory. The new rom function seems to work well with strings but when I try the following I get errors The error is: BoostC Optimizing C Compiler Version 1.8 Alpha (for PIC18 architecture) ver18test.c(7:21): internal error: (temporarily) 'rom' pointers can be initialized with strings only failure Does this mean it is being worked (temporarily) and will be fixed in BOOSTC1.9?
  18. Problem was resolved with dave's new 13/13/2004 TDF and H files.
  19. Yes, it is the same problem. I am developing for the 18F2455 and I sent my modified tdf file to Dave for his use (without the PCL fix). Could Dave take a look at it and see what additional changes need to be made other than the PCL fix or alternately email me the tdf file he developed for http://sourceboost.ipbhost.com/index.php?showtopic=788 Thanks Rob
  20. Bug description: BOOSTC 1.8 fails to link program that compiled and linked successfully with 1.7. Steps to reproduce: 1.) Compile program no errors. Compiling... C:\SBOOST\boostc.pic18.exe -t PIC18F2455 usbtest.c BoostC Optimizing C Compiler Version 1.8 Alpha (for PIC18 architecture) http://www.picant.com/c2c/c.html Copyright© 2004 Pavel Baranov Copyright© 2004 David Hobday success Done 2.) Link program and get following Linking... C:\SBOOST\linker.exe /ld C:\SBOOST\lib libc.pic18.lib usbtest.obj /t 18F2455 /d C:\SBoost\RBL\C\BoostC /p usbtest BoostLink Optimizing Linker Version 1.8 Alpha http://www.picant.com/c2c/c.html Copyright© 2004 Pavel Baranov Copyright© 2004 David Hobday 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 Var not found id:0xFF000017 Failed Done Expected behavior: Program that compiled and linked successfully under 1.7 would also compile and link successfully under 1.8 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: What is Var not found id:0xFF000017 telling me? I am not doing anything in that area of memory.
  21. Here is a tip that might help some users when single stepping through their programs with the SOURCEBOOST IDE. The default format for displaying data in the REGISTERS window in the IDE is decimal. This can be confusing when comparing to the MEMORY window which is hexadecimal. To change a REGISTER window cell format to hexadecimal: rightclick on the cell with data and select HEXADECIMAL. Rob
  22. I noticed the problem with the bit mapping and reported it as a bug. What I did to work around it was in the yourchip.tdf file change the register bit definition to replace any "" entries with "something" entry. Rob
  23. Dave wrote For the 18F4550, chip banks0-3 are defined as user data in the microchip specification. Bank 15 is defined as SPRs. Banks 4-7 are defined as USB data or User data. The user can set up usb buffer descriptions and buffers in this area. Whatever is not needed for USB can be used for any purpose. From your note I am not clear whether banks 4-7 should be general or special function. Any guidance is appreciated. Rob
  24. Bug description: Faulty TDF file causes linkage failure for 18F2455-18F4550 chips Compiler Version 1.7 Alpha (for PIC18 architecture) Steps to reproduce: 1.) Create a new project for 18F4550 2.) Add a main.c file to the project with the following code #include <system.h> //pic definition files required by boostc void main() { //BUFFER REGISTERS //NAMING CONVENTION bdNstatDP where //N is endpoint# = 0,1,2,3 //D is direction=i,o (in,out) //P is pingpong=e,o (even,odd) char bd1statie@0x410; bd1statie=0; } 3.) Compile and link the project using BoostC Compiler Version 1.7 Alpha BoostC Optimizing C Compiler Version 1.7 Alpha (for PIC18 architecture) success BoostLink Optimizing Linker Version 1.7 Alpha Failed to allocate fixed var:bd1statie at address:0x00000410 Failed Exit code was -1. [No error.] Expected behavior: successful linkage, one should be able to access USB buffer descriptors and data in the range 400-7ff Is the problem 100% reproducible: Yes SourceBoost version: 5.7 Compiler: BoostC Compiler version: Compiler Version 1.7 Alpha (for PIC18 architecture) OS: Windows 98 Comments: The fix appears to be addition to the 18f2455,2550,4455,4550.tdf as follows: //USB RAM RegisterGP[ 100h ] { // block of general purpose memory Description = "USB RAM",""; Address = 400h; } RegisterGP[ 100h ] { // block of general purpose memory Description = "USB RAM",""; Address = 500h; } RegisterGP[ 100h ] { // block of general purpose memory Description = "USB RAM",""; Address = 600h; } RegisterGP[ 100h ] { // block of general purpose memory Description = "USB RAM",""; Address = 700h; }
  25. Dave... I gathered that about the timer because there was a note in interrupt.c but I did not read anything else into the note. Thanks for the additional information. The address of Portb has changed with the 18 series and I thought that might have confused the simulator. Rob
×
×
  • Create New...