 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Anobium
Joined: 05 Jun 2012
Posts: 4
|
| Using Printf to RS232/LCD display |
 Posted: Sun Jun 10, 2012 5:55 am |
 |
|
I am new to the software, so, for this first posting be patience....
16F88 (the primary PIC) connected to a LCD driver PIC (also 16F88) using RS232, this PIC is then connected to the LCD driver (6 wire connection). The LCD driver is based on the good work in 'flex_lcd.c'. I am running the 16F88 at max freq.
The flex_lcd.c works very well. Thank you.
Background. The primary PIC operates via RS232 to the LCD driver, this enables me to use EEPROM stored messages, and lots of additional functionality with the modified flex_lcd driver.
My issue. When I use 'printf' I get data overruns in the LCD driver pic, the example below does not display correctly on the LCD.
| Code: |
printf("%c,%cReset",254,1);
|
This code does work correct on the LCD. (I have used this method to demonstrate/show the issue... this is NOT my function!)
| Code: |
printf("%c",254);delay_ms(1);
printf("%c",1);delay_ms(3);
printf("R");delay_ms(1);
printf("e");;delay_ms(1);
printf("s");;delay_ms(1);
printf("e");;delay_ms(1);
printf("t");;delay_ms(1);
|
To prevent the overruns I have created a function, where I have a delay of 2ms between each character - this give the LCD driver and the LCD to work correctly.
What are my options? Can I change the intercharacter timing of the printf? Stick with my function?
I want to use printf... it is the easy option.
Any thoughts? |
|
 |
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Sun Jun 10, 2012 9:37 am |
|
|
Hi,
Using printf to send diagnostic messages from your code is a totally standard practice, and I've been doing it for years. I'm 100% sure that the problem is in the code you are using to receive and display the data, so please post that code. Make sure you post a complete, compilable example of what you are currently using.
Also, before we dig into this, are we talking "real" hardware, or a Proteus simulation?
John |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19447
|
|
| Posted: Sun Jun 10, 2012 10:32 am |
|
|
Keyword _modified_.
Flex LCD, depending on whether you use the read/write line or not, _always_ either waits longer than a byte will take to write, or tests for the LCD being busy. It won't return until it has written the character to the display. I'd guess one of the modifications has either removed the read status functionality, or has shortened one of the critical delays.
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Jun 10, 2012 11:53 am |
|
|
I think the problem is that he has two PICs. One is essentially the same
as the Seetron "Backpack" PIC, which turns an ordinary 2x16 LCD into a
serial LCD.
So I believe his problem is that:
1. He probably doesn't have an interrupt-driven receive fifo buffer
in the LCD PIC (similar to Ex_Sisr.c). Therefore he easily overruns
the 2-byte receive buffer in the UART and loses commands.
2. He doesn't have any handshaking between the master PIC and the
LCD PIC. So he overruns the buffer and loses commands when the
LCD can't respond to commands as quickly as he sends them. |
|
|
Anobium
Joined: 05 Jun 2012
Posts: 4
|
|
| Posted: Sun Jun 10, 2012 1:10 pm |
|
|
@ezflyr. It is real hardware not a sim. However, it does works fine within a sim. :-)
@Ttelmah. Great points. I have do have R/W disconnected. The flex_lcd code has an option to not use R/W. I have revert the code shown below and make the appropiate connection. | Code: | | // #define USE_LCD_RW 1 |
@PCM programmer. I am stunned. You are good.
I have not come acros the Seetron "Backpack" PIC but I have now. I have just build the same using a 16F88. My solution, of course, uses the same protocols but it would as the LCD have the same control set. The version I have also supports the FLEX_CD control controls plus direct control of the A1/A2 & A3 ports as I need to control these ports.
Now you mention the Seetron... I guess this has been done before using CCS?
I do not have an interrupt-driven receive fifo buffer. But, I can understand the principles. Via interrupts load a buffer with a buffer pointer and then consume the buffer in slow order which would resolve the loss of data stream issue.
Does this code exist? How should I look for code?
Re handshaking. Again, you correct. None. I am using a single serial connection (plus 0V) between the devices. Any thoughts?
Last thought... I am currently running at 9600, I want to get to the faster speed possible. 2400 is a tad to slow!
I am grateful for the response. I am most grateful as I am changing my project from a Picaxe solution, and, I have hunted around for a long time for a good compiler/IDE and a great user forum - I hope this is the right group. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Jun 10, 2012 7:54 pm |
|
|
| Quote: |
I do not have an interrupt-driven receive fifo buffer.
Does this code exist? How should I look for code?
|
Look in this directory:
| Quote: |
c:\program files\picc\examples\ex_sisr.c
|
For best results, make the buffer size be a power of 2.
Example: 64 |
|
|
Anobium
Joined: 05 Jun 2012
Posts: 4
|
|
| Posted: Tue Jun 12, 2012 3:38 am |
|
|
A few follow-on questions.
A) When using ex_sisr.c I am assuming that the interrupt routine is only executed when the 16f88 hardware UART is in use. Is this correct?
B) When using ex_sisr.c I am assuming that the interrupt routine is NOT executed when the 16f88 FORCE_SW UART option is in use. Is this correct?
C) As the FORCE_SW option uses software to drive the comms protocol why does this the software comms protocol support not interrupts? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19447
|
|
| Posted: Fri Jun 15, 2012 2:59 pm |
|
|
Because the hardware is needed to generate the interrupt.......
As a reply to your other question, trying to use the timer to handle this:
It is never going to work.
At 9600bps, a 'bit', is just 104uSec long. You _must_ sample within a relatively small percentage of the centre of this. So your allowable sampling error, is probably something like +/-20uSec. Your interrupt at 8MHz, is called every 128uSec. Long enough to completely miss a bit, let alone miss the centre. There is just not time to do this like this. To have any hope, your timer interrupt would have to be being called perhaps every 30uSec, and at 8MHz, this is just 60 instructions. Since it takes about 60 instructions to get into and out of an interrupt, nothing else would work at all....
You could potentially get this to perhaps work, by using the hardware EXT_INT pin instead, and triggering the receive code (with 'sample early' selected), in this interrupt. However it is still not a great solution.
Best, by a factor of perhaps 1000000*, is to redesign your hardware so you can use the hardware UART, or add an external UART, perhaps using I2C.
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
