after add rtc.c

HI, ALL! according to https://www.mail-archive.com/devel@rtems.org/msg03132.html i add a rtc.c file for stm32f4 have added below two lines at makefile.am //RTC libbsp_a_SOURCES += rtc.c libbsp_a_SOURCES += ../../shared/tod.c x - libi2cio_a-i2c-sc620.o x - libi2cio_a-spi-memdrv.o x - libi2cio_

Re: [ANN] GRiSP 2 Kickstarter

Addendum, something important which I forgot because for us its the obvious thing to do: The BSP for GRiSP 1 is already submitted upstream and so will all future BSP work we do on GRiSP 2 > On 18.04.2019, at 17:09, Peer Stritzinger wrote: > > Hi RTEMS users! > > We are making a new version

[ANN] GRiSP 2 Kickstarter

Hi RTEMS users! We are making a new version of our evaluation board for our RTEMS based software stack which allows to run the Erlang VM (in the sense of byte code not virtualization) almost directly on hardware. For details see https://www.grisp.org Short list of features: iM6ULL CPU, 128M

Re: pc686: --enable-rtems-debug not working

On Tue, Apr 16, 2019 at 8:01 AM wrote: > Hello, > > if I build the pc686 BSP with --enable-rtems-debug activated I can't run > any of the testsuites examples, but get the following error: > > $ qemu-system-i386 -append --console=/dev/com1 -no-reboot -serial stdio > -monitor none -nographic -kern

rtems_task_wake_after()/usleep() sleeping less than requested?

With our custom bsp of rtems (based on sparc/leon3 from 4.11.3) we are observing that rtems_task_wake_after() and usleep() quite often sleeps less than the requested amount when measured with rtems_clock_get_uptime_nanoseconds() timestamps. Is this expected behaviour for sleep in rtems or is this