Jump to content

PaulHolland

EstablishedMember
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

0 Neutral

About PaulHolland

  • Rank
    Regular
  1. Thanks, I know we can make all kind of tricks to solve problems, we can even make our own device.h file but that is not what should happen. The h file should be like we expect it and also what others are using.
  2. tmr1 is declared the same as tmr1l for compatibility. This is based on the way Microchip delcare these registers in their header files. Regards Dave Compatibility with what ?. Timer 1 has allways been a 16 bit timer, on all PIC12,PIC16 and PIC18 devices. Most other compilers I know treat tmr1 = 0 as a 16 bit operation. if you would write: if(tmr1 > 1000) { bla bla } it would not work on your compiler, you would have to do something like: if(tmr1h > (1000/256) if(tmr1l > (1000%256) { bla bla } I like the first example much more
  3. Yes, that solved the problem !. Do I get airmiles for finding bug's :-). Paul.
  4. Hi, I wanted to clear timer1 register in a interrupt and I used the following statement tmr1 = 0; The strange thing is that only tmr1 low part of the register is cleared !. I thought that the compiler would clear high and low at the same time unless I specified tmr1l or tmr1h register. Who know's ?. I know from other compilers that they do clear all if you leave the HIGH LOW away.
  5. I noticed when the code was overlapped, ie interrupt routine positioned over vector locations the linker generated warnings, so if this did happen it is not totally silent.So if you can accept the waste, that is forget the space used by the pclath loading and the unused goto, and move ISR to 0x107 so it's clear of any interrupt vector locations then you get what you want? The code you suggest only works because you are using a PIC16F1xxx target, in other PIC16 target there is more than a pclath loading and a goto. That's because registers have to be preserved before pclath can be loaded as
  6. Hi, I used both compilers and can tell some differences. 1: CCS is bringing out a software update almost every month, not to increase features but fix bug's 2: CCS does use its own non-standard kind-of C language. Not to improve but since they do not know how to build a REAL compiler. Most non-standard features are done since its not easy to make a ANSI C compiler for a PIC platform I think Dave can acknowledge this :-). The problem with the non standard C language is that porting your code is difficult. and this will lock you in with CCS if you build a large code base. 3: CCS: The kind
  7. easy: put the following line in your main C file top !. // ID 2000 = 0x12 // ID 2001 = 0x34 // ID 2002 = 0x56 // ID 2003 = 0x78 pragma DATA 0x2000, 0x12, 0x34, 0x56, 0x78
  8. pclath needs to be set before the goto or the goto may go to the wrong place, so they can't be set in the ISR it's self, they have to be set before.In your case you need to set pclath as part of your code before at 0x004 before jumping straight to the ISR. Regards Dave Hi Dave, I know this pclatch stuff very well but this was not my point. Construct the code I told you and compile it and see what the compiler made of the result it will look like this 0x104 bcf pclatch,3 <------------ useless instruction (see the rest of my message) 0x105 bcf pclatch,4 <----
  9. Fair comment, you are right this will slow things down. You could shift everything using -rb put the interrupt routine at a fixed address and then you could call from the original vector location as you will know it's address. Can't be done except through a asm goto and use the offset (because of -rb use) code restart entry point. There is not a mechanism to do this, -rb is the only way to stop linker using low memory. Regards Dave Hi Dave, I noticed a new problem (maybe bug) if you relocate your code with the linker command -rb 0x100 and you place your interrupt cod
  10. You can use -rb 0x100 linker option to set the ROM base address to 0x100. You will need to patch interrupts and code start through to the new code location. I hope that helps. Regards Dave Hi Dave, No, This is not what I am looking for. -rb 0x100 only shifts the whole address space 256 bytes up. I want the interrupt vector at 0x0004 to go directly to the application and I only want to intercept the reset vector at 0x0000. I do not want to redirect the interrupt vector from my bootloader since this will slowdown my interrupt responce. My second question: How can I call fro
  11. Hi, My software is buildup of a bootloader and an application. I would like to call some functions inside the bootloader from my application. Since the bootloader functions are written in asm and I have placed the addresses to access them at fixed addresses in the first memory page it should be easy to call them. void foo() @ 0x0010 //this function will start at address 0x0010 { } void foo1() @ 0x0011 //this function will start at address 0x0011 { } etc.. in asm I have a goto at these addresses that point to the real code and I exit the code with a return. My proble
  12. Hi, I have found a sourceboost error in version 7.01. with the PIC16F1824 I am using the following inline assember code. movlw _Key ; movwf _fsr0 ; movwf _fsr1 ; addfsr FSR1,4 ; Normally FSR0 should be address of _Key and FSR1 should be address of _Key + 4 but addfsr does not work correct. The above code is compiled to: 01F7 0084 MOVWF gbl_fsr0 01F8 0086 MOVWF gbl_fsr1 01F9 3100 ADDFSR 0, 0x00 <-------------- This is wrong it should be opcode 3144 !! The compiler makes an error with ADDFSR instruction. I also found that the compiler makes an error with
  13. PIC16F1824 I did some more research and its a true error in sourceboost !. The above code is compiled to: 01F7 0084 MOVWF gbl_fsr0 01F8 0086 MOVWF gbl_fsr1 01F9 3100 ADDFSR 0, 0x00 <-------------- This is wrong it should be 3144 !!
  14. Hi, Maybe I have found a compiler error in version 7.01. I am using the following inline assember code. movlw _Key ; movwf _fsr0 ; movwf _fsr1 ; addfsr FSR1,4 ; Normally FSR0 should be address of _Key and FSR1 should be address of _Key + 4 but addfsr does not work correct. Why ?.
  15. Hi, Ian, Its a pitty. But $ is not only a MPASM statement I have used it and seen it on many assemblers starting with the 8748/49 from Intel :-) It would be more usefull if boostC would be able to use obj files generated with other compilers or assemblers since this would make it all possible even without re-inventing the weel. Most obj file formats follow one of two standards, following this would open a complete new world. Improving the *.lst file would also be usefull since this would enable real men to optimize the code they write in C. PaulHolland.
×
×
  • Create New...