Delighted in your youth. You have tons of good ideas, so don't let my grouches deter you. My (now) son-in-law bought me a Pi kit. The first problem was I had no USB keyboard. I had probably a dozen IBM PS2 clickety click keyboards (and some other cheapies) around, and I still use at least 2 of them to keep the wife awake. So he bought me a USB keyboard. Then "What is HDMI?" I asked. But once we hooked it up it was great "Raspian" linux, and even had XForms-toolkit and freepascal in the repository. It doesn't have a real-time clock however. I really got hissed at on AVRfreaks for suggesting a Linux terminal interface. Then came Arduino Uno, and I love that "Abstract Communication Module" (fake modem) interface. Now Intel has bought into Arduino and "Edisons" are happening. Apparently "Lady Gaga" and her drone army was a hit show at the Superbowl. So I don't know the future. But out here in the wilderness they buried a big fiberoptic cable under my driveway last fall. Century Link says I can get 10 megs(?). But Verizon has been great, too. When we first moved out here it would cost at least a dollar to call the next town, and a dollar was a lot 35 years ago. The mailwoman is very respectful of ebay packages. It's a different world, and mostly I like it. Your turn, dude. I'm going to grow asparagus. Iznogoud wrote: >> Just to conclude this thread, I wanted to share that I found an example >> program in the 7-17-2016 Unix(7) manual page that uses the newer >> SOCK_SEQPACKET socket types. My older 2012 manual page does not. I don't >> mind feeling old, but I like to think I still know something, so I'll >> sleep well tonight and brag to my wife tomorrow. >> >> The example even calls the exchanged messages "commands" so the Linux >> experts are thinking like us, or maybe more like you. >> > You are talking about this one: > http://man7.org/linux/man-pages/man7/unix.7.html > This is a great example. There are conventions used there, in the spirit of > what I was talking about. The server expects keywords, like DOWN and END, and > will pass if anything is garbled. This is typical of an example with no > error-checking beyond the null-terminated string, etc. (Essentially, there is > no protocol when you are writing your own software for your use or tests.) > > Inter-process communication, as was mentioned in that man page, is also done > with pipes through the file-system. There are pros and cons to this. There is > also shared-memory type communication with the "RAM drive" that is typically > in a mount-point like /dev/shm. In the case of pipes, you write to a pipe > and you read from the other side. The process is FIFO and you will need some > system call like "select()" to monitor a file pointer. There are also pipes > that stay within a memory space so that threads can talk to eachother in the > same way. I use this for my audio sequencer software to get real-timeness on > POSIX thread communication where one thread manages the hardware via ALSA and > another thread generates sounds to fill a buffer. Here is a snippet from my > software: > > read(seq->pipep[0], cmd, (size_t) 4); > > if(strncmp(cmd,"QUIT",4) == 0) icmd = -1; > if(strncmp(cmd,"WAIT",4) == 0) icmd = 0; > if(strncmp(cmd,"PLAY",4) == 0) icmd = 1; > > switch(icmd) { > > The above code reads from the pipe, identifies one of three expected commands, > and reacts (with the "switch" block of statements). It is triggered from the > outcome monitoring of the pipe determines in the following statements: > > /* keep monitoring the pipe for a command from the master */ > FD_ZERO(&rfds); > FD_SET(seq->pipep[0], &rfds); > nfds = seq->pipep[0] + 1; > iret = select(nfds, &rfds, (fd_set *) NULL, (fd_set *) NULL, &stv); > > This method would work really well for real-timeness and your data acquisition > needs. The timeout for the select() can be set given a gettimeofday() call > that is used to try and maintain a constant rate. You need to do the thinking > there on how this can work for you. I hope this helps, hence the long reply. > > > One last thought regarding your automation discussion and for your information. > You can do a lot with fully programmable OS type controlers based on the > Raspberry Pi and the I2C functionality/protocol. (I love the Pi for a lot > of reasons, mostly its price for a fully functioning computer.) Most components > you need for sensors and automation can be had with I2C support built-in. It > is a client-server protocol that is an industrial standard and it is well > supported under Linux. Pythoners can use it via Python bindings to I2C, which > is great, and that is how your Pascal code can probably interface well via > a Python interface and a file- or pipe-based setup. Look it up. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list >