flyingnunrt
Senior Member
Sooo how can I minimise this glitch at reset?
18X using 4 NMH cells
non saftey critical, but the spike is upsetting a downstream device.
should the output be put through a darligton?
Spike on reset
- Thread starter flyingnunrt
- Start date
18X using 4 NMH cells
non saftey critical, but the spike is upsetting a downstream device.
should the output be put through a darligton?
BeanieBots
Moderator
It really depends on exactly what is connected.
Power up takes ~76mS and then however much longer due to your code to make an output a true logic level.
In most cases, a simple pull-down resistor will do the trick.
Power up takes ~76mS and then however much longer due to your code to make an output a true logic level.
In most cases, a simple pull-down resistor will do the trick.
Eh? Why a Darlington?
Mind you , we don't know what the downstream device is.
CB on standby.
BB is quite right in most cases.
Remember, when a pin goes to 'Input' that simply means high impedance state as far as the rest of the circuit is concerned. If it briefly went 'Output' then that's a different matter.
Soooo, tell us what..
A) .. "upsetting" means.
B) .. your "downstream device" is.
The solution can be dead easy or sometimes a pain.
Mind you , we don't know what the downstream device is.
CB on standby.
BB is quite right in most cases.
Remember, when a pin goes to 'Input' that simply means high impedance state as far as the rest of the circuit is concerned. If it briefly went 'Output' then that's a different matter.
Soooo, tell us what..
A) .. "upsetting" means.
B) .. your "downstream device" is.
The solution can be dead easy or sometimes a pain.
This is a common problem with any microcontroller though most time the effect of the glitch is not seen or has no adverse effect. In my experience most problems are cured by an appropriate pull-up or pull-down, sometimes by inclusion of a capacitor or an inverter.
Sometimes however there is no simple solution; a device expecting Txxxx serial may receive a low signal when a PICAXE powers up and before a program initialises the transmission line high which may be misinterpreted as data received. Even if transmitting with Nxxxx to get over I/O initialised low and using an inverter to create the Txxxx polarity the inverter itself may produce a low glitch during power up.
To minimise glitches you should initialise I/O as soon as possible in the program and, for outputs which need to initialise high, it would be best to use lines which initialise as inputs, then make them outputs at the appropriate levels, and use pull-ups.
As noted, some further information on what the downstream device is and what it expects to receive will help.
Sometimes however there is no simple solution; a device expecting Txxxx serial may receive a low signal when a PICAXE powers up and before a program initialises the transmission line high which may be misinterpreted as data received. Even if transmitting with Nxxxx to get over I/O initialised low and using an inverter to create the Txxxx polarity the inverter itself may produce a low glitch during power up.
To minimise glitches you should initialise I/O as soon as possible in the program and, for outputs which need to initialise high, it would be best to use lines which initialise as inputs, then make them outputs at the appropriate levels, and use pull-ups.
As noted, some further information on what the downstream device is and what it expects to receive will help.
flyingnunrt
Senior Member
Downstream device is simply a stopwatch. (To be used for a timing device for flyball racing.)
Using the axe to power up the stopwatch so that it can start in the stopwatch mode.
But it has to start in say stopwatch mode, 100 % of the time, at reset of the picaxe.
(Picaxe runs a sequence of lights, like at the drags, and an IR beam break checks for a clear start or red light, finally a beam break stops the clock.)
The spike sometimes forces the stopwatch to restart in normal clock mode instead of Stopwatch mode.
I would like to use the power supply for the axe to also power the stopwatch, which is what is causing the hassle.
Already tried a 10k pull down but that didn't help.
Stopwatch is grounded to same ground as picaxe.
Also tried a cap and although that did reduce the glitch it introduced a switching delay problem, but might still be a possible solution.
I might try a pull up instead of pull down resistor but I doubt that it will work.
The darlington idea was just a grasp at straws to invert the output
and it is already on the project board I've got.
Using the axe to power up the stopwatch so that it can start in the stopwatch mode.
But it has to start in say stopwatch mode, 100 % of the time, at reset of the picaxe.
(Picaxe runs a sequence of lights, like at the drags, and an IR beam break checks for a clear start or red light, finally a beam break stops the clock.)
The spike sometimes forces the stopwatch to restart in normal clock mode instead of Stopwatch mode.
I would like to use the power supply for the axe to also power the stopwatch, which is what is causing the hassle.
Already tried a 10k pull down but that didn't help.
Stopwatch is grounded to same ground as picaxe.
Also tried a cap and although that did reduce the glitch it introduced a switching delay problem, but might still be a possible solution.
I might try a pull up instead of pull down resistor but I doubt that it will work.
The darlington idea was just a grasp at straws to invert the output
and it is already on the project board I've got.
"...simply a stopwatch". - Can you give us a link to this Stopwatch data Sheet?
Is it a chip or have you hacked a proper stopwatch? How have you interfaced? What voltage?
Have you determined 100% whether it is a power glitch or I/O pin glitch causing the Stopwatch to get upset?
"Also tried a cap and although that did reduce the glitch it introduced a switching delay problem, but might still be a possible solution."
- where did you put this capacitor?
What size? What Value?
Is this guess-and-place?
Have you placed decoupling on each chip?
Is the wiring poor? Is the wiring neat or does it look like a Gorgon's haircut?
If you provide full information and your circuit schematic then someone may have a quick'n'slick solution and hopefully mean you don't have to rely on complete guesswork.
Is it a chip or have you hacked a proper stopwatch? How have you interfaced? What voltage?
Have you determined 100% whether it is a power glitch or I/O pin glitch causing the Stopwatch to get upset?
"Also tried a cap and although that did reduce the glitch it introduced a switching delay problem, but might still be a possible solution."
- where did you put this capacitor?
What size? What Value?
Is this guess-and-place?
Have you placed decoupling on each chip?
Is the wiring poor? Is the wiring neat or does it look like a Gorgon's haircut?
If you provide full information and your circuit schematic then someone may have a quick'n'slick solution and hopefully mean you don't have to rely on complete guesswork.
How you're connecting / powering your stopwatch, your full circuit, will be useful. It may not just be an issue of the PICAXE 'glitching' but of other things connected to the stopwatch. It could be a similar problem to 'phantom powering' which can affect PICmicro devices.
On top of all that, it could be the stopwatch itself. There may be no guarantee that it will enter the required mode when powered up. A number of devices I have require pressing a reset contact after power-up / changing batteries or they don't work reliably.
Have you proved ( or have a manufacturer's guarantee ) that the stopwatch will reliably always power up in the desired mode, and that it is only when using a PICAXE the problem occurs ?
On top of all that, it could be the stopwatch itself. There may be no guarantee that it will enter the required mode when powered up. A number of devices I have require pressing a reset contact after power-up / changing batteries or they don't work reliably.
Have you proved ( or have a manufacturer's guarantee ) that the stopwatch will reliably always power up in the desired mode, and that it is only when using a PICAXE the problem occurs ?
flyingnunrt
Senior Member
I'm using a rev-ed CHI030 project board and with nothing elseconnected to it other than a super brite led on ouput 0.
ie. I have completely removed all other external devices.
You can see the spike on the LED (sometimes, approx 50% of the time) when you use the onboard reset button.
Power supply is 4xNiMH cells.
Try this code
Main:
low 0
pause 1000
high 0
end
ie. I have completely removed all other external devices.
You can see the spike on the LED (sometimes, approx 50% of the time) when you use the onboard reset button.
Power supply is 4xNiMH cells.
Try this code
Main:
low 0
pause 1000
high 0
end
BeanieBots
Moderator
Pure guess but one maybe Technical can confirm.
Your last statement is a high 0
This means the output is configured as an output and it's high.
After reset: (reset turns outputs to hi-Z)
The startup routine configures the port as an output (but the state is high) so the LED comes on. It is then 'cleared' to low (by the firmware).
This would give a very brief 'glitch' on the output.
I might be totally wrong.
Your last statement is a high 0
This means the output is configured as an output and it's high.
After reset: (reset turns outputs to hi-Z)
The startup routine configures the port as an output (but the state is high) so the LED comes on. It is then 'cleared' to low (by the firmware).
This would give a very brief 'glitch' on the output.
I might be totally wrong.
Is this LED controlled through a ULN2803A Darlington Driver, and/or, is it connected to +V or 0V ?
I have no idea what happens when the inputs of a ULN2803A are left floating, but that could be the issue. If so adding a pull-up / pull-down between PICAXE I/O pin and Darlington Input should fix it.
I have no idea what happens when the inputs of a ULN2803A are left floating, but that could be the issue. If so adding a pull-up / pull-down between PICAXE I/O pin and Darlington Input should fix it.
BeanieBots
Moderator
An open input on a ULN2803a should leave the output off / non conducting.
It is a fairly low impedance so will not 'float' like an open PICAXE input would.
http://focus.ti.com/lit/ds/symlink/uln2803a.pdf
It is a fairly low impedance so will not 'float' like an open PICAXE input would.
http://focus.ti.com/lit/ds/symlink/uln2803a.pdf
Thanks BeanieBots.
It could be the ordering of setting port related registers; Technical would have to answer that.
Knowing whether the HIGH or LOW turns the LED on, whether LED to +V or 0V, would help us to determine what we should perhaps be looking for. It could simply be Reset button bouncing.
I'm not sure that I can completely get to grips with the failure mode at present though. If the stopwatch is powered by the PICAXE I'm not sure why a glitch would cause it change modes.
I'd want to put a scope on it and see exactly what is happening.
It could be the ordering of setting port related registers; Technical would have to answer that.
Knowing whether the HIGH or LOW turns the LED on, whether LED to +V or 0V, would help us to determine what we should perhaps be looking for. It could simply be Reset button bouncing.
I'm not sure that I can completely get to grips with the failure mode at present though. If the stopwatch is powered by the PICAXE I'm not sure why a glitch would cause it change modes.
I'd want to put a scope on it and see exactly what is happening.
BeanieBots
Moderator
As it's the CHI030 board I think would be safe to assume it's an LED wired between +ve and a darlington output and that high turns it on.
The stopwatch issue is something else but the 'glitch' is apparent on a simple LED.
The order of setting registers sounds very plausible.
The stopwatch issue is something else but the 'glitch' is apparent on a simple LED.
The order of setting registers sounds very plausible.
flyingnunrt
Senior Member
@Hippy
If so adding a pull-up / pull-down between PICAXE I/O pin and Darlington Input should fix it.
Thats was what I was thinking.
Many Thanks
@BB
Just tried turning off output 0 before the reset and that also appears to be working.
If so adding a pull-up / pull-down between PICAXE I/O pin and Darlington Input should fix it.
Thats was what I was thinking.
Many Thanks
@BB
Just tried turning off output 0 before the reset and that also appears to be working.