16F628A USART in sync mode

Status
Not open for further replies.
K

kenmac

New Member
Hi folks,
I've been learning how to set up the '628A for synchronous comms.
Initially I have coded to send a continuous 9600bd signal with data set as 00h, basically just to confirm the Clock generation.
In this condition I would have expected to see (on the CRO) continuous Clock pulses, and zero data.
The Clocks are OK, but there is a Mark bit on the data line at the start of each byte.
I noted that the data line is normally high when not in use.
First thought was I hadn't set it to Sync, but that is not so.

Code: 
; ***set up Ports ****
	bsf	   STATUS,RP0		      ; bank1
	movlw	02h				  ; b'00000010'  PORTB.1 set
	movwf	TRISB			       ; set up portB 
	clrf	    TRISA			    ; set PORTA as outputs (not used)
;
;***set bits SYN,CSRC ***
	bsf		TXSTA,4			; set SYNC - selects Sync mode
	bsf		TXSTA,7			; set CSRC - selects Master mode
;
;*** Set up baudrate ***
	movlw	67h				; required value for 9600bd/4mhz 
	movwf	SPBRG			      ; set baud rate
	bcf	   STATUS,RP0	              ; bank0
;
;*** set bit SPEN ***
	bsf		RCSTA,7			; set SPEN - configures data/clock 
;
;*** enable Tx ****
	bsf		STATUS,RP0	      ; bank1
	bsf		TXSTA,5			; set TXEN
	bcf		STATUS,RP0	      ; bank0
;
	movlw	0x00			         ; data (00h)
loop1
	movwf	TXREG	  ; load data - this will trigger Tx if TXEN is set
	goto 	loop1		; continue sending data (00h)

I have been working from the Microchip data sheets, but can't see why these extra pulses are there.
The reason will probably be obvious to others more experienced in handling this area of programming.

kenmac
 
Yes, the serial line is held high when not transmitting. And then the start bit is the line going low for one period. The line returns high after the data bits, for a period count the same as the number of stop bits.

You can find more information about serial communication here: https://www.beyondlogic.org/.

Mike
 
I do not agree. In syncronous mode there should not be ANY framing bits since they are no longer needed. Also remember that in half duplex mode that you will be transmitting and receiving on the same line.

Edit:
I see SYNC, CSRC, and SPEN in the code now in addition to TXEN. This is most curious. You are not setup for 9 bit mode are you?

2nd Edit:
Should both TRISB<2> and TRISB<1> be set to '1' to allow the USART to control them? As I read the timing diagram for syncronous transmission the data will be on RB1 and the clock will be on RB2.
 
This is SYNCHRONOUS mode - no start-stop bits!
The required bits have been set, as shown in the code.


kenmac

edited: 9 bit mode not set
 
Change the movlw 2 to a movlw 6 so both TRISB<2> and TRISB<1> are set to '1' so the UART can control them.
 
kenmac said:
This is SYNCHRONOUS mode - no start-stop bits!
The required bits have been set, as shown in the code.


kenmac

edited: 9 bit mode not set
Click to expand...

Do you have a particular use for this?, or are you just playing with it?.

Is it perhaps dropping to receive mode for a moment, as it's a half-duplex system it might be checking for a reply?. The syncronous option always seems overly complicated, and I've never seen any real need for it?.
 
Nigel,

I think its unlikely that there is any kind of automatic line turnaround. In most syncronous systems the line is turned around manually by software when the transmitter is done. In this case we have an infinite loop which is continuously transmitting. The goal is to reproduce the picture in the data sheet which suggests that the data should be back to back with no intervening bits. If changing the TRIS register to allow the USART to control both RB2 and RB1 does not work the next thing I would look at is the continual pounding of the data register. Try rewriting your infinite loop to test for the transmit register to be ready for another byte before writing the next zero.

Stick with it -- the answer is out there.
 
The b1,2 pins were set/cleared as per the datasheet instruction to configure Sync mode.

Hi Nigel,
I work occasionally with the local Aviation Museum, which displays redundant comms equipment etc.
We have a Radar display, driven by digitally coded messages to display simulated aircraft tracks.
Part of it is a map overlay, which is generated from an old digital cassette tape, via one way 9600bd serial comms using EBCDIC protocol.
Unfortunately, the tape is degenerating and there are no longer any replacements available so we are planning to read the message packets into a PC for future storage/manipulation.
The basic idea was to use a PIC USART, programmed in assembly to read the data and store in an external Atmel Dataflash chip.
Then it can be read at leisure and retransmitted in Async to the PC using Hyperterminal.
I normally work in Basic so I have needed to do a quick refresher on Assembly and I am currently feeling my way thru the control requirements of the 16F628A USART.
That's the reason for bothering with Sync mode.

kenmac
 
Excuse me. The code in your original post is "movlw 2" which will set TRISB<1> to a '1' and TRISB<2> to a '0'. In the directions for syncronous mode it says that TRISB<2> and TRISB<1> need to be set to '1' so that the USART can control both lines.
 
The instructions in the datasheet were followed.
On Page 83 of the 628A datasheet it says:
" when setting up a Synchronous Master transmission TRISB<1> needs to be set and TRISB<2> cleared, in order to configure pins RB1, RB2 as the USART pins"
I assume that the internals then take care of the input/output modes.
Normally setting a pin to "1" will make it an input - confusing.

Papabravo
Where did you see that the two pins were to be set to "1"?

kenmac
 
I'm looking at page 84 of document DS40044D, Item #1 in the right hand column. This looks like REV D of the datasheet dated 2005. I checked the datasheet for the PIC16F628(without the A suffix) which is DS40300C and it also says that both bits must be set in conjunction with SPEN.

I unable to find a page 83 in a current version of a 16F628 datasheet that has the sentence you are referring to.
 
I happen to have a copy of the Reva datasheet and it does state on page 77 (and a few other places).
"1. TRISB<1> bit needs to be set and TRISB<2> bit
cleared in order to configure pins RB2/TX/CK
and RB1/RX/DT as the Universal Synchronous
Asynchronous Receiver Transmitter pins."

But on page 69 it also states,
"Bit SPEN (RCSTA<7>), and bits TRISB<2:1>, have to
be set in order to configure pins RB2/TX/CK and RB1/
RX/DT as the Universal Synchronous Asynchronous
Receiver Transmitter."

So, it looks like even Microchip were confused at the time.

Mike.
 
I think Microchip's shorts are showing. It doesn't happen often, but this might be the exception.

I will add one more point in favor of setting both TRISB bits. If you go to the data sheet section on multiplexed port pins, it is "common" to set the TRIS&# bit to a one to allow for an alternate peripheral function.

In any case what could it possibly hurt to run the experiment.

I'm still interested to know if testing TMRT before writing the Transmit Data Register has any effect.
 
It looks like I have an early version of the datasheet DS4044D (2004).
The relevant info re TRISB settings has been changed in the 2005 version.
It now says they should both be set!
Also, there is an error notification .pdf [DS8015L (2005)] which has a reference to the USART operation.
I will experiment with TRISB settings and see what happens.
Apart from the extra bit, the Tx of clock and data seems to work.

kenmac
 
OK - I tried setting the B1,2 = "1" (inputs) as per the later sheet.
Unfortunately it had no effect at all.
I also tried setting to 9 bits, but the extra bit was still there.

I'm going to also put this query on Microchip's forum - they will be closer to the design area.
I'll post any relevant new info that I get from them.

kenmac
 
Can you also try checking TXIF prior to writing to TXREG and only write TXREG when TXIF is set. Writing constantly to TXREG may cause some strange behaviour.

Mike.
 
I checked the errata on the PIC16F628A and it refers to the procedure for turning the line around when you want to switch from transmit to receive. It's annoying but should work.

On the witing of the Tx Data Register you can check either TXIF or TMRT to determine when to write the data register. Did you try that one yet? You did not say in your last post.

Edit: What is the timing relationship of the high going pulse to the clock signal? Is it one bit long? Part of a bit? A picture would sure help.
 
I haven't tried reading the TRMIT bit before loading the TXREG yet - I'll do that later today.
The timing is not apparent because I am restricted to a single trace CRO, but I may be able to borrow a more suitable type.
The bit width is the full 104uS (9600bd) as far as I can tell.


kenmac
 
OK, I have the answer.
I went to the trouble of borrowing a dual trace CRO to examine the timing of everything.
It seems that in between bytes the output pin is returned to the high state "1".
For continuous data, this state holds for the time of one bit.
This will not be read at the receive end, because the clock pulses are only generated one per data bit, i.e. 8 pulses per byte.
I had assumed that the clocks were continuous while Tx was enabled - not so.
I took sime pics of the CRO screen, and these are attached.

kenmac
 

Attachments

  • p1010003_2.jpg
    253.8 KB · Views: 542
  • p1010004_2.jpg
    60.9 KB · Views: 548
  • p1010005_2.jpg
    63.5 KB · Views: 558
Status
Not open for further replies.

Similar threads

  • Question
Using Timer1 in 16-bit mode.
Replies
18
Views
3K
Peet19
K
  • Question
Role of OSI Model in IoT Projects
Replies
6
Views
4K
rjenkinsgb
P
  • Question
Place EEPROM at byte boundaries in Pic18 series.
Replies
1
Views
2K
Ian Rogers
B
  • Question
Temperature controlled fan using PIC16F877a (in assembly language)
Replies
6
Views
4K
Dan Soze
D
  • Question
PIC 8-bit mode TX and 9-bit mode RX on same USART?
Replies
4
Views
2K
ccurtis
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…