Connect with us

Transmitt ASCII data

Discussion in 'Microcontrollers, Programming and IoT' started by ami85t, Mar 30, 2014.

Scroll to continue with content
  1. ami85t


    Feb 19, 2014
    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
  2. kpatz


    Feb 24, 2014
    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?
  3. ami85t


    Feb 19, 2014
    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	<>
    org		0x00
    	goto	start
    	org		0x20
    ; 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
    	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 ***************
    ;MUX init
    	movlw		0x07
    	movwf		MUX_sel
    ;transmit check /*/*/*/*
        CALL		DELAY
    	movlw		0xFF
    	movwf		demo_send
    	movf		demo_send, w  
    	CALL 		transmitting_data   	
    		movlw 		0xFF
    		movwf		led1
    		decfsz		led1
    		goto		t2
    		bcf			PORTD,5
    		bsf			PORTD,4		
    		banksel		led1		
    		movlw 		0xFF
    		movwf		led1
    		decfsz		led1
    		goto		t1
    		bcf			PORTD,4
    		bsf			PORTD,5
    ;---end Led flicker
    ;capture frequency/*/*
    	banksel		TMR1H	
    	clrf		TMR1H
    	clrf		TMR1L
    	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 ********************		
    	banksel		TXREG
    	movwf   	TXREG					    	; writing to TXREG clears TXIF
    	btfss		PIR1, TXIF						; wait for the frame to be transmitted
    	goto		trans_wait2
    		movlw	0xFF
    		movwf	del1
    		movlw	0xFF
    		movwf	del2
    		decfsz	del1, f
    		goto	loopa
    		decfsz	del2, f
    		goto	loopb
  4. OLIVE2222


    Oct 2, 2011
    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.
  5. ami85t


    Feb 19, 2014
    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?

  6. (*steve*)

    (*steve*) ¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd Moderator

    Jan 21, 2010
    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)
  7. ami85t


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

    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.

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

  8. (*steve*)

    (*steve*) ¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd Moderator

    Jan 21, 2010
    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)
  9. kpatz


    Feb 24, 2014
    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?
  10. ami85t


    Feb 19, 2014
    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
  11. KrisBlueNZ

    KrisBlueNZ Sadly passed away in 2015

    Nov 28, 2011
    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.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day