Neato '79 Gauge Discovery and a few questions?

This site may earn a commission from merchant affiliate
links, including eBay, Amazon, Skimlinks, and others.

I agree the propeller is nice, thats actually an awesome device, I might grab a few for future projects.

The problem is, for a tach or other timing-critical device your accuracy is determined by how well you know your instruction timing. When you write in a higher level language you usually won't know just how many instructions it takes to execute a line of code - best case is only one but you could actually wind up with 4 or many more instructions on a line. Python is actually pretty bad in this respect, as many of the functions are sorta like C macros... layers and layers of hidden instructions.

Example:
C:
Code:
i++;
You don't know if you compiler is going to translate that to:
Code:
incf i;
or in a worst case something like:
Code:
movfw i;
addlw 0x01;
movwf i;
On a computer you might have a background timer to keep things in sync, but on an embedded device you don't.

Its funny this came up, I have a bunch of ideas I'd like to try for my BJ42... combining hobbies, I guess. For one I want to rig up a new glow controller that lights up when a certain plug temperature is reached (rather than the simple coil used now). I've also been thinking about a cruise control........

Ok well I can't argue with that... I do know that the higher level languages keep you out of the muck but they also don't let you see what is happening in the muck. It works great for sysadmin stuff, not so much for timing critical stuff. Perhaps we need to split out the timing critical stuff to the pic, but the display stuff to the propeller.

I think we have a good start to a team here... perhaps we should take this off to a more appropriate site. Any suggestions for that?
 
Ok well I can't argue with that... I do know that the higher level languages keep you out of the muck but they also don't let you see what is happening in the muck. It works great for sysadmin stuff, not so much for timing critical stuff. Perhaps we need to split out the timing critical stuff to the pic, but the display stuff to the propeller.

I think we have a good start to a team here... perhaps we should take this off to a more appropriate site. Any suggestions for that?

Definitely. The propeller has a serial interface presumably to make it easy to connect to a computer. Many PICs like the extremely popular 16F628 (20MHz) have built in serial routines - the timing portions of the program would run at the 20MHz (5MHz instruction clock) to compile data before delivering it to the propeller via the built-in serial macros maybe 20 times per second or something.

Well, thats how I'd do it, anyway.
 
My biggest uC project was for a mountain bike. I built a combination speedo and halogen headlight controller. It would auto-dim the light based on bike speed for increased battery life. I used a bare PIC with a little serial BIOS so you could self-load code over a serial cable. The program was written in object-oriented assembly.

The display was an i2c lcd; nothing fancy.

I do have a background in graphics with some UI experience.

My current company makes a $15 micro that can encode and decode video. It can drive an HD display directly. You could watch TV on your all-glass cockpit and encode a couple of rock cameras to disk at the same time, then upload the videos over WiFi when you got home. It runs Linux 2.6.23. :)

I actually looked into using linux for an all glass dash... issue is that it takes forever to boot up even on flash drive compared to an embedded device. And yes you could send it to suspend, but I have had issue after issue on laptops when returning from suspend on linux...

I am interested in that chip your company makes though... one of my far fetched ideas is to put 2 micro cameras in each wheel well and pipe it to a screen so that you can see what is going on there while you drive... that would work great with a glass dash.

I think that the glass dash is going to be a place to bring all of these things together. Which essentially means that it needs to be modular... perhaps what we may need to do is use CAN to bring in outside data to the glass dash. What my ultimate goal is to do something like what these guys do minus the ridiculous cost.

PLX Devices Inc. - Custom Digital Gauges, Wideband O2 Air Fuel Ratio, OBD 2, Data Loggers

I want a person to use an external program to design the dash of their liking and just load it up and run it on the glass dash framework. The external program should allow a user to state where the input for each guage or indicator comes from... so for the glow plugs and cruise controller that amaurer wants, he just needs tell it where the input is and assign it to a guage or indicator.

And yes I have though about a touch screen too... but let's think about that at a later date.
 
I actually looked into using linux for an all glass dash... issue is that it takes forever to boot up even on flash drive compared to an embedded device. And yes you could send it to suspend, but I have had issue after issue on laptops when returning from suspend on linux...

I just timed it. Our chip boots to a shell prompt in 8 seconds including the video init and dhcp to get an ip address. The root file system is on an SD card in this system.

If one was to punt the wimpy micros and go for a full-blown system like ours you get five high-res timers and 300mhz, so you can write everything in C++ or your favorite interpreted language and use drivers and interrupt handlers for the time-critical portions to get good precision. It's got a serial port and i2c for connectivity, but I don't see why you'd need another processor for anything. I/O can be connected via i2c I/O expanders. It's also got SPI, 2xUSB 2.0, I/R, SATA, SD Card, Vector floating point, etc...
 
Last edited:
I thought one of the issues with the VSS on the backs was the wave wasn't the correct type. SIne or square I can't remember.

And assuming you don't have cruise control does it really matter how many pulses your getting? I thought it was just to tell the computer the vehicle was moving. Considering that most of us have larger tires and the speedo is off anyway. Does it really matter?
 
I just timed it. Our chip boots to a shell prompt in 8 seconds including the video init and dhcp to get an ip address. The root file system is on an SD card in this system.

If one was to punt the wimpy micros and go for a full-blown system like ours you get five high-res timers and 300mhz, so you can write everything in C++ or your favorite interpreted language and use drivers and interrupt handlers for the time-critical portions to get good precision. It's got a serial port and i2c for connectivity, but I don't see why you'd need another processor for anything. I/O can be connected via i2c I/O expanders. It's also got SPI, 2xUSB 2.0, I/R, SATA, SD Card, Vector floating point, etc...

Ok that is to the shell prompt... how long to get up X and then slap a gui on it. Hmmm since the chip runs linux... could it run something like Syllable? Syllable - News That boots up like a bat outta hell right to a full blown gui. The reason I want to stay away from linux ( and mind you I have been using linux since around 1994 when the kernel version was .97) is that it has such a broad scope of things it can do in so many different ways that it will start to get really slow on boot up... Frankly 8 seconds is really fast for linux, but if you got in your car... started it up and it took 8-10 seconds for you guages to respond would you be pissed? I know I would. I bet you that the best time we could get to bring up a full glass dash on that chip would be 15 seconds... that would make me want to punch something. That's why I think that the scope for a glass dash needs to be very narrow... basically a display module that can accept input from multiple sources and put them on screen in the fashion that the end user wants. If you distill down an automotive dash it is to monitor the engine and your speed and you want to know that info as soon as the engine starts.

What is the website for your company? It would be nice to check out that chip.


But this is just my opinion, and just like assholes everybody has one. :D
 
If you want it to be up quicker, you could connect it directly to power and use a motion sensor to get it to boot when you opened the door. You can put up a fake display right out of the boot prom to make it look like something immediately. I wouldn't use a window system for a gauge display anyway. We use Qt as a drawing package. Remember too that it plays video from wifi. It could preview the latest redtube videos while the engine was warming up as a background to the gauges. :eek:
 
My biggest uC project was for a mountain bike. I built a combination speedo and halogen headlight controller. It would auto-dim the light based on bike speed for increased battery life. I used a bare PIC with a little serial BIOS so you could self-load code over a serial cable. The program was written in object-oriented assembly.

The display was an i2c lcd; nothing fancy.

I do have a background in graphics with some UI experience.

My current company makes a $15 micro that can encode and decode video. It can drive an HD display directly. You could watch TV on your all-glass cockpit and encode a couple of rock cameras to disk at the same time, then upload the videos over WiFi when you got home. It runs Linux 2.6.23. :)

:idea: sounds like fun.
 
If you want it to be up quicker, you could connect it directly to power and use a motion sensor to get it to boot when you opened the door. You can put up a fake display right out of the boot prom to make it look like something immediately. I wouldn't use a window system for a gauge display anyway. We use Qt as a drawing package. Remember too that it plays video from wifi. It could preview the latest redtube videos while the engine was warming up as a background to the gauges. :eek:

See that is my point, I don't want to come up something ghetto fabulous to make me think I got a display. I don't have doors on my truck... it is an fj-40... nice to have the dash boot up every time someone walks by the truck while it is parked because I have a motion detector on it. Fake displays are not a real display. QT is a good place to start. Playing video over wifi is not what I want my glass dash to do... it's nice, but not it's primary function.

However, I do think that your chip would make an excellent starting point for a wicked in car entertainment system. So where can I see this chip?
 
If you want it to be up quicker, you could connect it directly to power and use a motion sensor to get it to boot when you opened the door. You can put up a fake display right out of the boot prom to make it look like something immediately. I wouldn't use a window system for a gauge display anyway. We use Qt as a drawing package. Remember too that it plays video from wifi. It could preview the latest redtube videos while the engine was warming up as a background to the gauges. :eek:

I figure it takes 20 seconds for glow plugs to warm up on average... so no down time there.... for a BJ or HJ. :)

Depending on how much power draw you can set the chip to keep running and power off the displays. just power them back up when you start. if the power is off for more then an hour save states and shutdown.
 
Last edited:
Since this is rapidly getting off topic... let's take this someplace where we can figure out what we want to do more effectively. I have created a yahoo group for those of use who want to actively pursue this project.

GlassDash : Glass Dash
 
However, I do think that your chip would make an excellent starting point for a wicked in car entertainment system. So where can I see this chip?

China. I'm trying to get a distributor in the US, but as of now you need to be threatening 10's of thousands of units per month to get a datasheet. It's been my goal since I've been working here to get a hacker-friendly demo board available for a low price, but so far, no dice. Sorry for the tease.

The chip is a 288-pin ball grid array, so you can't do anything with it without a having a PCB fab. It requires 300mhz DDR II, so the layout is critical.

The software release is also not ready for anyone less than a computer engineer. It's not like a PC with redhat.

What I'd like to do is get the company to do a basic design with the chip and memory, SPI EPROM, USB, SDIO, HDMI and a couple 0.1" on-center connectors to bring out the other I/O ports. Then you could add it to a hacker-style breadboard.

In the meantime, we're always behind schedule on some customer project, so this kind of diversion is hard to justify.

Stay tuned.
 
China. I'm trying to get a distributor in the US, but as of now you need to be threatening 10's of thousands of units per month to get a datasheet. It's been my goal since I've been working here to get a hacker-friendly demo board available for a low price, but so far, no dice. Sorry for the tease.

The chip is a 288-pin ball grid array, so you can't do anything with it without a having a PCB fab. It requires 300mhz DDR II, so the layout is critical.

The software release is also not ready for anyone less than a computer engineer. It's not like a PC with redhat.

What I'd like to do is get the company to do a basic design with the chip and memory, SPI EPROM, USB, SDIO, HDMI and a couple 0.1" on-center connectors to bring out the other I/O ports. Then you could add it to a hacker-style breadboard.

In the meantime, we're always behind schedule on some customer project, so this kind of diversion is hard to justify.

Stay tuned.

HA! jesus man, talk about a tease! While it sounds awesome, your chip is essentially unobtainium, and with a ball grid is beyond my abilities to easily prototype on. Plus it doesn't sound like you're gonna beat the PIC price-point :D Just guessin... heh.

If someone has a huge hardon for a glass dashboard that supports HD video (?!) then I guess a full-featured IC like that is in order. There are other micro-Linux implementations ike gumstix (gumstix.com), however on my planet this application is perfect for a uC. Short of HD video, simple data conversion and serial output just doesn't need anything beyond a microcontroller.

I should be honest, however, I'm not an EE, I'm an aero. engineer. I've got a working knowledge of this stuff from work and hobbies, but I won't call myself an expert.
 

Users who are viewing this thread

Back
Top Bottom