You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Simon Filgis <si...@ingenieurbuero-filgis.de> on 2021/08/13 14:50:59 UTC
Lin
Dear all,
has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART
peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa) would
also be interesting!
Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx in
a separate file?
Have a good Weekend,
Simon
Re: Lin
Posted by Tim Hardisty <Ti...@JTi.uk.com.INVALID>.
I will need to state that I have not studied LIN yet let alone the datasheets – I have simply added the interface to my hardware (SAMA5D27 based) – so, at this stage, I’m perhaps not going to be much help. Once there’s something that others think works, I will get up to speed with LIN and (if needs be) port to the A5D27 (they are very similar actually) and then test and report back.
If my involvement is, as a result, premature then apologies!
But, no, I have never seen µC registers change their meaning like that – the SAMA5D2 doesn’t do this with the FlexCOM ports.
-----------
Dear all,
Alan, Frank-Christian, Pavel, Tim,
After studying the E70 Datasheet and LIN in general I conclude with Pavel's Proposal.
Btw. did you ever see µC registers change their meaning with some mode setting??? Me not. But after one day it is not so much a surprise any more as it was to me in the first second.
What do you think, shall I extend arch/arm/src/samv7/hardware/sam_uart.h with all those second and third meanings to get unique names?
In same sam_uart.h I needed to add two lines:
I do not know why they have not been stated, but the bits exist and I need them. Does anybody have concerns or knows where they are already stated?
Consider the following application code:
bufferlin[9] = ComputeChksumValue(&bufferlin[0], 9);
ioctl(lin, TIOCSLIN, bufferlin[0]);
ret = write(lin, &bufferlin[1], 9*sizeof(char));
Now with ioctl -> cmd=TIOCSLIN I can issue sending of a LIN master header using dedicated HW:
Could you please have a look and give me feedback on what else would be desirable.
https://github.com/SimonFilgis/incubator-nuttx/commit/f0cec98b699c3359fd57f7b91036f69f1062b2ad
Best Regards,
Simon
On Sat, Aug 14, 2021 at 12:38 PM Tim Hardisty <Ti...@jti.uk.com.invalid> wrote:
My custom board has a Lin/K-Line interface using a TJA1021 transceiver, but software support is low on the priority/roadmap at this time.
Nevertheless, I would be happy to be involved in testing (I have a CAN/LIN analyzer/stream generator) if it helps.
-----Original Message-----
From: Pavel Pisa <pp...@pikron.com>
Hello Simon and others,
On Friday 13 of August 2021 18:50:23 Frank-Christian Kruegel wrote:
> Am 13.08.2021 um 16:50 schrieb Simon Filgis:
> > has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART
> > peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa)
> > would also be interesting!
> >
> > Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx
> > in a separate file?
>
> Do you need LIN Master or LIN Slave?
>
> LIN Master is easy. It's standard serial.
...
> LIN slave is much more complex, especially if you want to do autobauding
> by measuring the SYNC byte after the break. You might end up with a
> custom serial driver then. If a fixed bitrate is enough the only problem
> is detecting the BREAK signal. A received break signal is basically a 0
> byte with a framing error added. You only need to detect and clear the
> framing error.
I am on the way to vacations now but I am interest in LIN interfacing
discussion when I return. I do not have actual need for LIN support
but getting some reasonable code upstream to NuttX and Linux.
There is my latest version from 2019
https://github.com/ppisa/linux-lin
and some docs
https://github.com/ppisa/linux-lin/wiki
Finite state machines and some other ideas from Linux kernel
implementation can be reused on NuttX. As for the API,
I think that to keep size of the applications low
on the targets which do not use TCP or SocketCAN,
NuttX API should be implemented through read, write
(enough for the master) and IOCTLs to maintain slave
responses cache.
As for bitrate autodetection, there are special
HW support in many UARTs for autodetect of the LIN
bitrate. It would worth to add mechanism to setup
it o NuttX. On GNU/Linux where sllin attempts to
be compatible with all UARTs through generic API
it is problematic. On NuttX we can define API,
which can allow to implement LIN specific
low level drivers for chips with special support
ad for other map the API to generic UART low
level part. Or we can conditionally extend low
level API.
By the way
I return on Sunday August 22. It would be great
if prof. Roberto Bucher's and followup Michal Lenc's
presentation about PySimCoder on NuttX Workshop
can be scheduled on Sunday that I can attend them.
Best wishes
Pavel
--
Pavel Pisa
phone: +420 603531357
e-mail: pisa@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://dce.fel.cvut.cz/
personal: http://cmp.felk.cvut.cz/~pisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
company: https://www.pikron.com/
Re: Lin
Posted by Simon Filgis <si...@ingenieurbuero-filgis.de>.
Dear all,
Alan, Frank-Christian, Pavel, Tim,
After studying the E70 Datasheet and LIN in general I conclude with Pavel's
Proposal.
Btw. did you ever see µC registers change their meaning with some mode
setting??? Me not. But after one day it is not so much a surprise any more
as it was to me in the first second.
[image: image.png]
What do you think, shall I extend arch/arm/src/samv7/hardware/sam_uart.h
with all those second and third meanings to get unique names?
In same sam_uart.h I needed to add two lines:
[image: image.png]
I do not know why they have not been stated, but the bits exist and I need
them. Does anybody have concerns or knows where they are already stated?
Consider the following application code:
bufferlin[9] = ComputeChksumValue(&bufferlin[0], 9);
ioctl(lin, TIOCSLIN, bufferlin[0]);
ret = write(lin, &bufferlin[1], 9*sizeof(char));
Now with ioctl -> cmd=TIOCSLIN I can issue sending of a LIN master header
using dedicated HW:
[image: image.png]
Could you please have a look and give me feedback on what else would be
desirable.
https://github.com/SimonFilgis/incubator-nuttx/commit/f0cec98b699c3359fd57f7b91036f69f1062b2ad
Best Regards,
Simon
On Sat, Aug 14, 2021 at 12:38 PM Tim Hardisty <Ti...@jti.uk.com.invalid>
wrote:
> My custom board has a Lin/K-Line interface using a TJA1021 transceiver,
> but software support is low on the priority/roadmap at this time.
>
> Nevertheless, I would be happy to be involved in testing (I have a CAN/LIN
> analyzer/stream generator) if it helps.
>
> -----Original Message-----
> From: Pavel Pisa <pp...@pikron.com>
> Hello Simon and others,
>
> On Friday 13 of August 2021 18:50:23 Frank-Christian Kruegel wrote:
> > Am 13.08.2021 um 16:50 schrieb Simon Filgis:
> > > has anybody implemented a LIN driver for SAME70 USART? The SAME70
> USART
> > > peripheral is capable of. A SW implementation (sllin.c - Pavel
> Pisa)
> > > would also be interesting!
> > >
> > > Would you extend sma_lowputc.c and sam_serial.c or would you grep
> USARTx
> > > in a separate file?
> >
> > Do you need LIN Master or LIN Slave?
> >
> > LIN Master is easy. It's standard serial.
> ...
> > LIN slave is much more complex, especially if you want to do
> autobauding
> > by measuring the SYNC byte after the break. You might end up with a
> > custom serial driver then. If a fixed bitrate is enough the only
> problem
> > is detecting the BREAK signal. A received break signal is basically
> a 0
> > byte with a framing error added. You only need to detect and clear
> the
> > framing error.
>
> I am on the way to vacations now but I am interest in LIN interfacing
> discussion when I return. I do not have actual need for LIN support
> but getting some reasonable code upstream to NuttX and Linux.
>
> There is my latest version from 2019
>
> https://github.com/ppisa/linux-lin
>
> and some docs
>
> https://github.com/ppisa/linux-lin/wiki
>
> Finite state machines and some other ideas from Linux kernel
> implementation can be reused on NuttX. As for the API,
> I think that to keep size of the applications low
> on the targets which do not use TCP or SocketCAN,
> NuttX API should be implemented through read, write
> (enough for the master) and IOCTLs to maintain slave
> responses cache.
>
> As for bitrate autodetection, there are special
> HW support in many UARTs for autodetect of the LIN
> bitrate. It would worth to add mechanism to setup
> it o NuttX. On GNU/Linux where sllin attempts to
> be compatible with all UARTs through generic API
> it is problematic. On NuttX we can define API,
> which can allow to implement LIN specific
> low level drivers for chips with special support
> ad for other map the API to generic UART low
> level part. Or we can conditionally extend low
> level API.
>
> By the way
> I return on Sunday August 22. It would be great
> if prof. Roberto Bucher's and followup Michal Lenc's
> presentation about PySimCoder on NuttX Workshop
> can be scheduled on Sunday that I can attend them.
>
> Best wishes
> Pavel
> --
> Pavel Pisa
> phone: +420 603531357
> e-mail: pisa@cmp.felk.cvut.cz
> Department of Control Engineering FEE CVUT
> Karlovo namesti 13, 121 35, Prague 2
> university: http://dce.fel.cvut.cz/
> personal: http://cmp.felk.cvut.cz/~pisa
> projects: https://www.openhub.net/accounts/ppisa
> CAN related:http://canbus.pages.fel.cvut.cz/
> company: https://www.pikron.com/
>
>
>
>
Re: Lin
Posted by Tim Hardisty <Ti...@JTi.uk.com.INVALID>.
My custom board has a Lin/K-Line interface using a TJA1021 transceiver, but software support is low on the priority/roadmap at this time.
Nevertheless, I would be happy to be involved in testing (I have a CAN/LIN analyzer/stream generator) if it helps.
-----Original Message-----
From: Pavel Pisa <pp...@pikron.com>
Hello Simon and others,
On Friday 13 of August 2021 18:50:23 Frank-Christian Kruegel wrote:
> Am 13.08.2021 um 16:50 schrieb Simon Filgis:
> > has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART
> > peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa)
> > would also be interesting!
> >
> > Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx
> > in a separate file?
>
> Do you need LIN Master or LIN Slave?
>
> LIN Master is easy. It's standard serial.
...
> LIN slave is much more complex, especially if you want to do autobauding
> by measuring the SYNC byte after the break. You might end up with a
> custom serial driver then. If a fixed bitrate is enough the only problem
> is detecting the BREAK signal. A received break signal is basically a 0
> byte with a framing error added. You only need to detect and clear the
> framing error.
I am on the way to vacations now but I am interest in LIN interfacing
discussion when I return. I do not have actual need for LIN support
but getting some reasonable code upstream to NuttX and Linux.
There is my latest version from 2019
https://github.com/ppisa/linux-lin
and some docs
https://github.com/ppisa/linux-lin/wiki
Finite state machines and some other ideas from Linux kernel
implementation can be reused on NuttX. As for the API,
I think that to keep size of the applications low
on the targets which do not use TCP or SocketCAN,
NuttX API should be implemented through read, write
(enough for the master) and IOCTLs to maintain slave
responses cache.
As for bitrate autodetection, there are special
HW support in many UARTs for autodetect of the LIN
bitrate. It would worth to add mechanism to setup
it o NuttX. On GNU/Linux where sllin attempts to
be compatible with all UARTs through generic API
it is problematic. On NuttX we can define API,
which can allow to implement LIN specific
low level drivers for chips with special support
ad for other map the API to generic UART low
level part. Or we can conditionally extend low
level API.
By the way
I return on Sunday August 22. It would be great
if prof. Roberto Bucher's and followup Michal Lenc's
presentation about PySimCoder on NuttX Workshop
can be scheduled on Sunday that I can attend them.
Best wishes
Pavel
--
Pavel Pisa
phone: +420 603531357
e-mail: pisa@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://dce.fel.cvut.cz/
personal: http://cmp.felk.cvut.cz/~pisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
company: https://www.pikron.com/
Re: Lin
Posted by Pavel Pisa <pp...@pikron.com>.
Hello Simon and others,
On Friday 13 of August 2021 18:50:23 Frank-Christian Kruegel wrote:
> Am 13.08.2021 um 16:50 schrieb Simon Filgis:
> > has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART
> > peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa)
> > would also be interesting!
> >
> > Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx
> > in a separate file?
>
> Do you need LIN Master or LIN Slave?
>
> LIN Master is easy. It's standard serial.
...
> LIN slave is much more complex, especially if you want to do autobauding
> by measuring the SYNC byte after the break. You might end up with a
> custom serial driver then. If a fixed bitrate is enough the only problem
> is detecting the BREAK signal. A received break signal is basically a 0
> byte with a framing error added. You only need to detect and clear the
> framing error.
I am on the way to vacations now but I am interest in LIN interfacing
discussion when I return. I do not have actual need for LIN support
but getting some reasonable code upstream to NuttX and Linux.
There is my latest version from 2019
https://github.com/ppisa/linux-lin
and some docs
https://github.com/ppisa/linux-lin/wiki
Finite state machines and some other ideas from Linux kernel
implementation can be reused on NuttX. As for the API,
I think that to keep size of the applications low
on the targets which do not use TCP or SocketCAN,
NuttX API should be implemented through read, write
(enough for the master) and IOCTLs to maintain slave
responses cache.
As for bitrate autodetection, there are special
HW support in many UARTs for autodetect of the LIN
bitrate. It would worth to add mechanism to setup
it o NuttX. On GNU/Linux where sllin attempts to
be compatible with all UARTs through generic API
it is problematic. On NuttX we can define API,
which can allow to implement LIN specific
low level drivers for chips with special support
ad for other map the API to generic UART low
level part. Or we can conditionally extend low
level API.
By the way
I return on Sunday August 22. It would be great
if prof. Roberto Bucher's and followup Michal Lenc's
presentation about PySimCoder on NuttX Workshop
can be scheduled on Sunday that I can attend them.
Best wishes
Pavel
--
Pavel Pisa
phone: +420 603531357
e-mail: pisa@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://dce.fel.cvut.cz/
personal: http://cmp.felk.cvut.cz/~pisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
company: https://www.pikron.com/
Re: Lin
Posted by Frank-Christian Kruegel <nu...@istda.com>.
Am 13.08.2021 um 16:50 schrieb Simon Filgis:
> Dear all,
>
> has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART
> peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa) would
> also be interesting!
>
> Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx in
> a separate file?
>
> Have a good Weekend,
>
> Simon
Do you need LIN Master or LIN Slave?
LIN Master is easy. It's standard serial. The only nonstandard item is
the BREAK signal generation. For this, just insert an AND Gate into the
LIN TX UART line and keep the other input of the gate high. When you
need to send a break, flush the buffers, set the other input of the gate
to low, send two bytes (any value will do), wait until all bits are out,
and set the gate input high. Then you've sent a break with 20 bit times,
which is perfectly within the LIN specification, and without the need
for a timer etc.
LIN slave is much more complex, especially if you want to do autobauding
by measuring the SYNC byte after the break. You might end up with a
custom serial driver then. If a fixed bitrate is enough the only problem
is detecting the BREAK signal. A received break signal is basically a 0
byte with a framing error added. You only need to detect and clear the
framing error.
Grüße
Frank-CHristian Krügel
Re: Lin
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Simon,
I think we don't have LIN upper-half support on NuttX yet, but it
could start with higher level API definition.
I'm CC Mr. Pavel Pisa he is a NuttX contributor and could could be
interested to help on it.
Also we have people from Indian Tata Motors here, probably they
already implemented LIN support on NuttX, but I don't know for sure.
BR,
Alan
On 8/13/21, Simon Filgis <si...@ingenieurbuero-filgis.de> wrote:
> Dear all,
>
> has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART
> peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa) would
> also be interesting!
>
> Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx in
> a separate file?
>
> Have a good Weekend,
>
> Simon
>