Hi,
I saw an event basically means setting a bit in a 32 bit integer, so, yes,
they don't queue.
I got into the same issue with
rtems_message_queue_receive(RTEMS_NO_TIMEOUT), it blocks even
if there are messages in the queue like I said. Not even
rtems_message_queue_receive without timeout
didn't r
Hello Dwaine,
On 20/09/2018 18:58, Molock, Dwaine S. (GSFC-5820) wrote:
Hello Sebastian,
Which FPGA development board and RISC-V design did you use for implementation
and testing?
I used a Digilent Genesys2 with a custom SoC with Rocket and BOOM cores.
I tried to port RTEMS to the SiFive E3
On 19/09/2018 16:24, gro...@chichak.ca wrote:
> My initial tests look very promising. I did a clean pull and build and the
> ARM tools built without complaint.
Great. Do you have any macports or homebrew packages installed?
I keep my machines free of these to make sure we build with the most ba
Hello Sebastian,
Which FPGA development board and RISC-V design did you use for implementation
and testing?
Did you use the generic or patched version of QEMU?
Thanks,
Dwaine
> On Sep 6, 2018, at 2:31 AM, Sebastian Huber
> wrote:
>
> Hello Alex,
>
> On 06/09/18 08:28, Slide wrote:
>> Hi Se
Also the subject says message queue and event receive but the scenario
described is just about events. Events do not queue. They are one deep. If
the receiving task ever misses an event send (2 sends before.one receive),
then the described scenario.is expected.
--joel
On Thu, Sep 20, 2018, 7:44 A
On 20/09/2018 15:48, Catalin Demergian wrote:
Hi,
I'm using
#define BSP_ARMV7M_IRQ_PRIORITY_DEFAULT (13 << 4)
13*16=208 > 0x80=128, so I should be on the safe side.
what do you mean by operating system services ?
Everything which uses rtems_interrupt_disable() or
_Thread_Dispatch_disable().
Hi,
I'm using
#define BSP_ARMV7M_IRQ_PRIORITY_DEFAULT (13 << 4)
13*16=208 > 0x80=128, so I should be on the safe side.
what do you mean by operating system services ? like rtems_event_send in
ISR ?
is there other way to handle USB data other than copy data in a buffer in
ISR and signal a kernel
ta
Hello Catalin,
could you please check if you have the same behaviour on the RTEMS master.
On ARMv-7M and RTEMS exceptions and interrupts with a priority value of
less than 0x80 are non-maskable with respect to the operating system and
therefore must not use operating system services. If you us
Hi,
I'm using rtems_interrupt_handler_install now, the issue is the same.
Let me provide some context.
I use an IP layer (SLIP protocol) above the USB so datagrams can flow over
USB.
I'm sending ping packets in loop in a long duration test. After 1/2/3 hours
(it varies),
I don't reply to ping anym
