Tuesday, July 1, 2008
Serial Port Madness (NOT Arthropod)
Tuesday, July 1, 2008 
Recently I blogged about having trouble with Arthropod and an application that's using a socket, serial data from some hardware and a socketserver (namely Comfoolery). The hardware has been checked out on a few platforms and it works great on a Intel PC.
As it turns out, my problem with corrupted messages (tracking down this bug has shown sometimes I am getting two messages combined into one, sometimes an empty message, etc.) I got rid of Arthropod and the data coming in is still sometimes corrupted.
A theory now after lots of debugging is that somehow a Dell AMD machine is spitting out badness to my socket. Intel PCs don't seem to have this problem when running the same application on their hardware.
So right now instead of simply consuming the raw message and passing it up an event chain, it's going to have to be parsed on receipt. If it's in a form I am currently looking for, the event will fire. If I get garbage after the message is received, I throw out anything out of scope. I am also going to look for multiple carriage returns and snap those out as well.
I suppose it's good form to parse the messages coming in and ensuring that the event sends valid data. I was getting NaN for certain things which doesn't make a whole lot of sense... unless there is garbage in there when it's being translated to a Number (for instance).
So this proves that something that runs great on one hardware platform can wonk out on another. I don't know what AMD and Dell have to do with one another (I used straight serial and also a USB to serial adapter - and both provided some bad socket data). So I can only think at the moment that something in a AMD Dell isn't reliable when using a socket... to describe the whole set up and the bug would take a lot of effort... but so far this AMD Dell is the only machine to showcase the bad behavior.
All this work tracking this down shouldn't be in vain. I've spent the better part of a day testing my classes, the input hardware, multiple PCs, versions of the player, etc. It's all come down to one box providing wonky data.
Now you know that it might not be your code that is faulty, but the way the hardware is interpretting and passing data along. I am no hardware engineer, but I'm starting to feel a little like an apprentice.
This project should have been a no-brainer. But it's taight me something. Always vaidate your input data, even when you think it's a no-brainer. It might cost you some extra work, but in the end you'll be more comfortable knowing that you've accounted for the rarest case of getting poor data input. Even for a keyboard event listener? Sure, why not.
As it turns out, my problem with corrupted messages (tracking down this bug has shown sometimes I am getting two messages combined into one, sometimes an empty message, etc.) I got rid of Arthropod and the data coming in is still sometimes corrupted.
A theory now after lots of debugging is that somehow a Dell AMD machine is spitting out badness to my socket. Intel PCs don't seem to have this problem when running the same application on their hardware.
So right now instead of simply consuming the raw message and passing it up an event chain, it's going to have to be parsed on receipt. If it's in a form I am currently looking for, the event will fire. If I get garbage after the message is received, I throw out anything out of scope. I am also going to look for multiple carriage returns and snap those out as well.
I suppose it's good form to parse the messages coming in and ensuring that the event sends valid data. I was getting NaN for certain things which doesn't make a whole lot of sense... unless there is garbage in there when it's being translated to a Number (for instance).
So this proves that something that runs great on one hardware platform can wonk out on another. I don't know what AMD and Dell have to do with one another (I used straight serial and also a USB to serial adapter - and both provided some bad socket data). So I can only think at the moment that something in a AMD Dell isn't reliable when using a socket... to describe the whole set up and the bug would take a lot of effort... but so far this AMD Dell is the only machine to showcase the bad behavior.
All this work tracking this down shouldn't be in vain. I've spent the better part of a day testing my classes, the input hardware, multiple PCs, versions of the player, etc. It's all come down to one box providing wonky data.
Now you know that it might not be your code that is faulty, but the way the hardware is interpretting and passing data along. I am no hardware engineer, but I'm starting to feel a little like an apprentice.
This project should have been a no-brainer. But it's taight me something. Always vaidate your input data, even when you think it's a no-brainer. It might cost you some extra work, but in the end you'll be more comfortable knowing that you've accounted for the rarest case of getting poor data input. Even for a keyboard event listener? Sure, why not.
Comments:
There are currently 0 Comments:
