FPGARelated.com
Forums

debounce state diagram FSM

Started by Unknown April 29, 2007
On Apr 29, 7:47 pm, Amit <amit.ko...@gmail.com> wrote:
> On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote: > > > > > On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.com> wrote: > > > > On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.com> wrote: > > > > > On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.net> wrote: > > > > > > Amit wrote: > > > > > > On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.net> wrote: > > > > > >> 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. > > > > > Thank you so much for your answer but before I complete the reading I > > > > 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
On Apr 29, 7:47 pm, Amit <amit.ko...@gmail.com> wrote:
> On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote: > > > > > > > On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.com> wrote: > > > > On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.com> wrote: > > > > > On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.net> wrote: > > > > > > Amit wrote: > > > > > > On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.net> wrote: > > > > > >> 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. > > > > > Thank you so much for your answer but before I complete the reading I > > > > 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- Hide quoted text - > > - Show quoted text -
Amit, My first question came up because I draw the state diagram differently or wrong. From state SEE000 and if a 1 is input, it will go to state SEE1 and if another 0 comes in, it should go back to SEE000, not on to SEE0 (where I get the wrong output). Try to draw or map out the state diagram John has posted earlier. And try to trace it with the input you have and you will get the correct outputs at every single state or bit. However, I must highlight what John wrote earlier. During the initial input at power-on, the first bit should go to: if 1 go to state SEE111 and if 0 go to SEE000. As you can see, state SEE111 and SEE000 serve two function. One is when it sees 3 consecutive same bits it will change the output and other is during initial bit at power-on (maybe they should be renamed to Init_1&SEE111, Init_0&SEE000). Don't forget the reset which will set output to 1 regardless of what's on the line but this will be changed with sequences of bits streaming in later. Hope this helps, Anson
On Apr 29, 7:52 pm, Amit <amit.ko...@gmail.com> wrote:
> On Apr 29, 7:47 pm, Amit <amit.ko...@gmail.com> wrote: > > > > > > > On Apr 29, 7:17 pm, Anson.Stugg...@gmail.com wrote: > > > > On Apr 29, 6:00 pm, Amit <amit.ko...@gmail.com> wrote: > > > > > On Apr 29, 5:54 pm, Amit <amit.ko...@gmail.com> wrote: > > > > > > On Apr 29, 5:45 pm, John Popelish <jpopel...@rica.net> wrote: > > > > > > > Amit wrote: > > > > > > > On Apr 29, 12:01 pm, John Popelish <jpopel...@rica.net> wrote: > > > > > > >> 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. > > > > > > Thank you so much for your answer but before I complete the reading I > > > > > 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.
> 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
<Anson.Stuggart@gmail.com> schreef in bericht 
news:1177871564.475673.53180@y80g2000hsf.googlegroups.com...
> 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&#4294967295;s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de petrus bitbyter
On Apr 29, 3:12 pm, John Popelish <jpopel...@rica.net> wrote:
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

jpopelish@rica.net wrote:

> On Apr 29, 3:12 pm, John Popelish <jpopel...@rica.net> wrote: > 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.
None of this is topical in comp.lang.c. Please remove that group from your distribution. Thanks. Brian
billwang05@gmail.com wrote, On 30/04/07 04:42:

<snip>

> 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.
Would people PLEASE drop comp.lang.c from the groups, as this is OBVIOUSLY not topical in a C programming group. -- Flash Gordon
petrus bitbyter wrote:
(snip)
> All possible (eight) states have been accounted for. As you need only s=
ix=20
> states, you can combine state 000 with state 100 and state 110 with sta=
te=20
> 010. The leftmost bit of the state code is your output signal. See stat=
e=20
> diagram below. >=20 > +--+ > 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=B4s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de >=20 > petrus bitbyter
This is exactly the state diagram I drew before answering=20 the post. Nice work.
John Popelish wrote:

> This is exactly the state diagram I drew before answering > the post. Nice work.
This has nothing to do with comp.lang.c. Please remove that newsgroup from your distribution. Brian