CAN driver

Discussions and support about ChibiOS/HAL, the MCU Hardware Abstraction Layer.
jschall
Posts: 31
Joined: Wed Sep 06, 2017 4:29 am
Has thanked: 2 times

CAN driver

Postby jschall » Tue Nov 21, 2017 10:08 pm

There are four issues and requirements I'd like to address with the CAN driver, a couple of which I think will need API changes or additions:

Problem 1: Inner priority inversion problem. If the transmit mailboxes are filled with low-priority frames and the bus is saturated, a higher-priority frame cannot transmit.
Problem 2: I need to enforce FIFO ordering of frames with the same ID field. This is a requirement of the higher-level protocol that I am using.
Problem 3: I need accurate receive timestamps for each frame.
Problem 4: I need accurate transmit timestamps for some frames.

Problems 1 and 2 can be addressed to satisfaction by the same mechanism: wait to enqueue frames until they will be the highest priority frame in the hardware queue. This would be pretty simple to address this directly at the LLD level. It could also be done at the HAL level - there would need to be additional LLD APIs to retrieve the ID field from a mailbox.

Problem 3 can be addressed relatively simply. A timestamp field will need to be added to CANRxFrame, it will need to be populated by the LLD using a hardware timestamp, or alternatively (less accurately) it could be a system time collected within the receive ISR. I think both options should be implemented - if a hardware timestamp is available, it should use the hardware timestamp, and otherwise it should use system time in the ISR.

Problem 4 is where the major API change/addition is going to need to happen. Currently, canTransmitTimeout only blocks until the frame is enqueued in hardware, not until it is actually transmitted. It does not return the mailbox or any kind of handle. If canTransmitTimeout returned the mailbox that the frame was enqueued in, then another function could be added to retrieve the transmit timestamp associated with that mailbox. Again, this would optionally be a hardware timestamp, and otherwise it would be a system time collected within the mailbox empty ISR.

I'll get started on it. Let me know if there are any objections.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: CAN driver

Postby Giovanni » Tue Nov 21, 2017 10:26 pm

Hi,

I would have objection if anything STM32-specific would be brought at API level, the API is meant to be general and portable.

About problem 1, isn't this addressed by putting frames with different priorities into different mailboxes? queuing can be implemented mutexes if required.

I don't have a clear idea about other points yet. Do timestamps need to be done at driver level?

Giovanni

jschall
Posts: 31
Joined: Wed Sep 06, 2017 4:29 am
Has thanked: 2 times

Re: CAN driver

Postby jschall » Tue Nov 21, 2017 10:33 pm

So, I'm going to start by adding the following lld API:

Code: Select all

bool can_lld_get_tx_frame(CANDriver *canp, canmbx_t mailbox, CANTxFrame *ret)

Then, I'll add a special value for the mailbox parameter for canTransmitTimeout, called CAN_ANY_MAILBOX_IF_HIGHEST_PRIO, and defined as maybe UINT32_MAX.

Providing this value in the mailbox parameter when calling canTransmitTimeout will cause canTransmitTimeout to block until there is no frame in any mailbox that has priority equal to or greater than the frame to be enqueued.

jschall
Posts: 31
Joined: Wed Sep 06, 2017 4:29 am
Has thanked: 2 times

Re: CAN driver

Postby jschall » Tue Nov 21, 2017 11:19 pm

Giovanni wrote:Hi,

I would have objection if anything STM32-specific would be brought at API level, the API is meant to be general and portable.

About problem 1, isn't this addressed by putting frames with different priorities into different mailboxes? queuing can be implemented mutexes if required.

I don't have a clear idea about other points yet. Do timestamps need to be done at driver level?

Giovanni


I agree completely with avoiding STM32-specific things at the API level.

You could allocate a mailbox for each priority level, if your firmware only transmits at e.g. 3 priority levels. However, for my purposes, the above described approach is the approach I wish to use for dealing with the inner priority inversion issue, and will write my own CAN driver to have it if I have to. I'd prefer not, but it seems pretty noninvasive to add it to ChibiOS.

I believe timestamps must be done at the driver level if they are to be highly accurate.

steved
Posts: 823
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 12 times
Been thanked: 135 times

Re: CAN driver

Postby steved » Wed Nov 22, 2017 11:04 am

jschall wrote:Problem 1: Inner priority inversion problem. If the transmit mailboxes are filled with low-priority frames and the bus is saturated, a higher-priority frame cannot transmit.

While I can see the benefit of handling this if it's simple, isn't it really more of a system design issue? A saturated data bus is generally not good news.

For the other features, you'll presumably implement the ability to enable/disable them using #define statements in halconf.h, in the same way as other driver features?

steved
Posts: 823
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 12 times
Been thanked: 135 times

Re: CAN driver

Postby steved » Wed Nov 22, 2017 11:36 am

A couple of other fairly trivial things I was thinking of implementing, mainly to simplify run-time changes:

1. A mode-setting API; there are four possible modes available:
Loopback
Listen-only
Self-test (= loopback + listen-only)
Normal
2. A speed setting API for at least some standard speeds.
Not so sure about the practicality of this one, since it's not a simple computation; register values also depend on system-specific bus requirements (and CPU clock speed and configuration). For my purposes this is likely to end up as a simple lookup table for a set of standard baud rates, with the table selected according to clock configuration.

jschall
Posts: 31
Joined: Wed Sep 06, 2017 4:29 am
Has thanked: 2 times

Re: CAN driver

Postby jschall » Fri Nov 24, 2017 10:00 pm

Hi steved, thanks for your input!

steved wrote:While I can see the benefit of handling this if it's simple, isn't it really more of a system design issue? A saturated data bus is generally not good news.


Well, saturated bus is just an example. You can still get a priority inversion even if the bus is not saturated per se.

For the other features, you'll presumably implement the ability to enable/disable them using #define statements in halconf.h, in the same way as other driver features?


I'd imagine so. For example, there should be a HAL_CAN_USE_HARDWARE_TIMESTAMPS and if the LLD isn't capable, it should cause an error to be thrown. However, I don't see a reason to require a configuration to enable the "CAN_ANY_MAILBOX_IF_HIGHEST_PRIO" option.

steved wrote:A couple of other fairly trivial things I was thinking of implementing, mainly to simplify run-time changes:

1. A mode-setting API; there are four possible modes available:
Loopback
Listen-only
Self-test (= loopback + listen-only)
Normal
2. A speed setting API for at least some standard speeds.
Not so sure about the practicality of this one, since it's not a simple computation; register values also depend on system-specific bus requirements (and CPU clock speed and configuration). For my purposes this is likely to end up as a simple lookup table for a set of standard baud rates, with the table selected according to clock configuration.


Both of those are desirable. Some of the mode-setting stuff may be too STM32-specific.

For a reference on the speed setting API, maybe check out Pavel Kirienko's libcanard driver (MIT-licensed): https://github.com/UAVCAN/libcanard/blo ... m32.h#L174

jschall
Posts: 31
Joined: Wed Sep 06, 2017 4:29 am
Has thanked: 2 times

Re: CAN driver

Postby jschall » Fri Nov 24, 2017 10:06 pm

Question: I primarily use git and github, and have no SVN experience. Is there an official channel for pull requests? I can make my changes on top of the github ChibiOS mirror at https://github.com/ChibiOS/ChibiOS and then provide a link to the branch in this post. Would that be acceptable?

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: CAN driver

Postby Giovanni » Fri Nov 24, 2017 10:19 pm

Hi,

The github repository is a mirror of the subversion one, read only. You need to submit patches or whole files here.

Giovanni

jschall
Posts: 31
Joined: Wed Sep 06, 2017 4:29 am
Has thanked: 2 times

Re: CAN driver

Postby jschall » Fri Nov 24, 2017 11:20 pm

Ah, I just realized there is already a field for the hardware timestamp in canRxFrame. It really should get converted to a system time in ticks within the driver, though.


Return to “ChibiOS/HAL”

Who is online

Users browsing this forum: No registered users and 1 guest