Finding serial START bit by bit banging

[Mike - K8LH]

I think you may have introduced a bug in your latest code. If an interrupt happens where I have indicated then, if the buffer is not full but contains data, the xorwf TX_RPTR,W will not restore the value as you intended. This could be recalculated just as efficiently with incf TX_WPTR,F followed by bcf TX_WPTR,4.

Mike.

Ahhhh, good point... If the 'unload buffer' code in the ISR modifies TX_RPTR at this critical point in my Put232 subroutine, I'm all messed up... Thanks for the tip...

I'm not sure your bcf TX_WPTR,4 suggestion will work... (1) My TX_WPTR variable contains values in the range of B0..BF (10110000..10111111)... (2) Even if I was using 00..0F for my RX_RPTR and RX_WPTR values, the 'unload buffer' code in the ISR might catch that momentary TX_WPTR value of 00010000 just before the bcf TX_WPTR,4 instruction in main...

Thanks again for catching my mistake...

Regards, Mike

 

[Pommie]

I'm not sure your bcf TX_WPTR,4 suggestion will work... (1) My TX_WPTR variable contains values in the range of B0..BF (10110000..10111111)... (2) Even if I was using 00..0F for my RX_RPTR and RX_WPTR values, the 'unload buffer' code in the ISR might catch that momentary TX_WPTR value of 00010000 just before the bcf TX_WPTR,4 instruction in main...

1. Missed that. Should have realised that.
2. Surely, your interrupt code only changes TX_RPTR and so this won't cause a problem.

Anyway, just wanted to point out the possible problem as they are the sort of problem that suddenly crops up way down the line as timing changes.

Mike.

 

[Mike - K8LH]

I'm not sure your bcf TX_WPTR,4 suggestion will work... (1) My TX_WPTR variable contains values in the range of B0..BF (10110000..10111111)... (2) Even if I was using 00..0F for my RX_RPTR and RX_WPTR values, the 'unload buffer' code in the ISR might catch that momentary TX_WPTR value of 00010000 just before the bcf TX_WPTR,4 instruction in main...

1. Missed that. Should have realised that.
2. Surely, your interrupt code only changes TX_RPTR and so this won't cause a problem.

Anyway, just wanted to point out the possible problem as they are the sort of problem that suddenly crops up way down the line as timing changes.

Mike.

That's ok... I'm glad you pointed it out... I suspect that's why I did the original code that way and simply forgot so many months later...

You're correct... My 'unload buffer' interrupt code only changes TX_RPTR, but, it also checks for the 'buffer empty' condition by checking TX_RPTR=TX_WPTR and there's that slight chance of catching the transition of RX_WPTR from 10h to 00h using that 'bcf' method...

Take care... Regards, Mike

 

[Pommie]

You're correct... My 'unload buffer' interrupt code only changes TX_RPTR, but, it also checks for the 'buffer empty' condition by checking TX_RPTR=TX_WPTR and there's that slight chance of catching the transition of RX_WPTR from 10h to 00h using that 'bcf' method...

But your buffer won't be empty because it's already been added to and so it won't matter.

Mike.
Edit, It proves the old adage - Don't fix whats not broken.

 

[Mike - K8LH]

You're correct... My 'unload buffer' interrupt code only changes TX_RPTR, but, it also checks for the 'buffer empty' condition by checking TX_RPTR=TX_WPTR and there's that slight chance of catching the transition of RX_WPTR from 10h to 00h using that 'bcf' method...

But your buffer won't be empty because it's already been added to and so it won't matter.

Mike.
Edit, It proves the old adage - Don't fix whats not broken.

Yeah, you're right... Gosh, thanks...

Mike

 

[Mike - K8LH]

Hi Oz',

I apologize for raising this very old thread but I was curious how your program turned out on this project?

Regards, Mike

 

[Mike - K8LH]

Hi Oz',

You around any more?

 

[Oznog]

From 5 years ago?? I don't even remember what the original project WAS.

 

[Mike - K8LH]

From 5 years ago?? I don't even remember what the original project WAS.

Ok, sorry to bother you Sir...