472,789 Members | 1,245 Online

debounce state diagram FSM

I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?

Thanks,

Anson

Apr 29 '07 #1
70 4191
My suggestion:
Feed the input into a 3-bit shift register.
Detect all-ones (111) and used that signal to set a latch,
detect all-zeros (000) and use that signal to reset a latch.
The latch is your de-bounced signal.
Peter Alfke

On Apr 29, 11:32 am, Anson.Stugg...@gmail.com wrote:
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?

Thanks,

Anson

Apr 29 '07 #2
On Apr 29, 11:45 am, Peter Alfke <a...@sbcglobal.netwrote:
My suggestion:
Feed the input into a 3-bit shift register.
Detect all-ones (111) and used that signal to set a latch,
detect all-zeros (000) and use that signal to reset a latch.
The latch is your de-bounced signal.
Peter Alfke

On Apr 29, 11:32 am, Anson.Stugg...@gmail.com wrote:
I'm designing adebouncefilter using Finite State Machine. TheFSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set theFSMto output 1s until it receives the correct
input and ouput.
This is the test sequence with input and correct output.
1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.
Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?
Thanks,
Anson- Hide quoted text -

- Show quoted text -
Thanks Peter for the suggestion. But my problem is coming up with the
state diagram for this FSM. How can I implement what you suggested on
a state diagram? Thanks.

Anson

Apr 29 '07 #3
An************@gmail.com wrote:
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?
I'm not sure I understand your terminology, but I am
assuming that that state neames mean:

SEE1 = output = 0 after 1 has been input 1 times in a row.

SEE11 = output = 0 after 1 has been input 2 times in a row.

SEE111 = output = 1 after 1 has been input 3 times in a row
(or a 1 is input after 0 has been input less than 3
times in a row).

SEE0 = output = 1 after 0 has been input 1 times in a row.

SEE00 = output = 1 after 0 has been input 2 times in a row.

SEE000 = output = 0 after 0 has been input 3 times in a row
(or a 0 is input after 1 has been input less than 3
times in a row).

If this is the case, then the 12 transitions are:

before input after
SEE1 1 SEE11
SEE1 0 SEE000
SEE11 1 SEE111
SEE11 0 SEE000
SEE111 1 SEE111
SEE111 0 SEE0
SEE0 1 SEE111
SEE0 0 SEE00
SEE00 1 SEE111
SEE00 0 SEE000
SEE000 1 SEE1
SEE000 0 SEE000

Apr 29 '07 #4
On Apr 29, 12:32 pm, Anson.Stugg...@gmail.com wrote:
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?
A counter counts toward 3 as long as the input state stays the same.
Any change resets the counter to zero. On reaching 3, the counter
enables the last occurring input state to be latched to the output.
That is, instead of counting ones or zeros, count all clocks, with any
input change resetting the counter.
--
John
Apr 29 '07 #5
Peter Alfke wrote:
My suggestion:
Feed the input into a 3-bit shift register.
Detect all-ones (111) and used that signal to set a latch,
detect all-zeros (000) and use that signal to reset a latch.
The latch is your de-bounced signal.
That is exactly the way I do it with PIC code, a whole port
at a time, in parallel. I also generate additional bytes
that indicate a change of state of any of the port inputs
from 1 to 0 and 0 to 1. This single shot bits are very
handy to have on the shelf when a program development needs
one. So the storage requirement is i byte each for 8:

state of raw inputs,

previous state of inputs,

twice previous state of inputs,

debounced inputs,

debounced inputs that have just transitioned to 1,

debounced inputs that have just transitioned to 0.

I don't have the code handy, but I seem to remember that it
took only something like 18 instructions to maintain this
table of bytes servicing an 8 bit port.
Apr 29 '07 #6
On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.netwrote:
Anson.Stugg...@gmail.com wrote:
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.
This is the test sequence with input and correct output.
1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.
Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?

I'm not sure I understand your terminology, but I am
assuming that that state neames mean:

SEE1 = output = 0 after 1 has been input 1 times in a row.

SEE11 = output = 0 after 1 has been input 2 times in a row.

SEE111 = output = 1 after 1 has been input 3 times in a row
(or a 1 is input after 0 has been input less than 3
times in a row).

SEE0 = output = 1 after 0 has been input 1 times in a row.

SEE00 = output = 1 after 0 has been input 2 times in a row.

SEE000 = output = 0 after 0 has been input 3 times in a row
(or a 0 is input after 1 has been input less than 3
times in a row).

If this is the case, then the 12 transitions are:

before input after
SEE1 1 SEE11
SEE1 0 SEE000
SEE11 1 SEE111
SEE11 0 SEE000
SEE111 1 SEE111
SEE111 0 SEE0
SEE0 1 SEE111
SEE0 0 SEE00
SEE00 1 SEE111
SEE00 0 SEE000
SEE000 1 SEE1
SEE000 0 SEE000- Hide quoted text -

- Show quoted text -
That's it John...Thanks a lot...you're the man!

Apr 29 '07 #7
An************@gmail.com wrote, On 29/04/07 19:32:
I'm designing a debounce filter using Finite State Machine. The FSM
<snip>
Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?
You need to decide whether you will be implementing it in hardware or
software. If hardware, which I suspect from all the groups other than
comp.lang.c when why are you cross-posting to a C language group? If
software, then why post to all the other groups? Either way your
selection of groups has to be wrong.

Personally I would suggest implementing it in HW rather than SW
(although I have implemented debounce in SW a couple of times when the
HW design was broken).

Follow-ups set to exclude comp.lang.c, and I would like to request that
they are posting C related answers to this problem.
--
Flash Gordon
Apr 29 '07 #8
An************@gmail.com writes:
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?
This question has nothing to do with the C programming language. Why
did you post to comp.lang.c? Followups redirected.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 29 '07 #9
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?
Debouncing can come in several flavors, and from what I can gather from
your description, the debouncing should be focussed on changing the
debounced representation of the input. Something like shown below where
the OUT FF is a conditional toggle using the EXOR feedback and
conditioned to toggle or remain-the-same as a function of the three
input states prior to the active clock edge, all different from OUT
causing a toggle and one or more the same as OUT preventing the toggle:
View in a fixed-width font such as Courier.

..
..
..
.. .--------------------+----------------+->OUT
.. | | |
.. | __ | __ ----- |
.. IN>---+-----------|--\ \ \ __ '-\ \ \ | | |
.. | | | | >------| \ | | >|D Q|-'
.. | +--/ /__/ .----| >--/ /__/ | |
.. | | | .-|__/ | |
.. | | | | clk- |
.. | ----- | | | | |
.. | | | | __ | | -----
.. '-|D Q|-+-|--\ \ \ | |
.. | | | | | | >-' |
.. clk- | | +--/ /__/ |
.. | | | | |
.. ----- | | |
.. .---------' | |
.. | ----- | |
.. | | | | __ |
.. '-|D Q|---|--\ \ \ |
.. | | | | | >----'
.. clk- | '--/ /__/
.. | |
.. -----
..
..
..

Apr 29 '07 #10
On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.netwrote:
Anson.Stugg...@gmail.com wrote:
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.
This is the test sequence with input and correct output.
1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.
Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?

I'm not sure I understand your terminology, but I am
assuming that that state neames mean:

SEE1 = output = 0 after 1 has been input 1 times in a row.

SEE11 = output = 0 after 1 has been input 2 times in a row.

SEE111 = output = 1 after 1 has been input 3 times in a row
(or a 1 is input after 0 has been input less than 3
times in a row).

SEE0 = output = 1 after 0 has been input 1 times in a row.

SEE00 = output = 1 after 0 has been input 2 times in a row.

SEE000 = output = 0 after 0 has been input 3 times in a row
(or a 0 is input after 1 has been input less than 3
times in a row).

If this is the case, then the 12 transitions are:

before input after
SEE1 1 SEE11
SEE1 0 SEE000
SEE11 1 SEE111
SEE11 0 SEE000
SEE111 1 SEE111
SEE111 0 SEE0
SEE0 1 SEE111
SEE0 0 SEE00
SEE00 1 SEE111
SEE00 0 SEE000
SEE000 1 SEE1
SEE000 0 SEE000
Hi John,

It is not that I'm saying the table is wrong (since I'm new to this
and trying to learn) but how do you say: SEE1 with input 0 goes to
SEE11 state? because then our state must be SEE01!

Any comment?

Apr 30 '07 #11
Amit wrote:
On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.netwrote:
>Anson.Stugg...@gmail.com wrote:
>>I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.
This is the test sequence with input and correct output.
1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.
Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?
I'm not sure I understand your terminology, but I am
assuming that that state neames mean:

SEE1 = output = 0 after 1 has been input 1 times in a row.

SEE11 = output = 0 after 1 has been input 2 times in a row.

SEE111 = output = 1 after 1 has been input 3 times in a row
(or a 1 is input after 0 has been input less than 3
times in a row).

SEE0 = output = 1 after 0 has been input 1 times in a row.

SEE00 = output = 1 after 0 has been input 2 times in a row.

SEE000 = output = 0 after 0 has been input 3 times in a row
(or a 0 is input after 1 has been input less than 3
times in a row).

If this is the case, then the 12 transitions are:

before input after
SEE1 1 SEE11
SEE1 0 SEE000
SEE11 1 SEE111
SEE11 0 SEE000
SEE111 1 SEE111
SEE111 0 SEE0
SEE0 1 SEE111
SEE0 0 SEE00
SEE00 1 SEE111
SEE00 0 SEE000
SEE000 1 SEE1
SEE000 0 SEE000

Hi John,

It is not that I'm saying the table is wrong (since I'm new to this
and trying to learn) but how do you say: SEE1 with input 0 goes to
SEE11 state? because then our state must be SEE01!
The 6 states are defined above the transition table. There
is no SEE01 state, because there is no reason to keep track
of that sequence. If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives, you just go back to state SEE000 (the one
where the output was decided to be changed to zero) since
the required 3 1s in a row cannot occur till at least a
single 1 arrives. Any zero arriving before that triple 1 is
received just starts the count over.
Apr 30 '07 #12
On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.netwrote:
Amit wrote:
On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.netwrote:
Anson.Stugg...@gmail.com wrote:
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.
This is the test sequence with input and correct output.
1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.
Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?
I'm not sure I understand your terminology, but I am
assuming that that state neames mean:
SEE1 = output = 0 after 1 has been input 1 times in a row.
SEE11 = output = 0 after 1 has been input 2 times in a row.
SEE111 = output = 1 after 1 has been input 3 times in a row
(or a 1 is input after 0 has been input less than 3
times in a row).
SEE0 = output = 1 after 0 has been input 1 times in a row.
SEE00 = output = 1 after 0 has been input 2 times in a row.
SEE000 = output = 0 after 0 has been input 3 times in a row
(or a 0 is input after 1 has been input less than 3
times in a row).
If this is the case, then the 12 transitions are:
before input after
SEE1 1 SEE11
SEE1 0 SEE000
SEE11 1 SEE111
SEE11 0 SEE000
SEE111 1 SEE111
SEE111 0 SEE0
SEE0 1 SEE111
SEE0 0 SEE00
SEE00 1 SEE111
SEE00 0 SEE000
SEE000 1 SEE1
SEE000 0 SEE000
Hi John,
It is not that I'm saying the table is wrong (since I'm new to this
and trying to learn) but how do you say: SEE1 with input 0 goes to
SEE11 state? because then our state must be SEE01!

The 6 states are defined above the transition table. There
is no SEE01 state, because there is no reason to keep track
of that sequence. If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives, you just go back to state SEE000 (the one
where the output was decided to be changed to zero) since
the required 3 1s in a row cannot occur till at least a
single 1 arrives. Any zero arriving before that triple 1 is
received just starts the count over.

have a problem with this:
>If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives

Question: let's say we are at SEE1 and input is 1. How should I know
the system expects 0? why not 1?

Regards,
amit

Apr 30 '07 #13
On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.netwrote:
Amit wrote:
On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.netwrote:
>Anson.Stugg...@gmail.com wrote:
>>I'm designing a debounce filter using Finite State Machine. The FSM
>>behavior is it follows the inital input bit and thinks that's real
>>output until it receives 3 consecutive same bits and it changes output
>>to that 3 consecutive bit until next 3 consecutive bits are received.
>>A reset will set the FSM to output 1s until it receives the correct
>>input and ouput.
>>This is the test sequence with input and correct output.
>>1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
>>1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
>>The state diagram I came up has 6 states and it's named SEE1, SEE11,
>>SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
>>the input. Because it just came from SEE1 and before SEE1, it came
>>from SEE000, so at SEE1 it can not change ouput to 1 which is what I
>>have specified that state's ouput to be.
>>Anyone knows how to solve this problem? Or maybe there's other better
>>ways to design the state diagram?
>I'm not sure I understand your terminology, but I am
>assuming that that state neames mean:
>SEE1 = output = 0 after 1 has been input 1 times in a row.
>SEE11 = output = 0 after 1 has been input 2 times in a row.
>SEE111 = output = 1 after 1 has been input 3 times in a row
> (or a 1 is input after 0 has been input less than 3
> times in a row).
>SEE0 = output = 1 after 0 has been input 1 times in a row.
>SEE00 = output = 1 after 0 has been input 2 times in a row.
>SEE000 = output = 0 after 0 has been input 3 times in a row
> (or a 0 is input after 1 has been input less than 3
> times in a row).
>If this is the case, then the 12 transitions are:
>before input after
>SEE1 1 SEE11
>SEE1 0 SEE000
>SEE11 1 SEE111
>SEE11 0 SEE000
>SEE111 1 SEE111
>SEE111 0 SEE0
>SEE0 1 SEE111
>SEE0 0 SEE00
>SEE00 1 SEE111
>SEE00 0 SEE000
>SEE000 1 SEE1
>SEE000 0 SEE000
Hi John,
It is not that I'm saying the table is wrong (since I'm new to this
and trying to learn) but how do you say: SEE1 with input 0 goes to
SEE11 state? because then our state must be SEE01!
The 6 states are defined above the transition table. There
is no SEE01 state, because there is no reason to keep track
of that sequence. If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives, you just go back to state SEE000 (the one
where the output was decided to be changed to zero) since
the required 3 1s in a row cannot occur till at least a
single 1 arrives. Any zero arriving before that triple 1 is
received just starts the count over.

have a problem with this:
If you are at SEE1 a single 1 input has

been seen since the output was decided to be zero), and a
zero arrives

Question: let's say we are at SEE1 and input is 1. How should I know
the system expects 0? why not 1?

Regards,
amit
The thing I'm trying to say is that regarding what Anson says the
first input 1 has an output as 1 and .... so the system in this phase
believes "1" is the right output and we haven't got to "000" yet to
switch to "0" output.
Apr 30 '07 #14
On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.comwrote:

On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.netwrote:
Amit wrote:
On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.netwrote:
Anson.Stugg...@gmail.com wrote:
>I'm designing a debounce filter using Finite State Machine. The FSM
>behavior is it follows the inital input bit and thinks that's real
>output until it receives 3 consecutive same bits and it changes output
>to that 3 consecutive bit until next 3 consecutive bits are received.
>A reset will set the FSM to output 1s until it receives the correct
>input and ouput.
>This is the test sequence with input and correct output.
>1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
>1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
>The state diagram I came up has 6 states and it's named SEE1, SEE11,
>SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
>the input. Because it just came from SEE1 and before SEE1, it came
>from SEE000, so at SEE1 it can not change ouput to 1 which is what I
>have specified that state's ouput to be.
>Anyone knows how to solve this problem? Or maybe there's other better
>ways to design the state diagram?
I'm not sure I understand your terminology, but I am
assuming that that state neames mean:
SEE1 = output = 0 after 1 has been input 1 times in a row.
SEE11 = output = 0 after 1 has been input 2 times in a row.
SEE111 = output = 1 after 1 has been input 3 times in a row
(or a 1 is input after 0 has been input less than 3
times in a row).
SEE0 = output = 1 after 0 has been input 1 times in a row.
SEE00 = output = 1 after 0 has been input 2 times in a row.
SEE000 = output = 0 after 0 has been input 3 times in a row
(or a 0 is input after 1 has been input less than 3
times in a row).
If this is the case, then the 12 transitions are:
before input after
SEE1 1 SEE11
SEE1 0 SEE000
SEE11 1 SEE111
SEE11 0 SEE000
SEE111 1 SEE111
SEE111 0 SEE0
SEE0 1 SEE111
SEE0 0 SEE00
SEE00 1 SEE111
SEE00 0 SEE000
SEE000 1 SEE1
SEE000 0 SEE000
Hi John,
It is not that I'm saying the table is wrong (since I'm new to this
and trying to learn) but how do you say: SEE1 with input 0 goes to
SEE11 state? because then our state must be SEE01!
The 6 states are defined above the transition table. There
is no SEE01 state, because there is no reason to keep track
of that sequence. If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives, you just go back to state SEE000 (the one
where the output was decided to be changed to zero) since
the required 3 1s in a row cannot occur till at least a
single 1 arrives. Any zero arriving before that triple 1 is
received just starts the count over.
have a problem with this:
>If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives
Question: let's say we are at SEE1 and input is 1. How should I know
the system expects 0? why not 1?
Regards,
amit

The thing I'm trying to say is that regarding what Anson says the
first input 1 has an output as 1 and .... so the system in this phase
believes "1" is the right output and we haven't got to "000" yet to
switch to "0" output.- Hide quoted text -

- Show quoted text -
Amit,

I admit it is a little messy to understand. Basically, to come up with
state diagram, usually try to focus on the objective. In this case, it
is to detect 3 consecutive 1s or 0s and result a change on the output.
Therefore, case SAW01 or SAW10 will be not important enough to be
named a state.

Before the logic detects 3 of consecutive 1s or 0s, it will just keep
output bits with the inital bit received at power on or 1s in the case
if there has been a reset. There are only two logic states which
logically change the output: SEE000 and SEE111. All other states don't
really changes the outputs. These are only internal states.

I must mention that the state diagram doesn't address the issue when
the logic is first turned on and is it 1 or 0 at the input port. You
can verify this with the the state diagram John Popelish provided
earlier. The first bit is a 1 and if you follow the state diagram, you
will get 0s all the way until 9th bit and it's still a 0 so it will
continue until the last bit received. Infact, you will have to provide
additional logic for the first 8 bits.

Correct me if I'm wrong, but this is what I think.

Anson

Apr 30 '07 #15
Amit wrote:
Question: let's say we are at SEE1 and input is 1. How should I know
the system expects 0? why not 1?
The system does not expect anything. It reacts to the input
sequence as it arrives (at clocked intervals). The purpose
of the algorithm is to remove any state changes that remain
less than 3 clocks in a row (bounces).
Apr 30 '07 #16
Amit wrote:
The thing I'm trying to say is that regarding what Anson says the
first input 1 has an output as 1 and .... so the system in this phase
believes "1" is the right output and we haven't got to "000" yet to
switch to "0" output.
I ignored that part. The initial power up state is
arbitrary. Choose it as you wish, and initialize the state
to SEE000 if you choose 0 or SEE111 if you choose 1.
Apr 30 '07 #17
On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote:
On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.netwrote:
Amit wrote:
On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.netwrote:
>Anson.Stugg...@gmail.com wrote:
>>I'm designing a debounce filter using Finite State Machine. The FSM
>>behavior is it follows the inital input bit and thinks that's real
>>output until it receives 3 consecutive same bits and it changes output
>>to that 3 consecutive bit until next 3 consecutive bits are received.
>>A reset will set the FSM to output 1s until it receives the correct
>>input and ouput.
>>This is the test sequence with input and correct output.
>>1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
>>1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
>>The state diagram I came up has 6 states and it's named SEE1, SEE11,
>>SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
>>the input. Because it just came from SEE1 and before SEE1, it came
>>from SEE000, so at SEE1 it can not change ouput to 1 which is what I
>>have specified that state's ouput to be.
>>Anyone knows how to solve this problem? Or maybe there's other better
>>ways to design the state diagram?
>I'm not sure I understand your terminology, but I am
>assuming that that state neames mean:
>SEE1 = output = 0 after 1 has been input 1 times in a row.
>SEE11 = output = 0 after 1 has been input 2 times in a row.
>SEE111 = output = 1 after 1 has been input 3 times in a row
> (or a 1 is input after 0 has been input less than 3
> times in a row).
>SEE0 = output = 1 after 0 has been input 1 times in a row.
>SEE00 = output = 1 after 0 has been input 2 times in a row.
>SEE000 = output = 0 after 0 has been input 3 times in a row
> (or a 0 is input after 1 has been input less than 3
> times in a row).
>If this is the case, then the 12 transitions are:
>before input after
>SEE1 1 SEE11
>SEE1 0 SEE000
>SEE11 1 SEE111
>SEE11 0 SEE000
>SEE111 1 SEE111
>SEE111 0 SEE0
>SEE0 1 SEE111
>SEE0 0 SEE00
>SEE00 1 SEE111
>SEE00 0 SEE000
>SEE000 1 SEE1
>SEE000 0 SEE000
Hi John,
It is not that I'm saying the table is wrong (since I'm new to this
and trying to learn) but how do you say: SEE1 with input 0 goes to
SEE11 state? because then our state must be SEE01!
The 6 states are defined above the transition table. There
is no SEE01 state, because there is no reason to keep track
of that sequence. If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives, you just go back to state SEE000 (the one
where the output was decided to be changed to zero) since
the required 3 1s in a row cannot occur till at least a
single 1 arrives. Any zero arriving before that triple 1 is
received just starts the count over.
have a problem with this:
If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives
Question: let's say we are at SEE1 and input is 1. How should I know
the system expects 0? why not 1?
Regards,
amit
The thing I'm trying to say is that regarding what Anson says the
first input 1 has an output as 1 and .... so the system in this phase
believes "1" is the right output and we haven't got to "000" yet to
switch to "0" output.- Hide quoted text -
- Show quoted text -

Amit,

I admit it is a little messy to understand. Basically, to come up with
state diagram, usually try to focus on the objective. In this case, it
is to detect 3 consecutive 1s or 0s and result a change on the output.
Therefore, case SAW01 or SAW10 will be not important enough to be
named a state.

Before the logic detects 3 of consecutive 1s or 0s, it will just keep
output bits with the inital bit received at power on or 1s in the case
if there has been a reset. There are only two logic states which
logically change the output: SEE000 and SEE111. All other states don't
really changes the outputs. These are only internal states.

I must mention that the state diagram doesn't address the issue when
the logic is first turned on and is it 1 or 0 at the input port. You
can verify this with the the state diagram John Popelish provided
earlier. The first bit is a 1 and if you follow the state diagram, you
will get 0s all the way until 9th bit and it's still a 0 so it will
continue until the last bit received. Infact, you will have to provide
additional logic for the first 8 bits.

Correct me if I'm wrong, but this is what I think.

Anson

Anson, thanks for the explanation. Regarding SEE01 and SEE10 states,
that is right we won't need them and I read what John had said before
again and he is right.

But let's get back to the first input in the string which is "1" .
There, we can get to this conclusion that the previous value that
system was expecting to have as output has been "0" so the first input
(1) must be the third "1" of triple 1 string. Maybe following lines
explain it better:
hidden We
see
input: 11
10010100010111
output: 00
11111111000001

Right?
next question I have is regarding your very first question. What
happens to the state that once outputs "1" and in another situation it
outputs "0"?

how do you present this in your state diagram? If I'm not wrong this
is what you has asked in the first place.

Regards,
amit

Apr 30 '07 #18
On Apr 29, 7:47 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote:
On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.netwrote:
Amit wrote:
On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.netwrote:
Anson.Stugg...@gmail.com wrote:
>I'm designing a debounce filter using Finite State Machine. The FSM
>behavior is it follows the inital input bit and thinks that's real
>output until it receives 3 consecutive same bits and it changes output
>to that 3 consecutive bit until next 3 consecutive bits are received.
>A reset will set the FSM to output 1s until it receives the correct
>input and ouput.
>This is the test sequence with input and correct output.
>1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
>1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
>The state diagram I came up has 6 states and it's named SEE1, SEE11,
>SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
>the input. Because it just came from SEE1 and before SEE1, it came
>from SEE000, so at SEE1 it can not change ouput to 1 which is what I
>have specified that state's ouput to be.
>Anyone knows how to solve this problem? Or maybe there's other better
>ways to design the state diagram?
I'm not sure I understand your terminology, but I am
assuming that that state neames mean:
SEE1 = output = 0 after 1 has been input 1 times in a row.
SEE11 = output = 0 after 1 has been input 2 times in a row.
SEE111 = output = 1 after 1 has been input 3 times in a row
(or a 1 is input after 0 has been input less than 3
times in a row).
SEE0 = output = 1 after 0 has been input 1 times in a row.
SEE00 = output = 1 after 0 has been input 2 times in a row.
SEE000 = output = 0 after 0 has been input 3 times in a row
(or a 0 is input after 1 has been input less than 3
times in a row).
If this is the case, then the 12 transitions are:
before input after
SEE1 1 SEE11
SEE1 0 SEE000
SEE11 1 SEE111
SEE11 0 SEE000
SEE111 1 SEE111
SEE111 0 SEE0
SEE0 1 SEE111
SEE0 0 SEE00
SEE00 1 SEE111
SEE00 0 SEE000
SEE000 1 SEE1
SEE000 0 SEE000
Hi John,
It is not that I'm saying the table is wrong (since I'm new to this
and trying to learn) but how do you say: SEE1 with input 0 goes to
SEE11 state? because then our state must be SEE01!
The 6 states are defined above the transition table. There
is no SEE01 state, because there is no reason to keep track
of that sequence. If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives, you just go back to state SEE000 (the one
where the output was decided to be changed to zero) since
the required 3 1s in a row cannot occur till at least a
single 1 arrives. Any zero arriving before that triple 1 is
received just starts the count over.
have a problem with this:
>If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives
Question: let's say we are at SEE1 and input is 1. How should I know
the system expects 0? why not 1?
Regards,
amit
The thing I'm trying to say is that regarding what Anson says the
first input 1 has an output as 1 and .... so the system in this phase
believes "1" is the right output and we haven't got to "000" yet to
switch to "0" output.- Hide quoted text -
- Show quoted text -
Amit,
I admit it is a little messy to understand. Basically, to come up with
state diagram, usually try to focus on the objective. In this case, it
is to detect 3 consecutive 1s or 0s and result a change on the output.
Therefore, case SAW01 or SAW10 will be not important enough to be
named a state.
Before the logic detects 3 of consecutive 1s or 0s, it will just keep
output bits with the inital bit received at power on or 1s in the case
if there has been a reset. There are only two logic states which
logically change the output: SEE000 and SEE111. All other states don't
really changes the outputs. These are only internal states.
I must mention that the state diagram doesn't address the issue when
the logic is first turned on and is it 1 or 0 at the input port. You
can verify this with the the state diagram John Popelish provided
earlier. The first bit is a 1 and if you follow the state diagram, you
will get 0s all the way until 9th bit and it's still a 0 so it will
continue until the last bit received. Infact, you will have to provide
additional logic for the first 8 bits.
Correct me if I'm wrong, but this is what I think.
Anson

Anson, thanks for the explanation. Regarding SEE01 and SEE10 states,
that is right we won't need them and I read what John had said before
again and he is right.

But let's get back to the first input in the string which is "1" .
There, we can get to this conclusion that the previous value that
system was expecting to have as output has been "0" so the first input
(1) must be the third "1" of triple 1 string. Maybe following lines
explain it better:

hidden We
see
input: 11
10010100010111
output: 00
11111111000001

Right?

next question I have is regarding your very first question. What
happens to the state that once outputs "1" and in another situation it
outputs "0"?

how do you present this in your state diagram? If I'm not wrong this
is what you has asked in the first place.

Regards,
amit
it seems what I have typed above is messy and mixed. This is what I
was trying to show:

hidden We only see

11 10010100010111 <- input
00 11111111000001 <- output

regards,
amit

Apr 30 '07 #19
On Apr 29, 7:52 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 7:47 pm, Amit <amit.ko...@gmail.comwrote:

On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote:
On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.comwrote:
On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.netwrote:
Amit wrote:
On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.netwrote:
>Anson.Stugg...@gmail.com wrote:
>>I'm designing adebouncefilter using FiniteStateMachine. The FSM
>>behavior is it follows the inital input bit and thinks that's real
>>output until it receives 3 consecutive same bits and it changes output
>>to that 3 consecutive bit until next 3 consecutive bits are received.
>>A reset will set the FSM to output 1s until it receives the correct
>>input and ouput.
>>This is the test sequence with input and correct output.
>>1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
>>1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
>>ThestatediagramI came up has 6 states and it's named SEE1, SEE11,
>>SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
>>the input. Because it just came from SEE1 and before SEE1, it came
>>from SEE000, so at SEE1 it can not change ouput to 1 which is what I
>>have specified thatstate'souput to be.
>>Anyone knows how to solve this problem? Or maybe there's other better
>>ways to design thestatediagram?
>I'm not sure I understand your terminology, but I am
>assuming that thatstateneames mean:
>SEE1 = output = 0 after 1 has been input 1 times in a row.
>SEE11 = output = 0 after 1 has been input 2 times in a row.
>SEE111 = output = 1 after 1 has been input 3 times in a row
> (or a 1 is input after 0 has been input less than 3
> times in a row).
>SEE0 = output = 1 after 0 has been input 1 times in a row.
>SEE00 = output = 1 after 0 has been input 2 times in a row.
>SEE000 = output = 0 after 0 has been input 3 times in a row
> (or a 0 is input after 1 has been input less than 3
> times in a row).
>If this is the case, then the 12 transitions are:
>before input after
>SEE1 1 SEE11
>SEE1 0 SEE000
>SEE11 1 SEE111
>SEE11 0 SEE000
>SEE111 1 SEE111
>SEE111 0 SEE0
>SEE0 1 SEE111
>SEE0 0 SEE00
>SEE00 1 SEE111
>SEE00 0 SEE000
>SEE000 1 SEE1
>SEE000 0 SEE000
Hi John,
It is not that I'm saying the table is wrong (since I'm new to this
and trying to learn) but how do you say: SEE1 with input 0 goes to
SEE11state? because then ourstatemust be SEE01!
The 6 states are defined above the transition table. There
is no SEE01state, because there is no reason to keep track
of that sequence. If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives, you just go back tostateSEE000 (the one
where the output was decided to be changed to zero) since
the required 3 1s in a row cannot occur till at least a
single 1 arrives. Any zero arriving before that triple 1 is
received just starts the count over.
have a problem with this:
If you are at SEE1 a single 1 input has
been seen since the output was decided to be zero), and a
zero arrives
Question: let's say we are at SEE1 and input is 1. How should I know
the system expects 0? why not 1?
Regards,
amit
The thing I'm trying to say is that regarding what Anson says the
first input 1 has an output as 1 and .... so the system in this phase
believes "1" is the right output and we haven't got to "000" yet to
switch to "0" output.- Hide quoted text -
- Show quoted text -
Amit,
I admit it is a little messy to understand. Basically, to come up with
>statediagram, usually try to focus on the objective. In this case, it
is to detect 3 consecutive 1s or 0s and result a change on the output.
Therefore, case SAW01 or SAW10 will be not important enough to be
named astate.
Before the logic detects 3 of consecutive 1s or 0s, it will just keep
output bits with the inital bit received at power on or 1s in the case
if there has been a reset. There are only two logic states which
logically change the output: SEE000 and SEE111. All other states don't
really changes the outputs. These are only internal states.
I must mention that thestatediagramdoesn't address the issue when
the logic is first turned on and is it 1 or 0 at the input port. You
can verify this with the thestatediagramJohn Popelish provided
earlier. The first bit is a 1 and if you follow thestatediagram, you
will get 0s all the way until 9th bit and it's still a 0 so it will
continue until the last bit received. Infact, you will have to provide
additional logic for the first 8 bits.
Correct me if I'm wrong, but this is what I think.
Anson
Anson, thanks for the explanation. Regarding SEE01 and SEE10 states,
that is right we won't need them and I read what John had said before
again and he is right.
But let's get back to the first input in the string which is "1" .
There, we can get to this conclusion that the previous value that
system was expecting to have as output has been "0" so the first input
(1) must be the third "1" of triple 1 string. Maybe following lines
explain it better:
hidden We
see
input: 11
10010100010111
output: 00
11111111000001
Right?
next question I have is regarding your very first question. What
happens to thestatethat once outputs "1" and in another situation it
outputs "0"?
how do you present this in yourstatediagram? If I'm not wrong this
is what you has asked in the first place.
Regards,
amit

it seems what I have typed above is messy and mixed. This is what I
was trying to show:

hidden We only see

11 10010100010111 <- input
00 11111111000001 <- output

regards,
amit- Hide quoted text -

- Show quoted text -
Do you mean a 1 in the input string at power-up or after reset? If so,
state Init_1&SEE111 is where it should go.

Apr 30 '07 #20
Thanks Peter for the suggestion. But my problem is coming up with the
state diagram for this FSM. How can I implement what you suggested on
a state diagram? Thanks.
Here you go, I hope the ASCII art looks OK (if not, change to
monospaced font):

shift reg. = 111
+----+ --------------------+----+
| S0 | | S1 |
+----+ <-------------------- +----+
shift reg. = 000

Apr 30 '07 #21

<An************@gmail.comschreef in bericht
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?

Thanks,

Anson
Came into this this discussion late. Read the available texts but sure
missed some due to the "experimental" status of my ISPs newsserver. Also did
not analyse the tables to make sure I make my own mistakes:) So I came to
the next table:

Input Curent Next
state state
0 000 000
1 000 001
0 100 000
1 100 001
0 001 000
1 001 011
0 011 000
1 011 110
0 110 111
1 110 110
0 010 111
1 010 110
0 111 101
1 111 110
0 011 000
1 101 110
0 101 000

All possible (eight) states have been accounted for. As you need only six
states, you can combine state 000 with state 100 and state 110 with state
010. The leftmost bit of the state code is your output signal. See state
diagram below.

+--+
0| |
| v
.------.
| 000 |----------+
+--------->| 100 | |
| | |<------+ |
|0 '------' | |1
| ^ 0| |
| | | v
.------. |0 .------.
| | | | |
| 101 | | | 001 |
| |---------+ | | |
'------' | | '------'
^ | | |
| | | |1
|0 | | |
| | | v
.------. | | .------.
| | | +-------| |
| 111 | | | 011 |
| | | | |
'------' 1| '------'
^ | | |
| | v |
0| |1 .------. |1
| +-------->| | |
| | 110 |<------+
+------------| 010 |
'------'
| ^
1| |
+--+
created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de

petrus bitbyter
Apr 30 '07 #22
On Apr 29, 3:12 pm, John Popelish <jpopel...@rica.netwrote:
It was a bit larger than I remembered, but if anyone is interested,
here is the code I used to debounce and edge detect an 8 bit PIC
port. This process was called once a millisecond.

; read port C, debounce and fire single shots
; shift input data down
movf cinfil,w ; fetch cinfil
movwf cinfil1 ; copy to cinfil1
bsf STATUS,RP0 ; select regiater page 1
movf cin1,w ; fetch 1ms old values
movwf cin2 ; overwrite 2ms old data
movf cin,w ; fetch stale value of cin
movwf cin1 ; store as 1ms old data
bcf STATUS,RP0 ; select regiater page 0
; read new port C values
movf PORTC,w ; read port C
bsf STATUS,RP0 ; select register page 1
movwf cin ; store port C data in cin
; (0=start, 1=up, 2= down, 3=home, 4=temp high not, 5=temp low not,
6=lid closed, 7=spare)
; debounce requires 3 similar states in a row to supercede filtered
value
; and cin, cin1 and cin2 to detect 3 1s in a row
andwf cin1,w ; and 1 ms old data with new version
andwf cin2,w ; and 2 ms old data with this
movwf cinand ; save this combination for later
; or cin, cin1 and cin2 to detect three 0s in a row
movf cin,w ; get latest values
iorwf cin1,w ; or latest and 1ms old data
iorwf cin2,w ; or 2 ms old data with this
andwf cinfil1,w ; and debounced state of port C inputs with this
; to clear any 1s that have been followed by 3 0s in a row.
iorwf cinand,w ; or cinand, to set any zeros that have been followed
; by 3 1s in a row.
movwf cinfil1 ; update filtered (debounced version of port C inputs)
bcf STATUS,RP0 ; select register page 0
movwf cinfil ; update filtered (debounced version of port C inputs)
bsf STATUS,RP0 ; select register page 1
; fire turn on and turn off single shots
; if present is off and last was on, set "off ss" bit
comf cinfil1,w ; compliment cinfil bits
andwf cinfld,w ; and with delayed bits
bcf STATUS,RP0 ; select register page zero
movwf cinofss ; store as turn off single shot bits
bsf STATUS,RP0 ; select register page 1
; if last was off, and present is on, set "on ss" bit
comf cinfld,w ; compliment delayed inputs
andwf cinfil1,w ; and current value of inputs
bcf STATUS,RP0 ; select register page 0
movwf cinonss ; store as turn on single shot bits

Apr 30 '07 #23
petrus bitbyter wrote:
(snip)
All possible (eight) states have been accounted for. As you need only six
states, you can combine state 000 with state 100 and state 110 with state
010. The leftmost bit of the state code is your output signal. See state
diagram below.

+--+
0| |
| v
.------.
| 000 |----------+
+--------->| 100 | |
| | |<------+ |
|0 '------' | |1
| ^ 0| |
| | | v
.------. |0 .------.
| | | | |
| 101 | | | 001 |
| |---------+ | | |
'------' | | '------'
^ | | |
| | | |1
|0 | | |
| | | v
.------. | | .------.
| | | +-------| |
| 111 | | | 011 |
| | | | |
'------' 1| '------'
^ | | |
| | v |
0| |1 .------. |1
| +-------->| | |
| | 110 |<------+
+------------| 010 |
'------'
| ^
1| |
+--+
created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de

petrus bitbyter
This is exactly the state diagram I drew before answering
the post. Nice work.

Apr 30 '07 #24
petrus bitbyter wrote:
>
.... snip ...
+--+
0| |
| v
.------.
| 000 |----------+
+--------->| 100 | |
| | |<------+ |
|0 '------' | |1
| ^ 0| |
| | | v
.------. |0 .------.
| | | | |
| 101 | | | 001 |
| |---------+ | | |
'------' | | '------'
^ | | |
| | | |1
|0 | | |
| | | v
.------. | | .------.
| | | +-------| |
| 111 | | | 011 |
| | | | |
'------' 1| '------'
^ | | |
| | v |
0| |1 .------. |1
| +-------->| | |
| | 110 |<------+
+------------| 010 |
'------'
| ^
1| |
+--+
Obviously wrong.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

May 1 '07 #25
On 29 Apr, 19:32, Anson.Stugg...@gmail.com wrote:
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?

Thanks,

Anson
This debounce idea is terrible. Straight away you have aliasing
problems not to mention arbitrary latency.

The simple thing to do is detect an edge by e.g. edge driven interrupt
and then fire the output state immediately according to the edge
direction and start your one-shot debounce-duration timer that
inhibits the interrupt until it times outs.

Now you have instant "analogue" style response and you can reduce the
duration until bouncing happens and then back it off by a safety
margin.

Cheers
Robin

May 1 '07 #26

"Robin" <ro********@tesco.netschreef in bericht
On 29 Apr, 19:32, Anson.Stugg...@gmail.com wrote:
>I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?

Thanks,

Anson

This debounce idea is terrible. Straight away you have aliasing
problems not to mention arbitrary latency.

The simple thing to do is detect an edge by e.g. edge driven interrupt
and then fire the output state immediately according to the edge
direction and start your one-shot debounce-duration timer that
inhibits the interrupt until it times outs.

Now you have instant "analogue" style response and you can reduce the
duration until bouncing happens and then back it off by a safety
margin.

Cheers
Robin
As so often, it depends. Ever met some "designers" having terrible problems
with the start button of their coffee machine. It made the coffee well
enough but started too often spontanuously. They connected the button to the
only interrupt line of their micro. The interrupt routine started the proces
on the first edge detected. Being mainly (C)programmers, it took some time
to convince them that false starts may occur due to interferences made by
the environment, even if you do not notice them yourself. But they did
understand that humans would not complain when the coffee maker started some
milliseconds later so they build in some delay and checked again. (IMHO a
typical example of too strict a separation of hard- and softwaredesign.)

petrus bitbyter

May 1 '07 #27
So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
May 2 '07 #28
On Wed, 2 May 2007 01:25:29 +0200, "petrus bitbyter"
<pi*******************@enditookhccnet.nlwrote:
>
"Robin" <ro********@tesco.netschreef in bericht
>On 29 Apr, 19:32, Anson.Stugg...@gmail.com wrote:
>>I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until it receives 3 consecutive same bits and it changes output
to that 3 consecutive bit until next 3 consecutive bits are received.
A reset will set the FSM to output 1s until it receives the correct
input and ouput.

This is the test sequence with input and correct output.

1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)

The state diagram I came up has 6 states and it's named SEE1, SEE11,
SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
the input. Because it just came from SEE1 and before SEE1, it came
from SEE000, so at SEE1 it can not change ouput to 1 which is what I
have specified that state's ouput to be.

Anyone knows how to solve this problem? Or maybe there's other better
ways to design the state diagram?

Thanks,

Anson

This debounce idea is terrible. Straight away you have aliasing
problems not to mention arbitrary latency.

The simple thing to do is detect an edge by e.g. edge driven interrupt
and then fire the output state immediately according to the edge
direction and start your one-shot debounce-duration timer that
inhibits the interrupt until it times outs.

Now you have instant "analogue" style response and you can reduce the
duration until bouncing happens and then back it off by a safety
margin.

Cheers
Robin

As so often, it depends. Ever met some "designers" having terrible problems
with the start button of their coffee machine. It made the coffee well
enough but started too often spontanuously. They connected the button to the
only interrupt line of their micro. The interrupt routine started the proces
on the first edge detected. Being mainly (C)programmers, it took some time
to convince them that false starts may occur due to interferences made by
the environment, even if you do not notice them yourself. But they did
understand that humans would not complain when the coffee maker started some
milliseconds later so they build in some delay and checked again. (IMHO a
typical example of too strict a separation of hard- and softwaredesign.)

petrus bitbyter
Interrupts are evil. They should have used a state machine that ran,
say, 5 times a second and checked the switch state.

John

May 2 '07 #29
On Tue, 01 May 2007 17:29:11 -0700, Keith Thompson <ks***@mib.org>
wrote:
>So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?
Programming embedded systems, things that interface to the real world,
are off-topic to c programmers? Why am I not surprised?

John

May 2 '07 #30
Keith Thompson wrote:
>
So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?
Set follow-ups.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

May 2 '07 #31
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>>
So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?

Set follow-ups.
I did, but it didn't do any good. I could only set followups in my
own followup; other direct replies to the original message retained
the full cross-posting.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
May 2 '07 #32
John Larkin <jj******@highNOTlandTHIStechnologyPART.comwrite s:
On Tue, 01 May 2007 17:29:11 -0700, Keith Thompson <ks***@mib.org>
wrote:
>>So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?

Programming embedded systems, things that interface to the real world,
are off-topic to c programmers? Why am I not surprised?
Questions which have nothing to do with programming in C are off-topic
in comp.lang.c. (If the original poster had asked for a C solution,
it might have been different, but I don't think I've seen a single
line of C source code in this thread.)

I'm getting the impression that once someone posts an inappropriately
cross-posted discussion, there's just no way to keep it from
continuing on all the newsgroups to which it was originally posted,
because most people posting followups just don't pay attention to the

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
May 2 '07 #33
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
>>Keith Thompson wrote:
>>>So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?

Set follow-ups.

I did, but it didn't do any good. I could only set followups in my
own followup; other direct replies to the original message retained
the full cross-posting.
Err - not on this one, it seems ?

-jg

May 2 '07 #34
[f-ups to clc]

Keith Thompson <k...@mib.orgwrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.comwrite s:
Keith Thompson <k...@mib.orgwrote:
So repeated requests to redirect this discussion away
from comp.lang.c, where it's completely off-topic, have
not worked. Does anybody have any suggestions for what
*would* work?
Other than what you've done, no. Although you could probably
try to _make_ it topical. That way, an otherwise noisy thread
may at least have some merit.
Programming embedded systems, things that interface to the
real world, are off-topic to c programmers? Why am I not
surprised?

Questions which have nothing to do with programming in C are
for a C solution, it might have been different, but I don't
think I've seen a single line of C source code in this thread.)
Well, let's post some... [both single bit in - single bit out]

/* crude state machine */
int debounce(int in)
{
static enum { sxx, s00, s01, s11, s10 } state = sxx;
static struct { unsigned char out; unsigned char next; }
fsm[][2] =
{ /* 0 */ /* 1 */
/* sxx */ { { 0, s00 }, { 1, s11 } },
/* s00 */ { { 0, s00 }, { 0, s01 } },
/* s01 */ { { 0, s00 }, { 0, sxx } },
/* s11 */ { { 1, s10 }, { 1, s11 } },
/* s10 */ { { 1, sxx }, { 1, s11 } }
};
int out = fsm[state][in].out;
state = fsm[state][in].next;
return out;
}

/* shift register */
int debounce(int in)
{
static unsigned char reg = 3;
static unsigned char out = 0;
reg = ((reg << 1) | in) & 7;
if (reg == 0 || reg == 7) out = reg & 1;
return out;
}

--
Peter

May 2 '07 #35
Jim Granville <no*****@designtools.maps.co.nzwrites:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>>Keith Thompson wrote:

So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?

Set follow-ups.
I did, but it didn't do any good. I could only set followups in my
own followup; other direct replies to the original message retained
the full cross-posting.

Err - not on this one, it seems ?
No, not on this one. In my initial message, I redirected followups in
an attempt to divert the discussion away from comp.lang.c. In my
later message, I was trying to find out why that didn't work and what
might work instead, so I didn't bother redirecting followups.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
May 2 '07 #36
On 2007-05-01, CBFalconer <cb********@yahoo.comwrote:
petrus bitbyter wrote:
>>
... snip ...
> +--+
0| |
| v
.------.
| 000 |----------+
+--------->| 100 | |
| | |<------+ |
|0 '------' | |1
| ^ 0| |
| | | v
.------. |0 .------.
| | | | |
| 101 | | | 001 |
| |---------+ | | |
'------' | | '------'
^ | | |
| | | |1
|0 | | |
| | | v
.------. | | .------.
| | | +-------| |
| 111 | | | 011 |
| | | | |
'------' 1| '------'
^ | | |
| | v |
0| |1 .------. |1
| +-------->| | |
| | 110 |<------+
+------------| 010 |
'------'
| ^
1| |
+--+

Obviously wrong.
what's wrong with it?

the labels on the states seem odd, but if you do this:

initial state 010

state output.
000,001,011,100 0
110,010,111,101 1

it behaves as requested,

Bye.
Jasen

May 2 '07 #37
On 2 May, 03:25, Keith Thompson <k...@mib.orgwrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.comwrite s:
On Tue, 01 May 2007 17:29:11 -0700, Keith Thompson <k...@mib.org>
wrote:
>So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?
Programming embedded systems, things that interface to the real world,
are off-topic to c programmers? Why am I not surprised?

Questions which have nothing to do with programming in C are off-topic
in comp.lang.c. (If the original poster had asked for a C solution,
it might have been different, but I don't think I've seen a single
line of C source code in this thread.)

I'm getting the impression that once someone posts an inappropriately
cross-posted discussion, there's just no way to keep it from
continuing on all the newsgroups to which it was originally posted,
because most people posting followups just don't pay attention to the

--
Keith Thompson (The_Other_Keith) k...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
It's worse than that, this is really a DSP question.

The sampled input above will *require* an anti-alias filter - making
itself redundant.

Robin

May 2 '07 #38
Keith Thompson wrote, On 02/05/07 04:45:
Jim Granville <no*****@designtools.maps.co.nzwrites:
>Keith Thompson wrote:
>>CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?
Set follow-ups.
I did, but it didn't do any good. I could only set followups in my
own followup; other direct replies to the original message retained
the full cross-posting.
Err - not on this one, it seems ?

No, not on this one. In my initial message, I redirected followups in
an attempt to divert the discussion away from comp.lang.c. In my
later message, I was trying to find out why that didn't work and what
might work instead, so I didn't bother redirecting followups.
I also tried redirecting, and explicitly requested that people on other
parts of the thread exclude comp.lang.c, I was even polite about it. I
believe the reason it does not work is that a lot of people only care
about there own group, not other groups to which something might be
inappropriately cross-posted, so even after reading the requests they
continue posting to other parts of the thread without restricting
follow-ups.

I'm beginning to think the solution is to post a couple of requests, and
after 24 hours plonk everyone who ignores the requests.

Note I've not set followups this time because discussions about
topicality *are* topical.
--
Flash Gordon
May 2 '07 #39
John Larkin wrote, On 02/05/07 01:51:
On Tue, 01 May 2007 17:29:11 -0700, Keith Thompson <ks***@mib.org>
wrote:
>So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?

Programming embedded systems, things that interface to the real world,
are off-topic to c programmers? Why am I not surprised?
I gave the best C answer, which was that it is better solved in HW. I
also stated that I have done debounce in SW, but I did not get any
response asking how, so obviously everyone agreed that implementing it
in HW was better.

after all semi-conductors only work because of the laws of physics in
the real world, so you must be interested in whether string theory is
correct or what modifications are required to it for it to be correct
and want those discussions in your groups.
--
Flash Gordon
May 2 '07 #40
Flash Gordon wrote:
>
I also tried redirecting, and explicitly requested that people on other
parts of the thread exclude comp.lang.c, I was even polite about it. I
believe the reason it does not work is that a lot of people only care
about there own group, not other groups to which something might be
inappropriately cross-posted, so even after reading the requests they
continue posting to other parts of the thread without restricting
follow-ups.

I'm beginning to think the solution is to post a couple of requests, and
after 24 hours plonk everyone who ignores the requests.

Note I've not set followups this time because discussions about
topicality *are* topical.

Sci.electronics.basics and sci.electronics.design are under assault.
Both groups also get a lot of newbies who don't know how to delete cross
posts to other groups. The usual message count for the ten months
Earthlink spools these newsgroups is usually around 65 to 70 thousand
messages for SED. At the moment it is showing 131,828 messages. 21
thousand of those happened within the past week. Some idiot didn't like
being told he was wrong so he brought his buddies from alt.usenet kooks
in to try to destroy sci.electronics.design. We have been flooded by bot
generated garbage and weirdoes hijacking threads. I use the ignore
thread command in my news reader, and they are never seen again. if you
attract their attention, they may do the same to comp.lang.c when they
get tired on the electronics groups. They have a long history of showing
their "Intelligence". Well, at least they brag about how smart they
are. :(
--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
May 2 '07 #41
On 2007-05-01, Robin <ro********@tesco.netwrote:
On 29 Apr, 19:32, Anson.Stugg...@gmail.com wrote:
This debounce idea is terrible. Straight away you have aliasing
problems not to mention arbitrary latency.

The simple thing to do is detect an edge by e.g. edge driven interrupt
and then fire the output state immediately according to the edge
direction and start your one-shot debounce-duration timer that
inhibits the interrupt until it times outs.

Now you have instant "analogue" style response and you can reduce the
duration until bouncing happens and then back it off by a safety
margin.
depends if he merely wants to de-bounce or if he also wants to de-glitch

Bye.
Jasen
May 2 '07 #42
jasen wrote:
CBFalconer <cb********@yahoo.comwrote:
>petrus bitbyter wrote:
>>>
... snip ...
>>>
| | | v
.------. | | .------.
| | | +-------| |
| 111 | | | 011 |
| | | | |
'------' 1| '------'
^ | | |
| | v |
0| |1 .------. |1
| +-------->| | |
| | 110 |<------+
+------------| 010 |
'------'
| ^
1| |
+--+

Obviously wrong.

what's wrong with it?

the labels on the states seem odd, but if you do this:
I looked at the labels. The 111 state can only be reached by
inputting a 0, for example.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

May 2 '07 #43
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
>Keith Thompson wrote:
>>>
So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked.
Does anybody have any suggestions for what *would* work?

Set follow-ups.

I did, but it didn't do any good. I could only set followups in
my own followup; other direct replies to the original message
retained the full cross-posting.
Your follow-up setting didn't make it to here. Did mine make it to

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

May 2 '07 #44
On Wed, 02 May 2007 08:07:06 +0100, Flash Gordon
<sp**@flash-gordon.me.ukwrote:
>John Larkin wrote, On 02/05/07 01:51:
>On Tue, 01 May 2007 17:29:11 -0700, Keith Thompson <ks***@mib.org>
wrote:
>>So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?

Programming embedded systems, things that interface to the real world,
are off-topic to c programmers? Why am I not surprised?

I gave the best C answer, which was that it is better solved in HW.
But hardware costs money on a production basis, and code is free. So
"better solved in hardware" translates to "I'm only interested in
programming, so don't annoy me with applications."
I
also stated that I have done debounce in SW, but I did not get any
response asking how, so obviously everyone agreed that implementing it
in HW was better.
If it's a pure bounce problem, just check the switch state 10 times a
second and use what you see... no debounce needed.

John

May 2 '07 #45
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Keith Thompson wrote:

So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked.
Does anybody have any suggestions for what *would* work?

Set follow-ups.

I did, but it didn't do any good. I could only set followups in
my own followup; other direct replies to the original message
retained the full cross-posting.

Your follow-up setting didn't make it to here. Did mine make it to
No, my newsreader is fine. I redirected followups on my first
posting, in which I asked everyone to keep the discussion out of
comp.lang.c. I did not do so on my second posting, in which I was
trying to solicit ideas for *how* to get people to limit cross-posted
off-topic discussions to appropriate newsgroups.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
May 2 '07 #46
Keith,
A few minutes of breathing, adopting a forgiving attitude,
and forgoing the concerned posts about the cross-posting
would reduce the net traffic by 30% (accurate yesterday -
includes replies - probably increased today).

Of course it would be nice if people did not cross-post
potentially irrelevant topics (which this may or may not
the thread and the clutter is gone.

It seems to me that the only difference it makes is to
the people who are following the thread. I have to flip
through the posts without content (your complaints).

Regards,
Jim

May 2 '07 #47
John Larkin wrote, On 02/05/07 20:01:
On Wed, 02 May 2007 08:07:06 +0100, Flash Gordon
<sp**@flash-gordon.me.ukwrote:
>John Larkin wrote, On 02/05/07 01:51:
>>On Tue, 01 May 2007 17:29:11 -0700, Keith Thompson <ks***@mib.org>
wrote:

So repeated requests to redirect this discussion away from
comp.lang.c, where it's completely off-topic, have not worked. Does
anybody have any suggestions for what *would* work?
Programming embedded systems, things that interface to the real world,
are off-topic to c programmers? Why am I not surprised?
I gave the best C answer, which was that it is better solved in HW.

But hardware costs money on a production basis, and code is free. So
"better solved in hardware" translates to "I'm only interested in
programming, so don't annoy me with applications."
No, it translates to use the correct tool for the job. This is why
keyboard controllers do the debounce on keyboards rather than leaving it
to the OS.
>I
also stated that I have done debounce in SW, but I did not get any
response asking how, so obviously everyone agreed that implementing it
in HW was better.

If it's a pure bounce problem, just check the switch state 10 times a
second and use what you see... no debounce needed.
Having been this route more than once because it was a one-off and
already built, I can tell you that SW solutions do not work as well as
properly designed HW when the SW has other things to do, one reason
being that the HW can sample the data much faster.

Since the OP still has not commented on the possibility of a C solution
it still seems likely that is not what the OP actually wants.
--
Flash Gordon
May 2 '07 #48
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
.... snip ...
>>
Your follow-up setting didn't make it to here. Did mine make it to

No, my newsreader is fine. I redirected followups on my first
posting, in which I asked everyone to keep the discussion out of
comp.lang.c. I did not do so on my second posting, in which I was
trying to solicit ideas for *how* to get people to limit cross-posted
off-topic discussions to appropriate newsgroups.
set as received here. The path was:

Path:

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

May 2 '07 #49
Jim Lewis wrote:

Of course it would be nice if people did not cross-post
potentially irrelevant topics (which this may or may not
the thread and the clutter is gone.
While I'm not Keith, I'll say I can't agree with your position. The
best way to keep a newsgroup clear of clutter is to speak up when
off-topic stuff appears, not just ignore it.

That's a fairly typical reaction here in comp.lang.c. Those who don't
like it should refrain from posting off-topic messages here. The easy
way to avoid that in this thread is start removing clc from the
newsgroup list. By now, most people should have seen the complaints,
and really have very little excuse.

The original message was off-topic, and the vast majority of follow-ups
have been off-topic. There's very little question about that.

Brian
May 2 '07 #50

This thread has been closed and replies have been disabled. Please start a new discussion.