16F628A USART in sync mode - Electronic Circuits Projects Diagrams Free

kenmac · 11th April 2006, 06:31 AM

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

upand_at_them · 11th April 2006, 11:18 AM

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: http://www.beyondlogic.org/.

Mike

Papabravo · 11th April 2006, 12:14 PM

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.

kenmac · 11th April 2006, 12:24 PM

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

Papabravo · 11th April 2006, 12:33 PM

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.

**Nigel Goodwin** · 11th April 2006, 12:40 PM

Quote:

Originally Posted by kenmac

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

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?.

Papabravo · 11th April 2006, 02:39 PM

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.

kenmac · 11th April 2006, 02:45 PM

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

Papabravo · 11th April 2006, 02:58 PM

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.

upand_at_them · 11th April 2006, 03:04 PM

Woops. Ignore what I said. I missed that he was using synchronous mode.

Mike

kenmac · 12th April 2006, 12:26 AM

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

Papabravo · 12th April 2006, 03:24 AM

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.

Pommie · 12th April 2006, 05:12 AM

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.

Papabravo · 12th April 2006, 05:21 AM

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.

kenmac · 12th April 2006, 09:05 AM

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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

11th April 2006, 06:31 AM	(permalink)
kenmac	16F628A USART in sync mode 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

11th April 2006, 11:18 AM	(permalink)
upand_at_them	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: http://www.beyondlogic.org/. Mike

11th April 2006, 12:14 PM	(permalink)
Papabravo	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.

11th April 2006, 12:24 PM	(permalink)
kenmac	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

11th April 2006, 12:33 PM	(permalink)
Papabravo	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.

11th April 2006, 02:39 PM	(permalink)
Papabravo	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.

11th April 2006, 02:45 PM	(permalink)
kenmac	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

11th April 2006, 02:58 PM	(permalink)
Papabravo	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.

11th April 2006, 03:04 PM	(permalink)
upand_at_them	Woops. Ignore what I said. I missed that he was using synchronous mode. Mike

12th April 2006, 12:26 AM	(permalink)
kenmac	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

12th April 2006, 03:24 AM	(permalink)
Papabravo	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.

12th April 2006, 05:12 AM	(permalink)
Pommie	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.

12th April 2006, 05:21 AM	(permalink)
Papabravo	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.

12th April 2006, 09:05 AM	(permalink)
kenmac	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