Cost and complexity are constant concerns in the automotive industry and attention has been focused on reducing costs for systems which may tolerate less redundancy, and cheaper operation. One such area involves vehicle lighting. Wiring harnesses which require multiple wired and complicated connections, in addition to being expensive, provide potentially more numerous sites for connection failure in addition to requiring more materials. FIG. 1 illustrates a layout of a wiring arrangement for automobile 100. Body control module (BCM) 102 is connected by multiple wires 104 connecting front lights, left 106 and right 108, (FL-L and FL-R, respectively). Additionally, body control module (BCM) 102 is connected by multiple wires 105 connecting rear lights, left 110 and right 112, (RL-L and RL-R, respectively). Reducing the number of wires for connecting automobile wiring, such as those in harness wiring, is a step in the right direction. A Controller area network (CAN) bus or a Local Interconnect Network (LIN) bus may be adapted to provide monitoring and control of lighting systems, among other things. The CAN bus is a serial communications bus that was developed for the automotive industry to permit error detection and error correction and also replace a multi-wired wiring harness with a two-wire bus. The LIN bus was developed to create a standard for low-cost, multiplexed communication in automotive networks that would be cheaper than the CAN bus as the CAN bus is well-suited for higher bandwidth networks making use of more complicated error correction techniques. However, using strictly a CAN approach to controlling systems, such as lighting, may result in an overly expensive and overly complicated solution. LIN on the other hand, is generally not fast enough to provide sophisticated control of a system such as vehicle lighting. In one solution, drivers may be used in conjunction with separate controller units, on-board, having on-chip clock sources, such as crystal clock oscillators for both master and slave/satellite location sites. However, controllers with a crystal clock oscillator source on each printed circuit board or module, represent a level of redundancy that could be beneficially eliminated in order to achieve goals of lower costs and lower complexity. Until now, no digital interface has been presented in the automotive field which is well-suited for off-board communications while providing a solution with relatively low cost and low complexity as compared to existing solutions.
SUMMARY
A controlled device is provided that is operable by a controlling device, remotely located from the controlled device. The controlled device has a transceiver, the transceiver being operable to transmit to and receive digital frame information, including synchronization information having a sync frame, from the controlling device. Circuitry is provided located locally with the transceiver, for providing a recovered clock signal from the synchronization information using the sync frame. The circuitry has neither a crystal clock oscillator nor a phase-locked loop. A driver, connected to the transceiver, is operable to control one or more light emitting diodes according to the recovered clock signal.
BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present disclosure, reference is now made to the ensuing descriptions taken in connection with the accompanying drawings briefly described as follows:
FIG. 1 illustrates a layout of a wiring arrangement for an automobile.
FIG. 2 illustrates a schematic/layout drawing showing a master having a microcontroller and at least one slave/satellite device, on a separate circuit board from the master.
FIG. 3 illustrates a schematic/layout drawing showing another example of an implementation of the foregoing shown in FIG. 2, having a master and several satellite/slaves without a corresponding MCU on the satellite/slave board.
FIG. 4 illustrates a timing diagram showing various receive and transmit activities on the transmit and receive lines.
FIG. 5 illustrates a timing diagram showing specific bit sequences in received data in a sync frame and a device address frame.
FIG. 6 illustrates timing diagrams according to one simplified clock recovery scheme.
FIG. 7 illustrates a block diagram showing digital circuits which may implement the clock recovery scheme according to the clock recovery implementation of FIG. 6.
FIG. 8 illustrates a corresponding flow chart for the timing diagram of FIG. 6 and the block diagram of FIG. 7.
FIG. 9 illustrates a timing diagram showing a normal mode and a burst mode frame transaction.
FIG. 10 illustrates a lighting system which reduces the number of wires used for communication down to a 2-wire bus.
Applicable reference numbers have been carried forward.
DETAILED DESCRIPTION
The foregoing considerations may be addressed in connection with a digital interface to a network of one or more off-board subsystems for controlling automobile subsystems such as vehicle lighting. Such an interface may be compatible with a universal asynchronous receiver transmitter (UART) interface and it may address timing issues by using a protocol starting with a synchronization frame (sync frame), in conjunction with recovering a clock signal, sent by an off-board master device such as a microcontroller unit to a satellite/slave device, off-board. With distance and/or time separating a transmitter and receiver, a clock source from a remote location, undergoes drift. Such drift may primarily result in a change of phase. In order to synchronize operations using a degraded clock signal due to drift, the clock signal preferably has to be adjusted or recovered so that operations using the recovered clock may be synchronized with commands dispatched from the remote location. Many clock recovery methods, using the synchronization information may be used and are contemplated. The protocol herein, permits elimination of a crystal clock oscillator and phase-locked loop at slaves/satellites, thereby dispensing with an otherwise significantly higher cost.
FIG. 2 illustrates a schematic/layout drawing showing master 202 (controlling device) having one driver 200 and at least one satellite or slave 211 (controlled device), with driver 203, on board 205 (board, as used herein, may be a printed circuit board (PCB). In this example, driver 200 and master 202 lie on the same board (such as printed circuit board 201). Master 202 is provided with a driver chip Q1 shown in this example as controlling light emitting diodes (LEDs) 217 (each LED shown being representative of multiple LEDs, for example, 8, 12, 16 or 24 LEDs in number, per driver dedicated output). Master 202 receives instructions from a body control module (BCM) 206 which is an electronic control unit for monitoring and controlling electronic accessories in an automotive vehicle. Master 202 includes a microcontroller unit (MCU) 208 which communicates, over transmit (TX) and receive (RX), lines, with BCM 206 through LIN/CAN transceiver (XCVR) 210. Master 202 also includes CAN transceiver (XCVR) 212 which communicates over transmit (TX) and receive (RX) lines with MCU 208. MCU 208 includes a clock source such as a crystal clock oscillator (not specifically shown). CAN XCVR 212 on board 201 communicates with other CAN transceivers lying off-board such as CAN XCVR 204 on board 205. CAN XCVR 212 may communicate with other CAN transceivers using a two-wire bus such as FlexLED with a sync frame. FlexLED is a network protocol that adds additional protocols over UART+CAN's Physical Layer in an effort to prevent hacking and commands from un-authenticated source such as compromised third party dongles and hacked, over-the-air, in-vehicle updates. As shown, communication with CAN XCVR (212 and 204) takes place using bus lines FlexLEDH and FlexLEDL. An important feature of CAN is that the bus isn't actively driven during logic ‘High’ transmission—referred to as ‘recessive.’ During this time, both bus lines are typically at the same voltage, approximately VCC/2. The bus is only driven during ‘dominant’ transmission, or during logic ‘Low.’ For instance, assuming a 5V supply (VCC=5 volts), in dominant, the bus lines are driven such that (CANH−CANL)≥2.75V. This allows a node transmitting a ‘High’ to detect if another node is trying to send a ‘Low’ at the same time. This is used for non-destructive arbitration, where nodes start each message with an address (priority code) to determine which node will get to use the bus. The node with the lowest binary address wins arbitration and continues with its message. There is no need to back-off and retransmit like other protocols. A direct current (dc) voltage supply or dc-to-dc regulator 218, is located on board 201 and it supplies voltage on-board to driver 200 and off-board to driver 203. Low dropout voltage regulator (LDO) 232 on satellite 211 powers operations on satellite 211 in connection with receiving power on a power supply line (as marked in FIG. 2) from regulator 218. LDO 232 serves to regulate the voltage to satellite 211 without switching noise.
A clock signal from MCU 208 provides timing to driver 200 as well as to other drivers, such as driver 203 on board 205. Driver 203 may drive circuits or components such as LED 217 according to the clock signal. However, in order to avoid clock drift, a synchronization frame is sent with every message transmission transaction. The synchronization frame, also referenced as a “sync frame” may, for instance, include a sequence of bits in a marker pattern with good autocorrelation which may be used at a receiving end to determine the transmission message start time. In connection with receiving, at a transceiver 204, a Start bit (such as that represented in connection with a high to low transition where the low state (dominant) continues for a specified time (so as to be distinguished from a glitch)), the oscillator (not shown) in the receiver is used to generate a sampling at typically 16 times the baud rate. So if a Start bit is sufficiently low for enough sample points, then the synchronization is attempted using the sync frame. For clock recovery, the sampling of the sync frame may optimally occur at a greater rate than the baud rate. Having a known sync pattern in a sync frame enables the synchronization in connection with comparing known times between rising edges with measured times (measured counts). This enables the calculation of the frequency for recovery of the clock at the receiving end such as MCU 234 in connection with receipt of a message received by CAN transceiver (XCVR) 204. There is no need for MCU 234 to contain a phase-locked loop or a crystal clock oscillator.
FIG. 3 illustrates a schematic/layout drawing showing another example of an implementation of the foregoing shown in FIG. 2, having a master 202 and several satellite/slaves 211 without a corresponding MCU on the satellite/slave board 205. CAN XCVR 212 (on Master 202) and XCVR 204 on satellite/slave(s) 211 convert the single-ended UART signals (TX, RX) to differential signal pairs (FlexLEDH, FlexLEDL) and vice versa. While the CAN XCVRs do not code/decode in this topology, the sync frame issuing from CAN XCVR 212, as determined by MCU 208 on master 202 (per the FlexLED protocol as noted herein), is able to provide the relevant clock frequency to slave devices on slaves 211. Slave device (e.g., devices lying on board 205) such as MCU 234 (FIG. 2) or XCVR 204 (FIG. 3) may use the sync frame, accordingly, to adjust the relevant clock frequency from MCU 208 on master 202. There is no need to have an expensive clock generated by an MCU on a board at a satellite/slave. As a consequence, the applicable clock may be recovered without a crystal clock oscillator at satellite/slave MCU, such as the case with that shown with reference to FIG. 2 or it may be recovered by the receiving CAN XCVR 204 of FIG. 3, at board 205 of the satellite/slave 211 in connection with receiving a sync frame through signals on differential signal pair (FlexLEDH, FlexLEDL) from the CAN XCVR 212 (on master 202).
FIG. 4 illustrates a transaction, for one example, for a UART-based dual-wire interface and timing diagram for activities on the transmit and receive lines between CAN XCVR 212 to CAN XCVRs 204. The transmissions may be half duplexed in that they may make use of separate transmit-left and transmit-right bus lines, or they may, alternatively, be used with hardware or software to allow non-simultaneous transmissions, in either direction, on a shared bus line between two transceivers. According to one example, a networking protocol, as exhibited by the transmission of six frames, is as follows: a sync frame, for synchronization and clock recovery; a device address/data transmission mode frame, DEV_ADDR; a register address, REG_ADDR; a DATA N byte number, indicative of the Nth data byte; and a cyclical redundancy (CRC) frame, e.g., 8 bits. Dev_Addr may signify to which device a message is sent. The REG_ADDR may designate which specific register at a device that the message is directed. For instance, in an automotive application, a message may be sent or received concerning the control or status of a particular LED in a particular sub-system as addressed by the DEV_ADDR and REG_ADDR frames. An MCU, such as MCU 234, may receive the information noted by receive waveform RX. According to a multi-byte UART-based protocol as used herewith, a message acknowledgement (ACK) may occur near the end of a CAN message to verify receipt of messages between a message transmitter and all message receivers. Satellite/slave drivers acknowledge receipt of a message, even those intended for others. An acknowledgment to the transmitter may occur even if the expected receiver is not present on the network. Consequently, receipt of an ACK is not an acknowledgement of a data transfer between a transmitter and a designated receiver, or confirmation that an action has been taken, but rather a confirmation that all network nodes agree that the CAN message did not violate any Data Link Layer protocol rules. The Data Link Layer protocol is a protocol governing detection and recovery from message collisions on a bus. Transmissions may occur from a Master to a Satellite as well as from a Satellite to a Master. For lighting systems, this allows an MCU, such as MCU 234, to cause transmission of information and status reports back to MCU 208 at Master 202 concerning such things as specific LED fixture outages. In addition, MCU 208 may control specific LEDs through messages sent to devices off-board from board 201 on satellites such as Satellite 211 on board 205. In one example, transmissions may be sent using pulse width modulation (PWM).
FIG. 5 illustrates a timing diagram showing specific bit sequences in received data in a sync frame and a device address frame, DEV_ADDR, (this example having 8 bits in the frame). A sequence with good auto correlation is shown for the sync frame pattern of 10101010. In one example, there is one data byte per transaction. In one example, the frame starts with a start bit ST and ends with stop bit SP. After this stop bit SP following the sync frame, shown for example by frame designation, 0xAA, a device address frame follows at frame 0x11. In one example, there are 8 bits per sync frame. An alternating pattern of logic ones and zeros provides a basis for a transceiver to lock on to the clock after the start bit is detected (for example, in connection with a dominant transition). Once the lock occurs, a stop bit is encountered at the end of the sync frame. As shown in FIG. 5, a start bit precedes a device address frame which may include an 8 bit address followed by a stop bit.
In connection with a XCVR 204 on satellite 211 (as shown in FIG. 2) receiving a Start bit (high to low transition where the low state (dominant scheme) continues for a specified time (so as to be distinguished from a glitch), a non-crystal clock oscillator (not shown) within XCVR 204 is used to generate a sampling that is faster than the associated the baud rate. Satellite 211 benefits from not having a crystal clock oscillator, an otherwise expensive component/element. It also does not need or have a phase-locked loop circuit, an also otherwise expense. If a Start bit stays sufficiently low for a long enough period of sample points (so as to distinguish it from a glitch), then synchronization is attempted using the sync frame that is encountered in the data stream. Having a known sync pattern in a sync frame enables detection of the pattern and enables time synchronization in connection with comparing known times between rising pulse edges with measured times of rising pulse edges at the receiver. Counts (a pulse based measurement) between rising edges are used to calculate and reproduce the clock frequency. The count is used in a manner similar to determining a moving-average which allows calculation of the pulse width of the sync pulse pattern. The synchronization may be detected by digital circuits within XCVR 204 for the example shown in FIG. 3. Alternatively, the synchronization may be detected by circuits within MCU 234 or XCVR 204 of FIG. 2. By knowing the pulse-width, the clock frequency for communication with the master is known. This same frequency may be used in transmitting information to the master 202.
FIG. 6 illustrates timing diagrams according to one simplified clock recovery scheme. Clocked data from Master 202 of FIG. 2 is received by a satellite 211. Eight encoded bits with a leading start bit, the start sequence, are received at a satellite 211 followed by a two trailing stop bits (logic low). This example shows a non-dominant scheme different from examples employing a dominant scheme wherein a number of encoded bits (for example 4-11 bits) begin with a leading start bit having a logic high to low transition followed by two trailing stop bits of logic high. Thereafter, a pattern of alternating logic ones and zeros, (a sync sequence) in a sync frame, are received at a satellite 211.
FIG. 7 illustrates a block diagram showing digital circuits which may implement the clock recovery scheme according to the clock recovery implementation according to FIG. 6. Clocked data from Master 202 (FIG. 2) may be detected by detector 704 which samples, according to oscillator 702, the clocked data received from master 202. Oscillator 702 is a non-crystal clock oscillator (which may be considered a relatively high speed oscillator) on satellite 211 within XCVR 204 (FIG. 2). A non-crystal oscillator as used herein throughout means an oscillator that does not include a crystal. Crystal oscillators are generally more expensive than oscillators that do not have crystals. Counter 706, which may be in satellite 211, counts the number of high bits in the clocked data according to each high oscillator pulse. The encoded sequence of eight bits are known and an expected number, N, of high pulses corresponds to detection of the 8 encoded bits with a leading high start bit.
FIG. 8 illustrates a corresponding flow chart for the timing diagram of FIG. 6 and the block diagram of FIG. 7. Reference shall now be made to FIGS. 6, 7 and 8. At step 800 data is received. If a pulse is detected at step 802, the counter is incremented at step 804. A decision is made at step 810 as to whether the count is equal to N signifying that the start sequence has been detected. If the answer is no, the phase is shifted for the oscillator by a predetermined amount and more data is received at step 800.
Should the count of detected high bits not equal the expected number, N, then the phase Φ is incremented at step 812 by a known amount by phase shifter 708 (FIG. 7) in XCVR 204 (FIG. 2). Shifting the phase of oscillator 702 causes detector 704 to sample at points shifted in time from the previous sampling times of the clocked data. The sampling rate should be fast enough to accommodate the sampling of the 8 encoded bits sufficient to allow the detection of the requisite number of pulses, N, as time progresses despite shifting the phase of oscillator 702. For the example shown in FIG. 6, should the count of a detected start sequence be determined with high bits equal to the expected number, N, (decision at step 810 being yes, as made by logic circuit(s) 714) then detector 704 is used to detect a sync sequence in connection with counter 706 counting the requisite number, M, of high bit pulses (as determined by logic circuit(s) 714) indicative of detection of the sync sequence matching the known sync frame data. As such, data is received at step 814 and a decision is made as to whether a pulse is detected at step 816. If a pulse is detected, counter 706 is incremented at step 818. Should the requisite number of sync counts not be obtained (as determined at step 820), then the phase Φ is incremented at step 822 by a known incremental amount by phase shifter 708 in XCVR 204 (FIG. 2), shifting the phase of oscillator 702. The phase shifting continues until such time as the period set for shifting the phase expires or becomes equal to the phase necessary to recover the clock from master 202. FIG. 6 shows an oscillator waveform and two additional oscillator waveforms each shifted, respectively, by Φ1 and Φ2. As shown by the Φ2 phase shifted oscillator waveform (the dashed lines which indicate sampling points in time), the Φ2 phase shifted oscillator waveform peaks line up with the three points on a high pulse from the sync frame sequence which follows the two trailing stop bits. M for the example shown in FIG. 6 may be 3.
Once the requisite number of pulses, M, is counted by counter 706, as determined at decision step 820, then the current phase Φ (which in this instance may, for example, be Φ2) is used as the phase shift for the clock signal used on satellite 211 at step 824, thereby recovering the clock signal from and on master 202. This phase shift used for the recovered clock signal is stored in register 716. As shown in step 816, the clock recovery stops at this point and the clock recovery steps are repeated at step 826 in connection with the next message transaction. Assuming a sinusoidal waveform for the clock from master 202, of A*sin(wt), where A is the amplitude (a scalar), t is time (often measured in seconds) and w is the angular frequency (which is often measured in radians per second) the recovered clock signal used on satellite 211 has an equation given by A*sin (wt+Φ) where Φ is the phase. In this example, w at master 202 is known at satellite 211. Clock drift results in a phase offset at satellite 211. For example, should the count equal M, when the value of Φ equals Φ2, then the recovered clock used on satellite 211 may be represented by A*sin (wt+Φ2).
The conditional statements carried out in decision symbols 810 and 816 and 820 may be implemented by digital logic circuits (not shown).
Simplified pseudo code carrying out the foregoing clock recovery scheme follows:
If Pulse detected, then increment counter*Search for start sequence
If pulse detected, increment counter;
Otherwise receive next data;
If sequence count not equal to N, then shift phase;
If not equal, then increment phase of oscillator;
Repeat until timeout or start sequence count equals to N;
If sequence count equals to N, then receive data*Start search for sync frame
If pulse is detected, increment counter;
Otherwise receive data;
If sync count equal to M, set phase for clock
Otherwise, increment phase of oscillator;
Repeat until timeout or sync count equals to M;
The foregoing will allow transmission of data or commands on an expedited basis. For instance, the DEV_ADDR frame may enable a burst mode operation. FIG. 9 illustrates a timing diagram showing frame activity for a normal mode of operation and a burst mode of operation for comparison. Each frame may occur between a start and stop bit (not shown). The burst mode, may be distinguished from the normal mode in that data frames may be transmitted consecutively in an effort to save communication overhead and achieve higher throughput. A longer chain of cyclical redundancy bits is required for such operation. Transferring high speed data offboard from an MCU, such as MCU 208, to a driver 203 is greatly facilitated by the forgoing described burst mode.
The foregoing is compatible with CAN electromagnetic compatibility/electrostatic discharge (EMC/ESD) considerations. Further, it provides an overall cost benefit as compared with a strictly CAN system in that the satellite/slave devices have no crystal clock oscillators. The foregoing architecture and protocol also permits burst-mode and allows error checking. As a further advantage, the foregoing is easily adaptable for use with MCUs using universal asynchronous receiver transmitter (UART) modules.
FIG. 10 illustrates a layout of a wiring arrangement for automobile 100 according to the system and protocol herein. The foregoing may be used with controlling lights, such as automobile front lights, parking lights, back lights, turn signals and stop lights, etc. In contrast with the layout shown in FIG. 1, a lighting system, used with this example greatly reduces the number of wires used for communication down to a 2-wire bus 600, while enabling control and reduced cost as compared with a more wire-intensive system.
The lighting systems referenced herein are particularly pertinent to LED lighting. However, other lighting is contemplated as well. The foregoing protocol is not limited for LED lighting as it may also be used in other automotive applications such as motor drivers, battery management, etc.
The foregoing provides a digital interface for transferring data according to a CAN/LIN protocol which is converted to a FlexLED protocol for use by drivers and slave devices off-chip that may greatly allow increased control (as compared with present systems) of functionality covering such things as tail light, brake light and front and back light operation on an automobile. Such control may allow standard light functionality in addition to animation effects involving LED timing and/or color.
A resulting smaller wiring harness may significantly reduce vehicle weight (as a consequence of using many fewer wires by comparison with those of current methods) and it allows smart control of lighting (via microcontroller) with reporting and diagnostics possible on individual lamps/LEDs.
The foregoing microcontrollers may be programmed according to variety of programming/processing methods to result in sophisticated control of systems, such as lighting, using a 2-wire bus. Such programming will permit monitoring and control of systems and subsystem with increased flexibility. Such programming is contemplated as also being configurable from remote locations, within constraints of security protocols, and readily updatable.
The foregoing has been described herein using specific embodiments for the purposes of illustration only. It will be readily apparent to one of ordinary skill in the art, however, that the principles of the invention can be embodied in other ways. Therefore, the disclosure should not be regarded as being limited in scope to the specific examples disclosed herein, but instead as being fully commensurate in scope with the following claims.
Patent Application
20200042032
