Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. George, An MPLAB project with a small compilable program would be more useful for us to see the problem. Regards Dave
  2. Paul, 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
  3. It would be useful if you can supply a small sample program that demonstrates the problem. Regards Dave
  4. 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
  5. 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
  6. Paul, 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
  7. Mike, Here is a way, but it seems more long winded than it should be: unsigned char level[4]; unsigned char colnb = 0; unsigned char* x = &level; asm { movf _x, W // address lo addwf _colnb,W // add column number, 0..3 movwf _fsr0l // movf _x + 1, W // address hi btfsc _status,C // addlw 1 // movwf _fsr0h // } Regards Dave
  8. LasseT This has been fixed and will be in the next release. Regards Dave
  9. So I upgraded from v6.97 to v7.01 because I wanted large array support. It should save me writing some kludgey code to jump from bank to bank using multiple arrays. But now that I have v7.01 I don't know how to enable large arrays. Default is still 256-byte maximum. I have this ultra-vague memory of reading how somewhere, but can't find the information anywhere. Use compiler and linker command line option -idx 2 to enable 2 byte indexes for arrays. Regards Dave
  10. mmckban, I used the following code and compiled under V6.96 and V6.97: #include <system.h> void main() { unsigned short an_in; unsigned short an_out; adresl = 23; adresh = 27; MAKESHORT(an_in, adresl, adresh); if (0 == gpio.4) { an_out = an_in; } else { an_out = (an_in*3)/2; } if (an_out >= 55) gpio.5 = 1; // LED on at ~ 20 Amps else gpio.5 = 0; // LED off otherwise // Set pwm duty cycle ccp1con.4 = an_out.0; // Set the low bits... ccp1con.5 = an_out.1; // " an_out = an_out >> 2; ccpr1l = an_out; // Set the high bits... while( 1 ); } The generated .asm files were exactly the same. Maybe with the new code you are ending up with a bigger value in an_out which then exceeds what can be put in the pwm control register so you end up with some bits lost. Consider clamping the an_out value so it finally cannot exceed 1023 no matter what the input value is. Regards Dave
  11. Fizzel, The addresses you specify here are for the devices configuration words. You can work out exactly what is being set by looking in the data sheet to see what all the bits are for. For this device it's much more readable to use the configuration pragma ( "#prgama config" ), you can find what all the setting options are in the devices header file (ie in PIC18F4520.h) at the end. Regards Dave
  12. Sound like code for a different compiler. With BoostC use the following two function: void interrupt() { ... } // for PIC18 low priority interrupts void interrupt_low() { ... } Put the code to handle the interrupt within these functions. if you want the function at a fixed address, say 0x200, use: void interrupt() @ 0x200 { ... } Regards Dave
  13. Something is wrong here, things to check: 1) The clock frequency declared in the code is correct. 2) The actual clock frequency is correct (not some PLL multiplier incorrectly configured). 3) The code does not have interrupts that consume lots of CPU cycles. The delay routines use software delays, so any interrupts that occur steal CPU processing cycles from the delay routine causing it to take longer to execute. With some clock frequencies the delays times are not so accurate, generally the lower the frequency the worse the resolution and more significant the overheads. Delay overhead: the delay incurred just by calling and returning from the function - we cannot get eliminate this delay. Unit delay: how long each unit of delay is. ie if we called thiis function with a value of one (and the delay resultion was 1) then we would get this delay. Delay resolution: the resolution of the delay. In this case 16 means a value in the range 1-16 will give 16 units of delay, a value in the range of 17-32 will give 32 units of delay. The truth is that the nature of delay generation with different clock frequencies means there will be limitations to how accurate the delays are, but what you can rely on (and normally this is the most important thing because devices normally have a minimum delay before something is complete or ready, eg an LCD ready for the next character to be sent to it) is that when you call the delay function you get at least the delay you ask for, ie delays are never shorted only lengthened, this is also true if delay routines are interrupted. I hope that helps. Regards Dave
  14. It got accidently deleted, and we never managed to recover it :-( Regards Dave
  15. LasseT, I can reproduce the issue, things are not as they should be :-( Regards Dave
  16. Henry, Three senarios: 1) Array that is <= 256 bytes long, must lie within a single bank, can be array of any size data or structure. 2) Array that is > 256 and <= 512 bytes long, aligned so no element crosses a bank, can be array of any size data or structure. 3) Array that is > 512 bytes long, no element crosses a bank, alignment is dictated by element size, can be array of any size data or structure whose size must be 2^n. Regards Dave
  17. Is that the complete compile window output, as I would expect to see more output?It might be that your antivirus software is preventing boostc_pic16.exe from executing. Regards Dave
  18. Hi All, New PIC18's now supported by the BoostC compiler: PIC18F23K22, PIC18LF23K22, PIC18F24K22, PIC18LF24K22, PIC18F25K22, PIC18LF25K22, PIC18F26J13, PIC18LF26J13, PIC18F26K22, PIC18LF26K22, PIC18F26J53, PIC18LF26J53, PIC18F27J13, PIC18LF27J13, PIC18F27J53, PIC18LF27J53, PIC18F43K22, PIC18LF43K22, PIC18F44K22, PIC18LF44K22, PIC18F45K22, PIC18LF45K22, PIC18F46J13, PIC18LF46J13, PIC18F46K22, PIC18LF46K22, PIC18F46J53, PIC18LF46J53, PIC18F47J13, PIC18LF47J13, PIC18F47J53, PIC18LF47J53, PIC18F65K22, PIC18F65K90, PIC18F66K22, PIC18F66K90, PIC18F67K22, PIC18F67K90, PIC18F85K22, PIC18F85K90, PIC18F86K22, PIC18F86J72, PIC18F86K90, PIC18F87K22, PIC18F87J72, PIC18F87K90. As always the complete list can be found here http://forum.sourceboost.com/index.php?s=&...post&p=4643 Until these new devices are added to the release you will need updated header files which can be found here: http://www.sourceboost.com/CommonDownload/..._12-12-2010.zip Also ICD2 header file has been updated and ICD3 header file has been added. Regards Dave
  19. Peter s, What makes them appear in the IDE is the map.txt file found in the folder with the configuration files. Regards Dave
  20. Paul, The way to make this work is as Pavel pointed out: //Make a 16 bit long value from adresh:adresl registers #define ReadADC( dst ) asm bsf _adcon0,1 \ asm movlw 0x01 \ asm loopi: \ asm addlw 0x01 \ asm btfss _status,0 \ asm bra _loopi \ asm bcf _adcon0,1 \ asm comf _adresl, W \ asm movwf _##dst \ asm comf _adresh, W \ asm andlw 0x03 \ asm movwf _##dst##+1 Regards Dave
  21. Looks like the problem is cause by the continuation character which combines all the ASM lines into one. For the compiler the label needs to be at the start of a line, so the macro fails. The work around is to split the macro into two: #define ReadADC1( dst ) asm bsf _adcon0,1 \ asm movlw 0x01 \ #define ReadADC2( dst ) loopi: \ asm addlw 0x01 \ asm btfss _status,0 \ asm bra loopi \ asm bcf _adcon0,1 \ asm comf _adresl, W \ asm movwf _##dst \ asm comf _adresh, W \ asm andlw 0x03 \ asm movwf _##dst##+1\ Regards Dave
  22. trossin, You are right it would be nice to get it working, in fact my apologies that we haven't already. Microchip changed the format of their cof files, the change is not a trivial one.Eventually this will work, but not many people complain so this is lower on our list of priorities. Regards Dave
  23. Moonwalker, Some answer about this please? Sorry. The simulator does support simulation of GPIO I/O ports Regards Dave
  24. Paul, Boostc uses its own unique .obj file format. What we need in this case is an assembler that generates output (.obj file) in the same format.As you say, a nice feature for future. Regards Dave
×
×
  • Create New...