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.
Monday, May 17, 2010
My Current Project
Okay so here is the first project post I am trying on this blog. And it isn't a robot. Its a human interface device. Okay not just any human it is a parental interface device. Its not for interfacing with your parents, but its so my parents can turn their TV on.
Years ago I set my parents up with an AV system where all the components were linked and talked to each other. If you put a VHS tape in the VCR it would turn on the TV and stereo and switch to the correct inputs. If you put in a DVD it would turn on the TV and stereo and switch to the correct inputs. If you turned the stereo off the TV, VCR, and DVD players would all shut off.
Recently they have replaced the last of all those components, and I've seen them fight with it on more than one occasion. There wedding anniversary is coming up soon so I decided to go old school and make them a gift this year. My gift...... a custom remote that takes care configuration and controls. They will only need one controller.
My goal is to set the whole thing up with a oled touch screen interface. I'll have a few physical switches, you want to change channels without looking at a screen to figure out what button to press. I've already specked out the major components and I'll post some links on that when I get organized.
For now I'm going to introduce you to the development cycle. The first step as been completed. I need to determine what protocols are used by my parents remotes. I built a quick little test rig with a battery and a IR detector. I handed the rig to my brother along with my saleae logic prob and had him covertly capture codes from my parents.
Years ago I set my parents up with an AV system where all the components were linked and talked to each other. If you put a VHS tape in the VCR it would turn on the TV and stereo and switch to the correct inputs. If you put in a DVD it would turn on the TV and stereo and switch to the correct inputs. If you turned the stereo off the TV, VCR, and DVD players would all shut off.
Recently they have replaced the last of all those components, and I've seen them fight with it on more than one occasion. There wedding anniversary is coming up soon so I decided to go old school and make them a gift this year. My gift...... a custom remote that takes care configuration and controls. They will only need one controller.
My goal is to set the whole thing up with a oled touch screen interface. I'll have a few physical switches, you want to change channels without looking at a screen to figure out what button to press. I've already specked out the major components and I'll post some links on that when I get organized.
For now I'm going to introduce you to the development cycle. The first step as been completed. I need to determine what protocols are used by my parents remotes. I built a quick little test rig with a battery and a IR detector. I handed the rig to my brother along with my saleae logic prob and had him covertly capture codes from my parents.
I've included a sample of the captured image. Let me help you interpret the image. IR codes are carried over a 38khz signal. The decoders filter for 38khz signals so you don't get interference from other IR sources. The Decoder inverts the results. A Low logic state indicates IR and a High logic state indicates the absents of IR. The particular protocol you are looking at has a start pulse then a slight pause. Then it sends another pulse. This is where we start getting the data. There are a series of about .5ms pulses. Between them there is a rest period of 1.2ms and .6ms. 1.2ms indicates a 1 and .6ms indicates a 0.
If you look at the image it is easy to spot 1s and 0s. So I'm ready for my next step. Now I can start working on code to detect and transmit codes.
Tuesday, April 27, 2010
Hey what is this?
So what is the deal here? Is this another blog? Why do you need another blog? Well you don't but I think I do. From time to time I start projects, and they don't get documented all that well. I've posted the final results on youtube and always get asked how you make that. Well that question is difficult to answer if there isn't a history or documentation of some sort for your project.
So that is where this blog comes to play. Its high time I finally get around to documenting the projects I work on so others can, (if they really really want to) follow my work. My question becomes does anyone want to?
My take on projects are possibly different from others. I enjoy the build often more than the final project. The result is I don't tend to just copy a project, but discover my own way to do things. Plus I am a real novice. I'm learning as I go. Some parts are sloppy, but I hope a few may end up being elegant.
My project interests follow aviation and robotics, so that is what my projects tend to follow.
Okay so there you have it. That's my introduction. Did I say anything? Maybe, maybe not. But I did type words and that is the important part. Without words you would have nothing to read. So now on with the projects!
So that is where this blog comes to play. Its high time I finally get around to documenting the projects I work on so others can, (if they really really want to) follow my work. My question becomes does anyone want to?
My take on projects are possibly different from others. I enjoy the build often more than the final project. The result is I don't tend to just copy a project, but discover my own way to do things. Plus I am a real novice. I'm learning as I go. Some parts are sloppy, but I hope a few may end up being elegant.
My project interests follow aviation and robotics, so that is what my projects tend to follow.
Okay so there you have it. That's my introduction. Did I say anything? Maybe, maybe not. But I did type words and that is the important part. Without words you would have nothing to read. So now on with the projects!
Subscribe to:
Posts (Atom)