Slightly strange PHP behaviour

murphaph

Hello all,
Not really sure if a solution exists for this but let's see:

I'm currently building a digital model railway controller. The hardware comprises a PCB with an AVR at its heart and is reached by way of a serial-USB (using FTDI FT232RL chip). The hardware is finished and I have tested it for comms under windows with realterm by sending simple commands like "on" and "off" and I can see the green and red leds resonding accordingly as well as measuring the track voltage swinging between o and 16Vac, so the thing works.

I then tried writing a simple PHP script based on the PHP serial class by Remy Sanchez. It failed to react as expected. The comms led illuminated as expected but the switching action simply wouldn't work.

I tried the same code on a Linux laptop and it switches reliably and I can read back the confirmation messages from the serial port, which is all great and if I have no alternative I will run this app on Linux, but would be cool to get it working under Windows tbh. Here's a stripped down version:

<?php
include "php_serial.class.php";

// Let's start the class
$serial = new phpSerial;

// First we must specify the device. This works on both linux and windows (if
// your linux serial device is /dev/ttyS0 for COM1, etc)
$serial->deviceSet("COM8");

// We can change the baud rate, parity, length, stop bits, flow control
$serial->confBaudRate(19200);
$serial->confParity("none");
$serial->confCharacterLength(8);
$serial->confStopBits(2);
$serial->confFlowControl("none");

// Then we need to open it
$serial->deviceOpen();
echo 'device opened<br />';
[B]$serial->sendMessage("XGO".chr(13));[/B]

$read = $serial->readPort();
echo $read;

// If you want to change the configuration, the device must be closed
$serial->deviceClose();


?>

the bit in bold is the crucial bit. I know the port is being openened in both windows and Linux and that "something" is being sent to the controller as the comms led is coming on, but it's clearly sending gibberish under windows. The commands follow a syntax of:
X[command]0x0D
eg
XGO0x0D or XSTOP0x0D

0x0D is just hexadecimal for 13 and is the ASCII carriage return code which indicates the end of a command to the controller box. I am using the decimal value of 0x0D and sending it as a character.

Any ideas why this would work in Linux and not in Windows (the class creators reckon the windows port READING can be buggy but reckon writing is fine). The Serial Class behind this.

conorcan2

For windows, try:

$serial->sendMessage("XGO".chr(13).chr(10));

murphaph

conorcan2 wrote: »

For windows, try:

$serial->sendMessage("XGO".chr(13).chr(10));

Cheers conor, I'll try that when I get home. I see that's a LF you're sending there after the CR, any particular reason? Have you come across something like this before?

murphaph

Unfortunately no go.

conorcan2

Did you install serproxy on Windows?

This will allow you to set up a tcp stack to/from your serial port and then you can use the php socket functions to communicate with it.

seamus

murphaph wrote: »

Cheers conor, I'll try that when I get home. I see that's a LF you're sending there after the CR, any particular reason? Have you come across something like this before?

That was my first reply too, which I then deleted, because it's not exactly the same thing that I was thinking of.

Windows and Linux handle end-of-line stuff differently, so whenever I see a problem in a script that's down to text being garbled (either when going in or coming out), I immediately have a look at the control characters and the mode of the file, as this is usually where the problems arise.

First thing I would do is ensure that you're on exactly the same PHP version for both win and linux boxes. Then compare the php.ini files - except for the file paths, ensure that the windows ini matches the linux ini exactly.

If that reveals nothing, then it kind of has to be an encoding issue - i.e. at some point in the communication to the COM port, the data is being changed from binary to ASCII or UTF or something. If the serial class has any kind of functions for forcing binary mode or forcing ASCII mode, it may be worth tinkering with them to see if your results improve.

Conor's other suggestion is also a good one, as sockets will give you great control over the character stream going to the device.

murphaph

Thanks guys for your thoughts, I'm pretty sure both PHPs are the same version, downloaded and installed them both within a few days of each other anyway. I'll check it and the ini files when I get home this evening and if nothing is revealed I'll have a crack at installing serproxy. I know I have edited the ini file on my windows machine a couple of times to enable various dlls including openSSH, perhaps that has something to do with it.