To PHP, or not to PHP - that's the question....

[jeofva]

I'm brand new to this forum and I'm hoping several of the more experienced here can help me with my question.  My question concerns using PHP as a standalone client-side program rather than its traditional role as a server-side page processing tool. I realize that PHP is probably not a first choice as a tool for a server-side programming job, but I'm very familiar with PHP, and therefore it would certainly speed up development of the application I have in mind. I know I could use a language such as Python, or C++ to do the job, but I am not sure I can afford the time to get up the learning curve. And then there is always the confusion factor of trying to go back and forth between two different languages at the same time, but for different jobs.

 

I have been successfully using PHP as a scripting language for generating webpages in conjuction with HTML, where a program takes the output of some form data, processes it, and displays it on the screen.  I have also created PHP page that contain code snippets which displays the output from one or more tables in a database when a user accesses the page.  But the PHP programs I have created all end with a single page being displayed. That is, until some action creates another page. What I need is a program that runs continually collecting data and updating a display page until such time as I manually stop it.

 

To be more specific, what I have in mind is developing a program that will be able to read the textual data (NMEA) streaming from a GPS receiver through a serial port (USB) on a continual basis, and update a display page after each read, which come at about one second intervals. The program would need to parse the incoming data stream as data filled the serial buffer, use the parsed data to update the  records of a  MySQL database, and graphically update the positional data on a display screen, all without user intervention.  I know I can do all of the pieces that need to be done, because I've used PHP to do similar thing in other programs.  What I'm not sure of is how best to use PHP as a continually running and updating program as opposed to a batch-mode type of program.

 

The computer I am planning to use would be running Linux, and the Apache server would be devoted entirely to running  just the programs associated with the project.  Any suggestions on how to go about this would be greatly appreciated.

[corbin]

You would probably have issues using PHP with a USB device like a GPS unless you feel like changing the PHP source, or there are some functions about which I don't know.

[jeofva]

You would probably have issues using PHP with a USB device like a GPS unless you feel like changing the PHP source, or there are some functions about which I don't know.

 

I found a class called serial.php that will hopefully handle the serial communications through the USB port, but what I really need to know is the best way to structure my code so that my script runs continuously through the process of collecting serial data as it streams in from the GPS, processes it,  and updates the screen with each new position coordinate until I tell it to stop. 

 

Presumably, I will be updating the screen from information I've stored previously in the database or possibly a temporary file, and I'll obviously have to generate an entire new page, graphics and all, for every new write to the database.  But after I've regenerated a page, how do I set up the code so that the process of generating a new page begins when there is enough data in the serial buffer?  I suppose I could use a timer, but that is no guarantee that there won't be either too much, or too little data in the serial buffer.  Can a PHP script be driven from a hardware interrupt?  I'm just not clear on how to proceed.

 

 

[corbin]

"Can a PHP script be driven from a hardware interrupt?  I'm just not clear on how to proceed."

 

Not unmodified PHP.  Actually, that would probably be a pain for any software, since hardware shouldn't care how much data is in its buffer.

 

 

 

You could just do this:

 

 

$buffer = '';

while(true) {
    $buffer .= GetFromGPS();
    if(strlen($buffer) >= MINIMUM_LENGTH) {
        Process($buffer);
        $buffer = '';
    }
    usleep(250000); //pause for 1/4 of a second.  This keeps CPU from being hogged.  Gotta <3 while(true) loops ;p
}

 

 

That assumes that GetFromGPS would be blocking.

[jeofva]

"Can a PHP script be driven from a hardware interrupt?  I'm just not clear on how to proceed."

 

Not unmodified PHP.  Actually, that would probably be a pain for any software, since hardware shouldn't care how much data is in its buffer.

 

 

 

You could just do this:

 

 

$buffer = '';

while(true) {
    $buffer .= GetFromGPS();
    if(strlen($buffer) >= MINIMUM_LENGTH) {
        Process($buffer);
        $buffer = '';
    }
    usleep(250000); //pause for 1/4 of a second.  This keeps CPU from being hogged.  Gotta <3 while(true) loops ;p
}

 

 

That assumes that GetFromGPS would be blocking.

 

Okay, using a program delay definitely sounds like the way to go, but I'm also having a small conceptual problem regarding how to generate regular display updates.  I'm probably thinking about this all wrong, and  I'm hoping someone can steer me in the right direction.

 

The way I am currently conceiving of implementing this program is as three separate scripts.  The first script simply collects the initial information that the program is going to need to get started, such as a new positional table name for the current GPS data run, and the input and output serial identifiers, etc.  The first script will then pass this information to a second script that will just be a terminatable WHILE loop which will use the POST parameters from the first program to collect whatever serial data is available, parse it, output some through the output serial port, then update the positional table, and finally send data to a third program that will display the data.

 

My main problem is with the third script in the program. I assume that I have to use a third script because the second one will never display anything until the WHILE loop has terminated and the script comes to an end. I need a display that is updated about 30-60 time per minute. 

 

Of course I can't figure out how the third script would work either. If at the end of each WHILE loop I send data to a third script for display purposes, won't my browser just keep loading fresh pages with the updated information until the browser quickly overloads?  In other words, I don't know how to send data from one script to another so that it just causes the second one to update rather than loading a fresh page. 

 

Can that be done, and if so, how?

[corbin]

Without a page reload, you would have to use AJAX.  Does the page really need to reload constantly?  Couldn't it just be reloaded every 5 or so minutes?

 

Oh, and if I were to do this, I would keep the back end and the front end fairly separate.  The data collection script would be run through a shell, not through Apache.  Then, it would cache data some where, and the display script, which would run under Apache, would read it.

[jeofva]

Without a page reload, you would have to use AJAX.  Does the page really need to reload constantly?  Couldn't it just be reloaded every 5 or so minutes?

 

Oh, and if I were to do this, I would keep the back end and the front end fairly separate.  The data collection script would be run through a shell, not through Apache.  Then, it would cache data some where, and the display script, which would run under Apache, would read it.

 

Yes, I need to have the display be constantly updated for the duration of each run.

 

It sounds then that I probably shouldn't be trying to use PHP to do what I want to do. Is there another language out there that is more suited to what I want to do, and that  wouldn't have too steep of a learning curve? 

[Mchl]

You could probably fairly easy create an application for data collection in C++ which would store the data to MySQL. You could then do the displaying part in PHP + AJAX.