Hserout can add a lot of delay in your program depending of the Baud rate and number of characters sent.Hi Albert,
Yes this is PIC (Oshonsoft) basic.
I was checking a problem using 4x HSEROUT, which helped me find what it was. I guessed that the HSEROUT was affecting the working. I have taken them out now, and it is working ok,and you have verified my thoughts. As this is a fine problem, I like a second opinion, thanks.
C.
It is true if only one character is sent, but what can the program do if several characters are sent? Wait between characters?Ah, but HSEROUT uses the hardware UART so the program is not delayed while the serial is sent. What you say would be true if SEROUT was used as that's a software modem.
Hserinit 9600
Hserout "Hello!"
End
-----------------
The assembler output ( for clarity I removed the RX routines and added comments <-----):
; user code start
l0001:
; 1: Hseropen 9600
; exact baud rate achieved = 9615.385; Bit period = 104µs; baud rate error =.16%
bsf STATUS, RP0
movlw 0x81
movwf SPBRG
bsf TRISB, 1
bsf TRISB, 2
movlw 0x24
movwf TXSTA
bcf STATUS, RP0
movlw 0x90
movwf RCSTA
; 2: Hserout "Hello!"
movlw 0x48
Call hs01
movlw 0x65
Call hs01
movlw 0x6c
Call hs01
movlw 0x6c
Call hs01
movlw 0x6f
Call hs01
movlw 0x21
Call hs01
; 3: End
l0002: Goto l0002
; End of user code
l0003: Goto l0003
; hardware serial communication routines
hs01:
btfsc PIR1, TXIF <---- test if UART ready to transmit
Goto hs02
Goto hs01 <----- loop until ready
hs02: movwf TXREG
Return
Probably. During init, the LCD will require some long delays. That's not too big a problem but there are delays in operation too. It takes several msec (per the 44780 datasheet) to clear the display or return home (Optrex says its 15.2msec!). Each character takes ~40usec to enter. The code must take these delays into account. Sometimes, the compiler will generate a dumb delay after writing but usually, the busy flag is polled before each operation. But in either case, its common to wait for the operation to complete, burning up CPU time - much like that UART code. I've written interrupt driven buffered LCD routines but I haven't seen a compiler's library that does it. All the compilers I know about wait on the LCD as I described.Hi all,
Thanks for your detailed offerings, which prove to be true when run in the circuit. This indicates to me that one has to be careful to keep time critical programs to the minimum, in case they get pushed into into errors.
Can I also assume that LCDOUT has similar affects?
C.
Hi J,Probably. During init, the LCD will require some long delays. That's not too big a problem but there are delays in operation too. It takes several msec (per the 44780 datasheet) to clear the display or return home (Optrex says its 15.2msec!). Each character takes ~40usec to enter. The code must take these delays into account. Sometimes, the compiler will generate a dumb delay after writing but usually, the busy flag is polled before each operation. But in either case, its common to wait for the operation to complete, burning up CPU time - much like that UART code. I've written interrupt driven buffered LCD routines but I haven't seen a compiler's library that does it. All the compilers I know about wait on the LCD as I described.
Since clearing the display takes so much time, I usually prefer to just write the new message with appropriate blanks to overwrite the old data rather than using the Clear Display command.
On a sort of related note, in your circuit be sure to pull the LCD E line down so that you don't send it garbage while the PIC is starting up. Also, if the code polls the busy line, be sure to use a pulldown to pull it low to a NOT BUSY condition. That way, if the LCD fails or is not present, the code won't hang forever waiting on a NOT BUSY that may never happen.
Have fun.
Even if you just add a line to toggle an output pin for an LED it will affect the program timing. It all depends on how time critical it is what you can get away with.Hi J,
I don't need an LCD in this particular program, I was only wondering if an LCD could be used for trouble shooting, and from what you say it can't. Thanks.
C.
Hi A,Even if you just add a line to toggle an output pin for an LED it will affect the program timing. It all depends on how time critical it is what you can get away with.
Or you can poll the TXIF flag without having the interrupt enabled. If it's found to be set and there is data to send, you can load the next character into TXREG. That's all you need to do.The hot setup is to use a FIFO (first in first out) buffer and and interrupt driven UART handler. The main code flow dumps characters into the buffer (fast) then resumes processing. The UART code loads the first character into TXBUF then enables TXIE. Whenever the UART has completed one character's transmission, the PIC gets interrupted and the service routine grabs the next character from the buffer and drops it onto TXBUF then returns. When the buffer is empty, TXIE is disabled and the UART handler waits for more characters.
Fun, ain't it!
Hi J,Or you can poll the TXIF flag without having the interrupt enabled. If it's found to be set and there is data to send, you can load the next character into TXREG. That's all you need to do.
Yes.
by Aaron Carman
by Aaron Carman
by Jake Hertz