Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by hollie

  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.
  16. Hello Dave, the bootloader I use does load high (I'm using the Tiny PIC bootloader). However, in order to be able to be launched after reset, the first 4 words from the original PIC program are moved to a location in high memory and are being replaced by a jump to the bootloader code. This causes a paging problem with 16F devices when the original 'goto main' is not preceded by a correct 'pagesel'. Since it is placed in high memory, the goto fails. I'll settle with modifying the asm file by hand for now and I'll be looking forward to the next version of the BoostC Another possible solution for this problem (instead of shifting the entire code as you mention) would be to allow the #pragma DATA to actually reserve a certain memory location, or to interpret the 'org' statement in inline assembly code. Anyway, thanks for the information. Regards, Hollie.
  17. Dave, aha, this could be a problem. The bootloader I use requires 4 specially crafted opcodes starting at locations 0x00 - 0x03. (I believe most bootloaders do, since they need to have a way to intervene in the 'boot process' of the PIC). So you mean that there is no way to put a specific opcode at 0x00? I already tried with assembly code also, but the compiler doesn't understand the org 0x00 statement. Are there any other options to obtain the same result? Kind regards, Hollie.
  18. Hi Dave, Ok, no problem. Actually I'm just switching from quite some year of assembly PIC programming, so those few opcodes won't hurt. Thanks for your swift reply. Kind regards, Hollie.
  19. Hello, does the BoostC 1.7 support inserting specific code at certain memory locations? In C2C-plus, one could do: #pragma RESERVE_ADDR_0 clrf 0x3 #pragma RESERVE_ADDR_1 movlw 0x00 #pragma RESERVE_ADDR_2 movwf 0xA #pragma RESERVE_ADDR_3 goto start__code What is the equivalent code that is supported by BoostC 1.7? Do I need to add the opcodes with a #pragma DATA statement? Thanks in advance, Hollie.
  20. Hello, I know that the BoostC is still under development, and that the documentation is not complete yet. However, I would like to point out a small typo in the 'volatile' section. volatile pinB1@0x6.1; //declare bit variable mapped to pin 1 of port B should read volatile bit pinB1@0x6.1; //declare bit variable mapped to pin 1 of port B according to me. Kind regards, Hollie.
  21. Hello, I'm giving the new BoostC 1.7 a try, and I wonder if it is possible to disable the interrupt context saving code generation in the linker. When I select a target that has no shared memory between banks (e.g. a PIC16F873A), then the linker fails with the following error message: Error: Unable to allocate memory for interrupt context saving Can I disable this feature somewhere? It is possible to disable this option for the C2C-plus toolsuite (through settings -> options -> compile options) but for the BoostC toolsuite, the option seems to be not available. I know I have to take care of the contect saving myself if I disable this option. Regards, Hollie.
  • Create New...