Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About PaulHolland

  • Rank
  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 !. Hopefully you will change this. I think you are forced to even change this: What if microchip will add a 32bit HW timer tmr16 for example. How are you going to clear this register ? tmr16l =0; tmr16m1 = 0; tmr16m2 = 0; tmr16h= 0; ? Its the same problem as accessing a multibyte var in memory, you introduced or will introduce LOW and HIGH to access these bytes. With a 16 variable declared in memory you also clear or set the whole variable and I do not have to do it byte by byte. I understand that you have done it this way since the beginning but you can solve it now by changing it on all new devices.
  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 that destroys some of the status flags. Another idea is to just use a regular function at a fixed address: void foo() @ 0x123 { asm retfie 1 } What you loose is the code that jumps to the routine - just as you want it. But also you loose the linker checking that flags a warning if a function is called from more than one asynchronus thread which could result in corruption. I guess your ideal is to loose the code that vectors to the routine? Regards Dave Hi Dave, I know the differences between PIC16 and PIC16F1XXX devices. Yes, I wanted to save the space and loose the code that vectors the routine. The trick you suggested is also OK. That way you only loose one byte the return at the end. I still think the warning should be an error since the code is non-working. I did not check if you get a warning though. thanks !. Paul.
  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-of C language is adjusted and modified during the years when they did hit a rock solid wall and had to change their modification. The downside of this is that old code will not compile with a new compiler version unless you change code. 4: I noticed many bugs in the compiler unless you used some strange command or trick to undo them. 5: reasonable code generation but waisting RAM resources. 6: Not superfast code, and even contains dead code. 7: They try to do clever but its actually a way of hiding they do not know how to make a real compiler. One example is that re-entrance code is if written is not allowed and suppressed by the compiler without it telling you anything or even giving you the option to allow it. Example: If you have a function your calling in your main and the same function you call in an interrupt routine the compiler will automatically disable all interrupts during the function call in your main routine !!.. This is very stupid since your code can be written in a way that will not be harmful at all (using local declared variables instead of global). You only get a warning which you will ignore as always and your not able to disable this behavior of the compiler. You have: Local variables, Global variables but also static variables, CCS is seeing no difference between : static, local and global variables. Initializing local and static variables sometimes simply does not work even though the C code is perfect. Sourceboost: 1: Although not ANSI C its close enough to make a port an easy job. 2: Stable code and very few bug's. 3: Very compact code and use of RAM resources 4: Smart compiler and dead code removal although I suggested some improvements :-) 5: Very good priced for the quality. 6: PIC12F code generation is impressive since this is almost impossible with CCS in an efficient way. I am not connected to sourceboost is any way other that having one license for sourcboost C compiler !. When I used CCS i had more the feeling I was installing and keeping my compiler up to date and checking the forum for bug reports than building software. I also used some bad language a lot of times when I used CCS since it was not possible to write code or doing things I did not ask :-). CCS is nice for building somthing for a demo and you do not have a lot of time to write software since they offer lots and lost of functions and examples online. regards, Paul.
  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 <------------ useless instruction (see the rest of my message) 0x106 goto 0x106 <---------------- NON WORKING CODE SINCE RETFIE is lost by the linker. The RETFIE is GONE !. This due to the fact that I specified that the interrupt routine should be started at 0x106 with the following statement: LINKER: -rb 0x100 void Interrupt(void) @0x106 { //(empty) } It should simply read: 0x106 retfie Since I specified that I wanted to move the interrupt address to 0x106 !. If you put the Interrupt routine @0x104 or @0x105 you will get even more fun. If you specify 0x107 you will get the following code, which does have 3 instructions that are completely useless since at address 0x004 I have to place code to correct pclatch and a goto to 0x104. This code is now useless due to the fact that I: 1: Moved the code with the -rb 0xXXX linked command 2: used @0xXXX to lock the interrupt routine to a special address to minimize the goto's and make my interrupt as fast as possible. 0x104 bcf pclatch,3 <------------ useless instruction 0x105 bcf pclatch,4 <------------ useless instruction 0x106 goto 0x107 <------------ useless instruction 0x107 retfie Hope you can correct this in the compiler since it will improve speed a lot, (3 cycles look a few but if your getting 20.000 interrupts/sec its 60.000 lost cycles/sec) specially with the new PIC16F1XXX core since it automatically saves the context already. What should happen is that you remove the pclatch and goto in the situation I told you since the bootloader should make sure pclatch is correct before he jumps to the address of the Interrupt routine. I can solve the problem by specifying the interrupt routine at @0x106 and make a jump with a goto inside my bootloader to address 0x107 but this is not very neat since they do not match and in the future this might be a wonderfull place for a bug to happen. regards, Paul.
  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 code with an @ 0x106 you will create a looped interrupt routine you will never escape from. This is due to the fact that the bcf pclatch,3 and bcf pclatch,4 instructions are not considered part of the interrupt routine. If you would make them part of the interrupt routine it would solve this problem. I wanted to use this so that I will have only ONE goto from 0x004 to my 0x106 address instead of one goto from 0x004 to 0x104 and than from 0x106 to my interrupt routine somewhere in memory. I hope you get it. regards, Paul.
  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 from inline asm the _startup vector ?. I tried to use this: asm goto _startup but it will give an error. My last question: How can I reserve a part of the memory map so that the linked will not place code in this memory region ?. I want to block 0x0005 upto 0x03FF
  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 problem is that the code is OK but I do not want the foo and foo1 functions to be compiled and included in the code. How can I do this. Do I have to declare them external in some way ??..
  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 the moviw FSR0++ instruction since: moviw FSR0++ ; moviw FSR1++ ; are resulting in both a change of FSR0 register and not one increment on FSR0 and one increment on FSR1 as expected. The following instructions don't compile or with an error. MOVWF FSR1H MOVIW 0[FSR1]
  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...