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
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
expo
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 i
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 documente
> >
> >> 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 t
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
r
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. Whe
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 capa
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 mis
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 - A
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 d
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
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.
--
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
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
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 un
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 Ol
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(
-as
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
19 matches
Mail list logo
