When printing to the serial port I can get the output with a simple Linux command such as cat /dev/ttyUSB0.
However, the cat commands wait forever until I press Ctrl-C. If I was taking the input from the terminal instead, I could signal the end of file by pressing Ctrl-D which would terminate the cat command.
How do I signal from Arduino that there is no more data for now? Serial.end() and Serial.print(4, BYTE) does not work.
Tough luck, you can't. Your connection will stay active because you can't close it. Send some data so that your program know that no more input is expected. Coming from a serial terminal and read with getty, the Ctrl-D (ASCII 4) is considered the EOF character, but that won't work in all cases.
#4: I want an EOF to signal the end of transmission so that the receiving program can continue doing something else like storing data in DB. Your idea of using head and tail is quite neat.
What I want is that the receiving program (on the pc) should process the data when it's there and be free to do something else while waiting for data.
Part of the problem is that you're using the cat program to receive your data instead of writing your own program to do it. The cat program keeps control of the console thread until the program ends. Even if you send the EOF, until the cat program ends, it will not give the system back control.
What you should do is write a 'c' or java program that receives the data and saves them to a file. That way, you can send whatever character you want as an EOF marker, and tell your program to end or quit looping waiting for data. This can be done very easily on linux.
(or whatever baud rate you are using in place of 9600)
In your program use Serial.print(4,BYTE); to send an EOF. Then cat /dev/ttyUSB0 should reset the arduino, display the output and stop at the EOF. (It seems to give me a few bytes of rubbish at the beginning though, and occasionally not work at all.)
Since Linux is a full multitasking environment, it can do that whilst its doing something else. If its running from cron, its a effectively a background process.
What I posted before was just the meat of one of my scripts. The bit that deals with the arduino in full :
I stop the arduino resetting each time with a 10uF capacitor between gnd and reset. The head and tail and dropping the first part of what s received is incase it 'joins' the arduino half way through a transmission. The arduino just sends stuff over and over at 115200 baud.
Pluggy (and all of you): This is very interesting as I am actually working on the same, reading data from my electricity meter. I had problems with the sketch somehow getting stuck and I suspected some kind of congestion on the serial port. This was the initial reason for this thread as I thought that controlling the data flow with an EOF marker would cure the problem.
However, late yesterday night I stumpled upon this thread which is a nice introduction to interrupts. After reading the thread I realized that it was a very bad thing to have the Serial.Print() line in the ISR (triggered by a blink from the electricity meter).
I moved the print statement to the main loop, controlling it by a state variable set by the ISR instead. After this, my sketch has been running for hours without getting stuck! And without using any kind of EOF markers; the cat is just happily eating every bit of data now
Nevertheless, the tips I got here has been most useful to me, especially about using head and tail together with cat.
A few notes to Pluggy: If possible, I would be very grateful to see your sketch
I am aware of the problem with resetting the Arduino, but for some reason it does not happen on my Sheevaplug. I use no capacitor.
I'm always tweaking it, so its constantly changing. Recent changes have been an attempt to improve the central heating control. Its quite involved........
Hmmm, the Sheevaplug doesn't reset the arduino, whilst a hacked Seagate Dockstar (basically the same platform) running Debian does.
Be aware, the above sketch uses a specially hacked version of the Dallas temperature library so won't compile even if you got all the libraries in place.