Jump to content

manuel123

EstablishedMember
  • Content Count

    20
  • Joined

  • Last visited

Community Reputation

0 Neutral

About manuel123

  • Rank
    Regular
  1. Bug description: A triple add on unsigned short global variables and function return values fails when compling with -O2 or -Oa Steps to reproduce: In the following code the variable 'a' should be calculated to 4 but it is calculated to 5 instead. If the code is compiled with -O0 or -O1 the result is correct. unsigned short a = 1; unsigned short bar() { return 1; } void main() { // when compiling with -O2 or -Oa // the following line results in 5 instead of 4 a = a + a + a + bar(); } Expected behaviour: The variable 'a' should be calculated to 4. Is the problem 100% reproduceable: Yes, every time with the code above and -O2 or -Oa. IDE version: 6.93 Compiler: BoostC Compiler version: 6.93 Target device: PIC16F88 OS: WinXP Home SP3 Comments: Project file and source code are attached in the zip. AddAdd.zip
  2. Bug description: Under certain conditions labels are missing in the .casm file. Steps to reproduce: #include <system.h> unsigned char var; void main() { var = 0; adcon1.0 = var.0; } Expected behaviour: The following is a section of the .casm file. Line 0007 is a jump to label1 which does not exists in the .casm file. In the corresponding .asm file label1 is placed on line 000A. So, the resulting code works but is not readable in the debugger. void main() { var = 0; 0003 1283 BCF STATUS, RP0 0004 1303 BCF STATUS, RP1 0005 01A0 CLRF gbl_var adcon1.0 = var.0; 0006 1C20 BTFSS gbl_var,0 0007 280A GOTO label1 0008 1683 BSF STATUS, RP0 0009 141F BSF gbl_adcon1,0 000A 1283 BCF STATUS, RP0 000B 1820 BTFSC gbl_var,0 000D 1683 BSF STATUS, RP0 000E 101F BCF gbl_adcon1,0 } Is the problem 100% reproduceable: Yes. IDE version: 6.82 Compiler: BoostC, Compiler version: boostc.pic16.exe / v6.82 Target device: PIC16F88 OS: WinXP Comments: This is a minor bug because the resulting code and the behaviour of the debugger are correct. But the asm code is hard to read. BR manuel123
  3. Thank you very much! Yes you are right there is a problem here, it has been made apparent because this target has some unbanked memory. This is now fixed and will be in the next release. Regards Dave
  4. Compile the code for array length 80 and step though it with the debugger. RP0 is cleared at program start and will never be set before you arrive at BSF gbl_trisb,1 So, portb is accessed with this instruction, not of trisb. BR manuel123 The banks switching is CORRECT in both cases. When the array length is increased, the i variable ends up being placed into memory that appears in all banks, so no banks switching is required to access this variable. Regards Dave
  5. Dave, thanks for the reply. The problem is not the variable i but trisb which is available only in bank 1. There must be a BSF STATUS, RP0 somewhere in the code! Regards Manuel The banks switching is CORRECT in both cases. When the array length is increased, the i variable ends up being placed into memory that appears in all banks, so no banks switching is required to access this variable. Regards Dave
  6. In the HITECH code for the LCD the initialization is different and there is a for-loop after the init. Try doing something similar. Can you operate the PIC at 4MHz as the example code does? void setup(void) { unsigned long x; TRISC = 0xff; PORTC = 0xff; SSPSTAT = 0x80; SSPCON = 0x38; SSPCON2 = 0x00; SSPADD = 10; // SCL = 91khz with 4Mhz Osc for(x=0; x<60000; x++); // wait for LCD03 to initialise } If you have an oscilloscope or a logic analyzer, check if the i2c communication is acknowledged: SDA line should be low (=ack) during 9th clock pulse. If you don't have a scope, try reading the version (register 0x03) of the LCD. This should give you the feedback if the LCD understands the i2c. You can send the read value to the RS232 and display it on the PC with a terminal program (e.g. hterm). Or connect an LED to one GPIO pin and visualize the bits of the read value serially. Regards manuel123
  7. The address of register to write to is missing in the code above. Do: main(void) { i2c_init(0x00); i2c_start(); i2c_write(0xc6); i2c_write(0x00); i2c_write('A'); i2c_stop(); }
  8. I recommend the usage of the i2c driver that comes along with the distribution. I assume that you have assembled the external pull-ups on the i2c bus. Here is how to use the i2c interface. Note: I did neither compile nor test the code below and I assumed that the your LCD does not need to be configured. Please check again that the #defines map the register names to the correct addresses of your PIC device. I have this i2c driver running on a different PIC device together with a different i2c LCD. //////////////////////////////////////////////////////////////////////////// // i2c hardwareware implementation template arguments //////////////////////////////////////////////////////////////////////////// #define i2c_ARGS 3, PORTC, TRISC, 4, PORTC, TRISC, e_SSPCON1, e_SSPCON2, \ e_SSPSTAT, e_SSPBUF, e_SSPIF_BIT, e_SSPIF_PIR, \ e_BCLIF_BIT, e_BCLIF_PIR, 7, e_SSPADD, (i2c_reset_wdt | i2c_SMP |i2c_HW) // variables cannot be passed as template arguments. The following constants map to // the PIC registers and PIC's i2c register locations. These constants are // then used by the templated functions. #define PORTC 0x07 #define TRISC 0x87 #define e_SSPCON1 0x14 #define e_SSPCON2 0x91 #define e_SSPSTAT 0x94 #define e_SSPADD 0x93 #define e_SSPBUF 0x13 #define e_SSPIF_PIR 0x0c #define e_BCLIF_PIR 0x0d #define e_SSPIF_BIT 3 #define e_BCLIF_BIT 3 #include "i2c_driver.h" main(void) { i2c_init0x00); i2c_start(); i2c_write(0Xc6); i2c_write('A'); i2c_stop(); }
  9. Hi Paolo, function pointers are supported since v6.70. See http://www.sourceboost.com/CommonDownload/VersionLog.html Limitations: - As far as I know arrays of function pointers are not supported. - It seems that the call tree is not parsed through function pointers. So, function pointers should be used together with a software stack or -very carfully- with the hardware stack. See http://forum.sourceboost.com/index.php?showtopic=3279 BR manuel123
  10. Hi Dave, Pavel, have you taken a look on this issue: "Bug: Bank Switching" "bank switching fails depending on memory usage" http://forum.sourceboost.com/index.php?showtopic=3290 I need to know if it is really a bug and if so, if there is a workaround and when it will be fixed. It really hurts me. BR manuel123
  11. Who ever is interested in the answer: I found it in the meantime Both, the library directory and the library name have to be specified: Settings->Options->Extra linker options ../include/<libaray name>.lib BR manuel123
  12. Hi, besides libc.pic16.lib, I want to use an additional library. In the build options I specified -ld ../include where the additionial library is located. The Linker command line is boostlink.pic.exe /ld <lib dir> libc.pic16.lib <project name>.obj /t PIC16F88 /d <project dir> /p <project name> -ld ..\include -swcs 0 1 but the output is Error: Failed to open:libc.pic16.lib or ..\include/libc.pic16.lib How do I specify the library location correctly? Thanks manuel123
  13. The i2c_driver (\SourceBoost\include\i2c_driver.h) that comes with the SourceBoost distibution provides a code template that has to be copied to the user's program. This template uses "unsigend short" data types where "unsigend char" should be sufficient. Here are the wrong and the correct code: wrong code: // RAM used by the software i2c driver to emulate the equivalent i2c hardware registers unsigned short swi2c_SSPCON1@0x40; // define location for the emulated SSPCON1 unsigned short swi2c_SSPCON2@0x41; // define location for the emulated SSPCON2 unsigned short swi2c_SSPSTAT@0x42; // define location for the emulated SSPSTAT unsigned short swi2c_SSPBUF@0x44; // define location for the emulated SSPBUF unsigned short swi2c_SSPIF_PIR@0x45; // define location for the emulated SSPIF_PIR unsigned short swi2c_BCLIF_PIR@0x46; // define location for the emulated BCLIF_PIR unsigned short swi2c_SSPADD@0x43; // define location for the emulated SSPADD correct code: // RAM used by the software i2c driver to emulate the equivalent i2c hardware registers unsigned char swi2c_SSPCON1@0x40; // define location for the emulated SSPCON1 unsigned char swi2c_SSPCON2@0x41; // define location for the emulated SSPCON2 unsigned char swi2c_SSPSTAT@0x42; // define location for the emulated SSPSTAT unsigned char swi2c_SSPBUF@0x44; // define location for the emulated SSPBUF unsigned char swi2c_SSPIF_PIR@0x45; // define location for the emulated SSPIF_PIR unsigned char swi2c_BCLIF_PIR@0x46; // define location for the emulated BCLIF_PIR unsigned char swi2c_SSPADD@0x43; // define location for the emulated SSPADD IDE version: 6.81 OS: WinXP Comments: This is a minor bug because the resulting code works. BR manuel123
  14. Bug description: If the array length is 80 in the following example, bank switching fails. If the array length is 79, bank switching works fine. Steps to reproduce: ----------------------- #include <system.h> unsigned char var[80]@0x20; unsigned char i; void main() { portb.1 = 0; for (i=0; i<2; i++) { if (i==0) trisb.1 = 1; else trisb.1 = 0; } } Expected behaviour: This is the asm code for array length 79 (correct code). The two marked lines are missing when array length is 80. main ; { main ; function begin BCF STATUS, RP0 BCF STATUS, RP1 BCF gbl_portb,1 CLRF gbl_i label268438904 MOVLW 0x02 SUBWF gbl_i, W BTFSC STATUS,C RETURN MOVF gbl_i, F BTFSS STATUS,Z GOTO label268438908 BSF STATUS, RP0 <------- missing when array length is 80 BSF gbl_trisb,1 GOTO label268438911 label268438908 BSF STATUS, RP0 BCF gbl_trisb,1 label268438911 BCF STATUS, RP0 <------- missing when array length is 80 INCF gbl_i, F GOTO label268438904 ; } main function end Is the problem 100% reproduceable: Yes. IDE version: 6.81 Compiler: BoostC, Compiler version: boostc.pic16.exe / v6.81 Target device: PIC16F88 OS: WinXP SP2 BR manuel123
×
×
  • Create New...