Digital Dash Project... Questions

redheadedrod

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...

Peter Jakacki

My new 3.5" touch-screens are designed to interface to the Prop (or any other micro) via I2C so you can just keep adding extra ones as needed. The same interface board should be able to handle the large screens too I guess, I just haven't double checked that yet. The particular screen I'm using has it's own RAM so all the Prop has to worry about is writing to this screen. The I2C interface is a hybrid I2C and SPI style interface, all it needs is 3.3V or 5V and the I2C bus signals, normally the same as the Prop's EEPROM.

redheadedrod

How fast can these be updated? And how much processing power is needed from the Prop?

And how hard is it to write to the screen?

Rodney

MagIO2

I think this is really on the edge of what's doable with the propeller.

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.

Peter Jakacki

redheadedrod wrote: »

How fast can these be updated? And how much processing power is needed from the Prop?

And how hard is it to write to the screen?

Rodney

Well I can give you a better idea next week when I have my interface boards back. I have tried this straight from the Prop via SPI at 2.86MHz speeds (could be faster) and it does take 700ms to write to the whole screen. Mind you once you have drawn the screen the plot and unplot operations necessary for a moving needle for instance consume far less time so that it looks smooth. However the new interface pcb has a small but fast micro which can run at a much faster SPI speed and worry about some of the more mundane block operations such as clearing and filling. The QVGA display itself allows regions to be defined so that only they are affected as well.

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.

redheadedrod

I have not measured the dash as of yet. The 3.5" screens MAY work just fine.
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.

MagIO2

To be honest, it looks to me as if you really want a) graphics and b) high quality.

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.

Peter Jakacki

The analog dash is not going to be reproduced as is as this would require much higher resolution on each display. You need to "paint" some screens on your PC to get an idea what it could look like while fitting in with the resolution of the display. Color is not a problem as the default color depth is 16-bits and optionally 24-bits. Once you have done this then we all have a far better idea of what is required and whether it can be done.

Erik Friesen

One consideration for any screen going in a vehicle is sunlight readability. My first vehicle project used the little 2.5"? screen from parallax. It got real old not be able to read the screen, so my next project I used a fstn monochrome lcd.

redheadedrod

Thanks for the heads up so far.

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.

kwinn

With one prop for each display I don't see why you could not use a plain vanilla display and prop video out to get fast updates. For example, several of the top scan lines could reproduce the digits and graphics printed on a speedometer while the lower scan lines are used to reproduce the pointer (or a bar graph). This could even be done with a slightly modified version of one of the VGA text drivers. The same would also work for the temperature and fuel gauge.

Peter Jakacki

redheadedrod wrote: »

Thanks for the heads up so far.

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.

Rod, either way you do this you need to have an idea of what you are going to paint on the screen. So could you do me a favor and when you do this just post those images back to this thread as I would like to implement them on my displays, I am certain that it is doable and it would be a very simple solution and at the very least a good demonstration. vroom vroom.

redheadedrod

The way I see it I will have a possibility of a Straight Digital Digit displays, segmented bar graph, non segmented bar graph and Needle type displays. The Needle type display will likely take up the most power.

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

ericball

Video on the Propeller is software defined with a hardware shift register for actual pixel pushing. Each display will require at least 1 cog to drive the output. Additional cogs may be required depending upon the resolution and how the display is generated. To a certain extent you need to start with your display and then figure out how the Prop is going to drive it. For dumb screens the connection can either be composite video (3 pins, 102 colors) or VGA (8 pins, 64 colors).

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.

Kenny Gardner

Would the Lascar Panel Pilots work? They seem to be made for this type of application.

http://www.lascarelectronics.com/temperaturedatalogger.php?datalogger=393

Kenny

average joe

Our thread is a bit clogged but we have dual *touchscreens* running on the propeller using external memory. Schematic in this post::
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

redheadedrod

I didn't go all the way through the forum posting but I have seen that thread before. Just a lot more work has been done since I saw it.
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

average joe

There's a lot of clutter on that thread, mostly due to me. I've been meaning to condense the info down but have been busy with other projects. I have quite a few boards left and most parts. Feel free to PM me to discuss this in further detail.

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.