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

No, the send pulse correctly takes about 125us, that is not included in the 734us.
In your 250us delay each time round the loop takes 3 cycles so if you wanted 250us the variable should be about 80.

 

Attached is the entired code with all the correction I guess!

if i still have to fix Tenk...i will as im usinf a different computer...anyway

regards,

 

Attached is the entired code with all the correction I guess!

if i still have to fix Tenk...i will as im usinf a different computer...anyway

regards,

Sorry, I can't easily work with that. I made changes to the code in a few places like moving the segdata table and fixing the listen routine and I don't want to have to make them again, I might miss something.
If you started with the last code I sent you and made the changes to that then anything I did would still be there.

 

Have you checked my attachement? i made all the correction...from porta,b to every thing...but i will check again

 

I just forgot to move the segdata...actually just seen it...

 

I made changes to the listen routine and maybe fixed a couple of other things which I might not have put notes on.
Can you have a look at your new code and the last one I posted side by side and make any changes that I did.
There doesn't seem any point in me finding and fixing the same things again.

 

ok ! im having another look...i just built the code successfully...so I assume that the 'Tenk' and porta portb are fixed...im having a second look

 

OK!

i made all the final correction!

please find attached regards,

 

Thanks, that's much easier.
I'm having a look now.

 

Ohk Sir! I can't wait...#smiling#

 

Here's what I've got at the moment.
With the few changes marked by xx I think it might work.
Also interrupts should be disabled for at least sending the pulse (then reenabled). Otherwise the pulse is messed up and it will affect the measurement.
If you don't mind the display flickering they could be disabled until the end of the distance measurement which would make some difference to the accuracy.

 

;xx pulse should be the same pin as echo

why is that?? coz that means the pin through which the pulses are sent are the same pin through which the echo is captured...why that???

 

;xx outofrange needs clearing at some point. maybe after the next button press is detected

YES! and I found it..it MUST be cleared in the 'bin16_BCD' routine and more precisely right after the 'endbin16_BCD5' label and it is not!!!

lemme know what you think!!

regards,

 

;xx pulse should be the same pin as echo

why is that?? coz that means the pin through which the pulses are sent are the same pin through which the echo is captured...why that???

Oops, sorry, I got confused. They should be different pins the same as the code.
Ignore that one.

 

;xx outofrange needs clearing at some point. maybe after the next button press is detected

YES! and I found it..it MUST be cleared in the 'bin16_BCD' routine and more precisely right after the 'endbin16_BCD5' label and it is not!!!

Yes, that's a good place.

 

button_int
;xx changed
bcf flag16ms ; clear flag for next putton processing
comf PORTB,W ; sample active hi switches
andlw b'1000000
.................
...............

i don't understand what you mean here!

So with that flag cleared now...can it work?

 

In your original code it was bsf

 

In your original code it was bsf

yes Sir you are right and i just fixed it!

 

LOL, I forgot to check which pins are set as input and output. Sometimes it's the simplest thing that gets you.
In your init you need to set trisA, B and C to the correct values for the pins you are using. Unused pins should be set to output.
Don't forget to change banks and back.

 

I'm suspecting the getkey routine and button_int isr...
Coz this is da one responsible for the start of the main program...

Also when breadboard is powered with 5V, the unpressed button is read ~5V (a bit less) that means we should wait for a ~0V (button pressed) so main program can start, right? So is that what the current code tells us? I'll have to investigate that!!

What do u think?

Regards,