From mboxrd@z Thu Jan 1 00:00:00 1970 From: "eladyaakovi@campus.technion.ac.il" Date: Thu, 22 Jun 2017 15:21:41 +0000 Message-ID: References: , , , , , In-Reply-To: Content-Language: he-IL MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: Re: [Xenomai] Toggling GPIO RT Xenomai on Dragonboard 41c List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Giulio Moro , "xenomai@xenomai.org" Thanks for your answer, the fprintf is not an issue (I have tried with rt_printf too) rt_task_sleep(1000000000) rt_task_sleep(1000) oscilloscope measure 30 ms for both. ________________________________ =EE=E0=FA: Giulio Moro =FE=FE=F0=F9=EC=E7: =E9=E5=ED =E7=EE=E9=F9=E9 22 =E9=E5=F0=E9 2017 18:12:51 =FE=FE=E0=EC: Elad Yaakovi; xenomai@xenomai.org =FE=FE=F0=E5=F9=E0: Re: Toggling GPIO RT Xenomai on Dragonboard 41c > Is there any other sleep function for real time ? That is the correct sleep function for real time, and the sleep time is exp= ressed in nanoseconds, so you are trying to sleep for 1 microsecond, which = is well beyond Xenomai's capabilities on many (all?) platforms. Minimum lat= ency values are around 30 - 60 microseconds, if I am not mistaken. >> Are you using some Xenomai wrappers or is `fprintf` actually calling the= stdlib `fprintf` ? if that is a stdlib `fprintf` then you have no timing guarantees there, bec= ause your thread switches to secondary mode (linux mode) and so you can exp= ect ANY delay instead of the requested one. That delay would then be due to= the `rt_task_sleep()` but to the `fprintf`. Then, again, I have no idea what your file descriptor is, what `fprintf` is= or how you are measuring this "30ms" delay, so I cannot help further.