1

OBJECTIVE :- To achieve serial communication between arduino and the C++ program. I am using processing as an intermediate program which performs some operation over data and then passes those values to the arduino serially!

I have a C++ program which writes a data to a file at regular intervals,say UFR,90,87 to a file at every 30 milliseconds. The file being written is done in truncating mode,i.e., the file is overwritten every 30 ms.

Next, there is a processing code which has to fetch that value from file as soon it get's written. The C++ code is executed first and then the processing code. The processing code is using BufferedReader to read the contents of the file.

How should I enable synchronisation between the two programs so that the value just written by C++ program is read simultaneously(minor lag,less than 5-10 ms is acceptable) by Processing code and there is perfect synchronisation? There shouldn't be any mis-communication. Should I establish some kind of mutex lock/semaphore/something over the file between successive reading/writing?

Also, I am running C++ program from the terminal and the processing code from the processing IDE(GUI). The Operating system being used is Ubuntu 14.04/CentOS 7 Linux.

ALSO, SUGGESTION REQUIRED :- Would anyone please suggest me a better approach for establishing direct communication between arduino and C++ program. I was able to successfully transmit data with direct tranfer,but,not receive acknowledgement properly from arduino. We have to receive acknowledgement from arduino too which fails to acknowledge that the data has been received successfully. I tried sending data using the GNU screen emulator but it didn't acknowledge back the data received. Hence, I had to use this intermediate approach using Processing!

Am_I_Helpful
  • 18,735
  • 7
  • 49
  • 73

1 Answers1

2

If the two programs are to be run in such a lock step, and if data persistence is not a requirement, then perhaps explore some other InterProcessCommunication (IPC) primitives - such as pipes, sockets, messages, shared memory.

In your file based approach, you have about already answered your own question. Use semaphores; they are simple enough. Your producer checks if count is 0; if not wait; produce; set semaphore; the consumer tests if it is 1; if not waits; consumes; resets semaphore.

If you need produce irrespective of whether or not the previous production has been consumed or not, use mutexes; the ones that work cross process. Lock - write into file - unlock; consumer: lock - read - unlock.

Linux is no real time system, so there are no guarantees that your consumer would be awakened within 5-10ms after the consumer is done; BUT 5-10 ms is 'long' enough; OR may be NOT. This thread suggests that the time slice is of the order of 100ms - How to know linux scheduler time slice?. If that is the case then your consumer thread might have to wait for some time, much greater than 5-10 ms, if some other thread is scheduled first. Setting your consumer thread priority to a high value would alleviate some of this problem. It would ensure this - producer produces, sleeps, OS looks for next task, finds your consumer tasks which has now become runnable and is at very high pri. Purists would, at this point, tell you that there is no such guarantee and there are other things at play.

A net search of "producer consumer problem" would give you tons of other ideas as well; most are variations of the same basic idea.

Community
  • 1
  • 1
Amit
  • 1,836
  • 15
  • 24
  • 1
    Appreciate your suggestion,just waiting for some more advices. Else,I'll accept this answer. BTW, if you could just link examples for `some other InterProcessCommunication (IPC) primitives - such as pipes, sockets, messages, shared memory.`,that would be heartly accepted. – Am_I_Helpful Feb 13 '15 at 09:33
  • 1
    Note that latency on kernel signaling, eg. semaphores, is typically MUCH less than 5-10ms. If there is a core free, or if the consumer preempts the producer, you are talking 5-10us, (on Windows, anyway, I don't expect Linux would be much different). 'time slice' is irrelevant, except on grossly overloaded boxes where there are regularly more ready threads than cores. – Martin James Feb 13 '15 at 12:23