Okay well talk is cheep. So I slapped together a real really quick video of my current project, you know the touch screen remote control system, just to show it works.. Well sort of.
Right now the features working are, a debug menu accessed via the USB port. You can communicate directly with the 4D Systems touch screen with this interface, as well as decode several different types of Remote Control IR signals.
The actual touch screen is running on its own cog in the propeller. It just continually runs scripts stored on an uSD card. There are three different types of files it uses. A script File, a button File, and an image file. Scripts run a very limited script language I have written for it. It just does things like load an image, pause, load a different script, pause some more, load a button file.... The button files contain coordinates for the touch screen and a script name to go along with that.
So at boot up it runs a boot script witch loads a button file. When the script finishes running it waits for you to press the touch screen. When you press the touch screen it looks to see if there is button defined in that spot and if so run the script. That script may or may not load a new button file so commands that don't require a new menu will not need to update what the buttons do.
What that all boils down to is the entire thing is fully configurable via simple test editor, and a tool 4D systems provides to convert images into a format it can play.
Okay not a lot of detail... But here is the first video of it in action...
Thursday, June 10, 2010
Saturday, June 5, 2010
Wisdom for the day.
Okay so I still haven't posted what I wanted to about my current project. I've been busy, please forgive me. I've got a little bit of a time constraint on this project and I haven't been taking as much time to document as I would like. I did however just fix a problem that was driving me nuts for a long time, so I'm going to take a brake and tell my tail.
My project is using a Propeller microcontroler from Parallax. I'm communicating with a piece of hardware using serial. I've been pulling my hair out for days, searching for a bug that didn't exist. Let me explain...
I'm using the full duplex 4 port serial driver from the propeller object exchange. I've used it many times and had lots of success with it. On my current project I am using it because I need to serial ports, I'm using one for a debug port and the other to communicate with a display. The problem was I was the commands I was sending to the display were not always working correctly. I blamed myself (quite correctly as it turned out). My initial tests indicated that I was successfully communicating at 115200 bps. I was wrong! I kept checking my code trying to figure out why some times the same function would work and other times it would not.
The thing finally made me realize what I was going wrong happened today. I'm working on a text interpreter for running scripts on the propeller. No mater what I did it kept reporting the wrong file size back to me over serial. For some reason the last bit of every byte was 1. A of 20 bytes was reporting the file size of $0080808A. (okay so the two highest nibbles were right). I then wrote test code to display the contents of the file. It worked perfectly.
This was were it got frustrating. I finally decided to trudge on with the code event though the file size was missing I could just wait till I got errors and assume I was at the end of the file. So I wrote more code, implementing handshaking as a form of flow control. That's when it became clear. Data after the ACK was corrupt. It turned out all this time that if I was transmitting while receiving the received (well it could even be the transmitted I don't know) was corrupt. I turned the communication speed down and everything is working the way it is supposed to.
So my new found wisdom is don't assume bidirectional communication is functional until you test them at the same time! I made a mistake weeks ago and didn't even look at it but it was the problem.
My project is using a Propeller microcontroler from Parallax. I'm communicating with a piece of hardware using serial. I've been pulling my hair out for days, searching for a bug that didn't exist. Let me explain...
I'm using the full duplex 4 port serial driver from the propeller object exchange. I've used it many times and had lots of success with it. On my current project I am using it because I need to serial ports, I'm using one for a debug port and the other to communicate with a display. The problem was I was the commands I was sending to the display were not always working correctly. I blamed myself (quite correctly as it turned out). My initial tests indicated that I was successfully communicating at 115200 bps. I was wrong! I kept checking my code trying to figure out why some times the same function would work and other times it would not.
The thing finally made me realize what I was going wrong happened today. I'm working on a text interpreter for running scripts on the propeller. No mater what I did it kept reporting the wrong file size back to me over serial. For some reason the last bit of every byte was 1. A of 20 bytes was reporting the file size of $0080808A. (okay so the two highest nibbles were right). I then wrote test code to display the contents of the file. It worked perfectly.
This was were it got frustrating. I finally decided to trudge on with the code event though the file size was missing I could just wait till I got errors and assume I was at the end of the file. So I wrote more code, implementing handshaking as a form of flow control. That's when it became clear. Data after the ACK was corrupt. It turned out all this time that if I was transmitting while receiving the received (well it could even be the transmitted I don't know) was corrupt. I turned the communication speed down and everything is working the way it is supposed to.
So my new found wisdom is don't assume bidirectional communication is functional until you test them at the same time! I made a mistake weeks ago and didn't even look at it but it was the problem.
Subscribe to:
Posts (Atom)