Using both RS232 and CAN on ECIO40P

[Jay Dee]

Hi Guys,
Wishing to read data from an RS232 datastream and output some of the values over CAN, using an ECIO 40P (PIC18F4455)
I hope to get on with the RS232 ok and have done plenty with CAN but the CAN controller uses SPI and the SPI's SDO pin is also the RS232 TX pin.
I can toggle the CS pin of the CAN controller, so that it only operates when required, I guess I would also need to toggle something on the RS232 side to disable that as well.

But once I have initialised the CAN, can i still use the RS232 Rx/Tx?

Any ideas or experiance with sharing a single comms pin between different protocols?
Thanks,
J.

[LeighM]

Hi
I would suggest using the hardware UART (on the defined pins) and then use some other pins for the SPI CAN interface, using a software SPI.
That is, use the RS232 Flowcode component set to UART1. Then get the CAN component to connect elsewhere by customising the code defines section. Example here uses a software SPI on PORTD 0,1,2.
Regards,
Leigh

Code: Select all

	//Definitions for SPI slot allocation
	#ifndef	MX_SPI_REF1
		#define MX_SPI_REF1
		#define %a_MX_SPI_UREF			1
		#define MX_SPI_CHANNEL_1		0	// set software SPI mode
		#define MX_SPI_MOSI_PIN_1		0	// use PORTD 0 for SPI MOSI
		#define MX_SPI_MOSI_PORT_1		portd
		#define MX_SPI_MOSI_TRIS_1		trisd
		#define MX_SPI_MISO_PIN_1		1	// use PORTD 1 for SPI MISO
		#define MX_SPI_MISO_PORT_1		portd
		#define MX_SPI_MISO_TRIS_1		trisd
		#define MX_SPI_SCK_PIN_1		2	// use PORTD 2 for SPI SCK
		#define MX_SPI_SCK_PORT_1		portd
		#define MX_SPI_SCK_TRIS_1		trisd
		#define MX_SPI_BMODE_1			5
		#define MX_SPI_PR_SCALE_1		64
		#define MX_SPI_PO_SCALE_1		0
		#define MX_SPI_INT_1			0
	#else

[Jay Dee]

Hi, Thanks for that,
After defining the pins to use, can I then use the rest of the FC SPI elements as before?

From a more general piont of view, are there any common disadvantage / advantages to using a software over the UART hardware?

I guess setting the hardware UART to deal with the RS232 stream, allows the UART buffers to be used for the received byte, even if the program is elsewhere performing another task.
Regards, John.

[LeighM]

Yes, the UART needs to respond to external asynchronous events, i.e. receive a character, so it is better to use the hardware which can buffer the character until processed. Whereas the SPI for the CAN is the master so can be software driven. The external CAN device does all the data buffering in this case.
The SPI used for the CAN component is transparent to the user, so you don’t need to get involved with SPI within your Flowcode, just use the CAN macros.

I have assumed that you are using the CAN component and the e-blocks EB018 or the MCP2515 CAN controller. If you are using the SPI directly to some other CAN controller, then you instead simply need to use the SPI component and select “Software mode” for the SPI properties.

Regards,
Leigh

[Jay Dee]

Thanks for the confirmation Leigh, that helps confirm some stuff.
The project spec is growing (as ever) and might well end up with... 2 x CAN 2 x RS232 (possibly even 1 x LIN) thus allowing us to pass limited quantities of data between all of the networks in the system.
I we go the single CAN and single RS232, then the method you suggest above looks good.

If we go for a larger system, then using something like the MAX3110E chip, its basically 2 x RS232 transceivers with all of the support stuff ( and proper RS232 level drivers) integrated into a single chip and is communicated with using SPI.
The thinking being, since a PIC18F can only do one task at a time, it will just send/recieve data over a single SPI bus to which ever comms network is of interest. Hopefully the buffers will be large enough to hold the incoming data before the chip has time to poll them...or get a bit more clever and use the various interrupts from the CAN/RS232 chips. ! Project Creep Alert !
Thanks again to Matrix Tech Support, Keeping our projects moving!
J.