New Features for MPGuino?

[msc]

With all the concern about I/O expansion I have to wonder how much room is left for code expansion. If I'm piecing bits of information together correctly on the 168 chip you need to use 011 IDE because later libraries are too large to fit. I assume that with the 328 chip it's possible to use the latest IDE but probably loose a fair amount of the expanded code space to the larger libraries. Having no idea the actual number I'll guess that 3/4 of the code space in the 328 chip is already consumed just to run existing features. I suspect the reason behind the bump in clock speed from 16Mhz to 20Mhz was because the 16Mhz could barely keep up. I expect all the timer resources are in use as well. Between all that there are limits to what can be added. I'm sure there is plenty of space for some useful features but unless someone takes on some serious optimization and assembly coding I don't expect there is room to turn this into a Swiss army knife of instruments. I wouldn't worry about adding I/O until there is a plan for them.

My personal wish list is to add a tach and 12 hour clock then fit it in the Civic/CRX dash clock housing. I have seen reference to a tach that may or may not be in the current version and now I see that FalconFour has been working on the clock. It seems that all that is required to meet my goals are to patch together some code that is mostly done and create my own version of the hardware.

I'm expecting to receive an Arduino Nano and a couple displays soon and will have a chance to start tinkering. Just have to teach myself C along the way.

I'm looking forward to playing with the interface circuitry. I have it sorted out what should work for my CRX HF but have yet so look into the requirements for my Volvo 240 Wagon that I will be driving over the winter. I'm almost hoping the Volvo is pulse and hold injectors so I have motivation and a test bed to address the problems with them. I have would shold be a rock solid solution in mind for the PWM type of drive.

Mike

[nickdigger]

Originally Posted by msc

I suspect the reason behind the bump in clock speed from 16Mhz to 20Mhz was because the 16Mhz could barely keep up.

Not at all. The vast majority of clock cycles in the current code are spent waiting for LCD characters to be displayed. By tightening up the delays, you can reduce the 'load' down to 10% on a 16mhz 168, and a 20x4 LCD. 16mhz is plenty fast for this app.

[dcb]

ah, found my notes on it
http://ecomodder.com/forum/showthrea...tml#post108367

The faster crystal allows more accurate sample timing is probably the best reason, as well as enabling a more capable unit in general.

[saand]

msc,
You are likely to have an issue with your clock idea, you will have a big problem getting accurate timing unless you sink the clock to some external (more accurate) timing device than what the processor runs on.
There is a standard issue in timing applications for electronics where time will drift due to accumulating errors. So unless you are planning on making use of a clock crystal (oscillator that runs at close to 32 k Hz) then you are likely to have issues with your timer.

Feel free to prove me wrong but thought i might save you a bit of time because i have had this problem myself.

[bobski]

Originally Posted by saand

you will have a big problem getting accurate timing unless you sink the clock to some external (more accurate) timing device than what the processor runs on.

That's what led me to RTC chips in the first place. I made a simple stopwatch-timer program based on the millis() function and let it run over night along side a timex wristwatch. After about 10 hours, it was off by a minute and change. That's something like 0.2% error, which is fine for tracking injector pulses and such. On the other hand, losing an hour and a half every month isn't up to snuff for time keeping.

[dcb]

well, the thing is, the timer interrupt by itself, when controlled by an external crystal is every bit as precise as a "RTC". If you don't have an external crystal (i.e. you are using a ceramic resonator or an internal oscillator), it would be far less expensive than an RTC and support hardware.

Also worth noting that there are lots of ways for an application to interfere (mess up) when converting "computer time" to real time, though millis() looks pretty solid, in 0011 anyway.

But an accurate software clock has been done, several times, on an arduino. Arduino playground - Time . If a software clock is off by a consistent amount, then it can be calibrated in software too.

Based on the figures here, my guess is that your inaccuracies are due to using a ceramic resonator instead of a crystal.
Arduino Forum - Arduino clock accuracy

The accuracy of the millis() function is governed by the clock in your Arduino board which is driven by either a crystal or ceramic resonator. A crystal has an accuracy of roughly +/- 50 parts per million (ppm) or so (some are more accurate some are less, but 50ppm is about right for a cheap crystal).

50 ppm = 0.005% accuracy which in your case equals about 0.72 seconds deviation from the nominal delay over 4 hours at 16MHz

A ceramic resonator is about 0.5% accurate = 72 seconds over 4 hours or about 1 minute 12 seconds at 16MHz.
...
The same kind of clock accuracy calculations apply to a DS1307 RTC, the fundamental accuracy of the crystal determines the accuracy of the time it keeps, there's nothing special about the DS1307 in terms of accuracy and it could in fact be worse than the Arduino's internal clock. It all comes down to the simple question of how accurate you need the timing to be for your application and then select an appropriate oscillator.

I mean sheesh, 40 cent xtal vs 30 cent resonator + $20 RTC module?!?

FWIW, I have a hello kitty watch (came in a kids meal) hotglued to the dash for a clock

[bobski]

Originally Posted by dcb

I mean sheesh, 40 cent xtal vs 30 cent resonator + $2.73 RTC module?!?

Fixed that for ya. The sparkfun module, while convenient for breadboarding, is a ripoff IMO. If we're talking about swapping around system clock sources it's only fair to compare component-level prices, even if the components require a patch of PCB.

Originally Posted by dcb

Based on the figures here, my guess is that your inaccuracies are due to using a ceramic resonator instead of a crystal.

That's entirely possible. It certainly looks ceramic, rather than one of the metal-cased components I've seen on other board designs.

[dcb]

Well, it's probably more like $6 if you add in battery+holder+xtal (hmm, still need one of those) plus $1 of pcb real estate (fudge).

I'm a little irked at seeedstudio for that silly bit of "cost savings" on the ceramic resonator, lots of clones took that route.

[steffen707]

Originally Posted by bobski

Personally, I would like to get both the character display and buttons on the I2C bus. That way the Arduino "brain" could be located where ever is convenient (close to the ECM, somewhere central behind the dash, whatever) while the display and buttons are situated in easy view/reach,

Im not following your hardware software discussion here, BUT.

I too was thinking of moving my display and buttons to a nice job-box on the dash, and moving the brains of the operation to a cooler location. This might eliminate some people's units getting too hot, or how some people are trying to add in a fan to cool the unit.

I don't know if my freezing problems are from a bad chip, bad board, too much heat, software glitch. But I thought this would be somehthing to try. Can you just de-solder the buttons and the lcd and then solder on long wires and run them back to where they were soldered on the board? That was my intent.

[bobski]

Originally Posted by steffen707

Can you just de-solder the buttons and the lcd and then solder on long wires and run them back to where they were soldered on the board?

Yes. None of the signals are a high enough clock speed where wire capacitance could be an issue. The only possible problem would be electrical noise. Just avoid running the wires past any motors or high voltage items and you should be fine I imagine. If you still have noise problems (erroneous input, glitched characters on the LCD), try wrapping your extension wires with a layer of aluminum foil and ground the foil.