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

[PATCH] updated HAL_GetTick function

diff --git a/bsps/arm/stm32h7/start/bspstart.c b/bsps/arm/stm32h7/start/bspstart.c index 2fc8133cca..e6e995a50c 100644 --- a/bsps/arm/stm32h7/start/bspstart.c +++ b/bsps/arm/stm32h7/start/bspstart.c @@ -32,9 +32,10 @@ #include +/* Get number of milliseconds elapsed since startup */ uint32_t

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

[PATCH] Fixes for TMS570 BSP

When compiling the lwIP port for the TMS570, there were issues with the BSP. Headers are expected in a folder named ti_herc which did not exist. This fixes the issue. Furthermore, there were multiple warnings about define redefinitions. This was fixed as well. --- bsps/arm/tms570/include/bsp/irq.

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: Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board

I'll start by saying that AArch64 RTEMS on QEMU (for which there is a ZynqMP hardware model) works great and is what the current BSP targets. The current status of AArch64 RTEMS on real hardware is not as simple as I'd like, but it's possible and I've run the uniprocessor testsuite tests on an

Re: OS Neutrality in Python Development Guidelines?

On 19/04/2021 00:29, Chris Johns wrote: On 16/4/21 3:28 pm, Sebastian Huber wrote: On 15/04/2021 22:58, Gedare Bloom wrote: I guess we should define something to add here? Is anything written somewhere we can adopt? the spirit of the Python guide is to have rules which are enforced by tools.

Re: [PATCH] clock:_TOD_To_seconds(): Fix year 2514 overflow

On 13/04/2021 18:03, Sebastian Huber wrote: Hello, On 08/04/2021 15:41, Frank Kuehndel wrote: +/** + *  @brief Latest year to which a time of day can be initialized. + * + *  The following constant defines the latest year to which an + *  RTEMS time of day can be set using rtems_clock_set(). +

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

On Sun, Apr 18, 2021 at 9:12 AM G S Niteesh Babu wrote: > > Adds "rtems,path" as an additional bus path for the i2c driver. > Previously the bus path was provided in "rtems,i2c-path" property > only. > --- > rtemsbsd/sys/dev/iicbus/rtems-i2c.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 d

Re: [PATCH] updated HAL_GetTick function

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 > 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

Re: [PATCH] updated HAL_GetTick function

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 > > Date: Mon, 19 Apr 2021 10:39:55 +0200 > > Subject: [PATCH] updated HAL_GetTic

Re: [PATCH] clock:_TOD_To_seconds(): Fix year 2514 overflow

It is reasonable. Let's capture the analysis. I thought there was a place we had notes related to different time source overflows, but I can't find it quickly On Mon, Apr 19, 2021 at 9:44 AM Sebastian Huber wrote: > > On 13/04/2021 18:03, Sebastian Huber wrote: > > > Hello, > > > > On 08/04/2021

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

On Mon, Apr 19, 2021 at 9:55 PM Gedare Bloom wrote: > On Sun, Apr 18, 2021 at 9:12 AM G S Niteesh Babu > wrote: > > > > Adds "rtems,path" as an additional bus path for the i2c driver. > > Previously the bus path was provided in "rtems,i2c-path" property > > only. > > --- > > rtemsbsd/sys/dev/ii

Re: OS Neutrality in Python Development Guidelines?

On Mon, Apr 19, 2021 at 9:36 AM Sebastian Huber wrote: > > On 19/04/2021 00:29, Chris Johns wrote: > > > On 16/4/21 3:28 pm, Sebastian Huber wrote: > >> On 15/04/2021 22:58, Gedare Bloom wrote: > >>> I guess we should define something to add here? Is anything written > >>> somewhere we can adopt?

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

Hello Niteesh, On 19/04/2021 18:45, Niteesh G. S. wrote: On Mon, Apr 19, 2021 at 9:55 PM Gedare Bloom > wrote: On Sun, Apr 18, 2021 at 9:12 AM G S Niteesh Babu mailto:niteesh...@gmail.com>> wrote: > > Adds "rtems,path" as an additional bus path for

Re: OS Neutrality in Python Development Guidelines?

On Sun, Apr 18, 2021 at 5:20 PM Joel Sherrill wrote: > > > > On Sun, Apr 18, 2021, 5:29 PM Chris Johns wrote: >> >> On 16/4/21 3:28 pm, Sebastian Huber wrote: >> > On 15/04/2021 22:58, Gedare Bloom wrote: >> >> I guess we should define something to add here? Is anything written >> >> somewhere we

Re: [PATCH] Fixes for TMS570 BSP

Hi Robin, Pavel: On Mon, Apr 19, 2021 at 2:57 AM Robin Müller wrote: > > If this was intentional, I can also adapt the lwIP port sources to use > ti/herc. I was not sure about that. > I think Pavel should comment. I believe at the time care was taken to avoid importing TI HalCoGen code generatio

[PATCH rtems-net-legacy v2] bsp_drivers: Use os.path for compatibility with non Unix host

--- bsp_drivers.py | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/bsp_drivers.py b/bsp_drivers.py index 3ca10c6..ec25c23 100644 --- a/bsp_drivers.py +++ b/bsp_drivers.py @@ -36,18 +36,18 @@ def bsp_files(bld): include_dirs = {} include_files

Re: [PATCH rtems-net-legacy v2] bsp_drivers: Use os.path for compatibility with non Unix host

On Mon, Apr 19, 2021 at 11:30 AM Vijay Kumar Banerjee wrote: > > --- > bsp_drivers.py | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) > > diff --git a/bsp_drivers.py b/bsp_drivers.py > index 3ca10c6..ec25c23 100644 > --- a/bsp_drivers.py > +++ b/bsp_drivers.py > @

Re: [PATCH] updated HAL_GetTick function

On 19/04/2021 18:42, 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 Date: Mon, 19 Apr 2021 10:39:55 +0200 Subject: [PATCH]

[PATCH libBSD v2] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

Adds "rtems,path" as an additional bus path for the i2c driver. Previously the bus path was provided in "rtems,i2c-path" property only. --- rtemsbsd/sys/dev/iicbus/rtems-i2c.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c b/rtemsbs

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

Hello Christian, On Mon, Apr 19, 2021 at 10:18 PM Christian Mauderer wrote: > Hello Niteesh, > > On 19/04/2021 18:45, Niteesh G. S. wrote: > > > > > > On Mon, Apr 19, 2021 at 9:55 PM Gedare Bloom > > wrote: > > > > On Sun, Apr 18, 2021 at 9:12 AM G S Niteesh Babu >

[PATCH] score: Remove unused _Thread_queue_Dequeue()

--- cpukit/include/rtems/score/threadqimpl.h | 51 cpukit/score/src/threadqenqueue.c| 32 --- 2 files changed, 83 deletions(-) diff --git a/cpukit/include/rtems/score/threadqimpl.h b/cpukit/include/rtems/score/threadqimpl.h index 88aba49a68..ca59de9e3

[PATCH rtems-docs] legacy-networking: Add note with build instructions for rtems-net-legacy

--- legacy-networking/index.rst | 1 + legacy-networking/quick_start.rst | 29 + 2 files changed, 30 insertions(+) create mode 100644 legacy-networking/quick_start.rst diff --git a/legacy-networking/index.rst b/legacy-networking/index.rst index b85119d..acbfd35

Re: OS Neutrality in Python Development Guidelines?

On 19/04/2021 18:48, Gedare Bloom wrote: A random pick of a file and a brief scan ... https://git.rtems.org/rtems-central/tree/rtemsspec/interface.py#n313 There is no issue in this line. I believe some can configure their git to inject \n\r on clone/pull and fixes it up on commit. I have to

Re: [PATCH] Fixes for TMS570 BSP

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, 2021 at 2:57 AM Robin Müller > wrote: > > If this was intentional, I can also adapt the lwIP port sources to use > > ti/herc. I was not sure

Re: [PATCH v1 1/3] cpukit: Add signal mapping support

On 4/18/2021 20:18, Chris Johns wrote: On 19/4/21 9:23 am, Joel Sherrill wrote: On Sun, Apr 18, 2021, 5:13 PM Chris Johns mailto:chr...@rtems.org>> wrote: On 17/4/21 10:00 am, Kinsey Moore wrote: > On 4/16/2021 08:48, Gedare Bloom wrote: >> On Fri, Apr 16, 2021 at 1:19 AM Sebast

Re: [PATCH] score: Remove unused _Thread_queue_Dequeue()

OK. Interesting, was this previously used and something changed? On Mon, Apr 19, 2021 at 12:08 PM Sebastian Huber wrote: > > --- > cpukit/include/rtems/score/threadqimpl.h | 51 > cpukit/score/src/threadqenqueue.c| 32 --- > 2 files changed, 83 deleti

Re: OS Neutrality in Python Development Guidelines?

On 20/4/21 2:52 am, Gedare Bloom wrote: > The biggest issues are paths and CaseSensitive filesystems. I'm sure > there are other hidden brambles though. Path length in Windows ... https://git.rtems.org/rtems-tools/tree/rtemstoolkit/path.py#n63 Chris __

Re: [PATCH] score: Remove unused _Thread_queue_Dequeue()

On 19/04/2021 21:12, Gedare Bloom wrote: OK. Interesting, was this previously used and something changed? This was previously used (some years ago). Changes for the SMP support made it unused at some point. I reviewed this code recently and there are more things left to clean up. -- embedded

Re: OS Neutrality in Python Development Guidelines?

On 20/4/21 4:12 am, Sebastian Huber wrote: > On 19/04/2021 18:48, Gedare Bloom wrote: > A random pick of a file and a brief scan ... https://git.rtems.org/rtems-central/tree/rtemsspec/interface.py#n313 >>> There is no issue in this line. I disagree. At a technical level there is an

[PATCH] bsps/arm: Set MSP in ARMv7-M start code

This helps if applications are started by a boot loader. --- bsps/arm/shared/start/start.S | 8 1 file changed, 8 insertions(+) diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S index 50bf1d4841..bd623178ed 100644 --- a/bsps/arm/shared/start/start.S +++ b/bsps/ar

Re: [PATCH v1 1/3] cpukit: Add signal mapping support

On 20/4/21 5:02 am, Kinsey Moore wrote: > On 4/18/2021 20:18, Chris Johns wrote: >> On 19/4/21 9:23 am, Joel Sherrill wrote: >>> >>> On Sun, Apr 18, 2021, 5:13 PM Chris Johns >> > wrote: >>> >>> On 17/4/21 10:00 am, Kinsey Moore wrote: >>> > On 4/16/2021 08:48, Ge

Re: [PATCH] bsps/arm: Set MSP in ARMv7-M start code

On 20/4/21 3:28 pm, Sebastian Huber wrote: > This helps if applications are started by a boot loader. How does it help? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/arm: Set MSP in ARMv7-M start code

On 20/04/2021 07:30, Chris Johns wrote: On 20/4/21 3:28 pm, Sebastian Huber wrote: This helps if applications are started by a boot loader. How does it help?     /*      * Set the Main Stack Pointer (MSP) to the ISR stack area end just in      * case we run using the Process Stack Pointer (PS

Re: [PATCH v1 1/3] cpukit: Add signal mapping support

On 20/04/2021 07:30, Chris Johns wrote: We need a way for libdebugger or any other piece of software to capture and cascade the call. If this can be done on aarch64 then I am happy. The fatal error extensions execute in a user controllable order. You can for example register a libdebugger han

Re: [PATCH v1 1/3] cpukit: Add signal mapping support

On 20/4/21 3:54 pm, Sebastian Huber wrote: > On 20/04/2021 07:30, Chris Johns wrote: > >> We need a way for libdebugger or any other piece of software to capture and >> cascade the call. If this can be done on aarch64 then I am happy. > > The fatal error extensions execute in a user controllable

Re: [PATCH v1 1/3] cpukit: Add signal mapping support

On 20/04/2021 08:30, Chris Johns wrote: On 20/4/21 3:54 pm, Sebastian Huber wrote: On 20/04/2021 07:30, Chris Johns wrote: We need a way for libdebugger or any other piece of software to capture and cascade the call. If this can be done on aarch64 then I am happy. The fatal error extensions

Re: [PATCH v1 1/3] cpukit: Add signal mapping support

On 20/4/21 4:38 pm, Sebastian Huber wrote: > > On 20/04/2021 08:30, Chris Johns wrote: >> On 20/4/21 3:54 pm, Sebastian Huber wrote: >>> On 20/04/2021 07:30, Chris Johns wrote: >>> We need a way for libdebugger or any other piece of software to capture and cascade the call. If this can b