I got a slimmed down freepascal version of the posix timer example to work; http://www.sytekcom.com/eng/fp_Linux_PosixTimer.html Digging into the types involved, I don't think many appreciate the complexity of C "unions" and the havoc created with 32 bit, 64 bit, and hybrid data and memory types. The system calls might follow posix (portable OS...) but nothing else is portable. So 32 RT signals, and all the other variables and tricks will have to do; "siginfo" handlers only work with C. Even various freepascal types are wrong. Anyway, this freepascal code works on 32 bit opensuse 12.2. And the code doesn't look like chicken footprints in the snow. The comment text is mostly from the timer_create C example as well. As can be seen, with reasonable types defined, plucking C functions for pascal use is quite easy. Reliable microsecond timer accuracy. Rick Engebretson wrote: > Absolutely outstanding. Again, sincere thanks. > > Right now I'm reading "Programming for the Real World; POSIX.4," by > Bill O. Gallmeister; Copyright 1995 by O'Reilly & Associates Inc. The > book is much clearer than the Linux manpages, and explains why these > Posix.4 timers are an important new aspect of Linux (Unix) software. I > got the book many years ago when I thought the Linux 2.4 kernel was > great. Now seeing industrial linux hardware the size of this book with > real-time capabilities, it is a topic worth being aware of I believe. > > Many years ago I did a lot of "libc" adaptation of signals, > semaphores, the UART, etc. in freepascal. It's quite easy really, but > I have not yet found what's in librt; I know it comes with libc. Not > your (C, C++ programmer) problem at all, just a Pascal problem since I > need to know where functions are accessed. > > As for the stripchart XForms program, you are right, I have a lot to > figure out. It still draws reasonably accurate trigometric functions. > It will be a great goal to have a useful set to offer. Since you have > worked Monte Carlo (random) collision chemical reaction kinetics > theory simulations you might like to see how 3 or more sine waves add > up graphically. My outdoor long range television antenna is a good > oversize model of a molecule, with molecule dipoles instead in the > optical wavelength range. Chemistry does not need to be "random." > > Innovation matters. > > Iznogoud wrote: >>> Please look next at manual page "timer_create.2" . This is all new >>> Posix >>> compliance tools. There is an example provided. Apparently, the call >>> even allows you to define several types of clocks and event >>> reporting. I >>> don't understand "threads" and "virtual" stuff, but I do understand a >>> "process." >>> >> I looked at the manual page. Yes, it is all POSIX and in general if your >> application is sticking with unix, you want to stick to POSIX pieces of >> the glibc and the kernel. This particular piece of work, as the manual >> page states, is a mix of kernel work and some glibc pieces. This is very >> good in my opinion (to have most of it in glibc), as the user gets a lot >> of say in what happens during execution. >> >> There is an example given, but I do not think it would be instructive >> for >> you given that you do not touch C or system programming. But, in a >> nutshell, >> the example shows how a signal handler is established (in a special way) >> to trap timer expiration events for this particular process alone. It >> sets >> the signal handler and first blocks trapping of that signal by the >> handler. >> It gives the process time to establish the timer; which is the meanigful >> thing to do. Then, it unblocks the signal handling and sends the main >> process work to sleep. The timer will have expired when the process >> wakes >> up. The pending signal will "fall" into the handler when that happens. >> >> It works as expected. It is not the most instructive example, but it >> does >> do what it promises. I tried it as is and I tried it without blocking >> the >> signal trapping at all. In the former case (original code), it waited >> for >> 1 second before it trapped the signal due to the timer having >> expired. In >> that latter, the handler invoked immediately (after the 100 >> nanoseconds I >> had specified) while the process was starting to go to sleep for a >> second. >> >> One more (possibly instructive to you) point. If you follow this >> model of >> using HRTs and want to work with signals that are picked from specific >> timers, you will have to provide handler functions. Those become >> detached >> POSIX threads (is my understanding) to execute the handler code. >> There is >> no other way, if you think about it. You can certainly achieve >> realtimeness >> that way. Or you can engineer your UI so that it traps signals and then >> re-freshes the screen at constant framerate. A thread in the backend can >> do all intensive work and set a flag for what it is done. The main >> loop of >> the UI keeps checking the flag and draws new things when the flag is set >> and it unsets it. Really easy to program... >> >> >>> Using freepascal 3.0.0 to access C library calls isn't hard. But the >>> timer_create manpage also indicates a needed link to "-lrt" . The >>> freepascal team has added a lot of Unix and Linux calls over the years, >>> but not this one yet. I've done this before, and that's why I got old. >>> >> I had to link with -lrt (of course). It does not matter what the >> Pascal >> compiler and linker invokation do. I would make sure the Pascal compiler >> can produce compiled object code (.o files) and then link with the >> linker >> externally or just link with gcc (the C compiler/linker stript). >> >> >>> Understanding the XForms-toolkit somewhat, I do think this approach is >>> much better precision than the legacy timeout functions used in the >>> toolkit. And the XForms maintainer rightly criticized my using a system >>> Sleep call to get better accuracy, since it blocked XWindow events too. >>> So I think this is a very versatile feature to play with drawing >>> complex >>> functions on a screen stripchart. >>> >> Yes, do not sleep the main process that handles X window events... >> You will >> get a freeze and then possibly a pile of events to be handled at >> once. You >> typically want your UI to run in semi real-time and have all processing >> done in the background; this can include UI event-handling. Most >> people do >> not concern themselves with realtimeness issues and make the main >> code the >> UI event handler. I think this is bad practice, but it has a low >> barrier to >> entry for programmers and for non-intesive work. >> >>> When I get a decent set of software I'll try put it on a little web >>> site. Even try put up a few binary programs so you don't have to >>> work so >>> hard to figure what I'm talking about. Thanks for trying. >>> >> Use Github. I do use it for such things. >> >> I hope I had shed some light in this for you and I have not wasted >> anybody >> else's time with yet another pedantic post. >> >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >> tclug-list at mn-linux.org >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >> > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list >