U.S. patent application number 14/288057 was filed with the patent office on 2014-12-04 for method for providing a generic interface and microcontroller having a generic interface.
This patent application is currently assigned to Robert Bosch GmbH. The applicant listed for this patent is Axel AUE, Eugen Becker. Invention is credited to Axel AUE, Eugen Becker.
Application Number | 20140359179 14/288057 |
Document ID | / |
Family ID | 51899338 |
Filed Date | 2014-12-04 |
United States Patent
Application |
20140359179 |
Kind Code |
A1 |
AUE; Axel ; et al. |
December 4, 2014 |
METHOD FOR PROVIDING A GENERIC INTERFACE AND MICROCONTROLLER HAVING
A GENERIC INTERFACE
Abstract
A microcontroller for a control unit, in particular for a
vehicle control unit, includes a central processing unit (CPU), at
least one interface-unspecific input module, at least one
interface-unspecific output module, at least one routing unit and
at least one arithmetic unit for processing interface-specific
information. The microcontroller is configurable in such a way that
the at least one interface-unspecific input module, the at least
one interface-unspecific output module, the at least one routing
unit and the at least one arithmetic unit for processing
interface-specific information fulfill functions corresponding to
one of multiple serial interfaces, in particular of SPI, UART, LIN,
CAN, PSI5, FlexRay, SENT, IC2, MSC or Ethernet.
Inventors: |
AUE; Axel;
(Korntal-Muenchingen, DE) ; Becker; Eugen;
(Ludwigsburg, DE) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
AUE; Axel
Becker; Eugen |
Korntal-Muenchingen
Ludwigsburg |
|
DE
DE |
|
|
Assignee: |
Robert Bosch GmbH
Stuttgart
DE
|
Family ID: |
51899338 |
Appl. No.: |
14/288057 |
Filed: |
May 27, 2014 |
Current U.S.
Class: |
710/106 |
Current CPC
Class: |
G06F 13/42 20130101;
G06F 13/287 20130101 |
Class at
Publication: |
710/106 |
International
Class: |
G06F 13/28 20060101
G06F013/28; G06F 13/42 20060101 G06F013/42 |
Foreign Application Data
Date |
Code |
Application Number |
May 29, 2013 |
DE |
10 2013 210 064.7 |
Claims
1. A method for providing at least one generic interface in a
vehicle control unit having a microcontroller, the method
comprising: receiving input data according to a protocol of the one
of multiple serial interfaces via at least one interface-unspecific
input module; transmitting the input data via a routing unit to at
least one arithmetic unit; extracting, by the at least one
arithmetic unit, first payload data from the input data, in
particular by removing specifics of the protocol from the input
data; making the first payload data available to a central
processing unit (CPU); receiving, by the at least one arithmetic
unit, second payload data of the central processing unit (CPU);
generating, by the at least one arithmetic unit, output data from
the second payload data, in particular by adding specifics of the
protocol to the second payload data; transmitting the output data
via the routing unit to at least one interface-unspecific output
module; and sending the output data corresponding to the protocol
of the one of the multiple serial interfaces via the at least one
interface-unspecific output module; wherein the microcontroller
includes the central processing unit (CPU), the at least one
interface-unspecific input module, the at least one
interface-unspecific output module, the at least one routing unit
and the at least one arithmetic unit for processing
interface-specific information, and wherein the at least one
generic interface is configurable to provide functions
corresponding to one of multiple serial interfaces depending on the
configuration.
2. The method of claim 1, wherein the arithmetic unit has access to
a first memory, and the protocol specifics, in particular
information about one of start bits, stop bits, parity information,
control bits and stuffing bits, are stored in the first memory.
3. The method of claim 2, wherein the protocol specifics are stored
by the central processing unit (CPU) in the first memory.
4. The method of claim 1, wherein the at least one
interface-unspecific input module and the at least one
interface-unspecific output module are fixedly assigned to the one
of the multiple serial interfaces with the aid of the
configuration.
5. The method of claim 1, wherein the arithmetic unit carries out
calculations of higher protocol layers, in particular the
conversions of multiple UART message frames into one LIN message
frame.
6. The method of claim 1, wherein the first payload data are made
available to the central processing unit (CPU) by the arithmetic
unit writing the first payload data into a second memory and the
central processing unit (CPU) being informed about this with the
aid of an interrupt.
7. The method of claim 1, wherein the first payload data are made
available to the central processing unit (CPU) by the arithmetic
unit via direct memory access (DMA).
8. The method of claim 1, wherein the input data are assigned time
information in the at least one interface-unspecific input
module.
9. The method of claim 8, wherein each of the edge changes of the
input data which are present at an input of the microcontroller is
assigned a time stamp in the at least one interface-unspecific
input module.
10. The method of claim 9, wherein the at least one
interface-unspecific input module transmits the input data to the
routing unit by each of the edge changes of the input data having
assigned time stamps being transmitted separately.
11. The method of claim 10, wherein the arithmetic unit determines
a message frame from the edge changes of the input data having
assigned time stamps.
12. The method of claim 1, wherein an entire input message frame of
the input data is stored in the at least one interface-unspecific
input module, and the entire input message frame is made available
to the arithmetic unit.
13. The method of claim 12, wherein the input message frame is
analyzed by the at least one interface-unspecific input module with
the aid of oversampling, and a level of a bit of the message frame
is determined with the aid of voting of bit levels based on level
values of sampling points of the oversampling.
14. The method of claim 13, wherein the input message frame is
assigned a time stamp in the at least one interface-unspecific
input module.
15. The method of claim 1, wherein the arithmetic unit generates
the output data from the second payload data by determining
corresponding edge changes of the output data having assigned time
stamps based on a predefined baud rate.
16. The method of claim 15, wherein the output data are transmitted
to the at least one interface-unspecific output module by each of
the edge changes of the output data having assigned time stamps
being transmitted separately via the routing unit.
17. The method of claim 15, wherein the at least one
interface-unspecific output module compares the assigned time
stamps of each of the edge changes of the output data to time
information and, if they agree, applies the corresponding edge to
an output of the microcontroller.
18. The method of claim 1, wherein the arithmetic unit generates an
entire output message frame from the second payload data as output
data and transmits the same to the at least one
interface-unspecific output module.
19. The method of claim 18, wherein the at least one
interface-unspecific output module transmits the output message
frame when a corresponding trigger is triggered by the arithmetic
unit or by the central processing unit (CPU), or when a time stamp
which is assigned to the output message frame corresponds to time
information of the at least one interface-unspecific output
module.
20. The method of claim 1, wherein a baud rate detection is carried
out for the input data.
21. A microcontroller for a control unit, comprising: a
microcontroller arrangement, including: a central processing unit
(CPU); at least one interface-unspecific input module; at least one
interface-unspecific output module; at least one routing unit; and
at least one arithmetic unit for processing interface-specific
information; wherein the microcontroller arrangement is configured
to provide at least one generic interface in the control unit, by
performing the following: receiving input data according to a
protocol of the one of multiple serial interfaces via at least one
interface-unspecific input module; transmitting the input data via
a routing unit to at least one arithmetic unit; extracting, by the
at least one arithmetic unit, first payload data from the input
data, in particular by removing specifics of the protocol from the
input data; making the first payload data available to a central
processing unit (CPU); receiving, by the at least one arithmetic
unit, second payload data of the central processing unit (CPU);
generating, by the at least one arithmetic unit, output data from
the second payload data, in particular by adding specifics of the
protocol to the second payload data; transmitting the output data
via the routing unit to at least one interface-unspecific output
module; and sending the output data corresponding to the protocol
of the one of the multiple serial interfaces via the at least one
interface-unspecific output module; wherein the at least one
generic interface is configurable to provide functions
corresponding to one of multiple serial interfaces depending on the
configuration.
22. A microcontroller for a vehicle control unit, comprising: a
microncontroller arrangement, including: a central processing unit
(CPU); at least one interface-unspecific input module; at least one
interface-unspecific output module; at least one routing unit; and
at least one arithmetic unit for processing interface-specific
information; wherein the microcontroller arrangement is
configurable so that the at least one interface-unspecific input
module, the at least one interface-unspecific output module, the at
least one routing unit, and the at least one arithmetic unit for
processing interface-specific information fulfill the functions
corresponding to one of multiple serial interfaces depending on the
configuration.
23. The microcontroller of claim 21, wherein the arithmetic unit
includes an arithmetic logic unit (ALU).
24. The microcontroller of claim 21, wherein the
interface-unspecific input module includes a capture functionality
and/or the interface-unspecific output module includes a compare
functionality.
25. The microcontroller of claim 21, further comprising: a first
separate hardware circuit for CRC calculations.
26. The microcontroller of claim 25, further comprising: a second
separate hardware circuit for an arbitration, in particular a CAN
arbitration, or which is connected to a second separate hardware
circuit for an arbitration, in particular a CAN arbitration.
27. The microcontroller of claim 26, wherein the second separate
hardware circuit for the arbitration is configured to carry out an
analysis of whether input data are transmitted according to a CAN
or a CAN-FD protocol.
28. The microcontroller of claim 21, wherein the routing unit
and/or the arithmetic unit operate at a clock of at least 100
MHz.
29. The microcontroller of claim 21, wherein the microcontroller
arrangement is configured to receive input data via the at least
one interface-unspecific input module at an input baud rate of at
least one 1 Mbaud, and to send output data via the at least one
interface-unspecific output module at an output baud rate of at
least 1 Mbaud.
30. The microcontroller of claim 21, further comprising: at least
one interface-specific input module and at least one
interface-specific output module, in addition to the at least one
interface-unspecific input module and the at least one
interface-unspecific output module.
31. The microcontroller of claim 21, further comprising: a timer
module having a timer input module, a timer output module, a timer
routing unit and a timer arithmetic unit.
32. The microcontroller of claim 31, wherein the microcontroller is
configured to carry out timer functions of the timer module using
the at least one interface-unspecific input module, the at least
one interface-unspecific output module, the at least one arithmetic
unit and the routing unit, if these are not required to fulfill the
functions corresponding to one of the multiple serial
interfaces.
33. The microcontroller of claim 21, wherein the routing unit
and/or the arithmetic unit operate at a clock of at least 200
MHz.
34. The microcontroller of claim 21, wherein the multiple serial
interfaces include SPI, UART, LIN, CAN, PSI5, FlexRay, SENT, I2C,
MSC or the Ethernet.
35. A vehicle control unit, comprising: a microcontroller,
including: a central processing unit (CPU); at least one
interface-unspecific input module; at least one
interface-unspecific output module; at least one routing unit; and
at least one arithmetic unit for processing interface-specific
information; wherein the microcontroller is configurable so that
the at least one interface-unspecific input module, the at least
one interface-unspecific output module, the at least one routing
unit, and the at least one arithmetic unit for processing
interface-specific information fulfill the functions corresponding
to one of multiple serial interfaces depending on the
configuration.
36. The method of claim 1, wherein the multiple serial interfaces
include SPI, UART, LIN, CAN, PSI5, FlexRay, SENT, I2C, MSC or the
Ethernet.
37. The microcontroller of claim 22, wherein the multiple serial
interfaces include SPI, UART, LIN, CAN, PSI5, FlexRay, SENT, I2C,
MSC or the Ethernet.
Description
RELATED APPLICATION INFORMATION
[0001] The present application claims priority to and the benefit
of German patent application no. 10 2013 210 064.7, which was filed
in Germany on May 29, 2013, the disclosure of which is incorporated
herein by reference.
FIELD OF THE INVENTION
[0002] The present invention relates to electronic control units,
in particular for controlling functions in a vehicle, which have
interfaces to the outside for communicating with other users of a
communication system.
BACKGROUND INFORMATION
[0003] Control units in a vehicle customarily have serial
interfaces such as SPI, UART, LIN, CAN, PSI5, FlexRay, SENT,
Ethernet, I2C, MSC (Micro Second Channel) and others for connecting
to or communicating with other control units, sensors, actuators or
other peripheral devices. According to the related art, these
serial interfaces are implemented with the aid of a VHDL code in a
microcontroller of the control unit. In terms of hardware,
depending on the interface, e.g., an interface-specific
communication controller, including protocol controller, sample
unit, memory unit and transceiver (transmitter/receiver) must be
implemented for the implementation of a serial interface. A bus
transceiver is not necessary with SENT and SPI, for example.
Interface-specific hardware units (e.g., buffer with SPI, protocol
controller with CAN) make such an implementation additionally
complex and inflexible.
[0004] From WO-2006013212 A1, for example, the implementation of a
FlexRay communication module for coupling a FlexRay communication
link to a user assigned to the FlexRay communication module in a
FlexRay network is known. A microcontroller having a typical
configuration of serial interfaces may be found, for example, in
the document "16/32-Bit Architecture, XC2387C, XC2388C, 16/32-Bit
Single-Chip Microcontroller with 32-Bit Performance, XC2000
Family/High Line, Data Sheet V1.3 2011-07" from Infineon.
[0005] The requirements in regard to the type and number of serial
interfaces in different vehicle applications for a control unit or
for a microcontroller of such a control unit vary greatly. For
example, the requirement in one application may read: one SPI
interface, two LIN interfaces, 5 CAN interfaces. In another more
demanding application, further interfaces such as FlexRay or
Ethernet may additionally be required, or a higher number of
existing interfaces must be present. To address this, a
microcontroller having a very large number of interfaces of
different types may be used; however, this microcontroller would be
over-engineered for a large number of applications, and thus too
expensive. As an alternative, a specific microcontroller having
exactly the desired number of each interface type may be
implemented for each application; however, this is inconsistent
with the desire for standardization and results in high
implementation costs. Both approaches are additionally inflexible
for still unknown future requirements. Overall, the
interface-specific hardware implementation of the serial interfaces
in a microcontroller for a vehicle control unit thus results in
inflexible approaches, which are adaptable to different
requirements only with complexity.
SUMMARY OF THE INVENTION
[0006] The present invention is directed to a method for providing
at least one generic interface, a corresponding microcontroller and
a control unit having such a microcontroller.
[0007] A flexible configuration of a microcontroller includes a
central processing unit (CPU), an interface-unspecific input
module, an interface-unspecific output module, a routing unit, and
an arithmetic unit for processing interface-specific information.
The arithmetic unit may be not identical to the central processing
unit. The described circuit parts of the microcontroller form a
generic interface and are configurable in such a way that,
depending on the configuration, they are able to provide functions
corresponding to one of multiple serial interfaces, in particular
of SPI, UART, LIN, CAN, PSI5, FlexRay, SENT, I2C, MSC or
Ethernet.
[0008] Microcontrollers often must have a broad range of
applications since their configuration and production costs are
high, and it is thus not possible to develop a dedicated
microcontroller for every application. Due to the proposed
provision of generic interfaces in the microcontroller, it is not
necessary when designing the microcontroller to know the number of
each type of interface required in different applications of the
microcontroller. Rather, hardware circuits are provided which,
depending on the configuration, fulfill the tasks of a certain
serial interface.
[0009] In one method for providing generic interfaces by hardware
circuits of a microcontroller, input data are received via an
interface-unspecific input module in a generally separate submethod
for receiving and for processing input data according to a protocol
of the one of multiple serial interfaces and are transmitted via a
routing unit to an arithmetic unit. The arithmetic unit extracts
payload data from the input data, in particular by removing
specifics of the protocol from the input data. The first payload
data are finally made available to the central processing unit
(CPU).
[0010] In one generally separate submethod for processing data and
sending output data, second payload data of the central processing
unit are received by an arithmetic unit. The arithmetic unit
generates output data from the second payload data, in particular
by adding specifics of the protocol to the second payload data. The
output data are transmitted via the routing unit to one of the
interface-unspecific output modules and finally sent via an
interface-unspecific output module corresponding to the protocol of
the one of the multiple serial interfaces.
[0011] This method represents a particularly flexible way of data
processing since no interface-specific hardware units are used. The
data of a large number of protocols of a corresponding large number
of serial interfaces may be received and sent by the
interface-unspecific input and output modules, and the received
data may be evaluated in the arithmetic unit based on protocol
information with the aid of the configuration. This allows the
generic interfaces to be configured corresponding to certain serial
interfaces, depending on the application-specific requirements in
regard to the microcontroller.
[0012] The protocol specifics, in particular information about
start bits, stop bits, parity information, control bits, stuffing
bits or the like, may be stored in a memory, e.g., by the central
processing unit of the microcontroller. The generic interface, in
particular the arithmetic unit used for this purpose, may thus be
configured. The arithmetic unit has access to the memory and is
able to read the protocol information according to the provided
configuration.
[0013] An even broader field of use results for the generic
interfaces when the arithmetic unit is also used for calculations
of higher protocol layers. It may carry out the conversions of
multiple UART message frames into one LIN message frame, for
example.
[0014] The forwarding of payload data from the arithmetic unit to
the central processing unit is implemented the simplest by the
arithmetic unit writing the payload data into a memory to which the
central processing unit has access and accordingly informing the
central processing unit, e.g., with the aid of an interrupt.
[0015] In one more complex variant, however, which relieves the
arithmetic unit and the central processing unit, the arithmetic
unit may make the payload data available to the central processing
unit via direct memory access.
[0016] In the input module, the input data may be assigned time
information, for example, by applying a time stamp to each edge
change at the input of the input module. The edge changes are thus
linked to time information, which allows the input data to be
recorded independently of the protocol of the input data in such a
way that the contained payload data may be extracted with the aid
of the arithmetic unit based on the time information of the edge
changes. For this purpose, the edge changes, including the time
stamp, may each be transmitted from the input module via the
routing unit to the arithmetic unit. The routing unit offers the
advantage that the data transport is fast and reliable even between
multiple input modules, output modules and arithmetic units.
[0017] In one alternative variant, the input module may also store
entire messages and make these available to the arithmetic unit
(which may be via the routing unit). Since here not every edge
change having a time stamp is transmitted separately, the routing
unit is relieved and the transmission is no longer determined as
strongly by the speed and the load of the routing unit.
[0018] In this alternative variant, a piece of time information may
be assigned to the entire message by the input module. This may
once again be used by the arithmetic unit or the central processing
unit (CPU) for classifying or processing the input data.
[0019] In addition, particularly reliable detection of the content
of the input data by the input module may take place if this
content is analyzed by oversampling and a bit level for each bit of
the input data is determined from the level values of the sampling
points with the aid of majority voting.
[0020] In one method for outputting data which is analog for time
stamping of the edge changes in the input module, the arithmetic
unit processes payload data from the central processing unit by
converting these into edge changes having assigned time stamps. For
this purpose, the arithmetic unit must know the corresponding baud
rate for the intervals of the edge changes with which the output
data are to be output, i.e., the data transmission rate at output.
Each edge change having a time stamp is transmitted separately via
a routing unit to an output module. With the aid of a comparison to
time information, each edge change is applied to the output there
at the desired time. This allows a flexible and
protocol-independent data output using an interface-unspecific
output module.
[0021] As an alternative, it is also possible for an entire message
frame instead of individual edge changes having time stamps to be
made available by the arithmetic unit to the output module during
output. The entire message frame is then output, for example, with
the aid of a trigger by the arithmetic unit or the central
processing unit (CPU) or when a time stamp of the entire message
frame agrees with a piece of time information in the output module.
This relieves the routing unit, and the transmission speed is
limited less by the load and speed of the routing unit.
[0022] The arithmetic unit includes an arithmetic logic unit, for
example; it may be implemented as a multi channel sequencer.
[0023] A microcontroller, in which the interface-unspecific input
module has a capture functionality and/or the interface-unspecific
output module has a compare functionality, may provide generic
interfaces in a particularly flexible and easily implementable way.
A considerably higher flexibility of the microcontroller may be
achieved using fewer resources.
[0024] The options for use of the microcontroller may be expanded
by additional separate hardware circuits, for example for CRC
calculations or calculations as part of a bus arbitration (for
example, with CAN), which either form an integral part of the
microcontroller or are connected to the same. Such hardware units
which are optimized for a certain function relieve the less
specialized remaining modules, in particular the arithmetic unit of
the microcontroller. Some calculations and thus applications of the
microcontroller are only possible at the required reliability and
speed when using such additional units.
[0025] For the generic interfaces to provide the serial interfaces
in each case in a scope as they are common in many applications, in
particular in the automotive field, the routing unit and/or the
arithmetic unit should be operated at a clock of at least 100 MHz,
in particular at a clock of at least 200 MHz, and thus it should be
possible to receive input data at an input baud rate of at least 1
Mbaud and to send output data at an output baud rate of at least 1
Mbaud.
[0026] Very flexible use, while nonetheless being particularly
inexpensive, is provided by a microcontroller which includes both
specific serial interfaces implemented in hardware and generic
interfaces having interface-unspecific hardware, which may be
configured to provide additionally desired serial interfaces with
the aid of software calculations. For the known applications of the
microcontroller, a certain intersection of interfaces between the
applications may thus be fixedly implemented, while different
interface requirements between the applications or still unknown
interface requirements are covered by generic interfaces.
[0027] Hardware circuits may be combined with one or multiple timer
modules to provide generic interfaces in a microcontroller. The
interface hardware and a timer module may also flexibly support
each other in tasks if corresponding capacities are available in
one of the hardware blocks.
[0028] The described microcontrollers are usable particularly well
in control units, in particular in the automotive field. Here, the
requirements in regard to interfaces are particularly high, while
cost objectives are strict at the same time.
[0029] The present invention is described in greater detail
hereafter with reference to the accompanying drawings and based on
exemplary embodiments.
BRIEF DESCRIPTION OF THE DRAWINGS
[0030] FIG. 1 schematically shows an exemplary microcontroller
including hardware circuits for providing generic interfaces.
[0031] FIG. 2 schematically shows an exemplary microcontroller
including hardware circuits for providing generic interfaces and a
timer module.
[0032] FIG. 3 schematically shows an exemplary microcontroller
including hardware circuits for providing generic interfaces and a
special hardware circuit for CRC calculations.
[0033] FIG. 4 schematically shows an exemplary microcontroller
including hardware circuits for providing generic interfaces and a
special output module.
[0034] FIG. 5 schematically shows an exemplary microcontroller
including hardware circuits for providing generic interfaces and a
special input module and an additional memory.
[0035] FIG. 6 schematically shows an exemplary microcontroller
including hardware circuits for providing generic interfaces and a
circuit for supporting arbitration.
[0036] FIG. 7 schematically shows two exemplary signal
characteristics including edge changes for explaining a CAN
arbitration.
[0037] FIG. 8 schematically shows the exemplary sequence of a
method for receiving data via a generic interface.
[0038] FIG. 9 schematically shows the exemplary sequence of a
method for sending data via a generic interface.
[0039] FIG. 10 schematically shows the exemplary sequence of a
method for baud rate detection.
[0040] FIG. 11 schematically shows the exemplary sequence of a data
transmission with CRC calculation by a separate CRC unit.
DETAILED DESCRIPTION
[0041] The term "serial interface" hereafter shall be understood to
mean a connection for the serial data exchange between devices.
Serial data transmission denotes a data transmission in which the
bits are consecutively transmitted via one line or multiple lines.
Serial interfaces used in vehicles include SPI, UART, LIN, CAN,
PSI5, FlexRay, SENT, I2C, MSC and Ethernet, for example.
[0042] The "Generic Timer Module (GTM)" is known as the timer
module from WO-2011120823 A1. Hardware submodules are situated in
this timer module around a central routing unit (referred to as
"Advanced Routing Unit (ARU)"). The central routing unit routes
data between the different hardware submodules; in this process, a
"round robin" scheduling may be used for deterministic arbitration.
This means that source modules are operated within a maximum round
trip time and their data are routed via address information to the
corresponding destination modules. The timer module is thus able to
reduce the interrupt load of the CPU of a microcontroller, e.g., in
microcontrollers for electronic control units (ECU) which are used
to control functions in vehicles. Some of the hardware submodules
that the timer module has include input modules, the so-called
"Timer Input Modules (TIM)," and output modules, the so-called
"Timer Output Modules (TOM)" or also "ARU-connected Timer Output
Modules (ATOM)." In addition to the routing unit (ARU), the input
modules (TIM) and the output modules (TOM, ATOM), the timer module
also has a multi channel sequencer as an arithmetic unit.
[0043] The timer module resorts to the basic "capture/compare"
principle. Signals having time stamps arriving in the input units
(TIM) are concatenated according to their arrival. The input unit
(TIM) receives the corresponding time information from a time base
unit (TBU), for example. This functionality of the time stamp
corresponds to the "capture" of the "capture/compare." The time
information is used by the arithmetic unit or the central
processing unit for processing and prioritizing the signals.
Signals which are to be sent via the output units (TOM, ATOM) of
the timer module are also provided with time stamps, e.g., by the
processing arithmetic units (CPU, MCS). The time stamps of the
signals are compared to instantaneous time information in the
output module (ATOM) of the timer module. The output module
receives this information also from a time base unit, for example.
If the time stamp of the signal to be output corresponds to the
present time, the signal is sent. This functionality corresponds to
the "compare" of the "capture/compare." Instead of the described
time base, it is also possible to implement angular synchronous
"capture/compare" functions with the aid of the input and output
units. These may be required in the vehicle since the angular
position of a receiving or sending process relative to the
instantaneous engine angle is of particular importance. For
example, the input unit may provide incoming signals with angle
stamps, and outgoing messages may be sent at certain angle
points.
[0044] The arithmetic unit or data processing unit "Multi Channel
Sequencer (MCS)" may be implemented as a submodule having pipeline
stages, an arithmetic logic unit (ALU), decoders and a link to RAM
memory units. It is also possible to use multiple multi channel
sequencers in a timer module. The input units may be implemented as
a hardware component having latches and flip flops and a link to a
time- and/or angle-sensing unit. The output units may be
implemented as a hardware component having latches and flip flops,
which form a register, for example, and a link to a time- and/or
angle-sensing unit. The time basis for time-dependent functions may
be derived from the processor clock of the microcontroller (or its
central processing unit (CPU)); the angle basis for angle-dependent
functions may be implemented via a digital phase-locked loop
(DPLL).
[0045] Reference is made to WO-2011120823 A1 regarding the further
operating mode of the timer module, in particular of the described
components ARU, MCS, TIM, ATOM, TBU of the timer module. The
corresponding passages of the description of WO-2011120823 A1 are
hereby incorporated by reference into the present application.
[0046] Based on the functionality of the known timer module, one
central aspect of the present invention is to provide generic
serial interfaces in a microcontroller, in particular for use in
vehicle control units. For this purpose, either units of a
corresponding timer module which is already integrated into the
microcontroller may be reconfigured, or units may be integrated
into the microcontroller specifically for this use. For example,
"capture" and/or "compare" functionalities of input units (TIM)
and/or output units (TOM, ATOM) may be resorted to for generically
emulating specific interface inputs and outputs. The input and
output units are supported by an arithmetic unit, such as a multi
channel sequencer (MCS) which carries out calculations for
providing an interface. A routing unit may be used to distribute
data between the input modules, output modules and the arithmetic
unit. The modules described hereafter, i.e. input module, output
module, routing unit and arithmetic unit, which may be have the
functionalities of the corresponding units TIM, A(TOM), ARU and MCS
which are described above with regard to the "GTM" timer module.
However, the hardware circuit for the provision of generic
interfaces or the microcontroller having this hardware circuit
differs from the known timer module due to the different
requirements (e.g., speed of the routing and of the processing).
Using the above-described functions of the timer submodules, it may
be also possible to carry out changes in the hardware of the
microcontroller; however, at least the corresponding timer hardware
components must be adapted to the changed tasks and requirements
with the aid of configuration to be usable according to the present
invention.
[0047] FIG. 1 schematically shows a circuit configuration for
providing a generic, serial interface in a microcontroller.
[0048] Microcontroller 101 includes a group of hardware circuits
110, which configurably provide the functions of a certain serial
interface. Hardware components 110 include an input module 111
which is connected to an input data channel 102. Input data channel
102 is typically a wired communication link. Input module 111 is
connected to a routing unit 112. In addition to input module 111,
routing unit 112 is also connected to an arithmetic unit 113 and an
output module 114. Output module 114 is connected to an output data
channel 103. Output data channel 103 is typically also a wired
communication link. Input data channel 103 and output data channel
104 form part of a communication system using a certain protocol,
so that interface-unspecific hardware components 111, 112, 113, 114
must be configured in such a way that they provide the functions of
the corresponding interface which is able to process data of this
particular protocol. For example, input data channel 102 may be an
Rx input of a UART interface and output data channel 103 may be a
Tx output of a UART interface. Hardware components 111, 112, 113,
114 must be configured in this example in such a way that they
emulate a UART interface.
[0049] Input module 111 and output module 114 are
interface-unspecific hardware circuits, i.e., they are able to
process data from many different serial interfaces, composed
according to different protocol structures. Arithmetic unit 113
must be distinguished from the central processing unit (CPU) of the
microcontroller and is referred to hereafter as MCS for
distinction, since the arithmetic unit (MCS) in one specific
embodiment of the microcontroller is a multi channel sequencer.
Other hardware implementations of the arithmetic unit (MCS) are
also possible, which may be also having an arithmetic logic unit
(ALU).
[0050] Routing unit 112 connects input module 111, output module
114 and arithmetic unit (MCS) 113 in a time division multiplex
manner.
[0051] FIG. 1 shows a highly simplified illustration of
microcontroller 101. Such a microcontroller 101 of course has many
other components which are not shown here, among other things at
least one central processing unit (CPU), which is able to carry out
data processing operations, calculations and configurations in the
microcontroller. In addition, microcontroller 101 may include
multiple such input modules 111 and output modules 114. Depending
on the application, it may also include multiple arithmetic units
(MCS) 113. Many such modules 111, 113, 114 may be connected to a
single routing unit 112. It is also possible to use multiple
routing units 112 in such a microcontroller 101 for very complex
applications.
[0052] In one particular variant of the present microcontroller,
the same has a number of "genuine" serial interfaces, which are
implemented fixedly in hardware according to the related art, and a
number of "generic" interfaces in the form of hardware circuits as
described for FIG. 1. In this way, it may be possible to
advantageously implement the minimum number of required interfaces
of one particular interface type fixedly in hardware as in the
past, while the interfaces which differ among different
applications of the microcontroller may be provided as generic
interfaces and may thus be configured corresponding to the
particular use in software. A flexible use of the microcontroller
is thus possible at a reduced number of interfaces which must be
made available.
[0053] FIG. 8 schematically shows the sequence of a method for
providing a generic interface for receiving messages.
[0054] In a first step 801, an input module (e.g., 111 in FIG. 1)
of a microcontroller receives digital data from outside the
microcontroller as bits. An input signal is present at the input
module. This signal is present in a protocol corresponding to the
serial interface to be emulated. The edge changes between the bits
of the received data are each provided with time stamps in the
input module in step 802 (capture functionality). For this purpose,
the time stamps at which the pin state, i.e., the edge, changes at
the input of the input module are detected in the input module. The
input module may obtain the necessary time information for the time
stamp from a time base unit, for example. The data thus ascertained
are transmitted in step 803 from the input module to a routing unit
(e.g., 112 in FIG. 1) of the microcontroller. For this purpose, the
edge change during a change of the pin state is transmitted
together with the time stamp at which the other edge took effect.
The routing unit once again transmits the information in step 804
to an arithmetic unit (MCS, e.g., 113 in FIG. 1) of the
microcontroller.
[0055] In step 805, the arithmetic unit (MCS) processes the
information which it receives in the form of multiple separate
transmissions from the routing unit in accordance with the multiple
capture events in the input module. In the process, the arithmetic
unit (MCS) reconstructs the received signal from the received bit
stream (i.e., the time-stamped edge changes). The arithmetic unit
(MCS) moreover checks this signal and removes control bits (e.g.,
start bit(s), stop bit(s), parity bit(s), stuffing bit(s))
according to the present protocol. The arithmetic unit (MCS) may
receive the information for this processing (i.e., the information
about which protocol is involved or how the messages of this
protocol are structured) from a local volatile memory to which the
unit has access. The information is transmittable to there, for
example, from a non-volatile memory (e.g., flash memory) by a
central processing unit (CPU) of the microcontroller. When the
microcontroller is started, the input module and the output module
to which information is still written may be fixedly assigned to a
certain message protocol by the central processing unit (CPU), and
the information in this regard as well as the corresponding
protocol information are stored to a volatile memory accessibly for
the arithmetic unit (MCS).
[0056] In an optional step 806, the arithmetic unit (MCS) may carry
out further processing steps and calculations, such as the
calculation of higher protocol layers. For example, multiple UART
frames may be converted into one LIN frame, or various signal
calculations may be carried out.
[0057] The arithmetic unit (MCS) makes the processed information
available to a central processing unit (CPU) of the microcontroller
in step 807. The information may be stored in a memory (e.g., a
RAM) and the central processing unit (CPU) is informed about this
(e.g., with the aid of an interrupt or by triggering a DMA
channel). In addition to the payload data, the message may include
additional information, for example, such as an identifier in the
case of a CAN message.
[0058] In step 808, the central processing unit (CPU) finally
processes the received information.
[0059] FIG. 9 schematically shows the sequence of a method for
providing a generic interface for sending messages.
[0060] In step 901, a central processing unit (CPU) of a
microcontroller makes a signal (if necessary, having an identifier)
available to an arithmetic unit (MCS, e.g., 113 in FIG. 1). The
arithmetic unit (MCS) processes the signal in step 901. A sequence
of edge changes is calculated from the bits of the digital signal,
and the edge changes are provided with time information. For the
correct time intervals between the edge changes, the arithmetic
unit (MCS) requires the information about the baud rate to be used.
Moreover, protocol information corresponding to the protocol to be
used is added, for example, control bits such as start bit(s), stop
bit(s), parity bit(s), and stuffing bit(s). The arithmetic unit
(MCS) once again receive the information for this processing (i.e.,
the information about which protocol is involved or how the
messages of this protocol are structured) from a local volatile
memory to which the unit has access. The information is
transmittable to there, for example, from a non-volatile memory
(e.g., flash memory) by a central processing unit (CPU) of the
microcontroller.
[0061] The data thus obtained are forwarded by the arithmetic unit
(MCS) to a routing unit (e.g., 112 in FIG. 1) in step 902. In
subsequent step 903, the data are routed from the routing unit to a
predefined output unit (e.g., 114 in FIG. 1).
[0062] The output unit thus receives the data to be sent in the
form of edge changes, including information about the points in
time at which the edge changes are to be applied to which edge at
the output, and thus the desired message is sent. For this purpose,
the output unit compares the received time information to available
time information (compare functionality) in step 904. The time
information may be made available by a time base unit, for example.
If the time information agrees with the point in time assigned to
the subsequent edge change, the output unit finally applies the
edge change to the output and thus sends the desired data in the
form of a bit stream at the predefined baud rate and in the message
protocol corresponding to the serial interface which is to be
emulated. The transmission from the arithmetic unit (MCS) via the
routing unit to the output module in this embodiment variant takes
place separately for each edge change, including the time
information. The output module may be configured in such a way that
it is only ready to receive another edge change, including the time
information, when the previously received edge change has been sent
or applied to the output in accordance with the time
information.
[0063] Different configurations are possible for the hardware
implementation of the generic serial interfaces. On the one hand, a
microcontroller may have a timer module such as the above-described
"Generic Timer Module" and may additionally include hardware
circuits such as those described for FIG. 1. In such a
configuration, the timer module is able to fulfill the assigned
tasks without consideration of interfaces to be provided. The
interface functionality is provided by the additional hardware
circuits of the microcontroller. In such a configuration, timer
functions may be transmittable to the additional hardware circuits
with the aid of the configuration, provided that these circuits are
not fully utilized by the interface functionalities, in particular
provided that the corresponding input and output modules are not
assigned to any interface function. In one special variant, the
timer module (or its hardware units) may also assume the interface
functionality of the additional hardware circuits, provided that
the module has sufficient free capacity and a sufficient hardware
configuration for this purpose and is configured for this.
[0064] Such a hardware configuration is shown in FIG. 2. Here,
microcontroller 201 has a hardware circuit 210, which corresponds
to hardware circuit 110 of FIG. 1 (input data channel 202, output
data channel 203, input module 211, output module 214, routing unit
212, arithmetic unit (MCS) 213). In addition, microcontroller 201
has a timer module 230, which includes a timer input module 231, a
timer output module 234, a routing unit 232 and an arithmetic unit
(MCS) 233. Timer input module 231 is connected to signal input 222
and to routing unit 232. Timer output module 234 is connected to
signal output 223 and to routing unit 232. Routing unit 232 is
additionally connected to arithmetic unit (MCS) 233.
[0065] For example, timer module 230 may be implemented by the
above-described "Generic Timer Module."
[0066] In one additional variant, hardware units such as those
described for FIG. 1 may assume both the timer and the interface
functionality. Compared to the above-described Generic Timer
Module, such a hardware unit may have one routing unit or routing
units which is/are operated at a higher frequency, as well as fewer
modules per routing unit in order to increase the service rate and
be able to provide higher baud rates, as they are required for the
provisions of generic serial interfaces. For example, the routing
unit and the arithmetic unit (MCS) could be operated at frequencies
starting at 100 MHz, which may be starting at 200 MHz, instead of
at 80 MHz. The frequencies of the routing unit and of the
arithmetic unit (MCS) may be configured in such a way that
interfaces having 1 Mbaud or higher are providable.
[0067] The flexibility increases in both variants due to the
possible shift between interface functionality and timer
functionality. For example, the timer functions for controlling
eight cylinders of an engine may be provided in one application in
a control unit having the microcontroller utilizing a combined
timer/interface module having 16 output modules. For this purpose,
for example, eight output modules having a compare functionality
are used to control the ignition, and eight output modules having a
compare functionality are used to control the injection of one
cylinder in each case. If the microcontroller having a combined
timer/interface module is used in another application for
controlling an engine having four cylinders, eight of the
just-described 16 output modules are not required for the timer
functions of controlling the cylinders and are thus available, for
example to emulate the output signals of eight serial
interfaces.
[0068] Depending on the type of serial interfaces to be emulated,
further hardware components may be required in addition to the
afore-described modules and units.
[0069] For example, CRC calculations must also be carried out for
certain protocols, such as for PSIS or CAN. During the cyclic
redundancy check (CRC), a check value is ascertained for data, and
this check value is verified after transmission based on the
transmitted data in order to detect transmission or storage errors.
The implemented arithmetic unit (MCS) is not optimal for this type
of calculations and would have to be equipped with higher computing
power, if necessary. In the case of a hardware circuit having
multiple arithmetic units (MCS), each of these arithmetic units
(MCS) would be given the added load of these additional
calculations. Moreover, the CRC calculations must be carried out
very quickly with some protocols to be able to trigger actions in
the protocol, if necessary, such as error message frames.
[0070] For space and performance reasons, it is therefore
advantageous to carry out the CRC calculations in a dedicated
module. In one embodiment of the above-described hardware circuits
for emulating serial interfaces, these additionally include a
separate unit for calculating CRC information. In the case of a
hardware circuit having multiple arithmetic units (MCS), this CRC
checking unit may carry out the calculations centrally for multiple
or all these arithmetic units (MCS).
[0071] The additional CRC unit is able to make the CRC calculations
and CRC comparisons quickly enough even for protocols having high
requirements in regard to speed. The CRC unit may carry out at
least the calculation of CRC check values, and if necessary also
verifies CRC check values. Should a CRC check value be detected as
not being correct by the CRC unit, a new transmission may be
initiated by the arithmetic unit (MCS).
[0072] The CRC checking unit may be implemented as a hardware logic
circuit; for example, it may include an XOR gate and a shift
register for this purpose. An alternative to this would be an
implementation in software with calculation by one (e.g., small
additional) arithmetic unit.
[0073] FIG. 3 shows a hardware circuit having such an additional
CRC unit. Microcontroller 301 including hardware modules 310, i.e.,
input module 311, routing unit 312, arithmetic unit (MCS) 313 and
output module 314, largely corresponds to microcontroller 101 in
FIG. 1. Data input channel 302 and data output channel 303 are
connected in each case to input module 311 and output module 314.
In addition to microcontroller 101 of FIG. 1, microcontroller 301
also includes CRC unit 315, which in the embodiment shown is
connected to routing unit 312.
[0074] The calculation of a CRC value may be based on polynomial
long division. The CRC unit should therefore be configurable via
parameters at least for starting the microcontroller, so that
different polynomials are providable. For example, a polynomial
b7*x.sup.7+b6*x.sup.6+b5*x.sup.5+b4*x.sup.4+b3*x.sup.3+b2*x.sup.2+b1*x.su-
p.1+b0*x.sup.0 may be configured using the configuration parameters
b0 through b7. To be able to support different interfaces with
different CRC polynomials, it must be possible either to flexibly
(i.e., with regard to the propagation time) reconfigure a CRC unit
or multiple CRC units must be provided.
[0075] The sequence of a data transmission including CRC
calculation by a separate CRC unit is shown in FIG. 11. Here, the
example of a calculation of a CRC value from received data is
described.
[0076] In a first step 1101, the CRC unit is configured by the
arithmetic unit (MCS) or the central processing unit (CPU) of the
microcontroller. This is necessary since customarily a different
polynomial must be calculated for each interface. As described
above, the polynomials may be determined using configuration
parameters. In a CRC module which is used for the CRC calculations
of multiple generic serial interfaces, such a configuration is
therefore required prior to each calculation, unless two
consecutive calculations are to be carried out for the same
interface. This configuration of the CRC unit may also take place,
for example, by the CRC unit having access to a table including
different polynomials, being transmitted an index corresponding to
an entry in this table, and using the polynomial according to this
entry.
[0077] In second step 1102, the CRC module receives the data for
which a CRC calculation is to be carried out. For example, the data
are input data having CRC information received by the input module
and transmitted to the arithmetic unit (MCS). The CRC calculations
are carried out in the CRC unit in third step 1103. In fourth step
1104, results of the CRC calculations (CRC check value calculation
and, if necessary, verification) are sent from the CRC module to
the arithmetic unit (MCS) (CRC check value and/or result of the CRC
verification). The transmission of these data from the arithmetic
unit (MCS) to the CRC unit and from the CRC unit to the arithmetic
unit (MCS) in each case may be carried out via the routing
unit.
[0078] Finally, in fifth step 1105, the arithmetic unit (MCS) may
compare the CRC information calculated by the CRC unit to the
received CRC information and the result of the CRC verification may
be evaluated by the CRC unit, and in the case of a deviation, it
may thus establish that a transmission or memory error exists.
[0079] In an optional sixth step 1106, the arithmetic unit (MCS)
may trigger a new transmission if the arithmetic unit (MCS)
established a transmission or memory error.
[0080] The CRC calculation for the data to be sent takes place
analogously. Data are sent from the arithmetic unit (MCS) via the
routing unit to the CRC unit, which may be after configuration of
the CRC unit. A CRC calculation is carried out there, and the
result is transmitted from the CRC unit via the routing unit to the
arithmetic unit (MCS). There, the CRC value is added to the data,
and the data are made available to the output module.
[0081] According to the basic configuration (FIG. 1), the exemplary
embodiments described so far are based on the assumption that the
hardware circuit for providing generic, serial interfaces uses an
input module having a capture functionality and an output module
having a compare functionality. In another embodiment variant,
however, a deviating output module without a compare functionality
may also be used. Such a special module for outputting interface
frames thus deviates from the above-described output modules (TOM,
ATOM) of the hardware circuit and of the timer module.
[0082] The hardware implementation of such an output hardware
module may take place with the aid of a state machine in
combination with a memory, for example. Instead of the bit stream
to be received and to be sent, as described above, the special
output module may store an entire message frame in its memory. The
routing unit is thus able to send the entire message to the output
module using one sending operation. The higher hardware
requirements in regard to the output unit thus relieve the routing
unit. In addition, it is easier to achieve higher baud rates for
the output of data when using such an output unit, since this unit
is no longer limited by the clocking of the routing unit. In one
specific embodiment, the output unit must once again have time
information (or corresponding angle information) available.
Contrary to the above-described output unit, this output unit only
requires the information at which point in time (or at which angle)
and at which baud rate the entire message or the entire message
frame must be sent. The data are then sent based on the available
time or angle information and the baud rate which is known to the
output module. The data from the arithmetic unit (MCS) or from the
central processing unit (CPU) of the microcontroller may be written
directly into the memory of the output unit. The output unit
receives the signal (datum) as well as information about the data
rate and the sending point in time.
[0083] As an alternative, instead of via time information, the
sending process to the special output unit may also be initiated by
a concrete trigger of the arithmetic unit (MCS) or of the central
processing unit (CPU) of the microcontroller. The output unit then
independently applies the data to the output pin.
[0084] FIG. 4 shows a microcontroller having a special output
module 414. Microcontroller 401 including hardware components 410,
i.e., input module 411, routing unit 412, arithmetic unit (MCS) 413
and output module 414, as well as the links to input data channel
402 and output data channel 403, once again largely corresponds to
microcontroller 101 of FIG. 1. However, output module 414 has an
increased functionality, such as memory resources for storing a
complete message frame. In the shown specific embodiment, output
module 414 additionally has a further link to microcontroller 401.
Via this link, for example, data may be made available to output
module 414 by the central processing unit (CPU) of microcontroller
401, such as by the above-described direct writing of the output
data into the memory of output module 414 by the central processing
unit (CPU).
[0085] The sequence of a data output with the aid of such a special
output unit is described hereafter based on one exemplary
transmission via a generic interface having a UART configuration:
[0086] 1. The central processing unit (CPU) of the microcontroller
or the arithmetic unit (MCS) writes the message frame 01111111111
into a memory of the output unit. This corresponds to one start bit
(0), 8 data bits (11111111), one parity bit (1, in the case of odd
parity), and one stop bit (1). [0087] 2. The central processing
unit (CPU) of the microcontroller or the arithmetic unit (MCS)
writes the data rate of the message frame to be output into a
register of the output unit. [0088] 3. The central processing unit
(CPU) of the microcontroller or the arithmetic unit (MCS) sends a
trigger to the output unit in order to start the transmission. In
one further variant, the transmission starts after receipt of the
message frame after a predefined number of transmission processes.
In one further variant, the central processing unit (CPU) of the
microcontroller or the arithmetic unit (MCS) transmits a point in
time at which the transmission is to take place or start. [0089] 4.
The output unit independently outputs the message frame at the
selected data rate.
[0090] In the described exemplary embodiments having a special
output unit, an additional load is applied to the arithmetic unit
(MCS) or the central processing unit (CPU), such as by writing of
the information into the output unit and triggering of the sending
process. In one further advantageous embodiment variant, the output
unit thus receives the data or message frames to be sent by
automatic reloading from a memory. For example, such automatic
reloading may take place from a RAM to which the output unit has
access via linked lists and direct memory access (DMA). It is thus
also possible to output larger data packets at high speeds without
loading (interrupts) of the arithmetic unit (MCS) or central
processing unit (CPU) of the microcontroller.
[0091] In the described exemplary embodiments having the special
output unit, it is initially assumed that the remaining method
steps (data reception by the input module, routing by the routing
unit, protocol calculation by the arithmetic unit (MCS), if
necessary CRC calculation by the CRC unit) still take place as
described above, and that the remaining hardware circuit (input
module, routing unit, arithmetic unit (MCS), if necessary CRC unit)
is still composed as described above.
[0092] Analogously to the just described replacement of the output
module having a compare functionality with a special output unit,
in one further exemplary embodiment it is also possible to modify
the basic configuration (FIG. 1) by replacing the input module
having a capture functionality with a special input unit.
[0093] In this specific embodiment, such a special input module
need not resolve the input bit stream edge by edge as described
above, i.e., continue to transmit each edge change with time stamp
via the routing unit to the arithmetic unit (MCS). Rather, the
special input unit would receive (i.e., store) and filter an entire
bit stream. Oversampling may be used as filtering. Oversampling in
combination with voting, for example, allows the received bits
having high levels and the received bits having low levels to be
separated or distinguished more reliably from each other.
[0094] The input filter of the special input module is
programmable, for example, in such a way that it samples a 1 MHz
signal at 16 MHz. The 16 samplings per bit are then routed via a
voting instance which stores a 1 or 0 as the bit state according to
predefined settings (e.g., 3 out of 16 or 12 out of 16). As a
result of such a special input module, in which oversampling and
voting are implemented, it is also possible to implement interfaces
having higher requirements in regard to interference
resistance.
[0095] Due to the synchronization with a trigger event, such as a
start bit in the case of UART, the special input unit may be
brought into a defined state in relation to the bit stream. When
all bits are read in (e.g., UART: start bit, 8 data bits, parity
bit, stop bit), these data are transmitted from the output of the
special input module via the routing unit to the arithmetic unit
(MCS), which then compiles higher protocol layers (e.g., KWP2000,
LIN), for example, or writes the data directly into a FIFO memory
from which the application software is able to retrieve the data.
It is no longer necessary for the arithmetic unit (MCS) to
reconstruct the messages by an evaluation of the time-stamped edge
change messages on the part of the routing unit. The arithmetic
unit (MCS), in contrast, receives the data of one message frame as
a message from the routing unit instead of the edge changes being
transmitted as a separate transmission in each case. The routing
unit is thereby relieved from having to carry out many individual
transmissions. The speed of processing incoming data is no longer
highly dependent as before on the speed of the routing unit. In
addition to relieving the routing unit and arithmetic unit (MCS),
it is possible to process incoming data at a faster data rate.
[0096] In addition to the filtered bit levels, i.e., determined to
be correct after oversampling and voting, the information as to
whether and how much interference on the bits occurred, i.e., how
clear the voting was, for example, may be forwarded (e.g., to the
arithmetic unit (MCS) or the central processing unit (CPU) of the
microcontroller). For example, it may be transmitted how many
sampled values of one bit have the same level. To make the voting
more robust, it is also possible, for example, to mask out the
points (samplings) directly before and directly after an edge
change in order to make the voting, i.e., the bit detection, more
robust.
[0097] To improve the bit detection for the described hardware
circuits having the special input module, which carries out
oversampling and voting, it is also possible to use an ascertained
baud rate for the voting (such a baud rate detection is described
in greater detail below).
[0098] In one alternative variant of the specific embodiment having
the special input module, a direct transmission takes place from
the special input module into a memory, such as a FIFO memory, to
which the arithmetic unit (MCS) or the central processing unit
(CPU) of the microcontroller has access. As an alternative, the
arithmetic unit (MCS) or the central processing unit (CPU) could
also have direct access to the memory of the special input
module.
[0099] In one extension of the introduced exemplary embodiments
having the special input unit, this unit may issue a time stamp per
bit stream or per message frame (this, once again, requires access
to a piece of time information).
[0100] This time stamp may be used by the arithmetic unit (MCS) or
the central processing unit (CPU) of the microcontroller for
processing or evaluating the message frame.
[0101] As in the case of the special output unit, the special input
unit is associated with higher costs; the discussed advantages thus
must be weighed against the cost disadvantage to select the
appropriate specific embodiment.
[0102] In the described exemplary embodiments having the special
input unit, it is initially assumed that the remaining method steps
(data output by the output module, routing by the routing unit,
protocol calculation by the arithmetic unit (MCS), if necessary CRC
calculation by the CRC unit) still take place as described above,
and that the remaining hardware circuit (output module, routing
unit, arithmetic unit (MCS), if necessary CRC unit) is still
composed as described above. However, in one embodiment variant of
a particularly efficient hardware circuit for providing generic
serial interfaces, this circuit includes both a special input
module as just described having a filter functionality and a
special output module as described above.
[0103] A hardware circuit for providing generic serial interfaces
having a special input unit is schematically shown in FIG. 5.
Microcontroller 501 including hardware components 510, i.e., input
module 511, routing unit 512, arithmetic unit (MCS) 513 and output
module 514, as well as the links to data input channel 502 and data
output channel 503, once again largely corresponds to
microcontroller 101 of FIG. 1. However, deviating from this,
special input module 511 is a hardware unit having circuits for
providing a filter functionality, in particular an oversampling of
received bits and a voting, in which based on the sampled level
values at the sampling points of a bit the level value for this bit
is established using majority voting. In contrast to the input
module which is described for FIG. 1, special input module 511 must
include a memory having a sufficient size for storing an entire bit
stream or an entire received message frame.
[0104] Compared to FIG. 1, FIG. 5 additionally shows a memory 516,
such as a FIFO memory. At least input module 511 has access to this
FIFO memory. Corresponding to one of the above-described variants,
a direct transmission takes place from special input module 511
into memory 516 to which the central processing unit (CPU) of the
microcontroller has access, as is indicated in FIG. 5 by the shown
link from memory 516 to microcontroller 501.
[0105] In one further variant of the hardware circuit for providing
generic serial interfaces, the above-described specific embodiments
additionally include a further hardware component, which is used
for message arbitration. The component assumes time-critical
functions for which the remaining circuit parts are not optimally
usable due to their structure and clock frequency.
[0106] This may be a component which is used to support a CAN
arbitration. For the CAN arbitration, it must be detected within an
internal processing time (IPT) of a few nanoseconds at an
accordingly high data rate that a dominant level is present on the
bus. With a dominant level on the bus, the interface is not allowed
to drive a dominant level for the next bit (in the next clock
section) if a recessive bit exists in the present bit (in the
present clock section) in the interface. In this case, the
interface (and thus the corresponding CAN node) is withdrawn from
the arbitration since another CAN node has a message of higher
priority (i.e., having an earlier dominant level). The hardware
components described above by way of example with respect to FIG. 1
are not optimal for this functionality. Faster response times are
achievable using a module which is specifically intended for
this.
[0107] To illustrate the CAN arbitration, signal 701 present on the
CAN bus and signal 702, which is to be sent and present internally
in the microcontroller, are shown in FIG. 7. From left to right,
four clock sections are delimited by dotted lines. In clock section
1, a recessive level is present both on the bus and as the internal
signal. In clock section 2, a dominant level is present on the bus,
the internal signal having a recessive level for this clock
section. This node is thus withdrawn from the arbitration. The
hardware unit for arbitration thus suppresses a driving of the
intended dominant level in clock section 3. Accordingly, the node
is also no longer permitted to send in clock section 4 and the
following clock sections, until the end of the particular
transmission on the CAN bus which won the arbitration.
[0108] FIG. 6 shows a microcontroller 601 including hardware
modules 610 for providing a generic serial interface, in particular
a CAN interface, and having an additional hardware unit 630 for the
arbitration of messages via this interface. Microcontroller 601
including hardware components 610, i.e., input module 611, routing
unit 612, arithmetic unit (MCS) 613 and output module 614, once
again largely corresponds to microcontroller 101 in FIG. 1.
However, microcontroller 601 is additionally connected to the (in
the present example external) hardware module for arbitration 630.
Input data channel 602 is in particular a CAN Rx line; output data
channel 603 is a CAN Tx line. Additional hardware unit 630 may be
an external logic circuit which deactivates the sending of the node
as soon as a corresponding signal is received. In the case of a CAN
arbitration, such a send interruption would need to be carried out,
for example, as soon as a dominant level is present on the bus and
the host information for the same clock unit is recessive. Module
630 may be implemented, for example, as a logic circuit with the
aid of gate functions, a programmable logic device (PLD) or a field
programmable gate array (FPGA).
[0109] FIG. 6 additionally shows a second output module 615. This
module may support the additional hardware unit for arbitration 630
by providing timer resources. Such resources are required, for
example, to wait for a certain bit length or adhere to a certain
pause. An alternative implementation would be to provide these
timer resources also as an additional hardware circuit.
[0110] The additional hardware unit for arbitration may be flexibly
assignable to different output modules with the aid of a
configurable logic circuit. However, fixed assignment is also
possible.
[0111] The additional hardware unit for arbitration may be present
as a programmable logic circuit (e.g., FPGA or CPLD) outside the
microcontroller. By integrating such programmable logic circuits,
however, an alternative implementation on the microcontroller is
also possible.
[0112] The special hardware unit for arbitration may be configured
with additional measuring and evaluation functions. In one variant,
such a unit for CAN arbitration also detects, for example, whether
the protocol used is CAN or CAN-FD (CAN having a flexible data
rate).
[0113] In the described exemplary embodiments having the special
hardware unit for the arbitration, it is initially assumed that the
remaining method steps (data input in the input module, data output
by the output module, routing by the routing unit, protocol
calculation by the arithmetic unit (MCS), if necessary CRC
calculation by the CRC unit) still take place as described above,
and that the remaining hardware circuit (input module, output
module, routing unit, arithmetic unit (MCS), if necessary CRC unit)
is still composed as described above for FIG. 1. However, the
special hardware unit for arbitration is also easily combinable
with the exemplary embodiments having the special input module
and/or special output module.
[0114] In one further variant, a baud rate detection may
additionally be implemented in the afore-described specific
embodiments. Such a baud rate detection would allow an adaption to
different baud rates, for example.
[0115] The baud rate detection may be implemented in software or
hardware. With a software implementation, a baud rate detection may
be carried out by the arithmetic unit (MCS) or the central
processing unit (CPU) of the microcontroller from the capture
information of the input module, for example. An input frequency of
data may be surveyed and the baud rate may be ascertained by
reproducing a reference frequency. For this purpose, entire message
frames must be analyzed, which is time-consuming in a software
implementation.
[0116] In one alternative embodiment, the baud rate detection is
carried out in hardware. This may take place either in an
additional hardware circuit or in a special input module configured
with a corresponding additional functionality, as is described
above (e.g., for FIG. 5). Compared to the software implementation,
a faster baud rate detection and adaption is possible with a
hardware implementation; additionally the arithmetic unit (MCS) or
central processing unit (CPU) is relieved. FIG. 10 shows a
corresponding flow chart for the baud rate detection implemented in
hardware using the example of a generic UART interface.
[0117] The basic configuration of a message frame in the provided
protocol is known; for example, it is known in the present example
that a message frame always starts with a start bit having a low
level and ends with a stop bit having a high level. In a first step
1001 for ascertaining the baud rate, a number of clocks between the
start bit and the stop bit (i.e., the first high-low edge to the
last low-high edge) is counted by the corresponding hardware
functionality. The clock number may be derived from a time base
which provides the hardware functionality with a clock (e.g., from
a time base unit) and which is small compared to the baud rate to
be read in.
[0118] The length (i.e., number of bits) of the message frame is
known to the hardware functionality. For the protocol assumed by
way of example, it shall be known that a message frame has ten bits
(e.g., start bit, eight data bits, stop bit). The ascertained
number of elapsed clocks from the start bit to the stop bit is
divided by the number of bits of a message frame (by ten in the
example) in second step 1002. The baud rate thus ascertained may be
transmitted in third step 1003, e.g., to the arithmetic unit (MCS)
or the central processing unit (CPU) of the microcontroller.
[0119] While, for example, in the case of a UART or LIN interface
to be provided, the frame length may always be constant and thus
known, in the case of CAN, for example, the length (i.e., the
number of bits) of the message frame may be unknown. In one variant
of the described baud rate detection, the baud rate is also
detectable in hardware. For example, it is possible to ascertain
the shortest time between two bits of one message frame.
[0120] For the detection of the baud rate, the start and the end of
a message frame must be ascertainable. For example, this may be
carried out by an established number of clocks, such as three
clocks (at a constant baud rate corresponding to a fixed time,
e.g., 150 ns) for a certain level.
* * * * *