On Fri, Dec 03, 2010 at 02:46:16PM -0800, Kirk Wallace wrote:
> I'm working on using an ATtiny to watch EMC2's charge pump. The plan is
> to have a count down that gets reset by a charge pump edge. If the
> counter reaches 0, then an alarm pin gets set. The counter reset value
> determines how long the charge pump has to do a reset. I can write code
> with the appropriate value, but if I wanted to make the watchdog watcher
> generic, I should have a way for a user to make the setting on the fly.
> My problem is that I can do this with a dip switch, potentiometer,
> serial or SPI link, or some other way I haven't thought of yet. Does
> anyone have any thoughts on what would be a good way to do this? The
> primary purpose for the watcher is to keep the motor drivers powered
> down until the PC boots and EMC2 is running.
That is an admirable way to design, Kirk. Here are a few thoughts, which
probably don't do more than explore what you're already thinking.
If the device is 14 pin, then a dip switch is feasible, but still eats
pins which would be needed for any ancilliary functions which arise
later in the project. On an 8 pin device, another solution is needed, if
a broad range of timings is to be achieved.
Yes, a potentiometer connected to an A/D uses only one pin. Even if the
A/D is only good to 8 or 9 of the 10 bits, after accounting for errors,
then it's better than 0.4%. Even if the user didn't want a trimpot
(potentially in an environment with metallic particles and coolant mist)
affecting reliability, he could solder in two fixed resistors instead.
(And a filter capacitor on the junction, to reduce any noise
injected from power circuits. If the parallel combination of the
two resistors is over 10k, the capacitor also helps compensate for the
small current drawn by the A/D's S/H capacitance during sampling.)
Alternatively, if sufficient code space remains, to handle user
interfacing, then we the EEPROM could be used, as you're considering
with the serial solutions. If we drive a LED, via a transistor, there's
negligible load on the port pin, with a base resistor of several kOhm,
so we also connect a NO pushbutton switch to ground.
Now, firmware sets the port as input, after reset/power_up. If the
button is pressed at power_up, we go into SET mode, and await release of
the button. Once there, we switch the port pin to output, and blink the
LED once, then again switch to input, and wait 1-2 seconds for the
button to be pressed. In the absence of input, we repeat with another
blink. When there finally is input, we read a software counter we've
incremented between blinks, and take it as a direct value (e.g. ms x 20)
or an index into a short table, if so wide a range of values is needed,
that waiting for incrementing LED blink counts would become tedious.
An enhancement of this could be to first issue long blinks, signifying
tens of timing units, and capture N of them with a button push after the
Nth blink, then repeat with shorter blinks, signifying that we now want
the units, M, such that the whole value = 10*N + M. That more
conveniently covers a broader range of values, but still with a fine
resolution, than linear counting.
OK, that's fiddlier than a potentiometer, but there are compensations.
The LED may be used for other indications after set-up, and the
pushbutton is also available for other user input.
Then there's your serial solutions. Since all users have the EMC2 host
to hand, and probably have a serial port, even if by means of a
USB/serial dongle, then minicom or ckermit could easily be used to input
a value. The input could be echoed, to confirm that it was correctly
received. But that would use a second port pin. If we stay on an ATtiny,
then we need code space for a software UART. (I haven't checked that an
ATtiny's uncalibrated RC oscillator will always be accurate enough for
serial communication, but the first character sent from the PC could be
used for auto-calibration.)
Once a serial link to the EMC2 host exists, is it possible to resist the
temptation to put in a $3 - $4 ATmega, to limit the risk of running out
of code space, once the ancilliary functions stick their grinning faces
over the parapet?
Hmm, what other solutions are there?
Erik
--
For humans, honesty is a matter of degree. Engineers are always honest in
matters of technology and human relationships. That's why it's a good idea
to keep engineers away from customers, romantic interests, and other people
who can't handle the truth.
(Scott Adams - The Dilbert principle)
------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
