HOW to sync 4 Kinetis uc with 1 common RTC? and also how to communicate with all the uc?

[Amit_Kumar1]

Hello

I want to sync 4 kinetis uc  with 1 common RTC so that the time in all the uc remains the same. and also I want to establish rs 485 communication among 1 master and 3 slave uc . how should I proceed to get both the things done ?

Thanks

Amit Kumar

[VictorLorenzo]

Hi Amit,

Will all microcontrollers be in the same board? The fact that you are considering using one RS485 network for interconnecting the microcontrollers suggests some kind of distributed system.

If the microcontrollers will be in the same board you could use one 32KHz oscillator and create a clock distribution network so all microcontrollers connect to it (EXTAL32 RTC input pin). In this case perhaps it could be better using SPI for communicating the microcontrollers instead of RS485, you'll need less components and it will be presummable simpler to program.

By the contrary, if all microcontrollers are to be placed in different boards it is better not to share the same clock signal (distributing clock signals over long cables is sometimes difficult) but make each microcontroller have its own clock. Clock differences (supposing you may live with a few milliseconds difference), as you'll have one master and several slaves, can be trimmed out using special synchronization commands from the master.

-Victor

[Amit_Kumar1]

Hi Victor

I was thinking if I can connect some sensors and 2 microcontrollers in the following configuration using SPI.

                                                                

I.e the slave uc will act as a master for all the 4 sensors and will act as a slave for another uc and the distance between them is specified above. I have one more question. Do we need to add a buffer for 30 to 40 m distance communication ? if so can you tell me the part no.  which one will be most suitable ? 

Thanks & Regards

Amit Kumar 

[egoodii]

Might I suggest CAN?  The FlexCAN controller has one particular advantage in that the TX and RX message events are timestamped at the same bit-point 'on the wire', and you can use these 'correction factors' for the message contents sent by the 'master' to calibrate the time differentials.

From the manual, for this field in the MailBox:

TIME STAMP — Free-Running Counter Time Stamp

This 16-bit field is a copy of the Free-Running Timer, captured for Tx and Rx frames at

the time when the beginning of the Identifier field appears on the CAN bus.

This free-running counter runs at the bus bit-rate, so something like 500K/250K/125K diff-pair, or 83.3/33.3Kbps 'one-wire' is 'common'.  That gives a 'fundamental' resolution of 'some microseconds'.

Our implementation used J1939-style messages, but that is not important.  The detail is that the 'master' sends a 'current time' message, but the slaves just 'store' that for the moment.  Then the Master makes 'note' of the time delay between the free-running-counter value when it packed-up the time to send, and the 'actual' send time per the CAN timestamp read at the TX-complete interrupt.  This info goes in a second message, and when received the original-message RX-timestamp is compared to the current free-running-counter value at the second-RX processing instant to create a fully corrected time value for update:

1.1.1. DateTime (PGN 65290)

Sent by the time master periodically in order to synchronize date & time across all nodes on the bus. This is the first of a 2-part time synchronization sequence. Upon receipt of this message, the time slave shall simply remember the time contained within. The receiver shall not store the time into the local real-time clock.

A time slave may also send this message in order to set the system time. In response, the time master shall immediately send the DateTime message followed by the DateTime Sync message.

Byte 0: UTC Seconds (units=seconds, range=0 to 59, offset=0, length=1 byte)

Byte 1: UTC Minutes (units=minutes, range=0 to 59, offset=0, length=1 byte)

Byte 2: UTC Hours (units=hours, range=0 to 23, offset=0, length=1 byte)

Byte 3: UTC Month (units=months, range=1 to 12, offset=0, length=1 byte)

Byte 4: UTC Day (units=days, range=1 to 31, offset=0, length=1 byte)

Byte 5: UTC Year (units=years, range=0 to 250, offset=1985 years, length=1 byte)

Byte 6: Local Offset Minutes (units=minutes, range=-59 to 59, offset=-125, length=1 byte)

Byte 7: Local Offset Hours (units=hours, range=-12 to 14, offset=-125, length=1 byte)

Of course it would be 'much easier' to just work with the raw 32-bit 'seconds' register from the RTC module.

1.1.2. DateTime Sync (PGN 65291)

Sent by the time master following the DateTime message. This message contains the fractional seconds (high resolution) portion of the timestamp, as well as a calibration constant that incorporates the propagation delay of the DateTime message. Upon receipt of this message, the time slave shall compute the “adjusted current time”, which is the sum of 1) the time stored in the most recently received DateTime message, 2) the calibration offset contained in the DateTime Sync message, and 3) the difference in time between receiving the DateTime and DateTime Sync messages. This “adjusted current time” shall then be written into the local real-time clock.

Bytes 0-3: UTC Microseconds (units=us, range=0 to 999999, offset=0, length=4 bytes)

Bytes 4-7: Calibration Offset (units=us, range=0 to 10000000, offset=0, length=4 bytes)

With this, one can 'easily' approach the fundamental bit-rate-resolution time synchronization.  With our 'simple' 33.3K one-wire interconnect we had no trouble hitting our 100us time-differential guarantee.

[Amit_Kumar1]

hi Earl

I am having problem in interfacing 2 FRDM-K20D50 boards using SPI. Kindly look at this link. I have posted my problem here SPI communication b/w two FRDM-K20D50M Boards I am unable to find where i am doing wrong. Kindly look into the matter

Regards,

Amit Kumar

[egoodii]

If you are trying to get a pair of 'complex peripherals' to transfer serial data over a link, you might find it easier to start with the Freescale SCI2CAN example project (although you will need to add CAN transceivers).

[Amit_Kumar1]

Thanks Earl!!!!

I am not very confident on CAN as it will be a new topic for me, so it may take some time to configure things on it. I will try that and will keep u posted. but since the deadline of my project is close so 1st I will try with RS-485. and then will try to switch to CAN. Thanks for giving consolidated information about how CAN is better then the rest for long wire communication. :smileyhappy:

Regards

Amit Kumar

[VictorLorenzo]

Hi Earl,

Up to some extent, CAN is more difficult to debug at hardware and logical levels than RS485 or even I2C or SPI, but it is definitively one very robust, reliable and standardized bus.

Thanks for mentioning the CAN bus and for sharing your solution regarding the timers synchronization. It will also be usefull for amit.kumar in his project.

--Victor

[egoodii]

Amit never gives a 'required tolerance' for clock sync between the uCs, and that would certainly figure in to 'how much work' to put into an interface!  The CAN peripherals can certainly be 'a challenge', but you reap other benefits from the inherent 'smarts' therein:  Fully buffered for 8 complete messages 'in' and 'out' (6 'in' using the  RX FIFO which then leaves 8 for TX MBs), with self-retry on faults, plus optional traffic filtering!  Not to mention fully arbited multidrop bidirectional communication on one (or two) wires.

[VictorLorenzo]

Hi Amir,

The SPI bus is intended for communicating devices which are close, preferably in the same board. 10-20m is a way too long distance for one SPI bus. Perhaps you should consider using RS485 or RS422, with high quality twisted pairs cable. Pay attention to the fact that a relation exists between the cable length and the max communication speed (bit rate).

One more thing to consider is protection, as it will be more than expectable that interferences will be present in the cable, inputs and outputs connecting to the cable must be overvoltage/esd protected.

This links could help you to get some background:

• Guidelines for Proper Wiring of an RS-485 (TIA/EIA-485-A) Network - Tutorial - Maxim,  from Maxim has good background about wiring.
• http://www.ti.com/lit/an/slla272b/slla272b.pdf, The RS485 Design Guide, from Texas Instruments.
• http://www.analog.com/static/imported-files/application_notes/AN-960.pdf, RS-485/RS-422 Circuit Implementation Guide, from Analog Devices.

Maxim, ti (Analog Devices) and Linear, among many others, all have RS485 transceivers.

Take also good care when reading the parameters spec, some of them could say something like "±35kV high ESD-protected transceiver", that does not mean it can withstand 35kV on the lines. For specifying that parameter one very specific body discharge model is used that deviates (for being polite) from real life discharges and interferences you'll face.

Hope it helps,

--Victor

[Amit_Kumar1]

Thanks Victor

I will try this and will update you about the status. I wanted to know what is the maximum length for transmitting signal through SPI or I2C? so that I can place sensor as near as possible.

Regards

Amit Kumar 

[VictorLorenzo]

Hi Amir,

Using shielded cables and proper impedance adaptation and filtering you could connect to one I2C device even with one 1m long cable. We succeeded in doing it once using relatively low speeds (below 50KHz), but it was difficult to achieve due to low noise inmunity and high speed glitches that some times got the I2C states machines crazy.

I would not recommend using SPI for more than 15-to-20 cm as it will become complex to distribute the high rate clocks and signals (it is indeed complex even below 10cm).

If you're still evaluating the usage of SPI, perhaps this (http://www.ti.com/lit/an/slyt441/slyt441.pdf) note from ti will be of help for you. But it will add more cost than using RS485/RS422.

--Victor

[Amit_Kumar1]

Hello Victor

I was just trying SPI communication for small distance so just to verify if the block diagram is correct or it needs some modification?

                             

Actually I was going through the schematic of FRDM-K20D50 board. I found that open SDA is also connected using SPI but in this schematic they used 74LVC125ADB IC just before interfacing with Target uc.so Is there any need to connect this IC in above circuit ? as all the above  uc is working on 3.3V so I think I can interface it directly. correct me if I am wrong.

                                                     

Regards,

Amit Kumar

[Amit_Kumar1]

The SPI communication between 2 FRDM board was done successfully kindly refer this link SPI communication b/w two FRDM-K20D50M Boards the issue was with FRDM board. the J17 jumper is needed to be cut as it is connected to the accelerometer so the board was having problem in transmitting data . after cutting the track the board is working fine for SPI.

[Amit_Kumar1]

Thanks VictorLorenzo for the reply. All the microcontrollers will be on different boards with minimum distance b/w them around 2-3 meters and maximum distance can vary upto 30 meters. and thanks for the suggestion for sync of RTC clocks. I will try that

Regards

Amit Kumar

[perlam_i_au]

Hi Amit:

All you need to do for sync is use the same crystal (xtal) on IC package as source for XTAL32 input for all micro controllers.

[Amit_Kumar1]

Thanks Perla for the reply. I was wondering that if I connect 1 common RTC with all controllers then there may be some noise as all the controllers will be at some distance. altough I will try the same and will revert back

Regards,

Amit Kumar