Digital Dash Project... Questions
redheadedrod
Posts: 78
I wish to make a totally digital dash for my 2003 Chevy 1500 Truck.
My thought is to place 3 4.3" screens in the dash over where the needle displays are now. If you look at the dash it has 3 separate spots that could accept a screen about that size. Maybe even 3 5" screens.
My question is, how many screens can a single prop refresh?
I will also need to pull the data from the ODBII bus since this is how the dash does it now.
My plan is to desolder all of the motors from the circuit board and the backlight led's plus any indicators that will be blocked by the displays. I have a junkyard display to use as my test mule. I will be leaving the odometer in place and mounting the displays on top of the circuit board leaving the board in tact in case I ever decide to put the dash back into factory condition.
So I will in essence want to have a black background to the screens and display colorful guages on the displays. I will likely want to mimic the OEM needle type guages at first but also allow for messages on the screen and some other simple animations. I should have no less than 20 FPS updates on the screen and as I mentioned it needs to monitor the ODBII bus. I will likely pull all of my power directly from the Cluster hardness and package everything inside the modified dash module. I do not need touch screens for this since the screens will be behind a plastic window. I could leave the plastic window off and allow touch the touch screens to be active as well if I so desired.
Thanks for any suggestions!
I have not owned a Prop yet but I will be ordering a BOE and probably the breadboard kit as well in the next month to start learning how to make the prop spin...
My thought is to place 3 4.3" screens in the dash over where the needle displays are now. If you look at the dash it has 3 separate spots that could accept a screen about that size. Maybe even 3 5" screens.
My question is, how many screens can a single prop refresh?
I will also need to pull the data from the ODBII bus since this is how the dash does it now.
My plan is to desolder all of the motors from the circuit board and the backlight led's plus any indicators that will be blocked by the displays. I have a junkyard display to use as my test mule. I will be leaving the odometer in place and mounting the displays on top of the circuit board leaving the board in tact in case I ever decide to put the dash back into factory condition.
So I will in essence want to have a black background to the screens and display colorful guages on the displays. I will likely want to mimic the OEM needle type guages at first but also allow for messages on the screen and some other simple animations. I should have no less than 20 FPS updates on the screen and as I mentioned it needs to monitor the ODBII bus. I will likely pull all of my power directly from the Cluster hardness and package everything inside the modified dash module. I do not need touch screens for this since the screens will be behind a plastic window. I could leave the plastic window off and allow touch the touch screens to be active as well if I so desired.
Thanks for any suggestions!
I have not owned a Prop yet but I will be ordering a BOE and probably the breadboard kit as well in the next month to start learning how to make the prop spin...
Comments
And how hard is it to write to the screen?
Rodney
If you want to drive 3 screens with different and graphical content there is no way around using screens with their own display RAM. I did not find displays bigger than 3.5" which have RAM so far - except of the really expensive ones which have their own graphics controller on board.
I once used a 3,5" display with a 8 bit parallel interface which was fast enough to write a full screen in below 1/2 a second. (I think it was 166ms). The limiting factor was that a full screen full color image (24 bit) has to be read from SD card.
I'd think that in your case this would be a one time thing to show a nice dash board image. After that you should come along with updating smaller sections with line drawing or writing numbers/text.
As those kind of displays have a chip select, you can also use the same port pins to connect different displays.
If 3.5" is to small for you, you need to use a bigger display adding a display controller by yourself.
Other solution might be to build a 4 propeller board. 1 propeller per display and one for the main application. Did you already have a look at graphic demos? These show you what you can expect from this solution. Of course you can not expect 24 bit color depth for those displays.
I like a challenge and if you can give me some more information as to what you want presented I will make it happen as part of my developing GUI drivers for this unit. So, just tell me.
I am guessing that video from a camera would be completely out of the question (So if I wanted the screens to become rear view when I back up.. I will have other screens so this is not as big of an issue.)
I will post an image of a cluster like mine so you can see why I am looking at using 3 screens.
http://www.performancetrucks.net/forums/gm-parts-classifieds-23/f-s-escalade-platinum-cluster-418648
I am building this for myself but once I have it figured out I certainly could program raw displays for others and they could incorporate them however they want.
The cluster in the above thread is very similar to mine. I would replace the speedo with a screen, the 4 gauges on the right with another screen and the tach, small guage and light warnings with a third screen. The large area below the speedo is the Cluster Information display that shows the mileage and such. The smaller rectangle in the middle of the speedo is the gear indicator. I will keep the CID but the gear indicator is not critical and may be removed.
My original consideration was to do one Prop per screen. This way I can make them modular and use a fourth prop as a controller to tie them all together as well as monitor the ODBII bus for the data that it would then feed to the Props that need them. .
Then each screen could have a menu of types of data to display and they would be fed that data by the "controller" prop. This way it is totally configurable by the user. I would be using 3 of these screens but someone with a different cluster could use 2, 4, or maybe even just replace the speedo with 1 and keep the rest the same.
You could then just display anything from simple character data to fancy needle displays. And configure exactly what you want to display. Someone could likely replace the controller prop with a small ARM board if they wanted to as well.
I guess the daisy chained displays was a cool sounding idea if I could run them from one prop. If it is just the speed of the processor I could likely use a BeagleBone or something similar to drive it instead of Props but trying to keep it simple.
When you say it should be flexible it might be that someone wants to see a fullscreen number instead of a needle. So, if you have digit overflow 99 mhp -> 100 mph you really have to repaint a lot of the screen. Maybe you want some damn good looking fonts. These you would have to store on a mass storage device (SD?). This leads to the fact that the repaint will be visible.
Opaque numbers shown on a nice background are totally out of scope because this would require read modify write access which slows down things even more!
So, I don't say that it is impossible to do this with a propeller. But I am realistic and have to say that it will not be perfect and you have to put a lot of efford into this to make it as close to perfect as possible! I think a propeller 2 might help here, but who knows when it will be available?
The raspberry also has display-port but so far officially no display which is supported. As an interim solution there are displays that can display the video out. http://thegrieve.co.uk/blog/2012/11/the-raspberry-pipboy/
As far as I remember camera module is close to be finished.
On the other hand, it's also not very professional to have a display which first shows a linux-boot-screen and needs a while to start up.
Maybe the other multicore controller with the name that shall not be spoken out loud here ;o) would be an alternative?
Of course the prop would be a good choice for the ODB2 reader and data distributor as you can have as many serial interfaces or i2c or CAN interfaces as you need ... well up to the number of available pins.
Sounds like I might get "stuck" with a small ARM stick that can run VGA to run each display. Then perhaps use a prop to pull up the ODBII and control them.
The inital loading delay was one of the reasons for my wanting to look at the Prop.
I can likely do a fast boot and use QT as my graphics if I use a ARM stick and you won't see the boot up but I was hoping to get away from that since it is all new to me.
I used to do a monochrome display on an old Atari 8bit computer but that was in assembly and ended up being very slow. You could watch it draw the characters.
Also, I am not real concerned with it being daylight readable since the dash cluster on my truck is pretty well sunk into the dash with a "roof" over it to block the sun out as it is. Obviously if it is too dark to read in my house with the lights on it won't work.
But it is something to consider when considering something for other vehicles.
I guess my best bet is to get a BOE and see what the video looks like and go from there.
I have NO problem putting a prop on each screen and then having a 4th to do the actual ODBII communications if that will make this work. Might make this easier to make modular.
I could likely do the dash in as little as 4 bits but 8 is probably going to be the minimum I will shoot for. I realize that in some applications that the bit depth can add to the slow down and I would only go for more bits if I had to.
20+ years ago when I last manipulated screen data directly monochrome screens were real easy. It was simply a continuous memory location from the upper left hand of the screen to the bottom right hand of the screen going from left to right, top to bottom.
With multi-bit screens you had one of two types of memory setups. Using a 4 bit screen as an example, you could either have 4 different sets of monochrome like memory locations that were then combined to make the screen or the bits were all contiguous so they were just like the monochrome screen but took 4 bits to make the screen.
Which manner does the prop do its video?
Since the hydra is a prop based machine I have to believe there is some video capabilities there unless the hydra uses a specialized video processor which could work for me as well.
If I decide to use the prop as my video will I also have to keep track of what is in what memory location so when I do something like the needle I have to rebuild the back ground then move the needle? When I played with them in the past I was doing different sized text so I just made the whole block and didn't worry about what was behind it. I also did a monochrome strip chart recorder as well which used double buffering to appear smooth. Double buffering is where you use two sections of memory the size of the screen. You do all of your work on the portion not displayed then display it when finished and then work on the next screen on the offline screen and keep flipping between them. This allows you to display the screen without seeing the actual drawing happen.
Just curious what I will be getting into.
Rodney
Higher resolution displays require more RAM and there's only 32K of shared internal memory total. So the usual trick is to use a tiled display with each tile only having 4 colors. This can be very memory efficient, especially if tile data can be reused (e.g. single color) or if the internal ROM font can be used.
I'd recommend playing around with Graphics.spin as it is the prototypical tile display emulating a bitmapped display.
http://www.lascarelectronics.com/temperaturedatalogger.php?datalogger=393
Kenny
http://forums.parallax.com/showthread.php?137266-Propeller-GUI-touchscreen-and-full-color-display&p=1117341&viewfull=1#post1117341
Makes screen refreshes MUCH faster! The design would work with non-touch LCDs and most likely SSD1963 controllers for larger displays. You could probably get 3 to work with little difficulty. I'd use a 2nd prop to handle ODBII.
You could use these displays:
http://www.ebay.com/itm/New-4-3-480-272-TFT-LCD-Module-Display-Touch-Panel-SSD1963-For-51-AVR-STM32-/170956677033?pt=LH_DefaultDomain_0&hash=item27cdcfdfa9
or
http://www.ebay.com/itm/New-5-0-800-480-TFT-LCD-Module-Display-Touch-Panel-SSD1963-For-51-AVR-STM32-/180910383286?pt=LH_DefaultDomain_0&hash=item2a1f1960b6
These are all touchscreens, but I've seen non-touch versions. The "standardized" 40 pin connector is pretty handy.
Here's pacman running on the board :http://youtu.be/ZUDNXO4TZ6Y
Thanks average joe for the link though. I may not have time to look into this for a short while due to other projects so I will monitor this for now.
Gives me a good reason to get a prop and start playing around with it.
The pacman game looks pretty cool...
I have some things I need to accomplish today and will read the full thread. Not sure I like the idea of using SDCards since they DO go bad.
Might be an interesting project for me to play around with though and get my feet wet with electronics like this.
Rodney
RE SD cards.
There are tradeoffs, but the only time I've had issues with the SD card is when I removed the card while the system was running. There was that one time my program went "off the rails" and corrupted the card. Nothing a quick format and re-copying of the file system couldn't fix.