based at 4 Mhz, for 1.024ms ==>> prescaler= 1:4 NOT 1:8

movlw b'10000010' ; 10000001
; 1------- /RABPU, pull-ups off
; -0------ INTEDG, INT edge n/a
; --0----- T0CS, TMR0 int source
; ---0---- T0SE, source edge n/a
; -----001 PS<2:0>, pre 1:4
movwf OPTION_REG ; for 1024 us TMR0 overflows

 

It's getting a bit late but I've had a quick look and can have another go tomorrow.
I've marked all my comments with xx so they are easy to search for, so if you can fix them, I'll continue tomorrow.
<ed> The bit where I say "gets stuck here", it's probably supposed to until the interrupt detects a button press. Ignore that.</ed>

 

Alright then...tomorrow!!

Thanks a million!!

 

I thought I fixed the Tenk--TenK...coz i built it successfully first before posting....and I disabled the sensitive case...but i'll have another proper look

thanks!

 

I've simulated it a bit more, and added more things to fix.
Off to enjoy the sunshine for a while, so if you can make the changes and repost.
The multiply and BCD look to be working well and distance is generally working.

 

Hi!

Below is the edited distance routine with bank correction...

BUT you mentioned that the 'burst' routine generates 735us instead of 125us (5.872 times more...), that means the 'burst' routine need fixing, right???

As for the getkey routine, i think it is normal for it to get stuck, as the push button needs to be pressed first in order to proceed, am I correct??

Please let me know while I read your new post

 

ok! guess you want me to repost the entire codei will do that!

thanks!

 

----------------------------------------------------------------------
btfsc INTCON, T0IE ; timer0 interrupt?
goto tmr0_int ; service it
;xx never going to get here
btfsc flag16ms ; flag16ms is set
goto button_int ; service it
---------------------------------------------------------------------

needs to be changed like this:

btfsc flag16ms ; flag16ms is set
goto button_int ; service it
btfsc INTCON, T0IE ; timer0 interrupt?
goto tmr0_int ; service it


Am I correct???

 

..........
..........
movlw d'16' ;
movwf tmr0_cnt ; 16-msec "debounce" timer
movlw 1<<GIE|1<<T0IE ;
movwf INTCON ; enable global & TMR0 interrupts
;xx clear timer1H and L , undefined at startup

goto main


do you mean I have to clear TMR1H and TMR1L in the ; register variables initialization?? do you also mean I have to define them like all the other registers?? I didn't think so these are internal microcontroller (timer1) registers...

Anyways lemme know

Thanks!

 

#106
It's the 250us delay that takes too long.
I realise now that is is supposed to stop there.
#107
Yes please.
#108
That will partly work but there may be some flickering because every 16 times it won't do the display update.
If at the end of buttonint there is a goto to the INTCON test, that would be better.
#109
Yes, just clear them. I should have said they were unknown instead of undefined.

 

thanks for these comments!!

#106
It's the 250us delay that takes too long.
I realise now that is is supposed to stop there.

But now how to fix this problem??? I think the generation of the pulse MUST be stopped but how to do that??

thanks!!

 

#106
If at the end of buttonint there is a goto to the INTCON test, that would be better.

Do you mean in the 'button_int' instead of having a 'goto isr_end' i should have a 'goto intcon_test' which is a label to be put right before:

btfsc flag16ms ; flag16ms is set
goto button_int ; service it
btfsc INTCON, T0IE ; timer0 interrupt?
goto tmr0_int ; service it


let me know if i got it!

Thanks!

 

thanks for these comments!!

#106
It's the 250us delay that takes too long.
I realise now that is is supposed to stop there.

But now how to fix this problem??? I think the generation of the pulse MUST be stopped but how to do that??

thanks!!

Those 2 comments are unrelated to each other. The only problem is that the 250us delay takes too long.

 

Those 2 comments are unrelated to each other. The only problem is that the 250us delay takes too long.

i got you! I need a small value...lemme do a quick math...i'll suggest my value

thanks!

 

I guess a delay of 43 microseconds instead of 250 will generate the 5 cycles at 40 kHz but whitout waiting for the oscillation to die down...so maybe i'll have to choose a slightly higher value...am I making sense??

kindly regards,

 

I'm not quite understanding.
The 5 cycles at 40kHz works perfectly.
The 250us delay currently takes 735us because it goes round the loop too many times.
Reducing it to 43us would risk detecting the direct pulse if it hasn't died down.
I'd suggest getting things working with a 250us delay, then when everything is finished, trying to reduce it until the lowest reliable delay is found.

 

no! i think i made a mistake

given that we getting 734us instead of 250us

==>>734us - 125us = 609us
this implies that the current delay actually gives 609us
so in order to have a delay of 250us we need to create a delay of 91us

so instead of loading 243 we need to load 91! am I right?

regards

 

and what do you think of post #112?

 

Do you mean in the 'button_int' instead of having a 'goto isr_end' i should have a 'goto intcon_test' which is a label to be put right before:

btfsc flag16ms ; flag16ms is set
goto button_int ; service it
intcon_test
btfsc INTCON, T0IE ; timer0 interrupt?
goto tmr0_int ; service it


let me know if i got it!

Thanks!

I've put the label where it should be, otherwise yes.

 

No! 98 needs to be loaded

243 (actual value) gives 609us
==>>250us = (234*250)/609 = 99.75....=100