Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About fred

  • Rank

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Location
  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( void ) { //Handle timer1 interrupt if( pir1 & (1<<TMR1IF) ) { //////////////////////// // measurepoint 2 // //////////////////////// TMR1handler(); clear_bit( pir1, TMR1IF ); } //Handle timer0 interrupt if( intcon & (1<<T0IF) ) { // timer0 code clear_bit( intcon, T0IF ); } if( intcon & (1<<INTF) ) { // RB0 falling edge interrupt if (( bitno == 0 ) && ( stream.num == 0 )) { clear_bit( t1con, TMR1ON ); TMR1start( 0xFFFF + 0x50 - 889 ); //////////////////////// // measurepoint 1 // //////////////////////// lValue= 1; bitValPeriod= 0; buffer.num= 0; } clear_bit( intcon, INTF ); } return; } btw. something likes to happen also on the RB0 interrupt. Stimulus is generating a 1->0 pulse at 90000 ticks. the tickcounter says 90200 at the start of the the generated RB0 interruptroutine for this
  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 execution line in sourceboost IDE "C:\Program Files\SourceBoost\boostlink.pic.exe" /ld "C:\Program Files\SourceBoost\lib" libc.pic16.lib DAC.obj DAC_DEVICE.obj DAC_LPH7779.obj FR_EEPROM.obj FR_LIB.obj LCD_LPH7779.obj clock.obj sTimer.obj /t PIC16F648A /d "G:\development\DAC Control" /p DAC -swcs 6 2 BoostLink Optimizing Linker Version 6.84 linker execution line mplab IDE Executing: "C:\Program Files\SourceBoost\boostlink.pic.exe" "G:\development\DAC Control\DAC_LPH7779.obj" "G:\development\DAC Control\FR_EEPROM.obj" "G:\development\DAC Control\FR_LIB.obj" "G:\development\DAC Control\LCD_LPH7779.obj" "G:\development\DAC Control\sTimer.obj" "G:\development\DAC Control\clock.obj" "G:\development\DAC Control\DAC.obj" "G:\development\DAC Control\DAC_DEVICE.obj" "C:\Program Files\SourceBoost\Lib\libc.pic16.lib" -O1 -p "DAC" -t 16F648A -swcs 6 2 BoostLink Optimizing Linker Version 6.84 the -O1 option was already there, I added the -swcs 6 2
  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 has started apparently until the first overflow occurs and set IRreset. Hopefully this pulse train is immeditaley followed by a clean one.. I will check this first and see what the new results will be. fred [update edit] I introduced a variable streamValid. This one is set to false if the interval between the first two falling edges is outside the tollerance of 1778us. (GetIRSampleType( tmr1int ) != 1 ) From that point the values are not captured anymore and after the overflows occurs (end of pulse train) the sequence is to be considered as invalid at the start of the decode procedure. the ISR code and first lines of RC5decode() now looks like this void IR_ISR_handler( void ) { uint tmr1int; if ( (IRstreambit == 0xff) || (resetIR==1)) return; if ( IRstreambit > IRMAXPULSES ) { resetIR= 1; return; } tmr1int= StopTmr1()- TMR1BASE; if ( tmr1overflow == 1 ) { StartTmr1( 0xD8FF ); return; } clear_bit( intcon, INTE ); if ( tmr1overflow > 1 ) { if ( IRstreambit >= IRMINPULSES ) { IRstreambit= 0xff; } else { resetIR= 1; } return; } if ( IRstreambit > 0) { if (( IRstreambit == 1 ) && ( GetIRSampleType( tmr1int ) != 1 )) streamValid= 0; if ( streamValid ) { IRstream[IRstreambit- 1]= tmr1int; } } IRstreambit++; StartTmr1( TMR1BASE ); return; } // TMR1BASE is more or less the calculated value of 0xFFFF - (2*1778) - ( 1778 / 4 ) void RC5decode() { if ( IRstreambit != 0xff ) return; if (( resetIR ) || ( !streamValid )) { resetIR= 1; return; } //time to decode the captured stream of falling edges at this point! The first byte of the IR train pulses now look valid. In case when the toggle bit is '0' the long and medium sized interval are still reversed which is an invalid situation so decoding this one will always fail. I'm also still missing the last pulse. the result of this is that for most values the captured stream is valid as ok but decoding will give wrong results. for instance: A '0' press will return a command '1', a '1' press =>command 3, press'4' => command 0xd, press'6' => command also 0x0d. [/update]
  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 (possibly again) and finally enabling INTE. that's why I was stopping INTE at the start of IR_ISR to prevent new interrupts coming in between leaving the interrupt handling and resetting the array before the content could be decoded when relevant. You are right : At a first glance it doesn't look so bad. That's the bizar thing... If you look at the picture you will see that there should be 9 times 1712us after the longer pulse however. there are only 8 so one is missing ervery time..! Another strange one which theroretical is impossible but a bit harder to explain: the value of 3515 can never be follwed by 2667 at this time. the value of 3515 (=2 periods with only a falling edge at the end) can never start at the beginning of a period!! in a period you always have to deal with a 0->1 or 1->0. if this value starts at the start of a period it would be 0->0 which is impossible in a biphase coding..! As you can see in the picture there should always be a 2667 (1.5 period) and a 3515 combination with toggle '1' and machine code x10 after the two initial startbits ps. I'm very happy that someboby is looking with me at this problem because the whole ting is driving me crazy.. It's probably a simple and stupid thing but I just don;t see it. Thanks!! Fred
  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 periods) My IRsender sends IR using machine code 16. Here I illustrate what pulses theoratical are on rb0 when pressing the button '0' two times. (the toggle bit - bit3 - flips when the same key is pressed once more) Now what''s happening in real live... I press 3 times. After each time the captured array (containing the timer1 values) is displayed. (this results include the adjustments Orion suggested) The results are shown in this picture after subtracting the offset (TMR1BASE in de code which has the value of 4000) the values represents the usecs: (1712 is the average value to let it look like a bit less messy. the least min value is 0x1643 and the max is 0x165E. so the variation is max 27 which is pretty accurate I think) This looks bizar to me and I must make somewhere a verry fundamental mistake... - The very first element seems to be pretty unreliable.. - each next indiviual element just look to be valid which can't be occasional or a noise issue.. - after the '2' type the stream looks very good but except I'm missing one more pulse everytime.. - when the toggle bit is '1' the '3' and '2' interval types are reversed When I repeat the same captures more times the results stay the same! Except the very first element varies. I also tried another remote control and the results are similar. I get a bit frustrated by now because I think (uptil now ) the alorithm I made is pretty nice but apparently I can't get it implemented.
  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 == 0xff) || (resetIR==1)) return; if ( IRstreambit > IRMAXPULSES ) { resetIR= 1; return; } clear_bit( intcon, INTE ); tmr1int= StopTmr1(); if ( tmr1overflow > 0 ) { if ( tmr1overflow == 1 ) { StartTmr1( 0xD8FF ); } else { if ( IRstreambit >= IRMINPULSES ) { IRstreambit= 0xff; } else { resetIR= 1; } } return; } if ( IRstreambit > 0 ) { IRstream[IRstreambit- 1]= tmr1int; } IRstreambit++; StartTmr1( TMR1BASE ); set_bit( intcon, INTE ); clear_bit( intcon, INTF ); return; } IR_ISR_handler() is called within each interrupt. During the time that one of the interrupts is handled I want to have a status quo situation. I'm pretty struckling with this 'project' for some time now because I'm getting some strange timing results and really can't find what's happening until now. When I use stimilus (MPLAB) to simulate a RC5 pulse train on rb0 and which is generating these interrupts, everything looks pretty well but in 'real live' it isn't and I don't think it's a circuit problem either. So when I read something like then I'm more than curious if that's relevant here aswell
  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...