On Thu, 18 Jul 2019 23:07:08 +0100 andy pugh <bodge...@gmail.com> wrote:
> On Thu, 18 Jul 2019 at 22:01, Nicklas Karlsson <nicklas.karlsso...@gmail.com> > wrote: > > > It seems by no suprise writing real time to data to file within real time > > task have a negative impact on likelihood of real time delay. > > > > With RTAI and kernel modules I don't think that is is even possible. > > I tried non blocking fcntl(...) function and O_NONBLOCK flag without > > success. Adding some kind of buffer in for example shared memory between > > written by real time task and let another lower priority task write is a > > solution > > > Take a look at how streamer and hal_streamer do exactly this. Output values are as I could tell round buffer and I guess the filling up mechanism works. I have round buffer implementation on micro controller filled up with high frequency and send several values at a lower priority. There are good margin for overfill so sending is more of fast enough in average. In case values are not sent in time oldest are overwritten and never sent and a counter to keep if this happen. On Micro controller I know high frequency may interrupt lower frequency but no the opposite. Algorithm data is filled in a round buffer and sending/saving process should send/save the tail in not to small blocks. One counter for filling and one for sending/saving should do the trick. Atomic increment including overflow should solve the problem but as each counter is updated by one process only I guess atomic read/write is eough if properly done and I expect using an int will be atomic but maybe there could be an ordering problem if CPU reorder instructions? Or? Regards Nicklas Karlsson _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
