Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Serial comunication

Status
Not open for further replies.
ok guys i've finaly managed to find some time to get on with this.
i've updated the control panel program, it now has everything apart from the transmition code, i've included a discription of it all this time.
i've also added diagrams of the main control unit and the sub units, (values not yet confirmed) also i've added a pic of the LED package i found, datasheets for all the pic are really easy to find on the net if you need them.

just realised i have one to few pins on my sub unit module, the diagram i added to this post dosnt include a serial output line, so i need to find a solution to this as well, any idears?
 

Attachments

  • copy_of_control_panel1.txt
    5.1 KB · Views: 289
  • control_panel.txt
    6.9 KB · Views: 298
  • led_lamp.jpg
    led_lamp.jpg
    41.2 KB · Views: 851
Misterbenn said:
the other two attachments

The 1uF capacitors shown on both of your crystals will not work. Those values are much much too large causing excessive loading of the high impedance crystal. Find a reference design from the manufacturer for the optimal values or start with 20pF (20E-12) as a common value.
 
yes the diagrams were just to show the general drift of my circuit, none of the component values have acctualy been wooked out yet.
 
Misterbenn said:
yes the diagrams were just to show the general drift of my circuit, none of the component values have acctualy been wooked out yet.

Ok, well it looks fine I suppose.. I dont understand your missing pin issue.. what pin is missing.. I dont know what you are calling a "sub module"

Also, why cant you do the whole thing with one PIC? I bet you can find a way.
 
no i'm using one pic to control 5 other units, the sub units have to be abel to to pick up the serial transmition, re-transmit it to the next unit and control three LEDS.

on the 'sub unit' i have 6 pins, in my diagram i'm using one for serial in, two for the crystal oscillator and three for the LEDS. i need to find a pin to do the serial out with
 
Misterbenn said:
no i'm using one pic to control 5 other units, the sub units have to be abel to to pick up the serial transmition, re-transmit it to the next unit and control three LEDS.

on the 'sub unit' i have 6 pins, in my diagram i'm using one for serial in, two for the crystal oscillator and three for the LEDS. i need to find a pin to do the serial out with

Doesn't that PIC have an internal oscillator?, how about using that and freeing the two crystal pins? - it won't be 20MHz, but you shouldn't need 20MHz.

Failing that, just connect the serial output to all the serial inputs, I'm assuming you're sending a device ID to select each PIC?.
 
Misterbenn said:
no i'm using one pic to control 5 other units, the sub units have to be abel to to pick up the serial transmition, re-transmit it to the next unit and control three LEDS.

on the 'sub unit' i have 6 pins, in my diagram i'm using one for serial in, two for the crystal oscillator and three for the LEDS. i need to find a pin to do the serial out with

Sounds overly complicated.. all you need to do is drive 5 or 6 RGB led's right? all that serial comm stuff is just because you have put so many uC's in there. I'm probably missing an important point of your design but I can't see why one pic and some external driver circuits can't do the job..
 
no i'm driving 15 LEDs in total, in 5 individual sets of 3 (RGB)
i wasnt going to use ID codes no, (look at the bottom section of page one)
but i think i might just put it all on one serial line now, with each unit w8ing for their relevent bytes. EG 1st unit takes its info from the first 3 bytes, 2nd unit takes its info from the second three bytes ignoring all others.
 
Misterbenn said:
no i'm driving 15 LEDs in total, in 5 individual sets of 3 (RGB)
i wasnt going to use ID codes no, (look at the bottom section of page one)
but i think i might just put it all on one serial line now, with each unit w8ing for their relevent bytes. EG 1st unit takes its info from the first 3 bytes, 2nd unit takes its info from the second three bytes ignoring all others.

OK.. my only point was why not drive all 15 LED's with ONE pic?
I have not seen anything in your design so far that is really optimised by utilizing more PIC uC for sets of LEDs.. it just over complicates things and will take you longer to get working...and more board space...and more cost... lower reliability.. you get the idea.

With one pIC there is no serial or ID scheme to cause you problems..I'm just trying to understand why so much logic and parts to just drive 15 Led's.. hardly seems justified! :D

OTOH, each to their own.
 
i'm having to use so many PICs because i dont want all this on one board. there will be about 0.25m gap between each unit so thats 1.5 meters in total.

that would make for a fairly long PCB
 
Misterbenn said:
i'm having to use so many PICs because i dont want all this on one board. there will be about 0.25m gap between each unit so thats 1.5 meters in total.

that would make for a fairly long PCB

Oh, I see. yeah, if they have to be physically seperated you got the right idea!
 
RS232 implementation on a PIC

Misterbenn said:
i'll need some / lots of help with the transmition, and reception bit of the code. i'm planning to run this at about 20MHz, and transmit the LED light level data 50 times a second.
The attached code is a snippet from a project of mine where a PIC was required to read RS232 on one port and send RS232 on a second pin (at a different speed).

This code was written for a PIC16F870 clocked at 4MHz and is quite happy with RS232 data rates of 19200 baud (though 9600 would be plenty for this application ?).

Code:
; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;								RS232 Code
; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

;  RecChar - RS-232 Recieve Character Routine - 19200 Baud, no parity, 8 data, 1 stop
RecChar							;  Serial Recieve a Character from a Host
							;  A character is preceeded by a start bit,
							;  the 5v data line will go LOW for 104us (9600 baud)

			MOVLW	0x09			;  Setup the 8 Bits + Start to Recieve (ignore Stop)
			MOVWF	SCCount
			MOVF	PORTA, W		; Copy to W reg
			MOVWF	Temp			; and save in Temp
			BTFSC	Temp, 1			; Serial Input pin - TTL side goes LOW for START bit
			GOTO	RecChar			; Nothing yet

StartTest						; Time it - should be 104us per bit for 9600 baud
							;			52us for 19200 baud
			MOVLW	0x05			;start bit leading edge, wait for centre & retest
			CALL	Wait_n_
			GOTO	$ + 1
			MOVF	PORTA, W		; Centre of start bit -Copy to W reg
			MOVWF	Temp			; and save in Temp
			BTFSC	Temp, 1			; Serial Input pin - TTL still LOW for START bit
			GOTO	RecChar			; Must be noise - ignore it
			CLRF	KeyCode			; temporary storage of incoming byte
			GOTO	$ + 1
			GOTO	$ + 1

RCLoop							; Loop Here for Each Character
			MOVLW	0x05
			CALL	Wait_n_			; Wait for end of bit
			DECFSZ	SCCount,F
			GOTO	NextBit
			MOVLW	0x05
			CALL	Wait_n_			;centre of bit, wait for end
			RETLW	0			; All done - byte in KeyCode

NextBit							; Wait for middle of new bit
			MOVLW	0x05
			CALL	Wait_n_			;wait for centre of new bit
			MOVF	PORTA, W		; Copy to W reg
			MOVWF	Temp			; and save in Temp
			BTFSC	Temp, 1			; Serial Input pin
			GOTO	GotOne
GotZero			RRF	KeyCode, F		; Note RS232 sends LSB first
			BCF	KeyCode, 7
			NOP				; even up loop times
			GOTO	RCLoop

GotOne			RRF	KeyCode, F
			BSF	KeyCode, 7
			GOTO	RCLoop

			RETLW	0

;  SendChar - RS-485 Send Character Routine - 9600 Baud, ODD parity, 8 data, 1 stop
SendChar						; Serial Send the Character to the Host
			MOVWF	Temp			; Save the Character to Send
			MOVLW	8			; Setup the 8 Bits to Send
			MOVWF	SCCount
			CLRF	Parity			; Bit counter for parity calculation
StartBit		BCF	PORTA, 0		; Output the 'Zero' Start Bit
			GOTO	$ + 1			; NOTE: it is Inverted by driver (+12v)
			MOVLW	0x1E
			GOTO	SCLoopStart
SCLoop							; Loop Here for Each Character
			MOVLW	0x1D
SCLoopStart		CALL	Wait_n_

			RRF	Temp, f			; Note RS232 sends low bit first
			BTFSC	STATUS, C		; Do we have to Send a '1'?
			GOTO	SCOne			; One cycle for SCZero, two for SCOne

SCZero			NOP
			BCF	PORTA, 0		; NOTE: it will be Inverted by driver (+12v)
			GOTO	SCLoopEnd

SCOne			BSF	PORTA, 0		; Send a One - NOTE: it is Inverted by driver (-12v)
			MOVLW	0x01
			XORWF	Parity, f		; Toggle LSB to produce intermediate parity bit

SCLoopEnd		GOTO	$ + 1			; Do this for 8 Bits
			DECFSZ	SCCount, f		;
			GOTO	SCLoop
			MOVLW	0x1D			; Delay for the Last Data Bit
			CALL	Wait_n_
			NOP				; Delay the Correct Number of Cycles
;Parity transmit ...
			XORWF	Parity, f		; test if parity bit should be set (Zero flag set)
			BTFSC	STATUS, Z
			GOTO	ParityOn
			NOP
ParityOff		BCF	PORTA, 0		; Odd number of bits in byte sent
			GOTO	ParityDel
ParityOn		BSF	PORTA, 0		; Even number of bits in byte sent
			GOTO	$ + 1
ParityDel		MOVLW	0x20
			CALL	Wait_n_

			BSF	PORTA, 0		; Send a 'One' Stop Bit
			MOVLW	0x21
			CALL	Wait_n_
			RETLW	0
; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;								Odds and Ends
; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;  Wait46us - Wait Time for half of RS232 bit length - bit processing time (52us total)
Wait46us
			MOVLW	0x0D			; Loop for 46 instruction cycles
			GOTO	$ + 1			; Including Call and Ret (Used in RS232 Receive)
Wait_n_			MOVWF	Count			; Variable delay (6+3*n us)

			DECFSZ	Count, f
			GOTO	$ - 1
Wait4us			RETLW	0

;  Wait4ms - Wait Time for Key to Debounce - Wait through 4,000 Cycles
Wait4ms
			MOVLW	53			;  Loop Around 1,000x for a 4ms wait
			MOVWF	Count
			MOVLW	6
			MOVWF	Counthi

			DECFSZ	Count, f
			GOTO	$ - 1
			DECFSZ	Counthi, f
			GOTO	$ - 3
			RETLW	0

I don't pretend that this is the most efficient or most elegant way of producing the code but it is fairly well documented and proven.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top