On Mon, Jan 11, 2016 at 1:25 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:
> Well, we could still use the patch you sent with the protection in is
> pending, but I think this will break the BSPs I mentioned, since you
> changed timecounter functions signatures. Am I right?
>
>
Let's
Well, we could still use the patch you sent with the protection in is
pending, but I think this will break the BSPs I mentioned, since you
changed timecounter functions signatures. Am I right?
On Mon, Jan 11, 2016 at 4:18 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
Hello,
I already created a ticket which blocks the 4.11 release for this bug:
https://devel.rtems.org/ticket/2502
I sent a new version of the patch to one of your previous threads some days ago:
https://lists.rtems.org/pipermail/devel/2016-January/013289.html
There is still a bug in it, since
I made a fast search:
These BSPs use *rtems_timecounter_simple_downcounter*:
arm/shared/armv7m
m68k/mcf52235
m68k/mcf5225x
m68k/mcf5329
m68k/uC5282
powerpc/mpc55xxevb
sparc/erc32
sparc/leon2
sparc/leon3
sparc/shared
These use *rtems_timecounter_simple_upcounter*:
powerpc/mpc55xxevb
arm/lpc22xx
We
On Mon, Jan 11, 2016 at 12:28 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:
> I will issue a ticket. But I noticed that in my patch I include changes to
> common code that Sebastian suggested, and this will break any other BSP
> that uses rtems timecounter simple downcounter or upco
I will issue a ticket. But I noticed that in my patch I include changes to
common code that Sebastian suggested, and this will break any other BSP
that uses rtems timecounter simple downcounter or upcounter, since these
function's signatures changed. Should we update all BSPs? Or make changes
more
At this point, a ticket is needed for anything applied to 4.11 that is not
release
mechanics related.
--joel
On Mon, Jan 11, 2016 at 11:47 AM, Marcos Diaz <
marcos.d...@tallertechnologies.com> wrote:
> Hi Sebastian,
>
> we did some more testing and found out what's causing the problem. Based
> o
Hi Sebastian,
we did some more testing and found out what's causing the problem. Based on what
I posted at https://lists.rtems.org/pipermail/devel/2015-December/013235.html,
the problem arises when the ticker interrupt occurs while a task is executing
one of the instructions that make up the follo
On Mon, Jan 4, 2016 at 2:04 PM, Joel Sherrill wrote:
>
>
> On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>>
>>
>> On 23/12/15 22:22, Marcos Díaz wrote:
>>
>>> That patch didn't work,
>>> one reason is that it has a mistake:
>>> in kern_tc.c you d
On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
>
> On 23/12/15 22:22, Marcos Díaz wrote:
>
>> That patch didn't work,
>> one reason is that it has a mistake:
>> in kern_tc.c you defined this macro:
>>
>> #define _Timecounter_Release(lock_context) \
>
On 23/12/15 22:22, Marcos Díaz wrote:
That patch didn't work,
one reason is that it has a mistake:
in kern_tc.c you defined this macro:
#define _Timecounter_Release(lock_context) \
+ *_ISR_lock_ISR_disable_and_acquire*(&_Timecounter_Lock, lock_context)
I think you meant:
*_ISR_lock_Release_a
That patch didn't work,
one reason is that it has a mistake:
in kern_tc.c you defined this macro:
#define _Timecounter_Release(lock_context) \
+ *_ISR_lock_ISR_disable_and_acquire*(&_Timecounter_Lock, lock_context)
I think you meant:
*_ISR_lock_Release_and_ISR_enable*(&_Timecounter_Lock, l
Hello Marcos,
yes, nested interrupts are a problem for the current implementation. Its
a general problem of the RTEMS testsuite that we cannot test nested
interrupts. I think we have to fix this at some time.
Could you please test the attached patch?
--
Sebastian Huber, embedded brains GmbH
Hi, thanks for answering, but spnsext01 test works ok.
After a while I noticed the problem:
The ticker interrupt has lower priority than any irq. When I entered the
ticker:
The bit PENDSTSET of the ICSR register that was used to check whether the
sysclk had a pending interrupt or not went to 0,
Bu
Hello,
works the spnsext01 test on your target?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese
On Fri, 2015-12-18 at 16:18 -0300, Marcos Díaz wrote:
> Hi, i'm using c++ chrono to measure a steady signal periods (With
> GPIO
> interrupts), And I see that periodically I have errors of +1ms and
> then of
> -1ms. (I discarded GPIOP interrupts problem) I tried using rtems
> API's
> rtems_clock_ge
Hi, i'm using c++ chrono to measure a steady signal periods (With GPIO
interrupts), And I see that periodically I have errors of +1ms and then of
-1ms. (I discarded GPIOP interrupts problem) I tried using rtems API's
rtems_clock_get_uptime_nanoseconds
and then I saw the same errors.
I'm suspecting
17 matches
Mail list logo
