mirror of
https://github.com/apache/nuttx.git
synced 2026-08-01 20:28:58 +00:00
Introduce a single configuration option to provide strict transmit priority ordering based on CAN ID. The intention is to expose the user-visible behavior (strict TX priority ordering) rather than the underlying implementation details. Strict priority ordering is only meaningful when hardware transmit buffer cancellation is available, so splitting this functionality into separate configuration options was misleading and could result in partially effective or incorrect configurations. Signed-off-by: zhaohaiyang1 <zhaohaiyang1@xiaomi.com>
352 lines
9.4 KiB
Text
352 lines
9.4 KiB
Text
#
|
|
# For a description of the syntax of this configuration file,
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
|
#
|
|
|
|
config ARCH_HAVE_CAN_ERRORS
|
|
bool
|
|
default n
|
|
|
|
menu "CAN Driver Support"
|
|
|
|
config CAN
|
|
bool "CAN Character Driver Support"
|
|
default n
|
|
---help---
|
|
This selection enables building of the "upper-half" CAN driver.
|
|
See include/nuttx/can/can.h for further CAN driver information.
|
|
|
|
if CAN
|
|
|
|
config CAN_EXTID
|
|
bool "CAN extended IDs"
|
|
default n
|
|
---help---
|
|
Enables support for the 29-bit extended ID. Default Standard 11-bit
|
|
IDs.
|
|
|
|
config CAN_ERRORS
|
|
bool "CAN error reporting"
|
|
default n
|
|
depends on ARCH_HAVE_CAN_ERRORS
|
|
---help---
|
|
Support CAN error reporting. If this option is selected then CAN
|
|
error reporting is enabled. In the event of an error, the ch_error
|
|
bit will be set in the CAN message and the following message payload
|
|
will include a more detailed description of certain errors.
|
|
|
|
config CAN_TIMESTAMP
|
|
bool "CAN timestamp reporting"
|
|
default n
|
|
---help---
|
|
Support CAN timestamp reporting. if this option is selected then
|
|
CAN timestamp reporting is enabled. in the CAN message the ch_ts
|
|
member variable will record the timestamp of each frame.
|
|
|
|
config CAN_FD
|
|
bool "CAN FD"
|
|
default n
|
|
---help---
|
|
Enables support for the CAN_FD mode.
|
|
|
|
config CAN_TXFIFOSIZE
|
|
int "CAN driver I/O tx buffer size"
|
|
default 8
|
|
range 1 255
|
|
---help---
|
|
The size of the circular tx buffer of CAN messages. Default: 8
|
|
|
|
config CAN_RXFIFOSIZE
|
|
int "CAN driver I/O rx buffer size"
|
|
default 8
|
|
range 1 255
|
|
---help---
|
|
The size of the circular rx buffer of CAN messages. Default: 8
|
|
|
|
config CAN_NPENDINGRTR
|
|
int "Number of pending RTRs"
|
|
default 4
|
|
---help---
|
|
The size of the list of pending RTR requests. Default: 4
|
|
|
|
config CAN_TXCONFIRM
|
|
bool "can txconfirm ability"
|
|
default n
|
|
---help---
|
|
this section enables the can txconfirm ability.
|
|
|
|
Enabling this feature adds support for the can txconfirm
|
|
ability, the ability is used from CAN interrupt handler
|
|
when the transfer is complete, the ability will notify all
|
|
readers that the canid has been transferred.
|
|
|
|
config CAN_TXREADY
|
|
bool "can_txready interface"
|
|
default n
|
|
---help---
|
|
This selection enables the can_txready() interface. This interface
|
|
is needed only for CAN hardware that supports queueing of outgoing
|
|
messages in a H/W FIFO.
|
|
|
|
The CAN upper half driver also supports a queue of output messages
|
|
in a S/W FIFO. Messages are added to that queue when when
|
|
can_write() is called and removed from the queue in can_txdone()
|
|
when each TX message is complete.
|
|
|
|
After each message is added to the S/W FIFO, the CAN upper half
|
|
driver will attempt to send the message by calling into the lower
|
|
half driver. That send will not be performed if the lower half
|
|
driver is busy, i.e., if dev_txready() returns false. In that
|
|
case, the number of messages in the S/W FIFO can grow. If the
|
|
S/W FIFO becomes full, then can_write() will wait for space in
|
|
the S/W FIFO.
|
|
|
|
If the CAN hardware does not support a H/W FIFO then busy means
|
|
that the hardware is actively sending the message and is
|
|
guaranteed to become non busy (i.e, dev_txready()) when the
|
|
send transfer completes and can_txdone() is called. So the call
|
|
to can_txdone() means that the transfer has completed and also
|
|
that the hardware is ready to accept another transfer.
|
|
|
|
If the CAN hardware supports a H/W FIFO, can_txdone() is not
|
|
called when the transfer is complete, but rather when the
|
|
transfer is queued in the H/W FIFO. When the H/W FIFO becomes
|
|
full, then dev_txready() will report false and the number of
|
|
queued messages in the S/W FIFO will grow.
|
|
|
|
There is no mechanism in this case to inform the upper half
|
|
driver when the hardware is again available, when there is
|
|
again space in the H/W FIFO. can_txdone() will not be called
|
|
again. If the S/W FIFO becomes full, then the upper half
|
|
driver will wait for space to become available, but there is
|
|
no event to awaken it and the driver will hang.
|
|
|
|
Enabling this feature adds support for the can_txready()
|
|
interface. This function is called from the lower half
|
|
driver's CAN interrupt handler each time a TX transfer
|
|
completes. This is a sure indication that the H/W FIFO is
|
|
no longer full. can_txready() will then awaken the
|
|
can_write() logic and the hang condition is avoided.
|
|
|
|
config CAN_STRICT_TX_PRIORITY
|
|
bool "Prioritize sending based on canid"
|
|
default n
|
|
---help---
|
|
Enable strict transmit priority ordering based on CAN ID.
|
|
|
|
When the hardware transmit buffers (not a hardware FIFO) are
|
|
full and there are frames pending in the software tx_pending list,
|
|
the cancel ability is taken effect. this feature may cancel
|
|
the msg with the largest CAN ID in the mailbox.
|
|
|
|
Specifically, the driver may cancel the transmission of the
|
|
lowest-priority frame(the msg with the largest CAN ID) currently
|
|
stored in a hardware transmit buffer, reinsert that frame back
|
|
into the software pending list, and replace it with a
|
|
higher-priority pending frame.
|
|
|
|
This feature requires that the CAN controller hardware supports
|
|
cancellation (abort) of buffered transmissions.
|
|
|
|
Do not enable this option if the lower-half driver uses a hardware
|
|
FIFO to store transmit frames.
|
|
|
|
choice
|
|
prompt "TX Ready Work Queue"
|
|
default CAN_TXREADY_HIPRI
|
|
depends on CAN_TXREADY
|
|
|
|
config CAN_TXREADY_LOPRI
|
|
bool "Low-priority work queue"
|
|
select SCHED_LPWORK
|
|
|
|
config CAN_TXREADY_HIPRI
|
|
bool "High-priority work queue"
|
|
select SCHED_HPWORK
|
|
|
|
endchoice # TX Ready Work Queue
|
|
|
|
config CAN_LOOPBACK
|
|
bool "CAN loopback mode"
|
|
default n
|
|
---help---
|
|
A CAN driver may or may not support a loopback mode for testing. If the
|
|
driver does support loopback mode, the setting will enable it. (If the
|
|
driver does not, this setting will have no effect).
|
|
|
|
config CAN_USE_RTR
|
|
bool "Include RTR in CAN header"
|
|
default n
|
|
---help---
|
|
This selection includes RTR bitfield in the CAN header.
|
|
|
|
comment "CAN Bus Controllers:"
|
|
|
|
config CAN_MCP2515
|
|
bool "Microchip MCP2515 CAN Bus Controller over SPI"
|
|
default n
|
|
depends on SPI
|
|
select ARCH_HAVE_CAN_ERRORS
|
|
---help---
|
|
Enable driver support for Microchip MCP2515.
|
|
|
|
if CAN_MCP2515
|
|
|
|
config MCP2515_BITRATE
|
|
int "MCP2515 bitrate"
|
|
default 500000
|
|
---help---
|
|
MCP2515 bitrate in bits per second.
|
|
|
|
config MCP2515_PROPSEG
|
|
int "MCP2515 Propagation Segment TQ"
|
|
default 2
|
|
range 1 8
|
|
---help---
|
|
The length of the bit time is Tquanta * (SyncSeg + PropSeg + PhaseSeg1 + PhaseSeg2).
|
|
|
|
config MCP2515_PHASESEG1
|
|
int "MCP2515 Phase Segment 1"
|
|
default 2
|
|
range 1 8
|
|
---help---
|
|
The length of the bit time is Tquanta * (SyncSeg + PropSeg + PhaseSeg1 + PhaseSeg2).
|
|
|
|
config MCP2515_PHASESEG2
|
|
int "MCP2515 Phase Segment 2"
|
|
default 3
|
|
range 2 8
|
|
---help---
|
|
The length of the bit time is Tquanta * (SyncSeg + PropSeg + PhaseSeg1 + PhaseSeg2).
|
|
|
|
config MCP2515_SJW
|
|
int "MCP2515 Synchronization Jump Width"
|
|
default 1
|
|
range 1 4
|
|
---help---
|
|
The duration of a synchronization jump is SJW.
|
|
|
|
config MCP2515_CLK_FREQUENCY
|
|
int "MCP2515 on-board clock frequency"
|
|
default 8000000
|
|
range 1 25000000
|
|
|
|
config MCP2515_SPI_SCK_FREQUENCY
|
|
int "MCP2515 SPI SCK Frequency"
|
|
default 1000000
|
|
range 100000 10000000
|
|
|
|
endif # CAN_MCP2515
|
|
|
|
menuconfig CAN_SJA1000
|
|
tristate "Philips/NXP SJA1000 devices"
|
|
|
|
if CAN_SJA1000
|
|
|
|
config CAN_SJA1000_BITRATE
|
|
int "SJA1000 bitrate"
|
|
default 1000000
|
|
---help---
|
|
SJA1000 bit rate.
|
|
|
|
config CAN_SJA1000_SJW
|
|
int "SJA1000 Synchronization Jump Width"
|
|
default 1
|
|
range 1 4
|
|
---help---
|
|
The duration of a synchronization jump is SJW.
|
|
|
|
config CAN_SJA1000_SAM
|
|
bool "The CAN bus is sampled 3 times"
|
|
default false
|
|
---help---
|
|
Recommended for low to medium speed buses
|
|
to filter spikes on the bus-line.
|
|
|
|
config CAN_SJA1000_SAMPLEP
|
|
int "SJA1000 CAN sample point (Percentage)"
|
|
default 87
|
|
range 0 100
|
|
|
|
config CANBUS_REGDEBUG
|
|
bool "CAN BUS register debug enable."
|
|
default false
|
|
|
|
config CAN_SJA1000_DEBUG
|
|
bool "SJA1000 CAN BUS trace debug enable."
|
|
default false
|
|
|
|
endif # CAN_SJA1000
|
|
|
|
endif # CAN
|
|
|
|
config CAN_KVASER
|
|
bool "Kvaser PCI CAN card"
|
|
default n
|
|
depends on PCI
|
|
---help---
|
|
Enable driver support for Kvase PCI CAN card.
|
|
NOTE: for now works only with QEMU
|
|
|
|
if CAN_KVASER
|
|
|
|
config CAN_KVASER_IRQ_PASSES
|
|
int "Kvaser PCI interrupt passes"
|
|
default 16
|
|
range 1 512
|
|
---help---
|
|
This option sets how many times the card status will be checked
|
|
during one interrupt handler. A value greater than 1 helps avoid
|
|
data loss when there is a lot of traffic on the CAN bus.
|
|
The downside is that it increases the interrupt service time.
|
|
|
|
choice
|
|
prompt "Kvaser PCI CAN device type"
|
|
default CAN_KVASER_CHARDEV if CAN
|
|
default CAN_KVASER_SOCKET if NET_CAN
|
|
|
|
config CAN_KVASER_CHARDEV
|
|
bool "Kvaser PCI can device as chardev"
|
|
depends on CAN
|
|
select ARCH_HAVE_CAN_ERRORS
|
|
|
|
config CAN_KVASER_SOCKET
|
|
bool "Kvaser PCI can device as socketCAN"
|
|
depends on NET_CAN
|
|
select NET_CAN_HAVE_ERRORS
|
|
|
|
endchoice # "Kvaser PCI CAN device type"
|
|
|
|
endif # CAN_KVASER
|
|
|
|
config CAN_CTUCANFD
|
|
bool "CTUCANFD PCI CAN card"
|
|
default n
|
|
depends on PCI
|
|
---help---
|
|
Enable driver support for CTU CAN FD PCI card.
|
|
NOTE: for now works only with QEMU
|
|
|
|
if CAN_CTUCANFD
|
|
|
|
choice
|
|
prompt "CTU CAN FD PCI CAN device type"
|
|
default CAN_CTUCANFD_CHARDEV if CAN
|
|
default CAN_CTUCANFD_SOCKET if NET_CAN
|
|
|
|
config CAN_CTUCANFD_CHARDEV
|
|
bool "CTU CAN FD PCI can device as chardev"
|
|
depends on CAN
|
|
select ARCH_HAVE_CAN_ERRORS
|
|
|
|
config CAN_CTUCANFD_SOCKET
|
|
bool "CTU CAN FD PCI can device as socketCAN"
|
|
depends on NET_CAN
|
|
select NET_CAN_HAVE_ERRORS
|
|
select NET_CAN_HAVE_CANFD
|
|
|
|
endchoice # "CTU CAN FD PCI CAN device type"
|
|
|
|
endif # CAN_CTUCANFD
|
|
|
|
endmenu # CAN Driver Support
|