Re: CTU CAN FD driver multi-licence for Nuttx

[Andrew Dennison]

On Wed, 9 Aug 2023 at 10:43, Brennan Ashton 
wrote:

> On Tue, Aug 8, 2023, 5:22 PM Andrew Dennison  >
> wrote:
>
> > Hi Nuttx Dev,
> >
> > We are negotiating with the authors of the linux device driver for the
> CTU
> > CAN FD IP core to it re-licenced from GPL to so the driver can then be
> > ported to Nuttx.
> >
> > I've seen various licencing examples in the nuttx code base: but no high
> > level description that gives a definitive answer. For example there are
> > some cases where Authors are preserved and the code is BSD-2-Clause or
> > BSD-3-Clause (not Apache-2.0).
> >
> > We would appreciate some feedback on whether the proposal from Pavel
> below
> > is acceptable or if any minor adjustments would help.
> >
> > Kind regards,
> >
> > Andrew Dennison
> > Chief Architect and Hardware Team Lead
> > MoTeC (A Bosch Company)
> >
> > On Tue, 8 Aug 2023 at 19:48, Pavel Pisa  wrote:
> >
> > >
> > > OK, consider driver code license and NuttX compatible.
> > > We need to discuss what will be actual variant and file
> > > headers text. I suggest
> > >
> > > // SPDX-License-Identifier: GPL-2.0+ OR BSD-2-Clause OR Apache-2.0
> > >
> > >
> >
> /***
> > >  *
> > >  * CTU CAN FD IP Core
> > >  *
> > >  * Copyright (C) 2015-2018 Ondrej Ille  FEE CTU
> > >  * Copyright (C) 2018-2020 Ondrej Ille 
> > self-funded
> > >  * Copyright (C) 2018-2019 Martin Jerabek 
> > > FEE CTU
> > >  * Copyright (C) 2018-2020 Pavel Pisa  FEE
> > > CTU/self-funded
> > >  *
> > >  * Project advisors:
> > >  * Jiri Novak 
> > >  * Pavel Pisa 
> > >  *
> > >  * Department of Measurement (http://meas.fel.cvut.cz/)
> > >  * Faculty of Electrical Engineering (http://www.fel.cvut.cz)
> > >  * Czech Technical University(http://www.cvut.cz/)
> > >  */
> > >
> > > I am not sure if that is acceptable for NuttX mainline, but I do not
> like
> > > process which stripped all information about real code authors when
> > > NuttX has been absorbed by Apache. The Copyright (C) statementscan be
> > > replaced
> > > by text "Authors list"  if copyright of NuttX copy should be
> transferred
> > > to Apache. But I would tend to keep list of authors who invested time,
> > > lot of it even from own spare one...
> > >
> >
>
>
> I want to call out one thing that does not seem right. That information is
> retained here
> https://github.com/apache/nuttx/blob/master/LICENSE
>
>
> This is covered here
> https://www.apache.org/legal/resolved.html#required-third-party-notices
>
>
> Hopefully that helps provide some guidance.
>
>
Hi Brennan,

Thanks for the additional information - I hadn't found the Apache link as I
was just looking at Nuttx in isolation and missed any reference there is to
that other page. From the apache link it would seem the following would be
acceptable:

1) The file headers can contain "// SPDX-License-Identifier: GPL-2.0+ OR
BSD-2-Clause" and the author copyrights as proposed by Pavel. Note that I
have not included the Apache-2.0 licence as this does not seem to be
required, but I'm not sure it makes a difference either way.
2) The top level nuttx LICENCE file is updated with a statement that the
ctu_can_fd driver is being used under the terms of the BSD-2-Clause licence

Kind Regards,

Andrew

-- 
*MoTeC Pty Ltd*

121 Merrindale Drive
Croydon South 3136
Victoria Australia
*T: *61 3 9761 5050
*W: *www.motec.com.au 


-- 
  
 
 
 



-- 
 

-- 


Disclaimer Notice: This message, including any attachments, contains 
confidential information intended for a specific individual and purpose and 
is protected by law. If you are not the intended recipient you should 
delete this message. Any disclosure, copying, or distribution of this 
message or the taking of any action based on it is strictly prohibited.

Re: CAN TX fail handling

[Alan C. Assis]

Hi Tim,

Agree! This behavior could be implemented in the driver, for example
using some elapsed time. But again, it needs to be analyzed careful to
avoid introduce sometime too specific for a user needs.

Currently the can_close() try to wait for the TX complete that could
never happen because this issue.

If you implement the idea of resetting the CAN controller in the
can_close() you need to guarantee that it will be reinitialized
correctly, because in can_open() it expects the CAN controller in
working state.

BR,

Alan

On 8/9/23, Tim Hardisty  wrote:
> Thanks Alan,
>
> I can see that a timeout/retry in detail would be hardware dependent.
> But in the absence of "something," code can send a message, but have no
> idea that it hasn't actually been sent, then try and close the "file"
> and the thread will hang indefinitely. I think we need something that
> reports the fail so some kind of recovery/reset can be attempted?
>
> Perhaps the "close" could be wrapped with something to deal with this?
> Or the open mode needs to be different somehow?
>
> POSIX/Linux type programming is new to me, after decades of bare-metal
> type software dev where I'm in total control albeit unique to a
> given/chosen processor, so any suggestions would be very welcome.
>
> On 09/08/2023 19:56, Alan C. Assis wrote:
>> Hi Tim,
>>
>> I think that the default behavior of CAN Controller is trying to send
>> indefinitely a message, some HW can define some retry limit.
>>
>> Please take a look:
>> https://forum.pjrc.com/threads/67435-FlexCAN-Infinite-Endless-TX-Retries
>>
>> So, I'm not sure if it will make sense to implement a CAN TX timeout
>> on NuttX side, since this behavior could be HW dependent.
>>
>> BR,
>>
>> Alan
>>
>> On 8/9/23, Tim Hardisty  wrote:
>>> I am now cracking on with the app for my custom board, and in parallel
>>> writing a production board-test app.
>>>
>>> In trying to cover potential board faults, I have found that if there's
>>> something that prevents a CAN message reaching an endpoint/destination,
>>> the CAN transmitter (of course, as I understand it) is continuously
>>> retrying the message send, meaning the test app hangs when you try and
>>> close the file once the test has been deemed to fail. That is "by
>>> design" in the higher (i.e. non-arch specific) can code as it waits for
>>> the TX FIFO/queue to empty until the close is allowed.
>>>
>>> What is the correct POSIX way to handle this error condition?
>>>
>>> Might it be better to use Socket CAN, for example, assuming it has
>>> better error handling by design, or is the NuttX CAN "system"
>>> fundamentally missing something to handle this (or, more likely, I've
>>> just missed it )?
>>>
>>>
> --
>
> Regards,
>
> Tim Hardisty
>
>
> A picture containing text, clipart Description automatically generated
>
>   
>
> +44 (0) 1305 534535
>
>   
>
> 
>
>   
>
> JTi.uk.com 
>
>   
>
> 
>
>   
>
> \JTinnovations 
>
> JT Innovations Ltd.
>
> Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.
>
> Company number 7619086
>
> VAT Registration GB 111 7906 35
>

Re: CAN TX fail handling

[Tim Hardisty]

Thanks Alan,

I can see that a timeout/retry in detail would be hardware dependent. 
But in the absence of "something," code can send a message, but have no 
idea that it hasn't actually been sent, then try and close the "file" 
and the thread will hang indefinitely. I think we need something that 
reports the fail so some kind of recovery/reset can be attempted?


Perhaps the "close" could be wrapped with something to deal with this? 
Or the open mode needs to be different somehow?


POSIX/Linux type programming is new to me, after decades of bare-metal 
type software dev where I'm in total control albeit unique to a 
given/chosen processor, so any suggestions would be very welcome.


On 09/08/2023 19:56, Alan C. Assis wrote:

Hi Tim,

I think that the default behavior of CAN Controller is trying to send
indefinitely a message, some HW can define some retry limit.

Please take a look:
https://forum.pjrc.com/threads/67435-FlexCAN-Infinite-Endless-TX-Retries

So, I'm not sure if it will make sense to implement a CAN TX timeout
on NuttX side, since this behavior could be HW dependent.

BR,

Alan

On 8/9/23, Tim Hardisty  wrote:

I am now cracking on with the app for my custom board, and in parallel
writing a production board-test app.

In trying to cover potential board faults, I have found that if there's
something that prevents a CAN message reaching an endpoint/destination,
the CAN transmitter (of course, as I understand it) is continuously
retrying the message send, meaning the test app hangs when you try and
close the file once the test has been deemed to fail. That is "by
design" in the higher (i.e. non-arch specific) can code as it waits for
the TX FIFO/queue to empty until the close is allowed.

What is the correct POSIX way to handle this error condition?

Might it be better to use Socket CAN, for example, assuming it has
better error handling by design, or is the NuttX CAN "system"
fundamentally missing something to handle this (or, more likely, I've
just missed it )?



--

Regards,

Tim Hardisty


A picture containing text, clipart Description automatically generated



+44 (0) 1305 534535







JTi.uk.com 







\JTinnovations 

JT Innovations Ltd.

Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.

Company number 7619086

VAT Registration GB 111 7906 35

Re: CAN TX fail handling

[Alan C. Assis]

Hi Tim,

I think that the default behavior of CAN Controller is trying to send
indefinitely a message, some HW can define some retry limit.

Please take a look:
https://forum.pjrc.com/threads/67435-FlexCAN-Infinite-Endless-TX-Retries

So, I'm not sure if it will make sense to implement a CAN TX timeout
on NuttX side, since this behavior could be HW dependent.

BR,

Alan

On 8/9/23, Tim Hardisty  wrote:
> I am now cracking on with the app for my custom board, and in parallel
> writing a production board-test app.
>
> In trying to cover potential board faults, I have found that if there's
> something that prevents a CAN message reaching an endpoint/destination,
> the CAN transmitter (of course, as I understand it) is continuously
> retrying the message send, meaning the test app hangs when you try and
> close the file once the test has been deemed to fail. That is "by
> design" in the higher (i.e. non-arch specific) can code as it waits for
> the TX FIFO/queue to empty until the close is allowed.
>
> What is the correct POSIX way to handle this error condition?
>
> Might it be better to use Socket CAN, for example, assuming it has
> better error handling by design, or is the NuttX CAN "system"
> fundamentally missing something to handle this (or, more likely, I've
> just missed it )?
>
>

CAN TX fail handling

[Tim Hardisty]

I am now cracking on with the app for my custom board, and in parallel 
writing a production board-test app.


In trying to cover potential board faults, I have found that if there's 
something that prevents a CAN message reaching an endpoint/destination, 
the CAN transmitter (of course, as I understand it) is continuously 
retrying the message send, meaning the test app hangs when you try and 
close the file once the test has been deemed to fail. That is "by 
design" in the higher (i.e. non-arch specific) can code as it waits for 
the TX FIFO/queue to empty until the close is allowed.


What is the correct POSIX way to handle this error condition?

Might it be better to use Socket CAN, for example, assuming it has 
better error handling by design, or is the NuttX CAN "system" 
fundamentally missing something to handle this (or, more likely, I've 
just missed it )?

[OT] Top IoT Boards for Development & Prototyping You Need to Know in 2023

[Alan C. Assis]

Thanks Halysson for the link:

https://www.iotforall.com/top-iot-boards-for-development-prototyping-you-need-to-know-in-2023

The irony: the board they used in the image is the Meadow F7 powered
by NuttX :-D

Case some one know this gentleman, please ping him.

BR,

Alan