Visit

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Visit

John Dammeyer

Hi everyone,

I know this isn’t directly CAN bus related but I had the pleasure of a visit with Lars-Berno Fredriksson from KVASER today.  Been a few years since I met him.  Got caught up on all the CAN and CANFD things that his company is doing. 

 

As we discussed the olden days when even CAN drivers weren’t available yet, I realized how much I missed the detailed discussions on the working of the CAN bus.  It’s true though, there are many experts out there now who have lots of experience and the internet is full of reference information that wasn’t around 20 years ago.  Companies like Microchip have their own forums and often people interested in the CAN bus never even make it to this list. 

 

Browsing through some of the messages from the comp.arch.embedded UseGroup in 1995, the names of the contributors are Ken Tindell, Edwin Armstrong, Olaf Pfeiffer, Stephen Pelc and there is a rich amount of information about CAN.  Ken Tindell started this list that was eventually and is now graciously supported and maintained by Vector.

 

I’ve been asked a number of times to put my experience down into either a book or a series of essays on CAN bus.  I’ve been fortunate enough to have had a set of interesting experiences.  Even to being on a team developing and extension of the CAN bus to run on powerline and deliver Ethernet Connectivity with up to 4K byte packets between the arbitration and the CRC.  In many ways CAN FD is a subset of that original design.

 

Anyway, I’d like to get some feedback on what might be interesting in a book or a series of essays.  There’s already lots on the low level stuff.  Less on High Level Protocols and what’s there is often deep into the details.  Maybe more implementation examples and how it’s done?

 

So the floor is open.  Let’s have a discussion on what isn’t well documented.

 

Thanks

John Dammeyer

 

 

 

 

"ELS! Nothing else works as well for your Lathe"

Automation Artisans Inc.

http://www.autoartisans.com/ELS/

Ph. 1 250 544 4950

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Visit

Simon Byholm
Hello John

One thing I've noticed is that CAN driver implementations usually
use a fifo style send buffer, letting low priority messages block the
queue, when there's a higher priority message that should really
be sent first.

Some discussion on this would probably be useful.

Simon

Simon Byholm - Software Manager / Quality Manager

Phone: +358 6 357 6306
Fax: +358 6 357 6320
email: [hidden email]
web: www.tke.fi

TK Engineering solves your CAN, CANopen, J1939 and NMEA2000 problems by providing the hardware, software and know-how you need to design, manufacture and troubleshoot your industrial and heavy machine CAN networks. Call +358 6 357 6300 or email [hidden email] to learn how we can help you solve your CAN related problems.
On 19.11.2016 11:46, John Dammeyer wrote:

Hi everyone,

I know this isn’t directly CAN bus related but I had the pleasure of a visit with Lars-Berno Fredriksson from KVASER today.  Been a few years since I met him.  Got caught up on all the CAN and CANFD things that his company is doing. 

 

As we discussed the olden days when even CAN drivers weren’t available yet, I realized how much I missed the detailed discussions on the working of the CAN bus.  It’s true though, there are many experts out there now who have lots of experience and the internet is full of reference information that wasn’t around 20 years ago.  Companies like Microchip have their own forums and often people interested in the CAN bus never even make it to this list. 

 

Browsing through some of the messages from the comp.arch.embedded UseGroup in 1995, the names of the contributors are Ken Tindell, Edwin Armstrong, Olaf Pfeiffer, Stephen Pelc and there is a rich amount of information about CAN.  Ken Tindell started this list that was eventually and is now graciously supported and maintained by Vector.

 

I’ve been asked a number of times to put my experience down into either a book or a series of essays on CAN bus.  I’ve been fortunate enough to have had a set of interesting experiences.  Even to being on a team developing and extension of the CAN bus to run on powerline and deliver Ethernet Connectivity with up to 4K byte packets between the arbitration and the CRC.  In many ways CAN FD is a subset of that original design.

 

Anyway, I’d like to get some feedback on what might be interesting in a book or a series of essays.  There’s already lots on the low level stuff.  Less on High Level Protocols and what’s there is often deep into the details.  Maybe more implementation examples and how it’s done?

 

So the floor is open.  Let’s have a discussion on what isn’t well documented.

 

Thanks

John Dammeyer

 

 

 

 

"ELS! Nothing else works as well for your Lathe"

Automation Artisans Inc.

http://www.autoartisans.com/ELS/

Ph. 1 250 544 4950

 

 


Reply | Threaded
Open this post in threaded view
|

Re: Visit

Kees Zagers
Tx priority.
This can be achieved by defining multiple FIFO's with different
priorities. The CAN controller in the Microchip PIC32 has this done in
hardware. Up to 32 FIFO's with flexible depth of 1 to 32 messages can be
defined as either Rx or Tx FIFO. The Tx FIFO's have 4 levels of priority.
If the CAN controller does not have an internal Tx FIFO, this mechanism
can be implemented in the driver.

Kees

Op 19-11-2016 om 20:12 schreef Simon Byholm:
Hello John

One thing I've noticed is that CAN driver implementations usually
use a fifo style send buffer, letting low priority messages block the
queue, when there's a higher priority message that should really
be sent first.

Some discussion on this would probably be useful.

Simon

Simon Byholm - Software Manager / Quality Manager

Phone: +358 6 357 6306
Fax: +358 6 357 6320
email: [hidden email]
web: www.tke.fi

TK Engineering solves your CAN, CANopen, J1939 and NMEA2000 problems by providing the hardware, software and know-how you need to design, manufacture and troubleshoot your industrial and heavy machine CAN networks. Call +358 6 357 6300 or email [hidden email] to learn how we can help you solve your CAN related problems.
On 19.11.2016 11:46, John Dammeyer wrote:

Hi everyone,

I know this isn’t directly CAN bus related but I had the pleasure of a visit with Lars-Berno Fredriksson from KVASER today.  Been a few years since I met him.  Got caught up on all the CAN and CANFD things that his company is doing. 

 

As we discussed the olden days when even CAN drivers weren’t available yet, I realized how much I missed the detailed discussions on the working of the CAN bus.  It’s true though, there are many experts out there now who have lots of experience and the internet is full of reference information that wasn’t around 20 years ago.  Companies like Microchip have their own forums and often people interested in the CAN bus never even make it to this list. 

 

Browsing through some of the messages from the comp.arch.embedded UseGroup in 1995, the names of the contributors are Ken Tindell, Edwin Armstrong, Olaf Pfeiffer, Stephen Pelc and there is a rich amount of information about CAN.  Ken Tindell started this list that was eventually and is now graciously supported and maintained by Vector.

 

I’ve been asked a number of times to put my experience down into either a book or a series of essays on CAN bus.  I’ve been fortunate enough to have had a set of interesting experiences.  Even to being on a team developing and extension of the CAN bus to run on powerline and deliver Ethernet Connectivity with up to 4K byte packets between the arbitration and the CRC.  In many ways CAN FD is a subset of that original design.

 

Anyway, I’d like to get some feedback on what might be interesting in a book or a series of essays.  There’s already lots on the low level stuff.  Less on High Level Protocols and what’s there is often deep into the details.  Maybe more implementation examples and how it’s done?

 

So the floor is open.  Let’s have a discussion on what isn’t well documented.

 

Thanks

John Dammeyer

 

 

 

 

"ELS! Nothing else works as well for your Lathe"

Automation Artisans Inc.

http://www.autoartisans.com/ELS/

Ph. 1 250 544 4950

 

 



-- 
Kees Zagers
SI-Kwadraat B.V.
Gulberg 31
5674 TE  NUENEN
Reply | Threaded
Open this post in threaded view
|

Re: Visit

Simon Byholm
Hello Kees

The keyword here is "can" be implemented in
the driver. Most of the time it is not.

For example on the NXP Freescale S12 the driver you
get with the paid Code Warrior does not have a
priority queue, while the free driver you can
download from the website, I assume this one
is a bit more recent, has  a priority queue.

Simon
Simon Byholm - Software Manager / Quality Manager

Phone: +358 6 357 6306
Fax: +358 6 357 6320
email: [hidden email]
web: www.tke.fi

TK Engineering solves your CAN, CANopen, J1939 and NMEA2000 problems by providing the hardware, software and know-how you need to design, manufacture and troubleshoot your industrial and heavy machine CAN networks. Call +358 6 357 6300 or email [hidden email] to learn how we can help you solve your CAN related problems.
On 21.11.2016 10:18, Kees Zagers wrote:
Tx priority.
This can be achieved by defining multiple FIFO's with different
priorities. The CAN controller in the Microchip PIC32 has this done in
hardware. Up to 32 FIFO's with flexible depth of 1 to 32 messages can be
defined as either Rx or Tx FIFO. The Tx FIFO's have 4 levels of priority.
If the CAN controller does not have an internal Tx FIFO, this mechanism
can be implemented in the driver.

Kees

Op 19-11-2016 om 20:12 schreef Simon Byholm:
Hello John

One thing I've noticed is that CAN driver implementations usually
use a fifo style send buffer, letting low priority messages block the
queue, when there's a higher priority message that should really
be sent first.

Some discussion on this would probably be useful.

Simon

Simon Byholm - Software Manager / Quality Manager

Phone: +358 6 357 6306
Fax: +358 6 357 6320
email: [hidden email]
web: www.tke.fi

TK Engineering solves your CAN, CANopen, J1939 and NMEA2000 problems by providing the hardware, software and know-how you need to design, manufacture and troubleshoot your industrial and heavy machine CAN networks. Call +358 6 357 6300 or email [hidden email] to learn how we can help you solve your CAN related problems.
On 19.11.2016 11:46, John Dammeyer wrote:

Hi everyone,

I know this isn’t directly CAN bus related but I had the pleasure of a visit with Lars-Berno Fredriksson from KVASER today.  Been a few years since I met him.  Got caught up on all the CAN and CANFD things that his company is doing. 

 

As we discussed the olden days when even CAN drivers weren’t available yet, I realized how much I missed the detailed discussions on the working of the CAN bus.  It’s true though, there are many experts out there now who have lots of experience and the internet is full of reference information that wasn’t around 20 years ago.  Companies like Microchip have their own forums and often people interested in the CAN bus never even make it to this list. 

 

Browsing through some of the messages from the comp.arch.embedded UseGroup in 1995, the names of the contributors are Ken Tindell, Edwin Armstrong, Olaf Pfeiffer, Stephen Pelc and there is a rich amount of information about CAN.  Ken Tindell started this list that was eventually and is now graciously supported and maintained by Vector.

 

I’ve been asked a number of times to put my experience down into either a book or a series of essays on CAN bus.  I’ve been fortunate enough to have had a set of interesting experiences.  Even to being on a team developing and extension of the CAN bus to run on powerline and deliver Ethernet Connectivity with up to 4K byte packets between the arbitration and the CRC.  In many ways CAN FD is a subset of that original design.

 

Anyway, I’d like to get some feedback on what might be interesting in a book or a series of essays.  There’s already lots on the low level stuff.  Less on High Level Protocols and what’s there is often deep into the details.  Maybe more implementation examples and how it’s done?

 

So the floor is open.  Let’s have a discussion on what isn’t well documented.

 

Thanks

John Dammeyer

 

 

 

 

"ELS! Nothing else works as well for your Lathe"

Automation Artisans Inc.

http://www.autoartisans.com/ELS/

Ph. 1 250 544 4950

 

 



-- 
Kees Zagers
SI-Kwadraat B.V.
Gulberg 31
5674 TE  NUENEN

Reply | Threaded
Open this post in threaded view
|

Confirming hardware Tx in socketCAN

Al Thomason
In reply to this post by John Dammeyer

I am not sure if this is the best forum to ask socketCAN questions on, if there is a better place - suggestions appreciated.

 

I am porting an existing program from a micro-controller to be usable in Linux.  I am using socketCAN for the Tx and Rx capabilities and all is working well using non-blocking RAW writes (letting the socket queue do its job).     However, one of the needs of the existing program is to assure a given packet has been sent out via the hardware.  It uses this to coordinate in-order transmission of multi-packet messages.   Is there a way to poll a CAN socket to determine if indeed a message has been sent, or if the entire queue is empty?  All references I have found to date cover file or perhaps TCP access – and changing (even temporarily) to blocking writes risks wedging the application.

 

Right now I am using an ugly sleep() for 3mS after transmitting ‘need to confirm’ packets, with the idea being to raise the likelihood a given packet was indeed sent (if it can be at all).   However, clearly some other non-delay approach would be preferred. Any other ideas?  

 

Thank you in advance for any suggestions.

 

-al-

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

RE: Confirming hardware Tx in socketCAN

John Dammeyer

I think this is a good forum for this question.  It has applications for a protocol like MilCAN for example.

 

In MilCAN there’s a rule that the messages should be sent as One Shot.  No retries since a runaway retry could step on top of place where the SYNC FLAG message must appear.

 

For processors that don’t have that ability the application needs to be able to verify that the message was properly sent before the next SYNC FLAG message and if not needs to be cancelled.

 

Therefore the ability to verify the status of a message (or cancel it)  is fairly important.  I’d certainly like to know how this would be done.

Thanks

John Dammeyer

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Al Thomason
Sent: March-09-17 9:27 AM
To: [hidden email]
Subject: [CANLIST] Confirming hardware Tx in socketCAN

 

I am not sure if this is the best forum to ask socketCAN questions on, if there is a better place - suggestions appreciated.

 

I am porting an existing program from a micro-controller to be usable in Linux.  I am using socketCAN for the Tx and Rx capabilities and all is working well using non-blocking RAW writes (letting the socket queue do its job).     However, one of the needs of the existing program is to assure a given packet has been sent out via the hardware.  It uses this to coordinate in-order transmission of multi-packet messages.   Is there a way to poll a CAN socket to determine if indeed a message has been sent, or if the entire queue is empty?  All references I have found to date cover file or perhaps TCP access – and changing (even temporarily) to blocking writes risks wedging the application.

 

Right now I am using an ugly sleep() for 3mS after transmitting ‘need to confirm’ packets, with the idea being to raise the likelihood a given packet was indeed sent (if it can be at all).   However, clearly some other non-delay approach would be preferred. Any other ideas?  

 

Thank you in advance for any suggestions.

 

-al-

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Confirming hardware Tx in socketCAN

Bram Kerkhof
In reply to this post by Al Thomason

Unless you have disabled it explicitly, CAN messages that are sent via a socket are "looped back" via the hardware driver to other open sockets so other clients are aware of the message you have sent.
By setting the raw socket option CAN_RAW_RECV_OWN_MSGS a socket will also receive the messages that have been sent through it. This looped back message can be used to validate whether a message was indeed sent by the controller.

However: there is an important caveat -- the hardware driver needs to support looping back sent messages otherwise SocketCAN will happily emulate it in software and every message will appear to have been sent regardless if it ever got on the wire or not!

I'm not aware of a better implementation with SocketCAN.

cheers,

Bram


Van: "Al Thomason" <[hidden email]>
Aan: [hidden email]
Verzonden: Donderdag 9 maart 2017 18:27:26
Onderwerp: [CANLIST] Confirming hardware Tx in socketCAN

I am not sure if this is the best forum to ask socketCAN questions on, if there is a better place - suggestions appreciated.

 

I am porting an existing program from a micro-controller to be usable in Linux.  I am using socketCAN for the Tx and Rx capabilities and all is working well using non-blocking RAW writes (letting the socket queue do its job).     However, one of the needs of the existing program is to assure a given packet has been sent out via the hardware.  It uses this to coordinate in-order transmission of multi-packet messages.   Is there a way to poll a CAN socket to determine if indeed a message has been sent, or if the entire queue is empty?  All references I have found to date cover file or perhaps TCP access – and changing (even temporarily) to blocking writes risks wedging the application.

 

Right now I am using an ugly sleep() for 3mS after transmitting ‘need to confirm’ packets, with the idea being to raise the likelihood a given packet was indeed sent (if it can be at all).   However, clearly some other non-delay approach would be preferred. Any other ideas?  

 

Thank you in advance for any suggestions.

 

-al-

 

 

 

 


Reply | Threaded
Open this post in threaded view
|

RE: Confirming hardware Tx in socketCAN

Al Thomason

Bram,

 

Thank you – I had seen mention of loopback, and perhaps that is a way – to wait until I see my specific message transmitted on the CAN bus.  But with further digging - specifically on the socketCAN developers list:  http://socket-can.996257.n3.nabble.com/   I noted a lot of posts back in 2008-2010 timeframe addressing what seemed to consider out-of-order messages as a bug.  My impression from those posting is that socketCAN is designed to always keep order of packets.  As I cannot find anything on that in the API documents (specifically can.txt) I have a query to that list asking for confirmation.  It seems that list’s traffic has slowed down these past years, but if I get any insight will reply back here.

 

Does this match up with your experience?   Or, are you thinking the real solution is to monitor the loop-back and confirm transmission.  And hum… w/o digging into each hardware driver, is there a way to tell if the driver supports actually hardware based loopback, or if it only came back via emulation?  

 

-al-

 

 

Viking Star

45' Monk Sr. / McQueen

mvVikingStar.blogspot.com

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, March 13, 2017 4:14 AM
To: [hidden email]
Subject: Re: [CANLIST] Confirming hardware Tx in socketCAN

 

Unless you have disabled it explicitly, CAN messages that are sent via a socket are "looped back" via the hardware driver to other open sockets so other clients are aware of the message you have sent.
By setting the raw socket option CAN_RAW_RECV_OWN_MSGS a socket will also receive the messages that have been sent through it. This looped back message can be used to validate whether a message was indeed sent by the controller.

However: there is an important caveat -- the hardware driver needs to support looping back sent messages otherwise SocketCAN will happily emulate it in software and every message will appear to have been sent regardless if it ever got on the wire or not!

I'm not aware of a better implementation with SocketCAN.

cheers,

Bram


Van: "Al Thomason" <[hidden email]>
Aan: [hidden email]
Verzonden: Donderdag 9 maart 2017 18:27:26
Onderwerp: [CANLIST] Confirming hardware Tx in socketCAN

 

I am not sure if this is the best forum to ask socketCAN questions on, if there is a better place - suggestions appreciated.

 

I am porting an existing program from a micro-controller to be usable in Linux.  I am using socketCAN for the Tx and Rx capabilities and all is working well using non-blocking RAW writes (letting the socket queue do its job).     However, one of the needs of the existing program is to assure a given packet has been sent out via the hardware.  It uses this to coordinate in-order transmission of multi-packet messages.   Is there a way to poll a CAN socket to determine if indeed a message has been sent, or if the entire queue is empty?  All references I have found to date cover file or perhaps TCP access – and changing (even temporarily) to blocking writes risks wedging the application.

 

Right now I am using an ugly sleep() for 3mS after transmitting ‘need to confirm’ packets, with the idea being to raise the likelihood a given packet was indeed sent (if it can be at all).   However, clearly some other non-delay approach would be preferred. Any other ideas?  

 

Thank you in advance for any suggestions.

 

-al-