Loading ...
Sorry, an error occurred while loading the content.
 

Re: asking for a good sugestion

Expand Messages
  • Vasile Surducan
    It s a nice feeling to know you are there ! Who told you last time I love you ! Eur, Josef, Javi, Wouter, Jake... I think wifes... or not ? ... The problem
    Message 1 of 20 , Feb 1, 2005
      It's a nice feeling to know you are there ! Who told you last
      time "I love you ! Eur, Josef, Javi, Wouter, Jake..."

      I think wifes... or not ?
      :)

      The problem is more complex like it looks. Yes Josef is a damn
      18B20, in fact is a bus with more those devices. I can't use tmr0
      for button read (not debouncing, Eur don't like it) because I have
      two precise events, one which happens at 100mS (required by
      hardware) and 1S (real time interrupt driven clock)and sometime the
      tmr0 must be stopped, it's not in free running mode (so I can't use
      a 10mS event and multiply it).
      Josef, I've noticed your favourite way, there is one of your
      answers in some piclist page, I read it yesterday.
      Eur, debouncing is must when some buttons are sharing many function.
      Else pressing "long" the "enter button" will have the effect of two
      different commands instead of just one. Also pressing short will
      have the effect of slow counter changing value and pressing long
      means fast counter changing value.
      Javi, you realise I'm not using software delays just because I
      can't, even I like more when is possible. I dislike also to split
      the temperature sensor routine with button routine, this will gave
      variable debouncing time.

      The biggest problem is the stack kill. I figured now even
      a "port_b_low_direction" is eating stack. Killing stack is avoided
      in this situation by tris manipulation. HD44780 library is eating
      also too many stacks (toooo many).

      I was thinking some problems will dissapear by increasing from 4 to
      20 MHz clock. In fact some dissapears but many other appears (like
      getting too small delays with tmr1).

      What can I say, thanks all,

      Vasile


      --- In jallist@yahoogroups.com, "Vasile Surducan" <vasile@s...>
      wrote:
      >
      >
      > Hi guys,
      >
      > loop, one is button debounce and the other is a lazy
      temperature
      > measurement. One complete temperature measurement take about
      700mS,
      > and button debounce must be at least ten time faster. The ISR is
      > taken for a precise time keeping (100mS frame) and from some
      hardware
      > reasons debouncing can't be moved inside the ISR (else a part of
      LCD
      > display should be also moved there and this slows the whole
      program).
      > TMR1 and some software counters are used now for buttons
      debouncing
      > (20MHz crystal).
      >
      > What do you suggest ?
      >
      > thx,
      > Vasile
    • Patrick Froucht
      Hi Vasile, Reading your post, it seems that for the button, you make problem (the debouncing) where you could just test if it is on or not. Remember those
      Message 2 of 20 , Feb 1, 2005
        Hi Vasile,

        Reading your post, it seems that for the button, you make problem (the
        debouncing) where you could just test if it is on or not. Remember those
        analog days...Simply use an RC filter between your button and a Schmitt
        trigger input which are numerous (at least one 8 bits port) with PIC's.
        You will free your software and your brain for the project.

        Patrick

        Vasile Surducan wrote:

        >
        >
        > It's a nice feeling to know you are there ! Who told you last
        > time "I love you ! Eur, Josef, Javi, Wouter, Jake..."
        >
        > I think wifes... or not ?
        > :)
        >
        > The problem is more complex like it looks. Yes Josef is a damn
        > 18B20, in fact is a bus with more those devices. I can't use tmr0
        > for button read (not debouncing, Eur don't like it) because I have
        > two precise events, one which happens at 100mS (required by
        > hardware) and 1S (real time interrupt driven clock)and sometime the
        > tmr0 must be stopped, it's not in free running mode (so I can't use
        > a 10mS event and multiply it).
        > Josef, I've noticed your favourite way, there is one of your
        > answers in some piclist page, I read it yesterday.
        > Eur, debouncing is must when some buttons are sharing many function.
        > Else pressing "long" the "enter button" will have the effect of two
        > different commands instead of just one. Also pressing short will
        > have the effect of slow counter changing value and pressing long
        > means fast counter changing value.
        > Javi, you realise I'm not using software delays just because I
        > can't, even I like more when is possible. I dislike also to split
        > the temperature sensor routine with button routine, this will gave
        > variable debouncing time.
        >
        > The biggest problem is the stack kill. I figured now even
        > a "port_b_low_direction" is eating stack. Killing stack is avoided
        > in this situation by tris manipulation. HD44780 library is eating
        > also too many stacks (toooo many).
        >
        > I was thinking some problems will dissapear by increasing from 4 to
        > 20 MHz clock. In fact some dissapears but many other appears (like
        > getting too small delays with tmr1).
        >
        > What can I say, thanks all,
        >
        > Vasile
        >
        >
        > --- In jallist@yahoogroups.com, "Vasile Surducan" <vasile@s...>
        > wrote:
        > >
        > >
        > > Hi guys,
        > >
        > > loop, one is button debounce and the other is a lazy
        > temperature
        > > measurement. One complete temperature measurement take about
        > 700mS,
        > > and button debounce must be at least ten time faster. The ISR is
        > > taken for a precise time keeping (100mS frame) and from some
        > hardware
        > > reasons debouncing can't be moved inside the ISR (else a part of
        > LCD
        > > display should be also moved there and this slows the whole
        > program).
        > > TMR1 and some software counters are used now for buttons
        > debouncing
        > > (20MHz crystal).
        > >
        > > What do you suggest ?
        > >
        > > thx,
        > > Vasile
        >
        >
        >
        >
        > ------------------------------------------------------------------------
        > Yahoo! Groups Links
        >
        > * To visit your group on the web, go to:
        > http://groups.yahoo.com/group/jallist/
        >
        > * To unsubscribe from this group, send an email to:
        > jallist-unsubscribe@yahoogroups.com
        > <mailto:jallist-unsubscribe@yahoogroups.com?subject=Unsubscribe>
        >
        > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        > Service <http://docs.yahoo.com/info/terms/>.
        >
        >


        [Non-text portions of this message have been removed]
      • Snail Instruments
        ... OK, how about TMR2 ... I suppose you count ten times 100ms to get 1sec. ... Not a problem, adjust the button task a bit: //bttime is time from last button
        Message 3 of 20 , Feb 1, 2005
          >18B20, in fact is a bus with more those devices. I can't use tmr0
          >for button read

          OK, how about TMR2

          > (not debouncing, Eur don't like it) because I have
          >two precise events, one which happens at 100mS (required by
          >hardware) and 1S (real time interrupt driven clock)

          I suppose you count ten times 100ms to get 1sec.

          >Eur, debouncing is must when some buttons are sharing many function.
          >Else pressing "long" the "enter button" will have the effect of two
          >different commands instead of just one. Also pressing short will
          >have the effect of slow counter changing value and pressing long
          >means fast counter changing value.

          Not a problem, adjust the button task a bit:
          //bttime is time from last button change

          if (TMR2IF){
          clear(TMR2IF);
          bt=readbt();
          changedbt=bt^lastbt;
          if(changedbt!=0){
          bttime=0;
          }else{
          if (bttime<255){
          bttime++;
          }
          }
          pressedbt=bt&changedbt;
          //process pressed buttons here
          if(bttime>50){
          //process buttons held down here
          }
          lastbt=bt;
          }

          Josef
        • Vasile Surducan
          OK, Josef I ll use TMR2 but not for debouncig but for reading the DS18B20 registers after a temperature measurement. In this way I ll not waste the waiting
          Message 4 of 20 , Feb 1, 2005
            OK, Josef I'll use TMR2 but not for debouncig but for reading the
            DS18B20 registers after a temperature measurement. In this way I'll
            not waste the waiting time to complete measure.
            Patrick, I'm using buttons connected to GND or to VCC from input
            pins only in small projects, when I have a LCD, buttons lie between
            data and command (enable) pin of the LCD, so no hardware
            trigger/filter is allowed.

            For both of you something which is probably better to knew for Jake:
            :))

            > >> Typical macho man married typical good-looking lady
            > >> and after the wedding, he laid down the following
            > >> rules: "I'll be home when I want, if I want and at
            > >> what time I want and I don't expect any hassle from
            > >> you. I expect a great dinner
            > >> to be on table unless I tell you that I won't be
            > >> home for dinner. I'll go hunting, fishing, boozing
            > >> and card-playing when I want with my old buddies
            > >> and don't you give me a hard time about it. Those
            > >> are my rules. Any comments?"

            > >> His new bride said, "No, that's fine with me. Just
            > >> understand that there will be sex here at seven
            > >> o'clock every night .....whether you're here or
            > >> not."





            --- In jallist@yahoogroups.com, Snail Instruments <snail@i...> wrote:
            >
            > >18B20, in fact is a bus with more those devices. I can't use tmr0
            > >for button read
            >
            > OK, how about TMR2
            >
            > > (not debouncing, Eur don't like it) because I have
            > >two precise events, one which happens at 100mS (required by
            > >hardware) and 1S (real time interrupt driven clock)
            >
            > I suppose you count ten times 100ms to get 1sec.
            >
            > >Eur, debouncing is must when some buttons are sharing many
            function.
            > >Else pressing "long" the "enter button" will have the effect of two
            > >different commands instead of just one. Also pressing short will
            > >have the effect of slow counter changing value and pressing long
            > >means fast counter changing value.
            >
            > Not a problem, adjust the button task a bit:
            > //bttime is time from last button change
            >
            > if (TMR2IF){
            > clear(TMR2IF);
            > bt=readbt();
            > changedbt=bt^lastbt;
            > if(changedbt!=0){
            > bttime=0;
            > }else{
            > if (bttime<255){
            > bttime++;
            > }
            > }
            > pressedbt=bt&changedbt;
            > //process pressed buttons here
            > if(bttime>50){
            > //process buttons held down here
            > }
            > lastbt=bt;
            > }
            >
            > Josef
          • Eur van Andel
            On Tue, 1 Feb 2005 09:46:36 +1100, Jake Anderson ... Is it? Program a PIC so it lights a LED on a random moment, then count how
            Message 5 of 20 , Feb 2, 2005
              On Tue, 1 Feb 2005 09:46:36 +1100, "Jake Anderson" <grooveee@...>
              wrote:

              >i dont know about you but my "reaction time" is ~18ms
              >ie press button when light comes on.
              Is it?

              Program a PIC so it lights a LED on a random moment, then count how long it
              takes for you to press a button.

              meanwhile, try these:

              http://www.phy.ntnu.edu.tw/java/Reaction/reactionTime.html
              yes, it it a local Java app.

              http://members.fortunecity.com/manaway/scalereactiontime.html

              you'll be disappointed.

              --
              Ir. E.E. van Andel, Fine Wire Heat Exchangers, Fiwihex B.V. www.fiwihex.com
              Wierdensestraat 74, NL-7604 BK Almelo, The Netherlands eur@...
              phone +31-546-491106 fax +31-546-491107 mobile +31-653-286573
            • Eur van Andel
              On Tue, 01 Feb 2005 09:24:50 -0000, Vasile Surducan ... You have 10ms, 100ms and 1s events, all driven by separate ISR parts? It
              Message 6 of 20 , Feb 2, 2005
                On Tue, 01 Feb 2005 09:24:50 -0000, "Vasile Surducan" <vasile@...-cj.ro>
                wrote:

                > The problem is more complex like it looks. Yes Josef is a damn
                >18B20, in fact is a bus with more those devices. I can't use tmr0
                >for button read (not debouncing, Eur don't like it) because I have
                >two precise events, one which happens at 100mS (required by
                >hardware) and 1S (real time interrupt driven clock)and sometime the
                >tmr0 must be stopped, it's not in free running mode (so I can't use
                >a 10mS event and multiply it).
                You have 10ms, 100ms and 1s events, all driven by separate ISR parts? It
                boggles the mind. Maybe you can explain what your program needs to do?

                It reads a sensor which takes 700ms
                It reads buttons and must react <100ms
                more???

                > Josef, I've noticed your favourite way, there is one of your
                >answers in some piclist page, I read it yesterday.

                >Eur, debouncing is must when some buttons are sharing many function.
                >Else pressing "long" the "enter button" will have the effect of two
                >different commands instead of just one. Also pressing short will
                >have the effect of slow counter changing value and pressing long
                >means fast counter changing value.
                Pressing short & long, OK. I wouldn't call that debouncing, but maybe I'm old
                (fashioned). Just check three times 100ms apart. One or two hits is short,
                three hits is long. In my experience, pressing a button for less then 100ms is
                hard.

                I have buttons that share functions too: they work different in different
                menu's on the screen.

                <JAL>
                procedure keyboard is -- %%%%%%%%%%%%%%%%%% K E Y B O A R D %%%%%%%%%%%%%
                if Sterm_key == 1 then
                if nylon_tending then
                lay_nylon_wire
                end if
                if copper_winding then
                copper_motor_state = run
                end if
                end if

                if Sterm_key == 2 then
                if copper_winding then
                copper_motor_state = coast
                end if
                if nylon_tending then
                glue_count = glue_count - 1
                end if
                end if
                [..]
                </JAL>

                > Javi, you realise I'm not using software delays just because I
                >can't, even I like more when is possible. I dislike also to split
                >the temperature sensor routine with button routine, this will gave
                >variable debouncing time.
                >
                >The biggest problem is the stack kill. I figured now even
                >a "port_b_low_direction" is eating stack. Killing stack is avoided
                ??? weird. Do it in assembler.

                >in this situation by tris manipulation. HD44780 library is eating
                >also too many stacks (toooo many).
                it is.

                >I was thinking some problems will dissapear by increasing from 4 to
                >20 MHz clock. In fact some dissapears but many other appears (like
                >getting too small delays with tmr1).
                increase the prescaler?
                --
                Ir. E.E. van Andel, Fine Wire Heat Exchangers, Fiwihex B.V. www.fiwihex.com
                Wierdensestraat 74, NL-7604 BK Almelo, The Netherlands eur@...
                phone +31-546-491106 fax +31-546-491107 mobile +31-653-286573
              • Mr S
                ... Couldn t you use a 10msec timer to fire all three ISRs and use a second timer, if needed for the event that must be stopped, that is trained by the first
                Message 7 of 20 , Feb 2, 2005
                  Hello, I'm a total neophyte here, and have a question:

                  --- Eur van Andel <eur@...> wrote:
                  > On Tue, 01 Feb 2005 09:24:50 -0000, "Vasile
                  > Surducan" <vasile@...-cj.ro>
                  > wrote:
                  >
                  > > The problem is more complex like it looks. Yes
                  > Josef is a damn
                  > >18B20, in fact is a bus with more those devices. I
                  > can't use tmr0
                  > >for button read (not debouncing, Eur don't like it)
                  > because I have
                  > >two precise events, one which happens at 100mS
                  > (required by
                  > >hardware) and 1S (real time interrupt driven
                  > clock)and sometime the
                  > >tmr0 must be stopped, it's not in free running mode
                  > (so I can't use
                  > >a 10mS event and multiply it).

                  Couldn't you use a 10msec timer to fire all three ISRs
                  and use a second timer, if needed for the event that
                  must be stopped, that is trained by the first timer
                  running at 10msecs?

                  Perhaps there is only one available timer?

                  I'm just trying to learn. Not trying to imply that
                  anything is right or wrong.

                  Thanks



                  __________________________________
                  Do you Yahoo!?
                  All your favorites on one personal page � Try My Yahoo!
                  http://my.yahoo.com
                • Vasile Surducan
                  ... have ... the ... use ... parts? It ... do? Sorry, I haven t time for that, is too much to say. ... Here was indeed the problem, but the answer was so easy.
                  Message 8 of 20 , Feb 2, 2005
                    --- In jallist@yahoogroups.com, Eur van Andel <eur@f...> wrote:
                    > On Tue, 01 Feb 2005 09:24:50 -0000, "Vasile Surducan" <vasile@s...>
                    > wrote:
                    >
                    > > The problem is more complex like it looks. Yes Josef is a damn
                    > >18B20, in fact is a bus with more those devices. I can't use tmr0
                    > >for button read (not debouncing, Eur don't like it) because I
                    have
                    > >two precise events, one which happens at 100mS (required by
                    > >hardware) and 1S (real time interrupt driven clock)and sometime
                    the
                    > >tmr0 must be stopped, it's not in free running mode (so I can't
                    use
                    > >a 10mS event and multiply it).
                    > You have 10ms, 100ms and 1s events, all driven by separate ISR
                    parts? It
                    > boggles the mind. Maybe you can explain what your program needs to
                    do?

                    Sorry, I haven't time for that, is too much to say.

                    >
                    > It reads a sensor which takes 700ms

                    Here was indeed the problem, but the answer was so easy.
                    If use a hardware delay and let a timer to count that time, when
                    try to read the sensor (in jal) with matchrom command, the reading
                    timeslot was gone. It requires another reset with a correct reading
                    cycle.
                    But surprise! DS18B20 in 12 bit mode does not need 750mS delay
                    between the start temperature reading command and read scratchpad
                    command like datasheet say, even in the worst situation (120C).It's
                    true I didn't tested at -50C but I 've tested on many device.
                    And another one: a wrong command issued on the 1 wire bus may change
                    the resolution register to a lower one. The effect: it looks like
                    the sensor was decalibrated by some misterious reasons when it's
                    not. :)) I've guess that's the answer to the folklor stories about
                    the measuring error which appears after a sensor soldering. I've
                    asked for DS18B20X so, I will know for sure.

                    > It reads buttons and must react <100ms
                    > more???

                    In some menues it must react below 100mS, and it's react.
                    Imagine how will be to increment somewhere to 300 with 100mS react
                    time and one button, a beard will grow on the operator's face. I
                    know, you'll say: use different buttons for decades or move a cursor
                    under the numbers and increment one by one, sometime is boring to
                    push so many times to set a damn number on the LCD.


                    >
                    > > Josef, I've noticed your favourite way, there is one of your
                    > >answers in some piclist page, I read it yesterday.
                    >
                    > >Eur, debouncing is must when some buttons are sharing many
                    function.
                    > >Else pressing "long" the "enter button" will have the effect of
                    two
                    > >different commands instead of just one. Also pressing short will
                    > >have the effect of slow counter changing value and pressing long
                    > >means fast counter changing value.
                    > Pressing short & long, OK. I wouldn't call that debouncing, but
                    maybe I'm old
                    > (fashioned). Just check three times 100ms apart. One or two hits
                    is short,
                    > three hits is long. In my experience, pressing a button for less
                    then 100ms is
                    > hard.
                    >
                    > I have buttons that share functions too: they work different in
                    different
                    > menu's on the screen.
                    >

                    ok, but then the example below is incomplete, two buttons are
                    changing the "copper_motor_state" and "nylon" which means just one
                    function for Sterm buttons 1 and 2. The problem is how long time is
                    passing between the true reading buttons moment (which is in another
                    routine) and the effect (which is below). And you know better. That
                    time it depends also by the program branches lenght and what must do
                    the program... :)

                    > <JAL>
                    > procedure keyboard is -- %%%%%%%%%%%%%%%%%% K E Y B O A R D %%%%%
                    %%%%%%%%
                    > if Sterm_key == 1 then
                    > if nylon_tending then
                    > lay_nylon_wire
                    > end if
                    > if copper_winding then
                    > copper_motor_state = run
                    > end if
                    > end if
                    >
                    > if Sterm_key == 2 then
                    > if copper_winding then
                    > copper_motor_state = coast
                    > end if
                    > if nylon_tending then
                    > glue_count = glue_count - 1
                    > end if
                    > end if
                    > [..]
                    > </JAL>
                    >
                    > > Javi, you realise I'm not using software delays just because I
                    > >can't, even I like more when is possible. I dislike also to split
                    > >the temperature sensor routine with button routine, this will
                    gave
                    > >variable debouncing time.
                    > >
                    > >The biggest problem is the stack kill. I figured now even
                    > >a "port_b_low_direction" is eating stack. Killing stack is
                    avoided
                    > ??? weird. Do it in assembler.
                    >
                    > >in this situation by tris manipulation. HD44780 library is eating
                    > >also too many stacks (toooo many).
                    > it is.
                    >
                    > >I was thinking some problems will dissapear by increasing from 4
                    to
                    > >20 MHz clock. In fact some dissapears but many other appears
                    (like
                    > >getting too small delays with tmr1).
                    > increase the prescaler?
                    > --
                    > Ir. E.E. van Andel, Fine Wire Heat Exchangers, Fiwihex B.V.
                    www.fiwihex.com
                    > Wierdensestraat 74, NL-7604 BK Almelo, The Netherlands eur@f...
                    > phone +31-546-491106 fax +31-546-491107 mobile +31-653-286573
                  • Eur van Andel
                    On Wed, 02 Feb 2005 14:43:47 -0000, Vasile Surducan ... You can HOLD the button: first 100ms check: increase by one second 100ms
                    Message 9 of 20 , Feb 2, 2005
                      On Wed, 02 Feb 2005 14:43:47 -0000, "Vasile Surducan" <vasile@...-cj.ro>
                      wrote:

                      > Sorry, I haven't time for that, is too much to say.
                      >>
                      >> It reads a sensor which takes 700ms
                      >> It reads buttons and must react <100ms
                      >> more???
                      >
                      >In some menues it must react below 100mS, and it's react.
                      >Imagine how will be to increment somewhere to 300 with 100mS react
                      >time and one button, a beard will grow on the operator's face. I
                      >know, you'll say: use different buttons for decades or move a cursor
                      >under the numbers and increment one by one, sometime is boring to
                      >push so many times to set a damn number on the LCD.
                      You can HOLD the button:

                      first 100ms check: increase by one
                      second 100ms check: do nothing
                      third: increase by two
                      fifth: increase by five (go to next 5, so 55, 60, 65 etc)
                      seventh increase by 10
                      ninth incr 25
                      11th 50

                      So you have to hold the button a full second to increase by 50. This is common
                      on digital interfaces.


                      > ok, but then the example below is incomplete, two buttons are
                      >changing the "copper_motor_state" and "nylon" which means just one
                      >function for Sterm buttons 1 and 2. The problem is how long time is
                      >passing between the true reading buttons moment (which is in another
                      >routine) and the effect (which is below). And you know better. That
                      >time it depends also by the program branches lenght and what must do
                      >the program... :)
                      They are doing different things _depending_ on the state. And yes, the example
                      is incomplete. The full program is >1000 lines.

                      >
                      >> <JAL>
                      >> procedure keyboard is -- %%%%%%%%%%%%%%%%%% K E Y B O A R D %%%%%
                      >%%%%%%%%
                      >> if Sterm_key == 1 then
                      >> if nylon_tending then
                      >> lay_nylon_wire
                      >> end if
                      >> if copper_winding then
                      >> copper_motor_state = run
                      >> end if
                      >> end if
                      >>
                      >> if Sterm_key == 2 then
                      >> if copper_winding then
                      >> copper_motor_state = coast
                      >> end if
                      >> if nylon_tending then
                      >> glue_count = glue_count - 1
                      >> end if
                      >> end if
                      >> [..]
                      >> </JAL>
                      >>
                      >> > Javi, you realise I'm not using software delays just because I
                      >> >can't, even I like more when is possible. I dislike also to split
                      >> >the temperature sensor routine with button routine, this will
                      >gave
                      >> >variable debouncing time.
                      >> >
                      >> >The biggest problem is the stack kill. I figured now even
                      >> >a "port_b_low_direction" is eating stack. Killing stack is
                      >avoided
                      >> ??? weird. Do it in assembler.
                      >>
                      >> >in this situation by tris manipulation. HD44780 library is eating
                      >> >also too many stacks (toooo many).
                      >> it is.
                      >>
                      >> >I was thinking some problems will dissapear by increasing from 4
                      >to
                      >> >20 MHz clock. In fact some dissapears but many other appears
                      >(like
                      >> >getting too small delays with tmr1).
                      >> increase the prescaler?
                      >> --
                      >> Ir. E.E. van Andel, Fine Wire Heat Exchangers, Fiwihex B.V.
                      >www.fiwihex.com
                      >> Wierdensestraat 74, NL-7604 BK Almelo, The Netherlands eur@f...
                      >> phone +31-546-491106 fax +31-546-491107 mobile +31-653-286573
                      >
                      >
                      >
                      >
                      >
                      >
                      >Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                      >
                      >

                      --
                      Ir. E.E. van Andel, Fine Wire Heat Exchangers, Fiwihex B.V. www.fiwihex.com
                      Wierdensestraat 74, NL-7604 BK Almelo, The Netherlands eur@...
                      phone +31-546-491106 fax +31-546-491107 mobile +31-653-286573
                    • Vasile Surducan
                      ... Of course. But you have to consider the total error which the counting will add to the final time. Assuming you need a long time RTC with zero errors, this
                      Message 10 of 20 , Feb 4, 2005
                        --- In jallist@yahoogroups.com, Mr S <szinn_the1@y...> wrote:
                        > Hello, I'm a total neophyte here, and have a question:
                        >
                        > Couldn't you use a 10msec timer to fire all three ISRs
                        > and use a second timer, if needed for the event that
                        > must be stopped, that is trained by the first timer
                        > running at 10msecs?

                        Of course. But you have to consider the total error which the
                        counting will add to the final time. Assuming you need a long time
                        RTC with zero errors, this will be difficult (for me) even in
                        assembler. Will be more difficult in jal. Maybe you have a tested
                        example when starting from a 10ms tick you've get zero error one hour
                        count ?


                        > Perhaps there is only one available timer?
                        >
                        > I'm just trying to learn. Not trying to imply that
                        > anything is right or wrong.
                        >
                        > Thanks
                        >
                        >
                        >
                        > __________________________________
                        > Do you Yahoo!?
                        > All your favorites on one personal page – Try My Yahoo!
                        > http://my.yahoo.com
                      • Eur van Andel
                        On Fri, 04 Feb 2005 08:46:54 -0000, Vasile Surducan ... Vasile, you can make a Bresenham timer with timer1 with zero error one hour
                        Message 11 of 20 , Feb 4, 2005
                          On Fri, 04 Feb 2005 08:46:54 -0000, "Vasile Surducan" <vasile@...-cj.ro>
                          wrote:

                          >> Hello, I'm a total neophyte here, and have a question:
                          >>
                          >> Couldn't you use a 10msec timer to fire all three ISRs
                          >> and use a second timer, if needed for the event that
                          >> must be stopped, that is trained by the first timer
                          >> running at 10msecs?
                          >
                          > Of course. But you have to consider the total error which the
                          >counting will add to the final time. Assuming you need a long time
                          >RTC with zero errors, this will be difficult (for me) even in
                          >assembler. Will be more difficult in jal. Maybe you have a tested
                          >example when starting from a 10ms tick you've get zero error one hour
                          >count ?
                          Vasile, you can make a Bresenham timer with timer1 with zero error one hour
                          count.

                          Then you can use the compare register to generate an accurate 10ms interrupt.
                          See the code I posted some days ago about steppers:


                          if PIR1_CCP1IF then -- compare register is matched
                          if copper_stepper_direction then
                          stepper_motor_full_forward( copper_step )
                          else
                          stepper_motor_full_backward( copper_step )
                          end if
                          port_d_high = copper_step -- output the new step

                          assembler
                          movf copper_pitch, w
                          addwf CCPR1L, f -- next stepper moment
                          skpnc -- got carry?
                          incf CCPR1H, f -- yes, add 256 to high byte
                          end assembler

                          PIR1_CCP1IF = false
                          return


                          --
                          Ir. E.E. van Andel, Fine Wire Heat Exchangers, Fiwihex B.V. www.fiwihex.com
                          Wierdensestraat 74, NL-7604 BK Almelo, The Netherlands eur@...
                          phone +31-546-491106 fax +31-546-491107 mobile +31-653-286573
                        Your message has been successfully submitted and would be delivered to recipients shortly.