|
UART-not consistant
Darrel I will give it a try tomorrow. I have a question about the UART, it uses 1 start, 1 stop and 8 bits. LSB is sent out first from the TX to the RX. Isn't the byte in the receive buffer backwards now? If that is the case, wouldn't the data '100' decimal never show up correctly since the byte is backwards in the RX buffer?
Nick
|
> ... Isn't the byte in the receive buffer backwards now? ..
No. The USART receives data LSB first too.
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2824" />
From the TX, it shifts out from the lowest bit, and the RX side shifts it in starting from the highest bit. So the TX LSB ends up at the RX LSB after 8(10) shifts.
<!---->
DT
|
Darrel,
I tried commenting out the lines you suggested. I am still getting garbage on the LCD. I think what is happening is that when the UART interrupts and the 2 manchester encoded bytes are being decoded another interrupt happens and hoses any sync the UART had. In addition to corrupting the contents to be displayed.
The first time decoding 2 bytes it is fine. This code is the stepping stone to my ultimate application, 6 bytes back to back in continuous mode. Is there a better way of doing this?
Nick
|
OK, I didn't look past the first major problem I saw. Leave those lines commented.Originally Posted by Macgman2000
Now for step 2.
Yes, that's a big problem too.I think what is happening is that when the UART interrupts and the 2 manchester encoded bytes are being decoded another interrupt happens and hoses any sync the UART had...
At 9600 baud, you only get just a little over 1ms between each byte, (unless there are additional delays added from the transmit side).
The clear LCD command will take over 2ms by itself.
You could change that to $FE, $80 for Home Cursor, which will reduce the time to 50µs.
And each of the multiply's in the array operations will take 50µs. 2 per loop, 8 loops, for a total of 800µs.
Using a shift left(<<1) is the same thing as *2, and only takes a couple µs.
example: IF encoded.0[i<<1]=0 Then
With those two things changed, it might be able to do it all in time.
<br>
DT
|
AAAACK!
$FE,$80 still takes 2ms.
Let's see here ...
Trying to find another solution.
Last edited by Darrel Taylor; - 20th August 2008 at 23:35. Reason: Deleted bad idea.
DT
|
Decrease the LCD_CommandUS value until the LCD fails (without the UART code)?
I know the 'stock' LCD_CommandUS value is something like 1500us. All but one of the LCDs I've got here on my bench will run down to a value of 100 without a hitch (that 'one' needs 250).
Might be the extra time you need.
Incidentally, the PBP 2.50 manual shows 44 as the stock value for DATAUS. I don't have much luck going much slower than that. A couple of the LCDs will go down to 25, but most like 50us.
And the code is set up for a 4 bit interface to the LCD. Switching to an 8 bit interface might shave another bit of timing off the LCD access.
Past that, I'm thinking it'll be a pain to rewrite the LCDOUT code to check the Busy Flag rather just relying on a generic pause.
Last edited by skimask; - 20th August 2008 at 23:48.
|
That was my "Bad Idea" that I deleted.
It sounds good, but there are commands in the LCD Initialization sequence. So without the proper COMANNDUS the Init fails. Black box time again.
I'd love to just say remove the LCD part, but that won't help since you can't see the results anymore.
Still pondering.
<br>
DT
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks