Re: [PATCH v1 1/2] wscript: Allow defines to be used for substitution

[Sebastian Huber]

On 12/04/2022 20:55, Kinsey Moore wrote:

This allows options set as defines to the compiler to be used as targets
for substitution using the syntax ${DEFINES:define_target}. These need
special handling since they are not in a form that is trivially consumed
by the mapping code.
---
  wscript | 4 
  1 file changed, 4 insertions(+)

diff --git a/wscript b/wscript
index 4d63dbc66f..9de9d67b91 100755
--- a/wscript
+++ b/wscript
@@ -107,6 +107,10 @@ class EnvWrapper(object):
  except IndexError:
  fmt = "{}"
  if isinstance(v, list):
+if fields[0] == "DEFINES":
+for D in v:
+if D.startswith(fields[1]+'='):
+return "{}".format(D.split("=")[1].strip('"'))
  return " ".join([fmt.format(w) for w in v])
  return fmt.format(v)
  


Sorry, I don't understand what this is supposed to do. Could you please 
give me an example use case?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 2/2] wscript: Allow substitution outside values

[Sebastian Huber]

On 12/04/2022 20:55, Kinsey Moore wrote:

diff --git a/wscript b/wscript
index 9de9d67b91..e2fc047ea8 100755
--- a/wscript
+++ b/wscript
@@ -276,10 +276,10 @@ class Item(object):
  if target is None:
  target = os.path.splitext(source)[0] + ".o"
  bld(
-asflags=self.data["asflags"],
-cppflags=self.data["cppflags"],
+asflags=[self.substitute(bld, asflag) for asflag in 
self.data["asflags"]],
+cppflags=[self.substitute(bld, cppflag) for cppflag in 
self.data["cppflags"]],


Could you please add a self.substitute_list(bld, values) or add list 
support to self.substitute(bld, value).


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN Options and Licensing, Testing, etc

[Prashanth S]

Hi Joel,

Have you determined how you will test CAN on BBB?

I planned to test the CAN driver with another BBB running linux. And if CAN
analyzer is economical then I would use that.

Regards
Prashanth S

On Wed, 13 Apr 2022 at 00:38, Joel Sherrill  wrote:

>
>
> On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp 
> wrote:
>
>> Hi Joel,
>>
>> at least for the SocketCAN network layer part the license is a dual
>> license BSD3/GPLv2
>>
>> // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
>>
>> https://elixir.bootlin.com/linux/v5.17.2/source/net/can/af_can.c#L1
>>
>> The reason was that we (at Volkswagen) intended the idea, the API, (CAN)
>> data structures and code could be easily ported to BSD/MacOS/Windows.
>>
>> In fact we created a working Windows PoC but CAN hardware vendors had no
>> interest to unify a open CAN driver API - to maintain their Lock-In :-/
>>
>> Today only a few CAN network drivers in linux/drivers/net/can follow
>> this dual license approach. As they are 'Linux-specific' they are mostly
>> GPLv2.
>>
>
> Thanks for clarifying that.
>
> The PowerPC qoriq network drivers in libbsd are dual licensed and there
> is some framework included to support Linux drivers in libbsd. That's the
> extent of my knowledge but it at least means this could be possible to
> integrate without knowingly diving into a deep pit.
>
> It has the disadvantage that CAN support would be tied to using libbsd.
> That's likely  too heavy for some environments. But might be a good
> solution if portability of applications is a goal.
>
>
>> Best regards,
>> Oliver
>>
>>
>> On 12.04.22 19:13, Prashanth S wrote:
>> > Hi All,
>> >
>> > This is to ask for suggestions on implementing the CAN driver for BBB.
>> >
>> > Can I proceed with defining driver specific structures for the CAN
>> > driver or go with adding a generic API layer for ADC and GPIO.
>>
>
> Have you determined how you will test CAN on BBB?
>
> I imagine you can use libdebugger to debug CAN.
>
> A big part of the community part of GSoC is making sure you are
> in a good position to succeed. That means knowing how you will
> test.
>
> --joel
>
> --joel
>
>
>> >
>> > Regards
>> > Prashanth S
>> >
>> >
>> > On Tue, 12 Apr 2022 at 19:14, Joel Sherrill > > > wrote:
>> >
>> > Hi
>> >
>> > I didn't want to post this in the other thread and turn it from a
>> > technical into licensing discussion but that must be the first
>> > filter for a CAN solution for RTEMS if it uses third-party code. If
>> > I have extracted the options correctly, we have:
>> >
>> > + LinCAN - GPL
>> > + SocketCAN - GPL
>> > + NuttX CAN - Apache
>> > + CANOpen - Apache
>> >
>> > The licensing alone eliminates two of the solutions.
>> >
>> > My other concern was how you were going to test the drivers you
>> > wrote. Pavel mentions CAN in qemu. Perhaps the project should drop
>> > the ADC and focus on a CAN solution using the BSP supported by Qemu
>> > along with whatever analysis tools Pavel recommends. I am sure Pavel
>> > has some driver code for the Qemu path (not sure if it is in RTEMS
>> > or not) This would move the project from a single driver to trying
>> > to provide a CAN solution. This is much more valuable to the project
>> > long term.
>> >
>> > And since CANOpen is an independent and long running project, I'd
>> > lean to it as the selection.
>> >
>> > Just my thoughts
>> >
>> > --joel
>> >
>> >
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN Options and Licensing, Testing, etc

[Pavel Pisa]

Hello Joel, Prashanth and others,

On Tuesday 12 of April 2022 15:43:58 Joel Sherrill wrote:
> + LinCAN - GPL
> + SocketCAN - GPL
> + NuttX CAN - Apache
> + CANOpen - Apache
>
> The licensing alone eliminates two of the solutions.

LinCAN license is GPL with special exception which
I proposed at university to make it usable for embedded
targets withink companies and specially RTEMS

https://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/src/can_queue.c

/* To allow use of LinCAN in the compact embedded systems firmware*/
/* and RT-executives (RTEMS for example), main authors agree with next*/
/* special exception: */
/**/
/* Including LinCAN header files in a file, instantiating LinCAN generics */
/* or templates, or linking other files with LinCAN objects to produce*/
/* an application image/executable, does not by itself cause the  */
/* resulting application image/executable to be covered by*/
/* the GNU General Public License.*/
/* This exception does not however invalidate any other reasons   */
/* why the executable file might be covered by the GNU Public License.*/
/* Publication of enhanced or derived LinCAN files is required although.

Which is exactly based on RTEMS previous model, which in the fact I personally
like more than plain BSD, but I agree that it makes writing RTEMS code
even more harder because it disqualifies direct use of both BSD and GPL
sources if this kind of dual license should be kept.

But LinCAN code can be relicensed to almost any kind of license
by me. Only USB support (in separate branch) and some small part
of MPC5200 driver code is written by other people, my former studnets
during their semestral and theses work. There are traces of the original
Arnaud Westenberg and T. Motylewski code of preceding Linux CAN
driver attempts. But probably each their line has been rewritten
during my rearchitect of the code and bringing it to working state.
As the former group to which I have had belong at the time of writting
moved out of the faculty, I can relicense the code with only noticing
department head...

But it is questionable if the LinCAN code is so good start point.
On the other hand, I do not like binding RTEMS CAN drivers to BSD
stack and I do not like RTEMS to strong dependency on it in general.
It s OK for BBB, MPC5200, Zynq etc.. But for imxRT, SAME70, TMS570
an alike smaller which fit RTEMS hard RT control area well
it is blocker.

> My other concern was how you were going to test the drivers you wrote.
> Pavel mentions CAN in qemu.
> Perhaps the project should drop the ADC

Yes I would not mix that and I would not build ADC support on libbsd
at all. I can imagine advantage of SocketCAN and its combination
with libbsd and BSD networking stack, but I really diskike that
dependency for ADC

> and focus on a CAN solution using the BSP supported by Qemu along
> with whatever analysis tools Pavel recommends. I am sure Pavel
> has some driver code for the Qemu path (not sure if it is in RTEMS
> or not) This would move the project from a single driver to trying
> to provide a CAN solution. This is much more valuable to the project
> long term. 

QEMU supports SJA1000 on PCI/PCIe cards (Kavser and others) which
is supported by LinCAN and many other drivers. So it can be used with
x86 RTEMS BSPs and it has been tested with Malta MIPS (big endian)
and more ARM targets with PCI on Linux kernel.
But on the other hand BBB or Zynq are more appropriate targets
for real-time and RTEMS. QEMU support for BBB would be nice.
QEMU supports Xilinx CAN and CAN FD controllers. See

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/863043713/Using+CAN+CAN+FD+with+Xilinx+QEMU

It seems that support s available for Zynq UltraScale+ MPSoC and Versal ACAP.
Old Zynq 7000 XCAN does not seem to be supported.
So for RTEMS direct match is to use aarch64 xilinx-versal and xilinx-zynqmp
BSPs... But they would be probably harder to use than BBB
even if only the real HW test are available and BBB is more common
in community.

So ideal project would be to try setup API and add driver to test
it on real HW on BBB and then on x86 or xilinx-zynqmp in QEMU.

As for project timing, I would suggest to start real coding work
earlier, study period should be run before start of conding
period. If all goes well than there can be holiday at the end.
But to make this work well it demand lot of effort and it can be really
valuable and visible.

I am open to suggestions from others, I am adding Chris as he
is probably the best to comment Xilinx optiosn.
 
> And since CANOpen is an independent and long running project, I'd lean to
> it as the selection.


CANopen is layer above CAN and can be solved independently.

We have generic CANopen infrastructure which has been tested
on Linux LinCAN then 

Re: CAN Options and Licensing, Testing, etc

[Joel Sherrill]

On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp 
wrote:

> Hi Joel,
>
> at least for the SocketCAN network layer part the license is a dual
> license BSD3/GPLv2
>
> // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
>
> https://elixir.bootlin.com/linux/v5.17.2/source/net/can/af_can.c#L1
>
> The reason was that we (at Volkswagen) intended the idea, the API, (CAN)
> data structures and code could be easily ported to BSD/MacOS/Windows.
>
> In fact we created a working Windows PoC but CAN hardware vendors had no
> interest to unify a open CAN driver API - to maintain their Lock-In :-/
>
> Today only a few CAN network drivers in linux/drivers/net/can follow
> this dual license approach. As they are 'Linux-specific' they are mostly
> GPLv2.
>

Thanks for clarifying that.

The PowerPC qoriq network drivers in libbsd are dual licensed and there
is some framework included to support Linux drivers in libbsd. That's the
extent of my knowledge but it at least means this could be possible to
integrate without knowingly diving into a deep pit.

It has the disadvantage that CAN support would be tied to using libbsd.
That's likely  too heavy for some environments. But might be a good
solution if portability of applications is a goal.


> Best regards,
> Oliver
>
>
> On 12.04.22 19:13, Prashanth S wrote:
> > Hi All,
> >
> > This is to ask for suggestions on implementing the CAN driver for BBB.
> >
> > Can I proceed with defining driver specific structures for the CAN
> > driver or go with adding a generic API layer for ADC and GPIO.
>

Have you determined how you will test CAN on BBB?

I imagine you can use libdebugger to debug CAN.

A big part of the community part of GSoC is making sure you are
in a good position to succeed. That means knowing how you will
test.

--joel

--joel


> >
> > Regards
> > Prashanth S
> >
> >
> > On Tue, 12 Apr 2022 at 19:14, Joel Sherrill  > > wrote:
> >
> > Hi
> >
> > I didn't want to post this in the other thread and turn it from a
> > technical into licensing discussion but that must be the first
> > filter for a CAN solution for RTEMS if it uses third-party code. If
> > I have extracted the options correctly, we have:
> >
> > + LinCAN - GPL
> > + SocketCAN - GPL
> > + NuttX CAN - Apache
> > + CANOpen - Apache
> >
> > The licensing alone eliminates two of the solutions.
> >
> > My other concern was how you were going to test the drivers you
> > wrote. Pavel mentions CAN in qemu. Perhaps the project should drop
> > the ADC and focus on a CAN solution using the BSP supported by Qemu
> > along with whatever analysis tools Pavel recommends. I am sure Pavel
> > has some driver code for the Qemu path (not sure if it is in RTEMS
> > or not) This would move the project from a single driver to trying
> > to provide a CAN solution. This is much more valuable to the project
> > long term.
> >
> > And since CANOpen is an independent and long running project, I'd
> > lean to it as the selection.
> >
> > Just my thoughts
> >
> > --joel
> >
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v1 2/2] wscript: Allow substitution outside values

[Kinsey Moore]

This expands the ability to substitute variables outside the current
limitation of values in options to asflags, cflags, cppflags, cxxflags,
ldflags, and includes. It is possible for all of these flags to utilize
user-defined information in config.ini, especially for paths to external
resources.
---
 wscript | 52 ++--
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/wscript b/wscript
index 9de9d67b91..e2fc047ea8 100755
--- a/wscript
+++ b/wscript
@@ -276,10 +276,10 @@ class Item(object):
 if target is None:
 target = os.path.splitext(source)[0] + ".o"
 bld(
-asflags=self.data["asflags"],
-cppflags=self.data["cppflags"],
+asflags=[self.substitute(bld, asflag) for asflag in 
self.data["asflags"]],
+cppflags=[self.substitute(bld, cppflag) for cppflag in 
self.data["cppflags"]],
 features="asm_explicit_target asm c",
-includes=bic.includes + self.data["includes"],
+includes=bic.includes + [self.substitute(bld, inc) for inc in 
self.data["includes"]],
 source=[source],
 target=target,
 )
@@ -289,10 +289,10 @@ class Item(object):
 if target is None:
 target = os.path.splitext(source)[0] + ".o"
 bld(
-cflags=self.data["cflags"],
-cppflags=cppflags + self.data["cppflags"],
+cflags=[self.substitute(bld, cflag) for cflag in 
self.data["cflags"]],
+cppflags=cppflags + [self.substitute(bld, cppflag) for cppflag in 
self.data["cppflags"]],
 features="c",
-includes=bic.includes + self.data["includes"],
+includes=bic.includes + [self.substitute(bld, inc) for inc in 
self.data["includes"]],
 rule="${CC} ${CFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES} 
${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
 source=[source] + deps,
 target=target,
@@ -303,10 +303,10 @@ class Item(object):
 if target is None:
 target = os.path.splitext(source)[0] + ".o"
 bld(
-cppflags=cppflags + self.data["cppflags"],
-cxxflags=self.data["cxxflags"],
+cppflags=cppflags + [self.substitute(bld, cppflag) for cppflag in 
self.data["cppflags"]],
+cxxflags=[self.substitute(bld, cxxflag) for cxxflag in 
self.data["cxxflags"]],
 features="cxx",
-includes=bic.includes + self.data["includes"],
+includes=bic.includes + [self.substitute(bld, inc) for inc in 
self.data["includes"]],
 rule="${CXX} ${CXXFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES} 
${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
 source=[source] + deps,
 target=target,
@@ -578,11 +578,11 @@ class ObjectsItem(Item):
 
 def do_build(self, bld, bic):
 bld.objects(
-asflags=self.data["cppflags"],
-cflags=self.data["cflags"],
-cppflags=self.data["cppflags"],
-cxxflags=self.data["cxxflags"],
-includes=bic.includes + self.data["includes"],
+asflags=[self.substitute(bld, cppflag) for cppflag in 
self.data["cppflags"]],
+cflags=[self.substitute(bld, cflag) for cflag in 
self.data["cflags"]],
+cppflags=[self.substitute(bld, cppflag) for cppflag in 
self.data["cppflags"]],
+cxxflags=[self.substitute(bld, cxxflag) for cxxflag in 
self.data["cxxflags"]],
+includes=bic.includes + [self.substitute(bld, inc) for inc in 
self.data["includes"]],
 source=self.data["source"],
 target=self.uid,
 )
@@ -603,10 +603,10 @@ class BSPItem(Item):
 
 def do_build(self, bld, bic):
 bld(
-cflags=self.data["cflags"],
-cppflags=self.data["cppflags"],
+cflags=[self.substitute(bld, cflag) for cflag in 
self.data["cflags"]],
+cppflags=[self.substitute(bld, cppflag) for cppflag in 
self.data["cppflags"]],
 features="c cstlib",
-includes=bic.includes + self.data["includes"],
+includes=bic.includes + [self.substitute(bld, inc) for inc in 
self.data["includes"]],
 install_path="${BSP_LIBDIR}",
 source=self.data["source"],
 target="rtemsbsp",
@@ -624,11 +624,11 @@ class LibraryItem(Item):
 
 def do_build(self, bld, bic):
 bld(
-cflags=self.data["cflags"],
-cppflags=self.data["cppflags"],
-cxxflags=self.data["cxxflags"],
+cflags=[self.substitute(bld, cflag) for cflag in 
self.data["cflags"]],
+cppflags=[self.substitute(bld, cppflag) for cppflag in 
self.data["cppflags"]],
+cxxflags=[self.substitute(bld, cxxflag) for cxxflag in 
self.data["cxxflags"]],
 features="c cxx cstlib",
-includes=bic.includes + self.data["includes"],
+

[PATCH v1 1/2] wscript: Allow defines to be used for substitution

[Kinsey Moore]

This allows options set as defines to the compiler to be used as targets
for substitution using the syntax ${DEFINES:define_target}. These need
special handling since they are not in a form that is trivially consumed
by the mapping code.
---
 wscript | 4 
 1 file changed, 4 insertions(+)

diff --git a/wscript b/wscript
index 4d63dbc66f..9de9d67b91 100755
--- a/wscript
+++ b/wscript
@@ -107,6 +107,10 @@ class EnvWrapper(object):
 except IndexError:
 fmt = "{}"
 if isinstance(v, list):
+if fields[0] == "DEFINES":
+for D in v:
+if D.startswith(fields[1]+'='):
+return "{}".format(D.split("=")[1].strip('"'))
 return " ".join([fmt.format(w) for w in v])
 return fmt.format(v)
 
-- 
2.30.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v1 0/2] Add more substitution capabilities

[Kinsey Moore]

This patch set adds more substitution capabilities to the build system
such that BSP configuration options can be used in flags and include
paths.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN Options and Licensing, Testing, etc

[Prashanth S]

Hi All,

This is to ask for suggestions on implementing the CAN driver for BBB.

Can I proceed with defining driver specific structures for the CAN driver
or go with adding a generic API layer for ADC and GPIO.

Regards
Prashanth S


On Tue, 12 Apr 2022 at 19:14, Joel Sherrill  wrote:

> Hi
>
> I didn't want to post this in the other thread and turn it from a
> technical into licensing discussion but that must be the first filter for a
> CAN solution for RTEMS if it uses third-party code. If I have extracted the
> options correctly, we have:
>
> + LinCAN - GPL
> + SocketCAN - GPL
> + NuttX CAN - Apache
> + CANOpen - Apache
>
> The licensing alone eliminates two of the solutions.
>
> My other concern was how you were going to test the drivers you wrote.
> Pavel mentions CAN in qemu. Perhaps the project should drop the ADC and
> focus on a CAN solution using the BSP supported by Qemu along with whatever
> analysis tools Pavel recommends. I am sure Pavel has some driver code for
> the Qemu path (not sure if it is in RTEMS or not) This would move the
> project from a single driver to trying to provide a CAN solution. This is
> much more valuable to the project long term.
>
> And since CANOpen is an independent and long running project, I'd lean to
> it as the selection.
>
> Just my thoughts
>
> --joel
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

CAN Options and Licensing, Testing, etc

[Joel Sherrill]

Hi

I didn't want to post this in the other thread and turn it from a technical
into licensing discussion but that must be the first filter for a CAN
solution for RTEMS if it uses third-party code. If I have extracted the
options correctly, we have:

+ LinCAN - GPL
+ SocketCAN - GPL
+ NuttX CAN - Apache
+ CANOpen - Apache

The licensing alone eliminates two of the solutions.

My other concern was how you were going to test the drivers you wrote.
Pavel mentions CAN in qemu. Perhaps the project should drop the ADC and
focus on a CAN solution using the BSP supported by Qemu along with whatever
analysis tools Pavel recommends. I am sure Pavel has some driver code for
the Qemu path (not sure if it is in RTEMS or not) This would move the
project from a single driver to trying to provide a CAN solution. This is
much more valuable to the project long term.

And since CANOpen is an independent and long running project, I'd lean to
it as the selection.

Just my thoughts

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 BSP tree refactoring proposal.

[Karel Gardas]

Hello Sebastian,

On 4/12/22 08:58, Sebastian Huber wrote:
I already did proposed changes in my branch on github.com: 
https://github.com/karelfv/rtems/tree/stm32h7-boards-refactoring


All three supported BSPs compile with defaults and 7b3i-dk even run on 
my board. Can't test others due to missing hardware.



Please review the directory structure and let me know what do you 
think about it?


No, the tree is not ready for merge yet as this is done in one big 
commit. If you agree with the structure I'll clean it up and do more 
fine grained commits for merge preparation.


It looks good, thanks.


I've prepared merge branch for you. It is 
https://github.com/karelfv/rtems/tree/stm32h7-boards-refactoring-for-merge


I've just created boards directories, copy files around. Deleted old 
files and otherwise nucleo and stm32h7 bsps should be same like in HEAD 
(before h7b3i-dk bsp was merged!). I've updated system_h7xx file for 
h7b3i-dk bsp, but otherwise it should be also same as in HEAD. Of course 
#ifdefs are cleanup from system files between the boards so h7b3i-dk 
board changes are not presented in neither nucleo nor stm32h7 bsps. 
Files in nucleo nad stm32h7 boards dirs are same for now.


Nucleo-h743zi bsp may be cleanup and updated even further, but I'm not 
attempting that till I have real hardware for test here...


Thanks!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN driver message structure

[Pavel Pisa]

Hello Prashanth, Karel and Gedare,

On Tuesday 12 of April 2022 08:50:04 Karel Gardas wrote:
> not sure about others but Pavel Pisa is CAN expert here. CCing him
> directly as I've not seen him active recently.

Thanks for poke. I am subscribed on RTEMS devel (and many more lists)
but I am not capable to read all the messages so they are automatically
routed to the related folder.

As for the actual project proposal, I have already got notice
from Gedare and I have read it.

I have been driving force behind attempt to provide common
CAN drivers API for the Linux kernel

  http://ortcan.sourceforge.net/lincan/

but then thanks to cooperation of Volswagen and Pengutronix
SocketCAN API has been developed and only small remnants
of LinCAN has been reused.

As for the APIs, SocketCAN API is much more rich and user
friendly than characted driver LinCAN and others APIs.

On the other hand SocketCAN API is based on SKB infrastructure
and complete networking stack of Linux the kernel and this
stack is still not real-time/low latency capable even on
fully-preemptive Linux kernel variant.

We have done more analyses in cooperation with Oliver Hartkopp
from Volswagen

  https://static.lwn.net/images/conf/rtlws11/papers/proc/p30.pdf
  https://static.lwn.net/images/conf/rtlws-2011/proc/Sojka.pdf

The Linux kernel situation is better now but still not optimal
for demanding real-time CAN bus use.

In the case of RTEMS, using socket interface would even bind
driver to actually used external TCP/IP stack and BSD one
is problematic for smaller MCUs where CAN is really appropriate
choice.

I have proposed to port LinCAN to RTEMS many years ago.
But because no common testing environment has been found,
it has been decided that such tool has to be provided the first
and RTEMS donated GSoC slot to QEMU

  https://devel.rtems.org/wiki/Developer/Simulators/QEMU/CANEmulation
  https://www.qemu.org/docs/master/system/devices/can.html

After years of my further investments, the GSoC result has been
accepted into QEMU mainline and one of my bachelor studnets
implemented even CAN FD extension and support for our open source
CTU CAN FD IP core

  https://canbus.pages.fel.cvut.cz/

Xilinx used this base to include emulation of their CAN FD controllers
into QEMU.

We have invested into CAN bus support in NuttX in the last years.
NuttX provided character device API. See struct can_hdr_s
and struct can_msg_s

  https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/can/can.h

It has options for finegrained tuning of its size according to the required
capabilities. It has sense for memory really constrained MCUs,
but RTEMS targets little bigger ones and variability is a problem
on the user and driver codes which as to put too many lines
under different ifdefs. So I would chose single head format
for all variants. Differentiate CAN_MAXDATALEN worth because
24 unused bytes overhead for each CAN message is large for
really small MCUs with CAN only support of application.

There was attempt to provide even SocketCAN API on NuttX
which would be attractive to build portable applications
for both GNU/Linux and NuttX. The initial attempt has been
done for S32 by Peter van der Perk from NXP. When we
looked for MCU for Elektroline.cz applications we have choosen
imxRT the first and my student Michal Lenc has ported and extended
SocketCAN NuttX driver to imxRT 

https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/imxrt/imxrt_flexcan.c

May problems has been corrected and it is running for year on
non safety NuttX based monitoring part of the resonant track circuit
electronic unit prototype. But I do not have good feeling about
mapping of this driver into NuttX TCP/IP stack infrastructure
and it makes driver quite complex... Later we proposed Elektroline.cz
to move focus on SAMV7/SAME70 MCUs due to total incapability of NXP
representants to provide their suggested S32 chip in shorter than years
frame. In this case we have used  Gregory Nut's already provided
MCAN CAN driver and enhanced it for CAN FD and new core revision.
The most CAN drivers n NuttX are based on this character driver
API and at least in the NuttX case and actual development status
I have much better feeling about robustness and RT capabilities
of this solution.

> If you are going to write CAN driver, then you first need to interface
> with the physical hardware which may expect data push to it and pulled
> from it in a certain format. That is probably the reason why you see
> different CAN message formats spread over RTEMS tree.

Yes and it is bad from application point of view. Unfortunately,
there exists more integrated CAN drivers for RTEMS with many different
origins. Probably GRlib is the one really used and tested.

But situation is really suboptimal. I have proposed for RTEMS
to try use and unify support on many years ago (may it be even
before SocketCAN existence), but have never RTEMS project
which could pay at least some my student on this 

Re: AW: AW: [PATCH 12/12] spec/build/cpukit: Add option for enabling PPS synchronization

[Sebastian Huber]

On 12/04/2022 10:22, gabriel.moy...@dlr.de wrote:

In general, the patch set lacks test cases.

I was thinking that the next step could be to add a generic device which is 
required to use the API (a file descriptor is needed). This is

something that wanted to ask in the mailing list first. When this device is 
added, also the test cases can be. Furthermore I wanted to
split the submitted changes in order to make a review easier.

A file descriptor should be optional. It should be possible to add a PPS driver 
just using struct pps_state.


What do you mean with optional?

The RFC 2783 defines only a user API. For example for config the function 
time_pps_setparams() is needed. If we don't follow the RFC 2783, we will need 
to create an RTEMS API. Is that what you mean?


For the user API, using a file descriptor is fine.

I am referring to the PPS driver itself. It should just use struct 
pps_state. A PPS driver may register a device file which can be accessed 
by the user API. Providing a device file should be optional to be able 
to use PPS in applications which do not use a filesystem at all.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

[Karel Gardas]

On 4/12/22 10:05, Chris Johns wrote:

I think there is something else happening here. If I use a 4.11 compiler the
`setenv` call is not seen but `pthread_kill` is. Maybe 6 is more standards
compliant? I do not know.

I am porting a large piece of existing code to RTEMS and that code compiles and
runs on current Linux systems.

Why does Linux build this code and we do not?

Should we be compatible or standards compliant?


This is million dollar question.

But I can offer just simple advice: try to compile the code in question 
on Solaris (11 or even better 10). In the past it was much more strict 
about standard than both Linux and BSD camp hence I usually used that 
for detecting: is the code Linux specific or is it written to be more 
portable and standards compliant? It'll just give you a sign although in 
this particular case of C/C++ integration it may not work that well...


Good luck!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

AW: AW: [PATCH 12/12] spec/build/cpukit: Add option for enabling PPS synchronization

[Gabriel.Moyano]

> >
> >> In general, the patch set lacks test cases.
> >
> > I was thinking that the next step could be to add a generic device which is 
> > required to use the API (a file descriptor is needed). This is
> something that wanted to ask in the mailing list first. When this device is 
> added, also the test cases can be. Furthermore I wanted to
> split the submitted changes in order to make a review easier.
> 
> A file descriptor should be optional. It should be possible to add a PPS 
> driver just using struct pps_state.
> 
What do you mean with optional?

The RFC 2783 defines only a user API. For example for config the function 
time_pps_setparams() is needed. If we don't follow the RFC 2783, we will need 
to create an RTEMS API. Is that what you mean?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH 12/12] spec/build/cpukit: Add option for enabling PPS synchronization

[Chris Johns]

On 12/4/2022 5:04 pm, Sebastian Huber wrote:
> On 12/04/2022 03:29, Chris Johns wrote:
>> On 8/4/2022 3:48 pm, Sebastian Huber wrote:
>>> On 08/04/2022 02:45, Chris Johns wrote:
 On 7/4/2022 9:56 pm, Sebastian Huber wrote:
> We should avoid new CPU options in general.
 Is this documented with a suitable rational?
>>> This could be something for:
>>>
>>> https://docs.rtems.org/branches/master/eng/coding-conventions.html
>>>
>> I do not know the reason so I cannot say :)
> 
> I thought you were one of the strongest opponents against build configuration
> options. 

And I still am. I had forgotten this is related to that header.

> Every binary option in  basically doubles the
> testing effort.

Agreed and I think the location you said is good for documenting this.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

[Chris Johns]

On 12/4/2022 5:18 pm, Karel Gardas wrote:
> 
> Not sure, but isn't usage of C headers in C++ deprecated for a long time now?
> Shouldn't you use csignal and cstdlib? 

These functions are not defined in a C++ namespace so you are required to use C
functions to use them. I am not what the rational is but I am sure there is one.

> Newlib provided for RTEMS looks to push
> that even a bit further by providing C++ specific stdlib.h (in include/c++ and
> in include/c++/tr1) which just includes cstdlib and exports symbols out from 
> std
> name space and this way basically hides C specific stdlib.h
> 
> I'd bet newlib is more correct here, but I'm no expert...
> 
> Anyway in the c++/newlib case and if you really insist on c++ compiler here,

The issue is not what I want. I would simply manage this issue some other way,
ie a C call that wraps the functions I wish to use. :)

> have you tried to use include_next trick by defining
> _GLIBCXX_INCLUDE_NEXT_C_HEADERS? See include/c++/stdlib.h from tools...

I think there is something else happening here. If I use a 4.11 compiler the
`setenv` call is not seen but `pthread_kill` is. Maybe 6 is more standards
compliant? I do not know.

I am porting a large piece of existing code to RTEMS and that code compiles and
runs on current Linux systems.

Why does Linux build this code and we do not?

Should we be compatible or standards compliant?

Chris

> 
> Karel
> 
> On 4/12/22 08:44, Chris Johns wrote:
>> Hi,
>>
>> The following code:
>>
>> // aarch64-rtems6-g++ -std=c++98 -c test.o test.cpp
>> // aarch64-rtems6-g++ -std=c++03 -c test.o test.cpp
>> // aarch64-rtems6-g++ -std=c++11 -c test.o test.cpp
>> // aarch64-rtems6-g++ -std=c++17 -c test.o test.cpp
>> #include 
>> #include 
>> void t1(pthread_t thread) {
>>    ::setenv("ABC", "123", 0);
>>    ::pthread_kill(thread, SIGINT);
>> }
>>
>> produces:
>>
>> $ arm-rtems6-g++ -std=c++17 -c -o test.o test.cpp
>>
>>
>>
>>
>>
>>
>> test.cpp: In function 'void t1(pthread_t)':
>> test.cpp:8:5: error: '::setenv' has not been declared; did you mean 'getenv'?
>>  8 |   ::setenv("ABC", "123", 0);
>>    | ^~
>>    | getenv
>> test.cpp:9:5: error: '::pthread_kill' has not been declared; did you mean
>> 'pthread_key_t'?
>>  9 |   ::pthread_kill(thread, SIGINT);
>>    | ^~~~
>>    | pthread_key_t
>>
>> The same code compiles fine on FreeBSD:
>>
>> $ c++ -std=c++17 -c -o ../test.o ../test.cpp
>>
>>
>>
>>
>>
>>
>> $ c++ --version
>> FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
>> 6.0.0)
>> Target: x86_64-unknown-freebsd11.2
>> Thread model: posix
>> InstalledDir: /usr/bin
>>
>> and Linux:
>>
>> $ g++ -std=c++17 -c -o test.o test.cpp
>> $ g++ --version
>> g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
>> Copyright (C) 2021 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> Is there something broken in our newlib?
>>
>> Thanks
>> Chris
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

[Karel Gardas]

Not sure, but isn't usage of C headers in C++ deprecated for a long time 
now? Shouldn't you use csignal and cstdlib? Newlib provided for RTEMS 
looks to push that even a bit further by providing C++ specific stdlib.h 
(in include/c++ and in include/c++/tr1) which just includes cstdlib and 
exports symbols out from std name space and this way basically hides C 
specific stdlib.h


I'd bet newlib is more correct here, but I'm no expert...

Anyway in the c++/newlib case and if you really insist on c++ compiler 
here, have you tried to use include_next trick by defining 
_GLIBCXX_INCLUDE_NEXT_C_HEADERS? See include/c++/stdlib.h from tools...


Karel

On 4/12/22 08:44, Chris Johns wrote:

Hi,

The following code:

// aarch64-rtems6-g++ -std=c++98 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++03 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++11 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++17 -c test.o test.cpp
#include 
#include 
void t1(pthread_t thread) {
   ::setenv("ABC", "123", 0);
   ::pthread_kill(thread, SIGINT);
}

produces:

$ arm-rtems6-g++ -std=c++17 -c -o test.o test.cpp






test.cpp: In function 'void t1(pthread_t)':
test.cpp:8:5: error: '::setenv' has not been declared; did you mean 'getenv'?
 8 |   ::setenv("ABC", "123", 0);
   | ^~
   | getenv
test.cpp:9:5: error: '::pthread_kill' has not been declared; did you mean
'pthread_key_t'?
 9 |   ::pthread_kill(thread, SIGINT);
   | ^~~~
   | pthread_key_t

The same code compiles fine on FreeBSD:

$ c++ -std=c++17 -c -o ../test.o ../test.cpp






$ c++ --version
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
6.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin

and Linux:

$ g++ -std=c++17 -c -o test.o test.cpp
$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Is there something broken in our newlib?

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH 12/12] spec/build/cpukit: Add option for enabling PPS synchronization

[Sebastian Huber]

On 12/04/2022 03:29, Chris Johns wrote:

On 8/4/2022 3:48 pm, Sebastian Huber wrote:

On 08/04/2022 02:45, Chris Johns wrote:

On 7/4/2022 9:56 pm, Sebastian Huber wrote:

We should avoid new CPU options in general.

Is this documented with a suitable rational?

This could be something for:

https://docs.rtems.org/branches/master/eng/coding-conventions.html


I do not know the reason so I cannot say :)


I thought you were one of the strongest opponents against build 
configuration options. Every binary option in  
basically doubles the testing effort.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 BSP tree refactoring proposal.

[Sebastian Huber]

Hello Karel,

On 07/04/2022 13:07, Karel Gardas wrote:


Hello Sebastian,

I'd like to propose following STM32H7 BSP tree refactoring:

- move BSP's board dependent bits into boards//name> directory


- get rid of very complex (merged for 3 boards already) 
start/system_stm32h7xx.c file


- get rid of start/ext-mem-ctl.c file (as this is split off of 
system_stm32h7xx.c file anyway)


- in board directory use STM32 IDE provided system_stm32h7xx.c board 
specific file whenever supported (e.g. supplied by STM)


- in board directory allow usage of BSP files provided by ST Micro. E.g.

https://github.com/STMicroelectronics/stm32h7b3i-dk
https://github.com/STMicroelectronics/stm32h743i-eval


Pros:
- simplification of merging of future changes in STM provided 
system_stm32h7xx.c files (and others)

- simplification of doing board specific changes

Cons:
- a bit more duplicated code, not in bsp binary build, but in the tree


if it simplifies working with the STM provided files, this change is fine.




I already did proposed changes in my branch on github.com: 
https://github.com/karelfv/rtems/tree/stm32h7-boards-refactoring


All three supported BSPs compile with defaults and 7b3i-dk even run on 
my board. Can't test others due to missing hardware.



Please review the directory structure and let me know what do you think 
about it?


No, the tree is not ready for merge yet as this is done in one big 
commit. If you agree with the structure I'll clean it up and do more 
fine grained commits for merge preparation.


It looks good, thanks.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN driver message structure

[Karel Gardas]

Hi Prashanth,

not sure about others but Pavel Pisa is CAN expert here. CCing him 
directly as I've not seen him active recently.


Anyway, as a non-expert I'd like to offer my hopefully not that 
misleading point of view.


If you are going to write CAN driver, then you first need to interface 
with the physical hardware which may expect data push to it and pulled 
from it in a certain format. That is probably the reason why you see 
different CAN message formats spread over RTEMS tree.


But your approach or intuition of providing generic CAN message format 
is of course right here. The problem is, such messsage format then needs 
to be part of some CAN-related API which is used by user application. 
There are several ways how to design such API, but if we like to stay 
more generic, it's probably better to look around and see what people 
are already using.


- in Linux world, there is a push to SocketCAN: 
https://en.wikipedia.org/wiki/SocketCAN and 
https://www.kernel.org/doc/html/latest/networking/can.html
The API is also considered to be implemented or already implemented on 
top of some RTOSes like NuttX and Zephyr:

https://forum.opencyphal.org/t/socketcan-api-on-a-rtos/750
https://docs.zephyrproject.org/2.6.0/samples/net/sockets/can/README.html

- the other crowd is pushing CANopen which not only provides whole 
layered architecture, but also its own API:

https://en.wikipedia.org/wiki/CANopen
https://canopen-stack.org/v4.2/api/node/

I would definitely wait for Pavel message to know where the wind is 
blowing in industry these days and which API is most probably to be used 
in the future.


Cheers,
Karel

On 4/12/22 02:40, Prashanth S wrote:

Hi All,

This is to query on CAN message format for CAN drivers.

I want to implement a CAN driver for BeagleBone Black in RTEMS(GSoC).

As I looked through the RTEMS Source Tree, found
https://devel.rtems.org/browser/rtems/bsps/arm/lpc176x/can

, https://devel.rtems.org/browser/rtems/bsps/powerpc/gen5200/mscan

CAN drivers, which have driver specific CAN message structure.

https://devel.rtems.org/browser/rtems/bsps/powerpc/gen5200/include/bsp/mscan.h
struct can_message {
   /* uint16_t mess_len; */
   uint16_t mess_id;
   uint16_t mess_time_stamp;
   uint8_t  mess_data[MSCAN_MAX_DATA_BYTES];
   uint8_t  mess_len;
   uint8_t  mess_rtr;
   uint32_t toucan_tx_idx;
};

https://devel.rtems.org/browser/rtems/bsps/arm/lpc176x/include/bsp/can.h
typedef union {
   low_level_can_message low_level;
   registers_can_message registers;
  } can_message;

I would like to know if I should define a driver dependent CAN message
structure or use one of the existing ones.

Ideally, I think a generic (driver independent) CAN message structure will
help applications to be portable.

Regards
Prashanth S
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

libc functions from c++ issues

[Chris Johns]

Hi,

The following code:

// aarch64-rtems6-g++ -std=c++98 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++03 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++11 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++17 -c test.o test.cpp
#include 
#include 
void t1(pthread_t thread) {
  ::setenv("ABC", "123", 0);
  ::pthread_kill(thread, SIGINT);
}

produces:

$ arm-rtems6-g++ -std=c++17 -c -o test.o test.cpp






test.cpp: In function 'void t1(pthread_t)':
test.cpp:8:5: error: '::setenv' has not been declared; did you mean 'getenv'?
8 |   ::setenv("ABC", "123", 0);
  | ^~
  | getenv
test.cpp:9:5: error: '::pthread_kill' has not been declared; did you mean
'pthread_key_t'?
9 |   ::pthread_kill(thread, SIGINT);
  | ^~~~
  | pthread_key_t

The same code compiles fine on FreeBSD:

$ c++ -std=c++17 -c -o ../test.o ../test.cpp






$ c++ --version
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
6.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin

and Linux:

$ g++ -std=c++17 -c -o test.o test.cpp
$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Is there something broken in our newlib?

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel