Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About hollie

  • Rank

Contact Methods

  • Website URL
  • ICQ
  1. Dave, thanks for your swift reply. Inserting the lookup table with the #pragma DATA solves my problem. However, I notice that the compiler v6.40 does not take into account the program memory area that I assign using the #pagma DATA. It happily maps the other application code on the same memory location. This problem is correctly flagged during assembly. I have to manually map the table 'high enough' in memory to make sure that there is no other code overlapping with the defined table. Is this intended behaviour, or should I file a bugfix/enhancement request on this? It would be nice to be able to put the table in front of my other code so I don't have to worry about setting the PCLATH register before adding the offset to the PCL register. Kind regards, Lieven.
  2. Hello, in a time-critical application, I need to look up a calibration value from a table of 128 values that is placed in ROM. The table is defined as rom char* calibration_table = {0x10, 0x20, 0x30 , <and so on...>}; When I try to read a value from the table, it takes quite some cycles before the value is returned. This is due to the assembly code that is generated to read rom tables: __rom_get_00000 ; { __rom_get; function begin MOVF __rom_get_00000_arg_objNumb, W MOVWF __rom_get_00000_1_gotoTblOffs CLRF __rom_get_00000_1_gotoTblOffs+D'1' MOVF __rom_get_00000_arg_idx, W MOVWF __rom_get_00000_1_gotoTblOffs+D'2' BCF STATUS,C RLF __rom_get_00000_1_gotoTblOffs, F RLF __rom_get_00000_1_gotoTblOffs+D'1', F MOVF __rom_get_00000_arg_objNumb, W ADDWF __rom_get_00000_1_gotoTblOffs, F BTFSC STATUS,C INCF __rom_get_00000_1_gotoTblOffs+D'1', F MOVLW LOW( label4026531870 ) ADDWF __rom_get_00000_1_gotoTblOffs, F MOVLW HIGH( label4026531870 ) BTFSC STATUS,C INCF __rom_get_00000_1_gotoTblOffs+D'1', F ADDWF __rom_get_00000_1_gotoTblOffs+D'1', F MOVF __rom_get_00000_1_gotoTblOffs+D'1', W MOVWF PCLATH MOVF __rom_get_00000_1_gotoTblOffs, W MOVWF PCL label4026531870 MOVLW HIGH( label4026531871 ) MOVWF PCLATH GOTO label4026531871 MOVLW HIGH( label4026531872 ) MOVWF PCLATH GOTO label4026531872 label4026531871 MOVLW LOW( label4026531873 ) ADDWF __rom_get_00000_1_gotoTblOffs+D'2', W MOVLW HIGH( label4026531873 ) BTFSC STATUS,C ADDLW 0x01 MOVWF PCLATH MOVF __rom_get_00000_1_gotoTblOffs+D'2', W ADDWF PCL, F label4026531873 RETLW 0x10 RETLW 0x20 ... table goes on here I assume the code just below the rom_get label is a way to support multiple rom tables in memory by using just one function entry. This code then selects the correct table to jump to. The question is: is it possible to get around this? What I'd like to have in the end is some assembly code that look like: ; get the value at position 5 movlw 5 call lookup_table ; w register will contain the value now lookup_table addwf PCL, F nop retlw 0x10 retlw 0x20 ... and so on I tried to put this in an 'asm' block inside a function like this: void lookup_table(char index){ char retval; asm { goto getval lookuptable: addwf _pcl, F nop retlw 0x10 retlw 0x20 retlw 0x30 getval: movf _index, W call lookuptable movwf _retval } return retval; } But the compiler errors out with: The target device is a PIC16F84, there is no option to select another device that can do FLASH reads. Any ideas how to get around this one? Thanks, Lieven. P.S. I know I need to be careful not to cross page boundaries with this type of code.
  3. Hi Pavel, Great! I'll update my libs then. I noticed that the warning directive is not mentioned in the BoostC documentation yet. Regards, Lieven.
  4. Hello, currently, the preprocessor only supports generating errors at compile time. Would it be possible to add support for a #warning directive please? This would allow the programmer to print a statement to the compilation output window. I ask this because I've been debugging some code that worked fine on an 18F2320 and that stopped working after the transition to an 18F4620. Half a day later I found out that 'DEBUG' is defined for the 18F4620 target It would be very handy (and time-saving) if something like the following code construct is supported: #ifdef SOMETHING #warning "Using alternative code, because SOMETHING is defined" ... #endif Regards.
  5. Hello Roger, what I mean with the 'bit banging' is that the code library does not use a hardware unit in the PIC. The required waveform is generated in software. This is normal, as the PIC16F87X-series have no built-in funtionality to deal with one wire devices. The fact that the interface is emulated in software gives you the flexibility to use whatever IO you have available on your PIC to connect the one-wire devices to (hence the 'any pin' part of the statement). Kind regards, Lieven.
  6. Hello Dave, indeed, thank you. Regards, Hollie.
  7. Hello Dave, I have 2 remarks on this: Firstly, it seems to me that if there is no clock frequency is specified in a source file, a 4 MHz clock is assumed (see the error log in my first post, "Unable to successfully create 'delay_us' for target with clock freq 4000000 Hz". I really didn't specify anything like that in my source files). Secondly, if what I describe is the intended behaviour (as you tell in your reply), then you mean that one has to specify the clock frequency in all the source files of the project, since there is no way to predict the order in which they will be included in a project? This looks a bit strange to me. If you state that it is working correctly with compiler v1.9.1, then I think you need to add that it only works correctly if one first loads the main project file separately and then all the other source files of a project in a second step. This ensures that in the <project.__c> file, the main source file is mentioned first. Hence, it will be compiled first and the clock frequency will be known for compiling all subsequent source files. I think this should be stated in the documentation. Of course, when building a project from scratch, the user will normally first create the main file and will only later on add additional source files. But if one wants to make a new project starting from an existing project, I think it is not so strange if the user creates an empty project and includes all the source files of the other project in one step. In this case the problem I described can/will occur. Maybe another solution would be that the user can select one file to be the 'top of the design' and that this file is always compiled first? Or the compiler could compile the file that contains the 'main' function first? Kind regards, Hollie.
  8. Hello, in the mean time I have figured out that the only difference between the project that works and the one that doesn't is in the project file. The version that doesn't link contains: [Files] File0=solar.h Count=6 File1=adc.h File2=serial.c File3=serial.h File4=solar.c File5=adc.c The one that does link contains: [Files] File0=solar.h Count=6 File1=serial.h File2=solar.c File3=adc.h File4=serial.c File5=adc.c The clock frequency pragma is located in 'solar.h', so I think that the new linker assumes that the clock frequency is 4 MHz until it encounters the pragma statement (this statement is only encountered in the file 'solar.c', since 'solar.h' is included there). This would explain why it complains about the multiple clock frequency definitions. Did this behaviour change from the previous version? With the v1.8 compiler, I did not encounter this problem. Kind regards.
  9. Hello, I encounter a strange problem when I try to compile a project that I created in a previous version of SourceBoost/BoostC. When I load the old project file, or I create a new project and add all the source files at once, I get the following error at link time: Linking... C:\usr\local\SourceBoost\linker.exe /ld C:\usr\local\SourceBoost\lib libc.pic16.lib serial.obj solar.obj adc.obj /t 16F876A /d D:\home\xxxxx\projects\pic\test2 /p test2 BoostLink Optimizing Linker Version 1.9 Beta http://www.picant.com/c2c/c.html Copyright(C) 2004-2005 Pavel Baranov Copyright(C) 2004-2005 David Hobday Error: .obj/.lib different clock frequencies specified Error: Failed to process:solar.obj Error: .obj/.lib different clock frequencies specified Error: Failed to process:adc.obj 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 Failed Done There are 2 errors here: firstly the clock rate is only declared once, so it is strange that the linker tells me that different clock frequencies are specified. And secondly, the clock rate is declared to be 10MHz (both in the source file and in the IDE), while the linker tells me it is only 4MHz. What I did to solve this: I created a second new project, added the source files one by one (first the main file and then the 'libs'), and started a compilation between every addition of a file to the project (the compilations failed of course...). Once all files are added, the final project compiles and links properly. Steps to reproduce: Open the old project, or create a new project and add all the source files at once. Try to build the project. It fails. Expected behaviour: the project should build properly. Reproducible: 100%, I can send you 2 example projects that contain the same source code. One fails and one doesn't. IDE version : 5.8 Compiler : BoostC 1.9.1 Linker : 1.9 Target device : PIC16F876A OS : W2K
  10. Hello, when debugging my code, I use a preprocessor directive 'DEBUG' that I define at the command line using the '-d' option. I can then in my code skip certain sections that are hard to simulate, e.g. waiting for the completion of a serial transmission of the hardware UART unit in a PIC. Would it be possible to add a preporcessor directive '#warn' that prints its argument to the output pane? It would do exactly the same as the #error directive, but it should not cause a compilation error. In this way I could add a code statement like this: #ifdef DEBUG #warn "Debugging is enabled, certain code sections will be skipped!" #endif This way, it would be harder to 'forget' that the debugging directive is enabled, and thus loading code that won't work in your target device. Kind regards, Hollie.
  11. Hello, @asmallri: thank you for your suggestion. I know that I am writing processor specific code. However, considering the we have quite some LCD-related things going on and that even the data pins are not always connected to one single port, I thought it would be handy to have the tris-registers auto-calculated. It reduces the risk of introducing errors for our specific implementation. @dave: thanks for the clarification. I understand the concept of the volatile keyword, and I indeed incorrectly used it for the definition of the TRIS bits. However, even without the volatile keyword, the language construct #define PORTB 0x06 bit tris_bit @ PORTB + 0x80 . 0 fails. Could this be a handy feature to include in the compiler? Kind regards, Hollie.
  12. Hello, I have a question concerning the declaration of a volatile. I'm writing an LCD lib that would be very flexible in terms of pin location on the PIC (i.e. the data pins do not have to be connected to the upper or lower nibble of a port). For this, the volatiles are very handy. What I would like to do is to let the user of the code declare the port and the pin number of a certain connectio pin, e.g. #define LCD_DATA4_PORT PORTB #define LCD_DATA4_PIN 0 The 'internal' part of the code then works like: volatile bit lcd_d4 @ LCD_DATA4_PORT.LCD_DATA4_PIN; Now what I would like to be able to write also is: volatile bit lcd_tris_d4 @ LCD_DATA4_PORT + 0x80 . LCD_DATA4_PIN; So that the user doens't need to bother about declaring the TRIS register separately. However, it seems like doing <something> @ number + number . pin; is not supported. I think the compiler gets stuck on the addition in the address. Is this intended behaviour or should I post a bug report for this? Kind regards, Hollie.
  13. Hello all, I can confirm that the fix as described by asmallri works fine with the BoostC compiler. The compiler generates in the first four instruction words a jump to the main code. If the main code is not in bank 0, then the compiler will generate the required bank selection code. Clearing the PCLATH in the bootlader before rolling into the four instruction words makes sure that the PC points to the correct bank for the goto. So basically, when you are using the BoostC compiler, you don't need to insert asm statements any more for the bootloader to work. Kind regards, Hollie.
  14. Hello Dave, Thanks, looking forward to release 1.8 Regards, Hollie.
  15. Hello Andrew, indeed, this is a better solution. I'll look into the source of the bootloader I use and make the required changes. Thanks for your input. Kind regards, Hollie.
  • Create New...