Re: [PATCH] doc improvements

[PATCH] doc improvements is related to ticket https://devel.rtems.org/ticket/4187 which can then be closed On Wed, 2 Dec 2020 at 13:46, Robin Mueller wrote: > --- > user/start/sources.rst | 9 + > user/start/tools.rst | 9 - > 2 files changed, 17 insertions(+), 1 deletion(-)

Re: [PATCH] doc improvements

Actually, I just saw that when switching to the 5 branch for the RTEMS sources, there is no waf tool (at least I can't run it) so later parts of the QuickStart guide won't work.. I could just leave it like that, but then RTEMS 6 is built and all version numbers would have to be corrected.. KInd Re

Re: [PATCH] doc improvements

I will provide another patch with version numbers corrected. Kind Regards Robin On Wed, 2 Dec 2020 at 14:19, Robin Müller wrote: > Actually, I just saw that when switching to the 5 branch for the RTEMS > sources, there is no waf tool (at least I can't run it) so later parts of >

CMake support

Hello, I was wondering whether CMake support or an example is available or will be added in the future. We are using a framework which has different abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but we would like to use the same build system to build applications and right

Re: CMake support

ed, 9 Dec 2020 at 13:59, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Robin, > > you can use whatever build system you want to build your applications. > You can use pkgconfig to get the necessary flags for a particular BSP > installation. > > O

Re: CMake support

Hello, I created a repository on github for the first version of what a CMake support for RTEMS might look like: https://github.com/rmspacefish/rtems-cmake I tried to extract generic components like determining library paths into functions (RTEMSGeneric.cmake) and there is a hardware specific f

Re: CMake support

here: https://github.com/rmspacefish/rtems-cmake. For example, I > could do the exercise of using his Just 3 files to see if our embedded > target would compile and run. No hard promises about the time frames though > until the Christmas holidays :) > > Thank you for your attention.

Re: CMake support

https://github.com/Kitware/CMake/blob/master/Modules/FindPkgConfig.cmake . Kind Regards Robin On Fri, 11 Dec 2020 at 11:14, Robin Müller wrote: > Hi, > > There seems to be positive feedback, thanks for that. > > I can adapt the naming to be more consistent with your system. > My s

Re: CMake support

Hi. I now implemented pkg-config parsing and it works nicely with the tools given by CMake / kitware. I was able to build the hello application with the automatic pkg flag parsing for sparc/erc32, sparc/leon3 and arm/stm32h7. I do not know exactly when this feature was added to be honest. I set th

MSYS2 build: header file missing

Hi, The RSB was updasted because there were some issues with GMP and I tested whether this also fixed my MSYS2 build process for the RTEMS tools. I now get a header file missing error when building newlib: Making all in arm In file included from ../../../../../../../../../../gnu-mirror-gcc-1cd

Quick Start improvements: Tickets updated

Hi, I updated the RTEMS tickets with the patches for the Quick Start guide (also neat that there is the comparison view): BSP tests: https://devel.rtems.org/ticket/4188 Python Encoding Error: https://devel.rtems.org/ticket/4183 Some version 5/6 improvements / clarifications, also added how to w

Re: MSYS2 build: header file missing

If I understand correctly, the BSPs can be installed with waf only if the tool suite for the given architecture has been installed. Problem is, the RSB build will fail even if a tiny component is problematic. I thought the tool suite itself is installed using the build commands required by the sour

Re: MSYS2 build: header file missing

ilder --prefix=/c/Users/Robin/RTEMS/rtems-tools/rtems/6 --no-install --bset-tar-file --host=i686-w64-mingw32 6/rtems-sparc Kind Regards Robin On Fri, 18 Dec 2020 at 12:49, Robin Müller wrote: > If I understand correctly, the BSPs can be installed with waf only if the > tool suite for the given a

Re: MSYS2 build: header file missing

from the current OS? I could try to supply it manually.. Kind Regards Robin On Fri, 18 Dec 2020 at 16:35, Jiri Gaisler wrote: > > On 12/18/20 2:10 PM, Robin Müller wrote: > > In case you're interested, this is the fail report for the SIS Cxc build > on Linux (failed both fo

Re: MSYS2 build: header file missing

Hi Jiri, Thanks for the quick fix. I was able to build sparc-rtems6 on the Windows machine with the fix. So basically, arm-rtesm6 is still problematic because of the missing headers (but worked on Linux using Canadian Cross Compiling) but with sparc-rtems6 it's the other way around, it works on W

Re: [PATCH 1/3] prepared patch

Patch can also be found here: https://devel.rtems.org/ticket/4209#comment:3 Kind Regards Robin On Mon, 4 Jan 2021 at 16:12, Robin.Mueller wrote: > I added the weak attribute to some configuration structs so users can can > supply their own configuration > structs (otherwise I got redeclaration

Re: [PATCH] Squashed commit of the following:

Hello Gedare, I made the consistency changes. I am not sure about wrapping everything in the __rtems__ define, I did wrap the include because every bspopts.h include I saw was wrapped in that as well (if defines inside bspopts.h might be used). I never saw whole code blocks wrapped by that define

Re: [PATCH] This patch adds support for a STM32H7 variation

Hi Sebastian, That would also be a way. The question is whether all other board variation should be included as well. There are 12 boards listed in the STM32CubeH7 repository example applications and I have not checked which pin and HSE values these boards use or if there are any other important d

Re: [PATCH] This patch adds support for a STM32H7 variation

an 8, 2021 at 6:58 AM Robin Müller >> <mailto:robin.muelle...@gmail.com>> wrote: > >> > >> Are they really 12 BSPs or just build variants of this one BSP family? > >> > >> If just variants, I have come full circle on how I feel about having >

Re: [PATCH] STM32H7 doc update

I'd just like to bump my patch. The last changes were just the formatting changes from the code review. Kind Regards Robin On Tue, 12 Jan 2021 at 12:36, Robin Mueller wrote: > --- > > Added doc for board variation, added some fixes > from code review. (typo and line width formatting) > > use

Re: [PATCH] Basic lwIP for STM32H7 BSP

The DMA descriptors need to be placed at the start of the SRAM3 and need to be aligned in a certain way. The RX buffer will take up the first (slightly less than) 16 kB of SRAM3 but needs to be placed behind the DMA descriptors. It also needs to be placed in a way that the MPU configuration require

Re: [PATCH] Basic lwIP for STM32H7 BSP

The following link contains more theoretical information about why these sections were placed at these addresses: https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices Kind Regards Robin On Wed, 3 Feb 2021 at 14:44, Robin Müller wrote: > The DMA descriptors need to

Re: [PATCH] Basic lwIP for STM32H7 BSP

ing the top 16kB of SRAM and the other the 256B that contain the ETH > descriptors. I believe the MPU regions can be set in increments of 32Bytes, > so setting up the cache and buffering should be do-able without affecting > the stack. > Kind Regards Robin Müller On Wed, 3 Feb 202

Re: [PATCH] Basic lwIP for STM32H7 BSP

I think the DMA descriptors need to be 32 byte (0x20) aligned. That's the reason the example application was set up like this. Kind Regards Robin On Wed, 3 Feb 2021 at 15:32, Joel Sherrill wrote: > > > On Wed, Feb 3, 2021, 8:26 AM Robin Müller > wrote: > >> Also,

Re: [PATCH] Basic lwIP for STM32H7 BSP

Could you look into this, based on the existing patch? I don't really have the time to look (deeply) into it in the next few weeks, and the changes are probably easier for you to implement. I can offer to test it though :-) Kind Regards Robin Müller On Thu, 4 Feb 2021 at 14:41, Sebastian

Re: [PATCH] STM32H7 doc update

Hello, Just another bump for the small doc patch and a reminder for another patch I sent, which still needs some smaller adaptations for lwIP ([PATCH] Basic lwIP for STM32H7 BSP) Kind Regards Robin Müller On Thu, 21 Jan 2021 at 13:52, Robin Müller wrote: > I'd just like to bump my pa

Re: [PATCH 2/2] This adds a way to print the host triplet

There is no first patch (the first patch file was a SIS update, but that's already inside master I think). I think I used this when I canadian cross-compiled the RTEMS ARM toolchain for Windows on Linux and I was not sure what the triplet was. Kind Regards Robin On Wed, 24 Feb 2021 at 22:34, Chri

Re: [PATCH 2/2] This adds a way to print the host triplet

Thu, 25 Feb 2021 at 01:30, Chris Johns wrote: > On 25/2/21 9:21 am, Robin Müller wrote: > > There is no first patch (the first patch file was a SIS update, but > that's > > already inside master I think). > > I think I used this when I canadian cross-compiled the RTEMS

Re: [PATCH 2/2] This adds a way to print the host triplet

e was available, I did not have any OS specific issues any more. Kind Regards Robin On Thu, 25 Feb 2021 at 10:44, Robin Müller wrote: > I only used it to CXC the ARM toolchain (Linux -> Windows) mainly because > I have only needed the ARM tool suite up until now (and there were issues >

Re: [PATCH] Basic lwIP for STM32H7 BSP

5, Gedare Bloom wrote: > > > On Thu, Feb 4, 2021 at 10:58 AM Sebastian Huber > > wrote: > >> On 04/02/2021 18:45, Robin Müller wrote: > >> > >>> Could you look into this, based on the existing patch? I don't really > >>> have the time to

Re: [PATCH] Basic lwIP for STM32H7 BSP

. Are those used in the source code? Kind Regards Robin Müller On Mon, 22 Mar 2021 at 11:43, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 03/02/2021 14:50, Robin Müller wrote: > > > The following link contains more theoretical information about why > > th

Re: [PATCH] Basic lwIP for STM32H7 BSP

memory:84: syntax error collect2.exe: error: ld returned 1 exit status Kind Regards Robin On Thu, 25 Mar 2021 at 13:15, Robin Müller wrote: > That is how it was done in the lwIP demo provided by STM, I simply adopted > that. The SRAM3 is small, but big enough for lwIP, so all o

Re: [PATCH] Basic lwIP for STM32H7 BSP

e> wrote: > > On 26/03/2021 11:34, Robin Müller wrote: > > How would you define a generic linker section? I tried to put the > > following section into the > > linkcmdsmemory file like you suggested (at > > spec/build/bsps/arm/stm32h7/linkcmdsmemory.ym

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

Hi Vijay, It looks interesting, but I am not really a LwIP expert. I might look into it once I have more time in 1-2 weeks. I only have a BBB and the STM32H7 as test HW right now, but I guess this is a good starting point. Does this mean that the lwIP repository contains the architecture specific

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

The change with void HAL_ETH_MspInit(ETH_HandleTypeDef *heth) was just that most other function definitions I saw were on one line so I assumed this was a little formatting mistake. I can discard the change if this was intentional. I can add #ifndef __rtems__ for the section with the legacy defin

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

Hello Sebastian, I will have a look at it soon. Kind Regards Robin On Tue, 6 Apr 2021 at 10:01, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Robin, > > sorry for the delay. I checked in some patches to add a > "arm/nucleo-h743zi" BSP variant. Could you please check if th

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

The variant worked without issues. Kind Regards Robin On Fri, 9 Apr 2021 at 09:21, Robin Müller wrote: > Hello Sebastian, > > I will have a look at it soon. > > Kind Regards > Robin > > On Tue, 6 Apr 2021 at 10:01, Sebastian Huber < > sebastian.hu...@embedded-brai

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

I can split up the rest of the patch. I would rename STM32H7_ADD_LWIP from the BSP configuration to RTEMS_USE_LWIP as a more generic variant which could be reused for other BSPs if that is okay. Kind Regards Robin On Mon, 12 Apr 2021 at 10:46, Robin Müller wrote: > The variant worked with

Re: [PATCH 1/4] Implementation for HAL_GetTick

This implementation is problematic because HAL_GetTick is supposed to return elapsed milliseconds since boot and the current implementation assumes there are 1000 ticks per second. I'll send an updated patch. Kind Regards Robin On Mon, 12 Apr 2021 at 11:55, Robin.Mueller wrote: > This commit ad

Re: [PATCH] updated HAL_GetTick function

>From 88ac5780f5597a8bb3bf68c6b37fe6694956faaf Mon Sep 17 00:00:00 2001 From: Robin Mueller Date: Mon, 19 Apr 2021 10:39:55 +0200 Subject: [PATCH] updated HAL_GetTick function Patch text went missing, here is the full version of the patch. Provides implementation for HAL_GetTick but uses RTEMS. A

Re: [PATCH] Fixes for TMS570 BSP

If this was intentional, I can also adapt the lwIP port sources to use ti/herc. I was not sure about that. Kind Regards Robin On Mon, 19 Apr 2021 at 10:55, Robin Mueller wrote: > When compiling the lwIP port for the TMS570, there > were issues with the BSP. Headers are expected in a folder > na

Re: [PATCH] Fixes for TMS570 BSP

have tested everything. Kind Regards Robin On Mon, 19 Apr 2021 at 21:02, Pavel Pisa wrote: > Hello Robin and Gedare, > > (sent again to pass into the list) > > On Monday 19 of April 2021 19:13:29 Gedare Bloom wrote: > > Hi Robin, Pavel: > > > > On Mon, Apr 19,

Re: [PATCH] updated HAL_GetTick function

2, Gedare Bloom wrote: > > > On Mon, Apr 19, 2021 at 10:41 AM Gedare Bloom wrote: > >> On Mon, Apr 19, 2021 at 2:51 AM Robin Müller > wrote: > >>> From 88ac5780f5597a8bb3bf68c6b37fe6694956faaf Mon Sep 17 00:00:00 2001 > >>> From: Robin Mueller > >&g

Re: [PATCH] Updated tick implementation for HAL_GetTick

Okay, there is some issue with the rtems function to get the uptime nanoseconds.. The call appears to crash for some reason. Kind Regards Robin On Tue, 20 Apr 2021 at 18:31, Robin Mueller wrote: > This now uses rtems_clock_get_uptime_nanoseconds > to calculate the uptime ticks in milliseconds.

Re: [PATCH] Updated tick implementation for HAL_GetTick

Yes, I tried to switch oscillator and clock init in the start hook, but that did not appear to solve the issue. Kind Regards Robin On Tue, 20 Apr 2021 at 19:24, Robin Müller wrote: > This is really odd.. THe function is already called in the start up hook > function init_oscillator()

Re: [PATCH 2/4] Patch to avoid nameclash of PAGESIZE define

Hmm thats odd. File was created on Windows. Now im on Ubuntu, and if i try to load it it automatically does something with the line endings of the file taken from upstream/master.. Kind Regards Robin On Tue, 20 Apr 2021 at 19:17, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On

Re: [PATCH] Updated tick implementation for HAL_GetTick

Müller wrote: > Yes, I tried to switch oscillator and clock init in the start hook, but > that did not appear to solve the issue. > > Kind Regards > Robin > > On Tue, 20 Apr 2021 at 19:24, Robin Müller > wrote: > >> This is really odd.. THe function is already called

Re: [PATCH] Patch to avoid nameclash of PAGESIZE define

Does this one work? For some reason the full header was not included.. Kind Regards Robin On Tue, 20 Apr 2021 at 20:11, Robin Mueller wrote: > This commit excludes the PAGESIZE legacy define > because there is a nameclash with a define of the same name > coming from the RTEMS header limits.h. >

Re: [PATCH] Patch attempt two to avoid nameclash of PAGESIZE define

I just resent the patch and I hope this can be applied properly. Like already mentioned, when loading this file in Ubuntu 20.04, something was done to the line endings automatically.. But maybe this is the reason the patch could not be applied before, because I had the same issue of not being able

Re: [PATCH] Updated tick implementation for HAL_GetTick

0 Apr 2021 at 19:48, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 20/04/2021 19:45, Robin Müller wrote: > > > Hmm, do you have an idea how to fix this cleanly? Was this the reason > > the implementation returned 0? > Yes. > > This was not

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

GPIOA 1,2 and 7, GPIOG 11, 12 and 13 and GPIOC 1, 4, 5, the pins above are used. KInd Regards Robin On Mon, 12 Apr 2021 at 11:23, Robin Müller wrote: > I can split up the rest of the patch. > I would rename STM32H7_ADD_LWIP from the BSP configuration to > RTEMS_USE_LWIP as a more generi

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

Actually, the configurations for GPIOA and GPIOC are completely overlapping and could be reused to the NUCLEO BSP. Kind Regards Robin On Wed, 21 Apr 2021 at 11:23, Robin Müller wrote: > I'm sorry I have to dig this up and bother you again but it's something > that i spotted w

Re: [PATCH] Updated tick implementation for HAL_GetTick

.hu...@embedded-brains.de> wrote: > On 21/04/2021 19:30, Sebastian Huber wrote: > > > On 21/04/2021 11:00, Robin Müller wrote: > > > >> Okay, good to know. Do you think it's okay if my simpler > >> implementation is used completely? > >> An

STM32H7 UART pins Update

Hi Sebastian You recently updated the UART pins configuration, allowing different variants. I recently checked the CubeH7 library about pin differences between the NUCLEO and the STM32H7 after finding out about the pin differences for the Ethernet module and I found out some weird things. I checke

Re: STM32H7 UART pins Update

Small corrections: I was always referring to GPIOB PIN9 and PIN10 of course. Kind Regards Robin On Thu, 22 Apr 2021 at 15:20, Robin Müller wrote: > Hi Sebastian > > You recently updated the UART pins configuration, allowing different > variants. > I recently checked the CubeH

Re: STM32H7 UART pins Update

Thanks :-) I was able to omit the HAL_ETH_MspInit override in my lwIP code now. Kind Regards Robin On Thu, 22 Apr 2021 at 15:32, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Robin, > > I hope it is now fixed. For the Ethernet pin customization, you can use > the same appr

Re: STM32H7 UART pins Update

:04, Robin Müller wrote: > Thanks :-) I was able to omit the HAL_ETH_MspInit override in my lwIP code > now. > > Kind Regards > Robin > > On Thu, 22 Apr 2021 at 15:32, Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> Hello Robin, >> &g

Re: [PATCH] Correct NUCLEO-H743ZI Ethernet Pins

Hi Sebastian, How can i specify a define to only be generated for a certain variant and nothing for default? Kind Regards Robin On Thu, 22 Apr 2021 at 19:56, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > > On 22/04/2021 19:35, Robin Mueller wrote: > > > > Please change this to

Re: [PATCH 3/4] Additional define for stmh32xx_hal_uart.h

Ping :) On Mon, 12 Apr 2021 at 11:56, Robin.Mueller wrote: > The DMA include was missing and could lead to compilation > errors for certain cases. > --- > bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/bsps/arm/stm32h7/include/stm32h7xx_ha

Re: [PATCH] Correct NUCLEO-H743ZI Ethernet Pins

I sent a follow-up patch. Kind Regards Robin On Fri, 23 Apr 2021 at 09:45, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 23/04/2021 09:44, Robin Müller wrote: > > > > > How can i specify a define to only be generated for a certain variant > >

Re: [PATCH] Patch attempt two to avoid nameclash of PAGESIZE define

Can you try git apply --reject --whitespace=fix mychanges.patch taken from https://stackoverflow.com/questions/4770177/git-patch-does-not-apply . This worked for me Kind Regards Robin On Fri, 23 Apr 2021 at 12:32, Robin Müller wrote: > Can you try > > git apply --reject --white

Re: [PATCH v2] STM32 lwIP addition and CMake support

Okay, I can understand that you'd like to have one build system only. We had the same issue with a former Makefile build system and the new CMake system and decided to make the former system obsolete because maintaining both of them would be too much work. First thing I can do is that I split up

Re: [PATCH v2] STM32 lwIP addition and CMake support

track the issue list quite regularly. Hopefully there will be an answer soon.. Kind Regards Robin On Tue, 27 Apr 2021 at 18:58, Robin Müller wrote: > Okay, I can understand that you'd like to have one build system only. We > had the same issue with a former Makefile build system and th

Re: [PATCH] STM32 lwIP addition

Should I provide the changes for the code review as a separate patch or should I squash them again? Using the upstream unchanged is tricky because the code was taken from the examples and these examples are always targeted towards a specific API. I changed the version to be usable by both APIs. I

Issues with rtems_waf on Windows 10 with gccdeps module

Hi, I think the following commit in rtems_waf breaks the waf build on Windows 10: commit 096372fc4504730e50b51b952ce47ca603b35f01 Author: Chris Johns Date: Thu Oct 10 17:43:11 2019 +1100 Use gccdeps for dependency scanning. I get the error that RTEMS is not able to find the rtems.h file

Re: [PATCH] STM32 lwIP addition

Small correction: I changed the ethernetif.c file to be usable by all three major APIs. Kind Regards Robin On Wed, 28 Apr 2021 at 11:55, Robin Müller wrote: > Should I provide the changes for the code review as a separate patch or > should I squash them again? > > Using the upstre

Re: [PATCH] STM32 lwIP addition

27;ll send the updated patch with the disclaimer that there are still licensing issues to resolve after cleaning up a bit. Kind Regards Robin On Wed, 28 Apr 2021 at 12:00, Robin Müller wrote: > Small correction: I changed the ethernetif.c file to be usable by all > three major APIs. >

Re: Issues with rtems_waf on Windows 10 with gccdeps module

Users', 'Robin', 'Documents', 'RTEMS', 'rtems-tools', 'rtems', '6', 'sparc-rtems6', 'erc32', 'lib', 'include', 'rtems.h'] for {task 2179590063376: c test.c -> test.c.1.o} no from C

Re: Issues with rtems_waf on Windows 10 with gccdeps module

not sure. Kind Regards Robin On Thu, 29 Apr 2021 at 18:00, Gedare Bloom wrote: > On Thu, Apr 29, 2021 at 9:59 AM Gedare Bloom wrote: > > > > On Thu, Apr 29, 2021 at 3:14 AM Robin Müller > wrote: > > > > > > I replaced the file in rtems_waf manually

Re: Issues with rtems_waf on Windows 10 with gccdeps module

wrote: > Hi all, > > > On Thu, Apr 29, 2021 at 3:01 PM Chris Johns wrote: > > > > On 30/4/21 5:01 am, Robin Müller wrote: > > > Yes that is the prefix. The rtems.h file is definitely located at the > location > > > in the warning and it works on older commit

Re: Issues with rtems_waf on Windows 10 with gccdeps module

The "dirty solution" actually only works if the drive is named C, and maybe the backslashes should not be there in the first place. Maybe you already have dealt with this issue? Kind Regards Robin On Fri, 30 Apr 2021 at 10:36, Robin Müller wrote: > Issue can be reproduced

Re: Issues with rtems_waf on Windows 10 with gccdeps module

n Fri, Apr 30, 2021 at 2:36 AM Robin Müller > wrote: > > > > Issue can be reproduced by doing the quickstart application build on > Windows 10. The issue are backslashes in the absolute paths of the > dependency paths > > which were not stripped from dependency paths on

Re: Issues with rtems_waf on Windows 10 with gccdeps module

I also tried bld.path.find_or_declare('rtems.h') like in the supplied example, but that did not work for me either. Kind Regards Robin On Mon, 3 May 2021 at 14:31, Robin Müller wrote: > Hello Vijay, > > I tried bld.find_or_declare('rtems.h') but that did not

Re: [PATCH v2] STM32 lwIP addition and CMake support

his (maybe even directly in the issue) ? I can forward it to them as well. Thanks a lot in advance! Kind Regards Robin On Wed, 28 Apr 2021 at 02:45, Chris Johns wrote: > On 28/4/21 2:58 am, Robin Müller wrote: > > Okay, I can understand that you'd like to have one build system onl

Re: [PATCH v2] STM32 lwIP addition and CMake support

I posted a reply but I think it did not go through. Will post it now. Kind Regards Robin On Wed, 9 Jun 2021 at 18:31, Robin Müller wrote: > Hi, > > I received a reply from STM32 about the licensing issues. They requested > more specific information about the "vendor device r

Re: [PATCH 2/2] This adds a way to print the host triplet

Hi, I think this patch was forgotten so I'm just pushing it up again :-) Kind Regards Robin On Thu, 25 Feb 2021 at 10:57, Robin Müller wrote: > I still think it would be nice if very common tool suites like ARM could > be installed /downloaded in a pre-compiled way at least

Re: [PATCH] Fixes for TMS570 BSP

Hello, I think this patch was forgotten. Pushing it up :-) Kind regards Robin On Tue, 20 Apr 2021 at 16:56, Robin Müller wrote: > I am currently extending the lwIP port provided by you for the > STM32H743ZI-Nucleo. I am also extending it to be more easily adaptable to > other BSP

Re: Building a library for use with RTEMS via CMake

I managed to compile our project with CMake, using this repository: https://github.com/spacefisch/rtems-cmake It uses the pkg-config files to set up the cross compiler given the BSP and RTEMS prefix information. Maybe this can help you Kind Regards Robin On Tue, 20 Jul 2021 at 00:50, Michael Dav

Re: Building a library for use with RTEMS via CMake

. Kind Regards Robin On Wed, 21 Jul 2021 at 16:48, Robin Müller wrote: > rtems-cmake uses the toolchain file functionality which takes care of > finding the RTEMS compiler and add the required flags for RTEMS. > If the CMakeLists.txt belongs to a library, I would guess you will compile >

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

Hello, I am still waiting on STM32 reply because of the licensing issue. Might still take weeks/months.. Another solution would be to write some scripts to copy the code from the Cube sources.. But I would prefer to avoid them, because I also had to merge some of the files provided by STM so that

Re: [PATCH v2] STM32 lwIP addition and CMake support

So, we need to avoid using their example codes. > > On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom wrote: > > > > I joined the Issue. Thanks for working on this. > > > > On Wed, Jun 9, 2021 at 11:30 AM Robin Müller > wrote: > > > > > > I

Re: [PATCH v3 2/2] update README with instructions for stm32 patch

Hi, This patch now contains all files which have the problematic license so the RTMES LwIP code stays free of them. Actually, it probably would be a better idea if the patch is applied as part of the build process.. Does anyone have experience how to do this with waf? Kind Regards Robin Müller