Jump to content

fred

EstablishedMember
  • Content Count

    99
  • Joined

  • Last visited

Community Reputation

0 Neutral

About fred

  • Rank
    Regular

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Location
    Netherlands
  1. thanks twomers! I never realized to set PEIE for TMR1 and it was entering the interrupt routine cause of TMR0 overflow and not of TMR1... That's also explains why the delay between tmr1 overflow and starting the tmr1 routine never exceeded my setting for TMR0..
  2. I'm having some strange results using timer1. In MPLAB I just discovered when TMR1IF is set and TMR1 already passed 0 it just continues stepping a 'while' in main() before jumping to interrupt().... Is this normal behaviour or am I doing something wrong probably? I'm running a 16F648A at 4MHz some examples: TMR1 at measurepoint-1 0xFCD6 it has the value of 0x88 at measurepoint-2 TMR1 at measurepoint-1 0xFF00 it has the value of 0xBA at measurepoint-2 TMR1 at measurepoint-1 0xFA00 it has the value of 0xA6 at measurepoint-2 void interrupt( v
  3. When I link my project in sourceboost it links succesfull with still remaining 3 free bytes for code (.. ) When I link the same thing within the MPLAB it fails "Too much code to fit in ROM, overfilled by:27 locations." I copied the linker options from the sourceboost IDE in MPLAB IDE. When I look at the linker execution lines sourceboost added extra options however which probably causes extra optimization when linking. any ideas?? (to be sure it's the linker I first did a complete build of the project in MPLAB IDE and the relinked from within sourceboost IDE) linker exec
  4. Orin the only references I have to opion_reg are in the init part at the start of main() set_bit( option_reg, PSA ); clear_bit( option_reg, T0CS ); clear_bit( option_reg, 7 ); // disable pullups clear_bit( option_reg, INTEDG); // falling edge I realize that the beginning might be destroyed by noise. What happens when I have a 'low' situation due to noise at the time a RC5 pulse train starts.. Pretty unpredicatble I think! What I'll do is validating the very first pulse duration which always should be a 1778us one. If that happens I'll ignore the rest of the train that h
  5. the timer is only enabled in StartTmr1() which is only called from within IR_ISR_handler() so it isn't running at the start. And if it would then the whole stream starts with timeroverflow set which will end the capturing immediately. in the main loop - IRstreambit is checked. when it has the value of 0xff (set in IR_ISR_handler()) the capturing has finished succesfully (hm. ) and the array content will be decoded outside the interrupts. At the end of the decoding resetIR is set - resetIR is checked. when it's set all used variables and the array will be reset, timer1 stopped (po
  6. I will make that change. Unfortunately I don't beleave this is what is going on in my situation and solving my problem however. I'll try to illustrate what's happening (oops this is getting a bit off topic now. Hopefully this is not a big problem and the moderator will let it go or move it to a new topic because I get bogged on this..!) With this code I'm capturing (at least I'm trying to.. ) the time intervals of falling edges when receiving an IR RC% pulse train. When the stream is valid I can only distinguish 3 type of intervals: 1778us (1 period), 2667us (1.5period) or 3556us (2
  7. I think you're right about INTE. This is because I added if ( tmr1overflow ) resetIR= 1; else IR_ISR_handler(); recently during it's interrupt. Before that it could be relevant. I'll put it on comment. StartTmr1 en StopTmr1 looks like this void StartTmr1( unsigned int numval ) { _cnvint_ value; value.num= numval; tmr1h= value.hl.hi; tmr1l= value.hl.lo; set_bit( t1con, TMR1ON ); return; } inline uint StopTmr1(void) { _cnvint_ value; uint numval; clear_bit( t1con, TMR1ON ); value.hl.hi = tmr1h; value.hl.lo = tmr1l; numval= value.num; return(numval); } fred
  8. Hi Orin it's a 16F648A receiving an infrared RC5 signal on rb0 What basically happens is this: void interrupt( void ) { //Handle timer1 interrupt if( pir1 & (1<<TMR1IF) ) { if (( IRstreambit > 0 ) && ( IRstreambit != 0xff )) { tmr1overflow+= 1; IR_ISR_handler(); } clear_bit( pir1, TMR1IF ); } //falling edge portB.0 if( intcon & (1<<INTF) ) { if ( tmr1overflow ) resetIR= 1; else IR_ISR_handler(); clear_bit( intcon, INTF ); } return; } void IR_ISR_handler( void ) { uint tmr1int; if ( (IRstreambit == 0x
  9. The routine can be called from within two interrupts: 1/ timer1 2/ rb0 falling edge during handling from a timer1 interrupt a rb0 interrupt might occur or a timer1 interrupt in the situation it's handling the falling edge interrupt. To prevent this I'm just disabling both interrupts at the start of the routine and reactivate them at the end
  10. I'm using the MPLAB environment in combination with sourceboost IDE just for one functionality: 'Stimilus' next to their debugger It's a perfect way to simulate a pulse train on a pin to find some hard to track problems. Their solution to specify such a 'train' is horrible however and it should not be so hard to do a better job doing this (I think... ) Would be great to have something similar in Sourceboost IDE!
  11. Oops, there is a problem starting interrupts gain within an interrupthandler? I'm using a common interrupt handler for TMR1 and RB0. At the beginning of the handler I stop both interrupts and at the end I start them both again. This can give problems? Is there an easy way to get around that? I can't use flags to start them again later somewhere in main() because there 's a chance to miss an interrupt or run into timing problems then. [edit]hmm sorry Chris, I hope I'm not stealing your topic now..![/edit]
  12. it's working. Less work than expected... thnx mark
  13. I want to use the mplab debugger for a project. Is there a way to convert\integrate existing project file(s) to mplab or do I really have to build separate mplab projects from scratch?
  14. hm, put it in eeprom using #pragma and then move it to ram initially at runtime takes probably less space. ugly solution however.
  15. huh.... that's new to me and I'm\ confused now. isn't this something which is done by the compiler when the aray space is preserved in the data area? I thought that this is the major difference between defining char *array and char array[15] where the first is only the pointer and the 2nd pointing to the allocated data space! So defining a big character table doesn't only cost a lot of data space but even more code to have it initialized even when it's all static data?
×
×
  • Create New...