Transmitt ASCII data

[ami85t]

HI,
I am sending data via a PIC16f877 to a Bluetooth module (RN42SM)
and from there to a Android application.
The protocol for communication between the pic and the BT is via UART
and the BT default protocol is SPP.

The data received in the android app is always F8 or 80, no matter
whats the value of TXREG is.
What shell be done for getting the right data that's been send?
Is it a problem of the communication or interface?
If not and it's connected to the code- how do I send the data as ASCII characters?

I'm writing in Assembly.
Thanks, Amitai

 

[kpatz]

My first guess would be the baud rate of the UART and the Bluetooth module don't match. What are you initializing the UART control registers to?

 

[ami85t]

My first guess would be the baud rate of the UART and the Bluetooth module don't match. What are you initializing the UART control registers to?

I now that as default the BT functions as a pipe-line, but does that mean that
the baud rate and other specifications of the PIC need to be as the BT?
(Serial port 115.2K bps baud rate, 8 bits, no parity, 1 stop bit)

This is my code:

LIST	P=PIC16F877
    	
include	<P16f877.inc>
org		0x00

	__CONFIG _LVP_OFF &_WDT_OFF &_PWRTE_OFF &_CP_OFF & _HS_OSC	

	reset:
	nop
	goto	start
	org		0x20

start:
; configuration
;-----------------------------------

; used_ registers:
	MUX_sel			EQU H'0021'  		; for not transmitting '000000000'
	del1			EQU H'0030'  		; for delay
	del2			EQU H'0031'  		; for delay
	tro_transmit	EQU H'0050'  		; Frequency data register
	chk_zero		EQU H'0055'  		; for not transmitting '000000000'
	demo_send	 	EQU H'0056'  		; FF sent in beginning
	led1			EQU H'0070'  		; for led delay

	banksel		ADCON1
	movlw		0x07				; pin RA5 is configured as a digital I/O									
	movwf		ADCON1

;UART/*/*/
	banksel  	TXSTA
	movlw    	0x24        		 ; master, transmit EN, sync mode, Transmit Shift Register empty
	movwf    	TXSTA	       		; Baud Rate = Fosc/(4(SPBRG+1)) , BRGH (baud rate) ignored in sync
	
	banksel		TRISC
	bsf	 	 	TRISC, 6 
	bsf		 	TRISC, 7	
	
	banksel		SPBRG
	movlw	 	0x10		   		; = d"16" which corresponds to 15Kbps with 8MHz clock
	movwf	 	SPBRG
	
	banksel  	RCSTA
	movlw    	0x80		  		; enable UART	
	movwf    	RCSTA	
	
;PWM, timer2/*/*/
	banksel		TRISC
	bcf			TRISC, 2 			; make the CCP1 pin an output.
	banksel		T2CON
	
	movlw		0x04
	movwf		T2CON				; no post/Prescaler (1:1) , TMR2 ON
	
	banksel		PR2					; output frequency = 15000hz 	=			
	movlw		0x84
	movwf		PR2					; 1 / [(PR2) + 1] • 4 • TOSC •(TMR2 prescale value)
	
	banksel		CCPR1L				;duty cycle =(CCPR1L:CCP1CON<5:4>) • TOSC • (TMR2 prescale value)
	movlw		0b01000010 	
	movwf		CCPR1L				
	banksel		CCP1CON
	movlw		0b00111100 	
	movwf		CCP1CON

;capture, timer1 /*/*/
	banksel		TRISC
	bcf			TRISC, 1 			; make the CCP2 pin an output.

	banksel		T1CON
	movlw		0x09				; Timer1 Input Clock Prescale 1:1, en TMR1
	movwf		T1CON				; , int clk (fosc/4) , oscillator en
	banksel		CCP2CON
	movlw		0x07
	movwf		CCP2CON				; Capture mode, every 16th rising edge 
	banksel		PIE2
	bcf			PIE2, CCP2IE		; avoid false interrupts 
	
;MUX select
	banksel		TRISD
	bcf			TRISD, 0
	bcf			TRISD, 1
	bcf			TRISD, 2

;LED general delay
	bcf			TRISD, 4
	bcf			TRISD, 5
	banksel		PORTD	
	bcf			PORTD, 4
	bcf			PORTD, 5
	
; end configuration --------------------------------------




;************ MAIN PROGRAM ***************
;*****************************************

main:
	
;MUX init
	movlw		0x07
	movwf		MUX_sel
	
;transmit check /*/*/*/*
    CALL		DELAY
	movlw		0xFF
	movwf		demo_send
	movf		demo_send, w  
	CALL 		transmitting_data   	

main_loop:

		Led_flicker:
		movlw 		0xFF
		movwf		led1
		t2:
		CALL		DELAY
		CALL		DELAY
		CALL		DELAY
		CALL		DELAY
		decfsz		led1
		goto		t2
		
		bcf			PORTD,5
		bsf			PORTD,4		
		
		banksel		led1		
		movlw 		0xFF
		movwf		led1
		t1:
		CALL		DELAY
		CALL		DELAY
		CALL		DELAY
		CALL		DELAY
		decfsz		led1
		goto		t1

		bcf			PORTD,4
		bsf			PORTD,5
;---end Led flicker

;capture frequency/*/*
	banksel		TMR1H	
	clrf		TMR1H
	clrf		TMR1L
	check_capture:		
	banksel		PIR2
	btfss		PIR2, CCP2IF							; 1  = A TMR1 register capture occurred (must be cleared in software)
	goto		check_capture

;transmitting data	
	banksel		CCPR2H							; transmit MSB
	movf		CCPR2H, w
	banksel		tro_transmit
	movwf		tro_transmit
	CALL 		transmitting_data
	
	banksel		CCPR2L							; transmit LSB
	movf		CCPR2L, w
	banksel		tro_transmit
	movwf		tro_transmit
	CALL 		transmitting_data
		
;MUX select/*/*/
	movf		MUX_sel,w
	banksel		PORTD
	movwf		PORTD
	decfsz		MUX_sel
	goto		main_loop
	movlw		0x07
	movwf		MUX_sel
	
goto main_loop

	
				
;******** END MAIN LOOP ********************		

transmitting_data:
	banksel		TXREG
	movwf   	TXREG					    	; writing to TXREG clears TXIF
    trans_wait2:
	btfss		PIR1, TXIF						; wait for the frame to be transmitted
	goto		trans_wait2
	CALL		DELAY
	return

DELAY:
		movlw	0xFF
		movwf	del1
		movlw	0xFF
		movwf	del2
	
		loopa:
		decfsz	del1, f
		goto	loopa
		loopb:
		decfsz	del2, f
		goto	loopb
		return
		
end

 

[OLIVE2222]

You can maybe first check the BT module alone (if not yet done) by checking is bluetooth address (BD_ADDR) via the dedicated command for example. Also the CTS-RTS pins must probably be jumped. You can also test the BT module with a wire ended FTDI 3V3 USB /RS232 adapter and a terminal PC software.

 

[ami85t]

Thanks olive,
Since I posted this question the situation is match better
and the numbers that are transmitted are almost the
received as wanted. Why almost? because the 7th bit (2 MSB)
is always '1'. for example, instead of receiving 05 04 03 02 01
what is received is 85 84 83 82 81.

I assume that's connected to the Compatibility of the uart and
the default settings of the BT which is 1 stop bit. The uart can be ether
sync with no stop and start bit or async with start and stop bit
for each byte sent. Maybe that can be solved programing the BT?

Amitai

 

[(*steve*)]

because the 7th bit (2 MSB)
is always '1'. for example, instead of receiving 05 04 03 02 01
what is received is 85 84 83 82 81.

That sounds like a mismatch between the transmitting and receiving UART (or equivalents).

At some point, something is set for 7-bit with either the 8th bit forced high (a parity setting) or stop bits such that this appears to be the case.

It's been so long since I had to configure RS232 devices to talk that I can't actually remember if the stop bits look like 1s or 0s (I seem to remember it's zeros).

This can be quite hard to diagnose because there is at least 2 and possibly several more places where this can be implemented.

Try configuring everything for 8 but data with no parity (if that's possible)

 

[ami85t]

Thanks steve,
In the data sheet of the RN42SM is written:

default configuration
• Bluetooth slave mode
• Bluetooth pin code 1234
• Serial port 115.2K bps baud rate, 8 bits, no parity, 1 stop bit
• Serial port flow control disabled
• Low power mode off
• Name: FireFly-XXXX
• SPP standard- emulates a serial cable

so I tried to follow these instructions of the 3td row. from the data sheet
of the PIC it's really not cleat if the start/stop bits are '1' or '0', I've checked
it out a few times.

Try configuring everything for 8 but data with no parity

Can you be more specific please? to try different configurations for the transmitted data?

Amitai

 

[(*steve*)]

Can you be more specific please? to try different configurations for the transmitted data?

Configure everything that you can figure out how to configure as 8-N-1.

If that doesn't work, you may have to (by trial and error if necessary) determine the configuration for those things you can't configure and then make everything else match.

Those things may include:

The sending UART, the receiving UART, the hardware/software driving the sending UART, and the hardware/software being driven by the receiving UART.

If your link is bidirectional, then you can double this because you have both directions to worry about.

It is possible (but unlikely these days) that some component of the system is limited to 7 but data and forces the 8th bit to some fixed value (mark or space parity). If this is the case (or if you give up sooner) you may be able to send your 8 bit values another way.

Maybe you can send a pair of 4 bit values, or maybe you can encode it some other way. To make this work you'll have to have a lot more control over the software at each end (which you may have)

 

[kpatz]

Start bits are always 0 and stop bits are always 1. If the bit polarity were wrong your data bytes would be all wrong, not just the top bit.

PICs only support 8-N-1 or 9-N-1 natively, but you can do 7-E-1 or 7-N-2 in software easily enough by manipulating the top bit before transmitting.

It's also possible your baud rate isn't quite right. What frequency crystal are you using?

 

[ami85t]

8 MHZ crystal. I tried configuring the baud rate as close as I can.
There's an option of the BT of sending 7 bits, maybe that's a permanent
solution?
Amitai

 

[KrisBlueNZ]

I think kpatz is onto something. If the baud rate of your receiving UART is a bit too low, it will sample at the wrong point in each bit; the error will increase as the bits arrive. When the last bit arrives, the sampling times are so far off that the bit 7 sample is actually taken at the beginning of the stop bit.

First, check your calculations for the baud rate divisor. If they're right, try reducing the baud rate divisor value that you program into the USART by 1, to make the receiving UART sample slightly faster. You could also try increasing it by 1 from the current value, in case I've got my reasoning backwards. If this fixes the problem, you should change to a crystal that's an integer multiple of the baud rate, such as 7.3728 MHz. You'll need to recalculate the baud rate divisor, of course.