Go Down

Topic: Yet another Software Serial (Read 54557 times) previous topic - next topic

abeltomillo

Seems like I got it!

I just downgrade the baudrate to 9600 and using uart-lib at 19200. Using 250 ticks at first INT1, and 208 at the consecutive ones. Using 209 ticks to TX. Prescaler is /8. Timer0 and 2.

Any suggestions? ;)

Robin2


I just downgrade the baudrate to 9600 and using uart-lib at 19200. Using 250 ticks at first INT1, and 208 at the consecutive ones. Using 209 ticks to TX. Prescaler is /8. Timer0 and 2.


I have no idea what all this means.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

abeltomillo

hahaha.

ticks are the values for OCR0A and OCR2A.
They are cfged for 104ms. except for the first time delay after INT1, which is 250 ticks.

that's all.

Robin2

Two or three hours spent thinking and reading documentation solves most programming problems.

abeltomillo


jhs73

I feel stupid, because I cannot see where to download the sss.ino Any hints where to download it? Thanks
Jan

PaulS

I feel stupid, because I cannot see where to download the sss.ino Any hints where to download it? Thanks
Jan
The new forum stripped attachments from posts in the old forum. Your best bet is to PM Robin2, and ask for the file.

Robin2

I feel stupid, because I cannot see where to download the sss.ino Any hints where to download it? Thanks
Jan
Sorry about this. You don't feel nearly as stupid as I feel angry.

I believe the attachments will be restored tonight. If not I will fix the problem tomorrow.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

jhs73

I feel stupid, because I cannot see where to download the sss.ino Any hints where to download it? Thanks
Jan
Sorry about this. You don't feel nearly as stupid as I feel angry.

I believe the attachments will be restored tonight. If not I will fix the problem tomorrow.

...R
Thanks, I will try tomorrow
Jan

jboyton

I believe the attachments will be restored tonight. If not I will fix the problem tomorrow.
Is the code simple enough to post here?

I'm in the middle of writing my own software serial. I don't want to reinvent the wheel but the existing wheels don't turn very well, at least not for my purposes. I would love to see what your approach was; maybe I can use it.

Robin2

#40
Oct 22, 2014, 10:09 am Last Edit: Oct 22, 2014, 07:13 pm by Robin2
I will try to attach the files here. I am still hoping the Forum techies will reinstate the links in the original Post. There must be hundreds or thousands of Posts that have been rendered useless by this stupid error.

I'm not even 100% certain that the 2 files in the ZIP are identical to those that were in the original Post.

Let me know if they don't work.

...R

Edit to add - now that the links to attachments have been restored it seems there are three files in the original post but I only put 2 of them in the .zip file. Please disregard the .zip file and use the attachments in the original post.
...R
Two or three hours spent thinking and reading documentation solves most programming problems.

jboyton

#41
Oct 22, 2014, 09:13 pm Last Edit: Oct 22, 2014, 09:16 pm by jboyton
Thanks for posting the code.

I can't use pin3/INT1 so I'll have to make a few modifications before trying it. I'm still going to try my alternate strategy that doesn't use timer1 or timer2, but I will borrow from your code even if my approach is successful.

Robin2

I can't use pin3/INT1 so I'll have to make a few modifications before trying it.
It was deliberately written to be simple so it MUST use either INT1 or INT0. I just chose INT1 (pin3) because it was beside pin 4.

Feel free to use it as the basis for anything you choose.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

jboyton

It was deliberately written to be simple so it MUST use either INT1 or INT0.
I'm not sure why you say that. I got it to receive data using pin 8 without too much drama.

Thanks for the code!

jboyton

#44
Oct 24, 2014, 07:41 pm Last Edit: Oct 24, 2014, 08:39 pm by jboyton
Robin, did the transmit side work flawlessly for you?

I thought that getting transmit to work would be easy since all I had to do was change the pin number (and the hard coded port and bit masks). But the device I was communicating with (a GPS) didn't accept the commands I sent it. I looked into the code and initially found a number of issues, only one of which was fatal.

One was that within an ISR you were disabling interrupts (which does nothing) and then enabling them (which is potentially an issue).

Another is that your timing scheme (adding to the count with each interrupt) ignores the latency for entering the ISR. I found that instead of 104us the bit width averaged 108us and occasionally was 112-114us. Once I got everything working I found that this was right on the "okay" side of the edge of what the GPS's UART would accept. I adjusted the increment value down a little to reduce the odds of failure from this.

But what was actually keeping the transmit from functioning correctly was a failure to set the TX line high earlier. When it came time to transmit, the code set it high for one bit period which was insufficient. This caused the first character to be effectively lost, rendering the command unrecognizable by the GPS.

So the transmit seems to work now... I think. I'm not sure I trust it yet.

That said it's a huge improvement over the system Software_Serial, at least in this limited application. While receiving data at 9600 baud, Software_Serial hogs about 97% of the uP bandwidth. Your sss Serial code uses less than 10%.

Go Up