Shop OBEX P1 Docs P2 Docs Learn Events
Is there a way to count pulses (a steady 120hz) for a changing length of a butt - Page 2 — Parallax Forums

Is there a way to count pulses (a steady 120hz) for a changing length of a butt

2

Comments

  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-06-27 20:33
    You many need to use an external circuit to clean-up the button bounce -- the trick with your program is that you're manually counting pulses from an external device with an ~8 ms period; by inserting debouncing code you will start missing counts.· You may want to consider that PCF8583 as an external counter I mentioned earlier; it may be a better solution for you to measure the period (accurately) between button presses.





    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-27 20:40
    hmm.. bummer i figured it would be a easy solution. somehow the button is my problem tho. I hooked my counter up to another 555 timed at 3hz. and the numbers are much more steady. Only about a 7bpm difference between them. So somehow the button is making it very wack.
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-27 21:05
    Oh, btw, if anyone is keeping track of this and using the code, the BPM calculation should read

    bpm = (3600 / pCount) + 10, NOT bpm = 7200 / pcount

    I dont know why, (prolly from my 555 timers inaccuracy) but I had to add 10 to my result to get the range in the proper BPM. Mabee this will be fixed with a crystal clock.
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-27 23:09
    Where do I get the PCF8483? I searched parallax.com, and maxim-ic... nothing.
  • OrionOrion Posts: 236
    edited 2005-06-27 23:14
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-06-27 23:22
    How do you figure (the 3600 part)?· 120 Hz x 60 seconds (one minute)·= 7200.
    BPM said...
    Oh, btw, if anyone is keeping track of this and using the code, the BPM calculation should read

    bpm = (3600 / pCount) + 10, NOT bpm = 7200 / pcount

    I dont know why, (prolly from my 555 timers inaccuracy) but I had to add 10 to my result to get the range in the proper BPM. Mabee this will be fixed with a crystal clock.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-06-27 23:27
    Buttons are inherintly noisy.· The ticky part for you is that debouncing software takes a little more time than you have between raw input pulses.· If you use an external counter there will be a built-in delay while sending the message, so that will help -- you can go back to the non-debounced method to keep the code simple.
    BPM said...
    hmm.. bummer i figured it would be a easy solution. somehow the button is my problem tho. I hooked my counter up to another 555 timed at 3hz. and the numbers are much more steady. Only about a 7bpm difference between them. So somehow the button is making it very wack.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-28 02:39
    Jon Williams (Parallax) said...
    How do you figure (the 3600 part)? 120 Hz x 60 seconds (one minute) = 7200.

    When I found out I questioned myself also.

    But after calculating what my bpm SHOULD read, I found that it was double.
    I ran the program like you wrote it.
    My clock is 120hz.
    My button click is hooked up to a 555 running at 3hz.

    3 X 60 = 180BPM.

    If you run the program with bpm = 7200 / pcount, your BPM will be around 80.
    If you change it, the bpm will be correct (close to 180) (assuming you have exactly 3hz and 120hz)

    Or this might be a result of me using DEBUG code.
    Mabee its slowing the program down?
    Heres a question.
    How Do I NOT send the BPM back thru DEBUG? Is there a way to STORE it and send it in Bunches? Mabee this would prove if my debug is slow?
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-06-28 04:01
    There is no problem with your BASIC Stamp being slow -- that should be abundantly clear by now.· Since you're sending the DEBUG output between measurement windows it's not affecting the count.

    I'd say the *problem* is in your button pressing -- that's probably what's slow and is resulting in a higher-than-expected number.· Not that I got particularly scientific, mind you, but using the old "One thousand one, One thousand two..." counting between button presses always resulted in the correct value on every test.· Have you verified that your 120 Hz input is actually 120 Hz?· I had a scope to check my 555, but I also did this:

    · COUNT PulseIn, 1000, countHz
    · DEBUG ? countHz
    · END

    ... and I got 122 (which is what my scope said as well) -- and this was close enough to test the code.· If you want to speed up your DEBUG output (again, it's NOT affecting the count routine -- unless you snuck a DEBUG output into the middle of it), just send the value:

    · DEBUG DEC countHz, CR

    This will print just the value without·the variable name (you know what you're looking at).

    The lesson is you have to be very careful when you start "shotgun compensating" -- pretty soon nothing will work, nothing will match expectations, and ultimately you'll be left scratching your head wondering why.·

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2005-06-28 04:38
    I agree with Jon that the Stamp will be quite accurate in its counting, and the discrepancies you are seeing might be something in your 555 circuit or more likely in our collective misunderstanding of what you want to do.

    The existing routine counts for 1/2 of a cycle of your 555 input, whereas it looks to me that you probably want to count for a full cycle.

    Here is the existing subroutine:

    Count_Pulses:
    DO : LOOP UNTIL (Bttn = Pressed)
    DO : LOOP UNTIL (Bttn = Released)
    DO
    IF (Hz = 1) THEN
    pCount = pCount + 1
    DO : LOOP UNTIL (Hz = 0)
    ENDIF
    LOOP UNTIL (Bttn = Pressed)
    RETURN

    It starts counting when the button is "released" and stops counting when it is next "pressed". That is 1/2 cycle. And that may explain why you need 3600/pcount instead of 7200/pcount. Also, since 555 oscillators are usually not symmetrical output, more time in one state than the other, that 3600 would not be right on either, so that might explain your "+10".

    To count for the full cycle, you need something more like this:

    Count_Pulses:
    DO : LOOP UNTIL (Bttn = Pressed)
    DO : LOOP UNTIL (Bttn = Released)
    DO ' count the + half cycle
    IF (Hz = 1) THEN
    pCount = pCount + 1
    DO : LOOP UNTIL (Hz = 0)
    ENDIF
    LOOP UNTIL (Bttn = Pressed) ' until + half cycle ends
    DO ' then count the - half cycle
    IF (Hz = 1) THEN
    pCount = pCount + 1
    DO : LOOP UNTIL (Hz = 0)
    ENDIF
    LOOP UNTIL (Bttn = released) ' until it ends
    RETURN ' this should give the 7200/pcount=bpm

    That will have the effect of waiting until the button is pressed and released, then counting the + half cycle, then the - half cycle. The counting ends when the button is released a second time. The system then waits for the button to be pressed and released again before it starts counting. That is, the alternate program skips every other cycle of your 3hz button input.

    I'm puzzled why your experiment yielded such scattered reults. Was that also from the 3hz 555 oscillator, or was it from a real finger pressing a button? The 555 should not bounce. If it is a real pushbutton, you can deal with that using an RC circuit in parallel with the button, or by a software test outside the main counting loop, where it will not limit your counting speed.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-28 05:01
    ok. Ran this code to verify HZ

    COUNT PulseIn, 1000, countHz
    DEBUG ? countHz
    END

    My results.
    Heres my 555 BUTTON simulator.
    countHz = 4
    countHz = 5
    countHz = 5
    countHz = 5
    countHz = 5
    countHz = 5
    countHz = 5
    I then swapped pins to measure 120hz....
    countHz = 120
    countHz = 120
    countHz = 120
    countHz = 120
    countHz = 120
    countHz = 120
    countHz = 120
    countHz = 120
    countHz = 120
    countHz = 119
    countHz = 119

    I then used this code, file attached.
    This is NOT MODIFIED, from you.

    My results are this

    Press button. Wait. Press again.
    Count = 12
    BPM = 600

    The BPM is double, for 5hz.
    5 X 60 = 300. BPM.

    So then I changed ONLY ONE THING in the code.
    this: bpm = 7200 / pCount
    to this: bpm = 3600 / pCount

    My results are:

    Press button. Wait. Press again.
    Count = 12
    BPM = 300

    If you still say that 7200 is correct. I beg of you to teach me why. I am not being mean here, just learning, trying to understand everything that is being put out here.
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-28 05:10
    Tracy Allen said...

    The existing routine counts for 1/2 of a cycle of your 555 input, whereas it looks to me that you probably want to count for a full cycle.

    It starts counting when the button is "released" and stops counting when it is next "pressed". That is 1/2 cycle. And that may explain why you need 3600/pcount instead of 7200/pcount. Also, since 555 oscillators are usually not symmetrical output, more time in one state than the other, that 3600 would not be right on either, so that might explain your "+10".

    That will have the effect of waiting until the button is pressed and released, then counting the + half cycle, then the - half cycle. The counting ends when the button is released a second time. The system then waits for the button to be pressed and released again before it starts counting. That is, the alternate program skips every other cycle of your 3hz button input.

    I'm puzzled why your experiment yielded such scattered reults. Was that also from the 3hz 555 oscillator, or was it from a real finger pressing a button? The 555 should not bounce. If it is a real pushbutton, you can deal with that using an RC circuit in parallel with the button, or by a software test outside the main counting loop, where it will not limit your counting speed.

    The one that had VERY scattered results was an acutal button. And I will havta deal with the bounce issue in circuit I guess. You say it can be dealt with OUTSIDE the main counting loop.? I would imagine that any software that will deal with my bouncing button, will affect the counting.? Due to the BUTTON command using up time to do its work?

    So wait. This program, it only counts from LAST BUTTON RELEASE to NEXT BUTTON PRESS?
    So I am acutally loosing some timing in there.?
    If I need to count every hz, then I need to reprogram it to count from LAST BUTTON RELEASE to NEXT BUTTON RELEASE right? Or is that what you had just said? LOL.. and gave me the program for... heh...

    Post Edited (BPM) : 6/28/2005 5:15:49 AM GMT
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-28 05:14
    after reading your code, and message a few more times, you did say that. GREAT! so thats why I was all wack! I didn't realize the code wasn't counting for the full cycle button release to button release. (I am not that good at understanding programs yet)

    I do havta say, after being "all about hardware" I am pushed into the software realm without the EDGE that is associated with learning a language.
    I love it, what a great way to help teach microprocessors and programming.
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-28 06:18
    I tried out your code tracy, and it works without me changing the 7200. GREAT, (now I get to compare the two codes and learn exactly what is going on between them heh)

    I thank you very much for all your help, you too Jon!

    I have attached the working code.

    Heres my results after a bit more design tweaking.
    I raised the HZ to 240. Hoping for a bit more accuracy on counting. Not sure if it will help.
    And obviously I changed the divisor to 14400.
    I know I still need a debouncer...

    BPM = 123
    BPM = 129
    BPM = 124
    BPM = 126
    BPM = 133
    BPM = 129
    BPM = 128
    BPM = 133
    BPM = 123
    BPM = 129
    BPM = 124
    BPM = 127
    BPM = 127
    BPM = 124
    BPM = 128
    BPM = 120
    BPM = 126
    BPM = 119
    BPM = 125
    BPM = 129
    BPM = 128
    BPM = 127
    BPM = 126
    BPM = 125
    BPM = 138
    BPM = 129

    But thats pretty good!

    I am guessing my target bpm was 128.
    Testing this with a steady, 4hz signal, resulted in the following.
    The average being 240. [noparse]:)[/noparse]
    BPM = 240
    BPM = 236
    BPM = 236
    BPM = 244
    BPM = 240
    BPM = 240
    BPM = 236
    BPM = 236
    BPM = 236
    BPM = 244
    BPM = 240
    BPM = 236
    BPM = 240
    BPM = 240
    BPM = 240
    BPM = 244
    BPM = 240
    BPM = 240
    BPM = 240
    BPM = 236
    BPM = 236
    BPM = 236
    BPM = 244
    BPM = 240
    BPM = 240
    BPM = 240
    BPM = 240
    BPM = 236
    BPM = 240
    BPM = 240
    bs2
    968B
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-28 06:23
    Now mabee I should actually build the BO-BOT, I have the kit... Just didn't do it. Heh, I had other evil plans in mind for my stamp2 (like a BPM tool)
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-28 06:29
    I would like to continue on the BPM, but the next step i think is to debounce the button. and I need an external circuit for that?
    Then I need to display the bpm (external circuit)
    etc.. I must wait for my stuff to get here.
    Then comes the issue of me only having a BS2.
    My external circuits prolly require some elaborate subroutine to communicate to them. Untill the parts get here I guess I can't do much.
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-28 06:37
    I searched for PCF8483 on BOTH mouser.com and digikey and NO parts were found that describe some kind of counter.

    digikey showed me a 0.027µF capacitor when searching on "PCF 8483"
    and nothing when searching on "PCF8483"

    mouser showed 4 semiconductor results...
    two were RS-485/422 Interface ICs
    one was a 4-BIT BIN FULL ADDER
    and the other was a Driver IC.

    The ever elusive PCF8483 hunt continues!

    could I debounce with SCHMITT TRIGGER LOGIC?
    Or some other way?
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2005-06-28 07:05
    The part mentioned was pcf8583.

    regards peter
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-28 08:14
    Thanks for the corrected part #
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-06-28 14:14
    Can you define for me what you mean by beats-per-minute?· When I run your code I get exactly double what I think I should, though looking at you code the results are correct (though not matching my input).
    If I press the button every six seconds is this not 10 beats per minute?· When I run your code as is I get 20 if there is six seconds between button presses.
    There will be a treshold where the instruction cycle won't be able to keep up with your input; I'd suggest that 120 Hz is probably pretty close to it in high-level PBASIC.· Of course, if you port this over to the SX using SX/B then it's a different story ... though SX/B does not offer th convenience of 16-bit math.
    BPM said...
    I tried out your code tracy, and it works without me changing the 7200. GREAT, (now I get to compare the two codes and learn exactly what is going on between them heh)

    I thank you very much for all your help, you too Jon!

    I have attached the working code.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2005-06-28 17:04
    Yeh, counting for 6 seconds with an input of 240 hz should yield 6*240=1440 counts. And 14400/1440 = 10 beats per minute. I don't see offhand where the discrepancy lies in the setup wrt BPM's result.

    I think the limit for count frequency with this routine may go as high as 300 hertz even with a BS2.
    There is still some optimization that could be applied. For example, the statement
    LOOP UNTIL (startBtn=pressed) ' pressed defined as =0
    is within the loop and the loop will run significantly faster with
    LOOP WHILE startBtn ' loop while startBtn=1, using WHILE construct and leaving off the =
    Less transparent for self documentation, granted, but faster.
    If I get a chance I'll run a little test to compare techniques, how fast they can go.

    BPM could get an extra decimal point in the result, using the formula,
    BPM = 14400/pcount *10 + (14400//pcount * 10 / pcount)
    debug dec BPM/10,".",dec1 BPM

    that gives one extra decimal point over simply
    BPM = 14400/pcount
    e.g., 10.3 BPM instead of 10.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-06-28 17:25
    I misse the part where he changed to 240 Hz...· I think I'll bow out of this thread; I don't seem to be smart enough to understand what's wanted or contribute anything useful.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2005-06-28 18:42
    Please don't bow out, Jon . No one here will ever attribute to you a lack of smarts! Quite quite the contrary. The problem goal under consideration is ambiguous and developing, so there is a lot of second guessing going on.

    I did test the attached program, which has three possible methods around a #SELECT#CASE directive. It counts square wave on p0 during a 1 second interval that p1 is high. (The p1 1 second high gating signal is generated by a second Stamp, and the p0 frequency input to be counted is generated by an Extech process calibrator.)


    Method 1: The BS2pe counted without error up to 400 hertz but failed at 480 hertz. On a BS2p, it counted up to 800 hertz, but failed at 1200. (The Extech calibrater has only discrete steps, with nothing between 400 and 480 nor between 800 and 1200).

    Method 2: This is code optimized method 1, using the LOOP WHILE startBtn instead of LOOP UNTIL (startBtn=pressed) within the main loop. On a BS2pe that could count up to 800 hertz without error and on a BS2p up to 1200 hertz.

    Method 3: This is the code using XOR bit manipulation I posted earlier, but with the same optimization as method 2. On the BS2pe it counted ccorrectly up to 400 hertz, and on a BS2p, ujp to 800 hertz. So it is indeed slower than Jon's approach with the IF-THEN logic. I still like this method, because it is less modal, and thus easier to add additional parallel processing.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-29 11:08
    Jon Williams (Parallax) said...
    I misse the part where he changed to 240 Hz... I think I'll bow out of this thread; I don't seem to be smart enough to understand what's wanted or contribute anything useful.


    LOL you not smart?

    The problem is, I am constantly changing my parameters and requirements. And I am asking multiple questions one after another.
    I am being very confusing, and I appologise for it.


    For instance, I am learning how to drive a dual 7seg display using a 74LS47. (stamp2 ----> BCD(with common anode lines)
    > 74ls47 ----> 7segment)
    I have searched and found your code

    Pins = decVal / 10 * 16
    Pins = decVal // 10 | Pins
    
    



    I still dont understand what the HECK this says. LOL. But I am searching the help and slowly putting it together.
    [noparse]:)[/noparse]
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-06-29 12:54
    To start with, that code you reference is for the BS1 (I can tell because PINS is a BS1 reserved word).· But let me see if I can explain because you can sustitute OUTH (P8..P15) on the BS2, like this:

    OUTD = decVal / 10
    OUTC = decVal // 10

    The first line divides decVal by 10, so the 10s digit gets output to OUTD (P12..P15, which would connect to your 74LS47 pins A..D).· The second line uses the modulus (//) operator which returns the remainder of a division.· Let's say that decVal is 25: 25 dvidied by 10 is 2, with 5 left over (remainder).· So 5 (%0101) would be output OUTC (P8..P11).

    That said, it's actually easier with the BS2's DIG opertor -- it returns the digit in the specific position of a number.· So you can do this:

    OUTD = bpm DIG 1··· ' get 10s (101) digit
    OUTC = bpm DIG 0··· ' get 1s (100)·digit

    But didn't you say somewhere you wanted three digits?· If yes and you can squeeze your Hz input and button(s) into P0..P3, then you can use the OUTB, OUTC, and OUTD pin groups like this:

    OUTD = bpm DIG 2··· ' get 100s (102)·digit
    OUTC = bpm DIG 1··· ' get 10s (101) digit
    OUTB = bpm DIG 0··· ' get 1s (100)·digit

    Make sense?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-29 22:19
    GREAT it makes 100% sense!

    I can see where having an I2C device to decode the digits comes in handy now. Just 3 digits and I am already using 75% of my out pins.

    If I have digit displays that have common anodes, couldn't I use the same 4 out pins for all 3 digits(74ls47 inputs), and then just use 3 more pins to BLANK the other digits, then flashing the digit that I am sending to my output?

    So, send number to all 3 74ls47's, but two of the 47's keep BLANK on. And the other 47 turn it off.
    And so on for the other two digits.

    OUTB = bpm DIG getDig ' get digit 0, 1, 2 (i would use a, For getDig = 0 to 3)
    OUTC = blank DIG blankDig 'get blank mode of 3 digits, 000, or 111. But if I do this, it will convert the digit to BCD, So I need to figure out which BCD numbers will send the proper blank signals. Easy...

    This way I am still using alot, but now 7 pins for 3 digits. I am sure theres some catch to doing this tho, and look forward to your reply! [noparse]:)[/noparse]
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-06-29 22:35
    To share the outputs with multiple 47s you end up multiplexing -- not easy to do in PBASIC and the results will not be satisfying. I would use three 74HC595 output shift registers that are daisy-chained. With three pins and a few lines of code you would end up with 24 additional digital outputs, enough to handle your 7-segment·displays without worry.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-30 07:46
    Tell me what you think of this. It works really good. It uses 1 - 74ls47. And 3 transistors. (1 for each common anode).
    To add any number of digits, only requires 1 additional line per digit. (so 1 transistor, and one pinout per digit)

    Using this method, you could drive up to 12 digits? (with no leftover pins)
    I don't have any artifacts or shadow in any of my digits AT ALL! (in total darkness)
    To blank each digit, I cut off the power to the digit using the transistor.

    Actually I am amazed at how easy it is to add more digits.

    But at the same time, this 3 digit 7-segment BCD out display takes up 7 pins.

    ' {$STAMP BS2}
    ' {$PBASIC 2.5}
    
    number    VAR    Word
    digit     VAR    Word
    
    
    DIRS = %1111111
    
    Main:
    
    number = 159
    
    DO
      FOR digit = 0 TO 2
          SELECT digit
    
          CASE 0
            OUTB = 000                 ' blank all displays
            OUTA = number DIG digit    ' load 1's digit in 74ls47
            OUTB = 001                 ' turn on 1's display.
    
          CASE 1
            OUTB = 000                 ' blank all displays
            OUTA = number DIG digit    ' load 10's digit in 74ls47
            OUTB = 010                 ' turn on 10's display.
    
          CASE 2
            OUTB = 000                 ' blank all displays
            OUTA = number DIG digit    ' load 100's digit in 74ls47
            OUTB = 100                 ' turn on 100's display.
    
          ENDSELECT
      NEXT
    LOOP
    
    



    Obviously this method isn't efficient, or pin conserving, but it has taught me alot about displaying digits.
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-30 08:18
    I am sure your laughing at that....
    Its definely not efficient. uhhh dont ask why I included all that select case Smile.. LOL

    This works exactly the same

    Display_Digits:
    
            OUTA = bpm DIG 0           ' load 1's digit in 74ls47
            OUTB = 001                 ' turn on 1's display.
            PAUSE 1                    ' let em burn!
            OUTB = 000                 ' blank all displays
    
            OUTA = bpm DIG 1           ' load 10's digit in 74ls47
            OUTB = 010                 ' turn on 10's display.
            PAUSE 1                    ' let em burn!
            OUTB = 000                 ' blank all displays
    
            OUTA = bpm DIG 2           ' load 100's digit in 74ls47
            OUTB = 100                 ' turn on 100's display.
            PAUSE 1                    ' let em burn!
            OUTB = 000                 ' blank all displays
    
    RETURN
    
    
  • Clock LoopClock Loop Posts: 2,069
    edited 2005-06-30 08:50
    Jon Williams (Parallax) said...
    To share the outputs with multiple 47s you end up multiplexing -- not easy to do in PBASIC and the results will not be satisfying. I would use three 74HC595 output shift registers that are daisy-chained. With three pins and a few lines of code you would end up with 24 additional digital outputs, enough to handle your 7-segment displays without worry.


    After trying to combine the two; my digit code, with the BPM calcualtion code, I see what you mean that the results will not be satisfying. I am having to call my Display Digits subroutine so many times thru the bpm count code, that it messes up the count. And the displays are still dim/flickering

    I suppose this is where a latch comes in handy?

    After looking at a latch-able 7-segment driver,HEF4511. I see what your saying about multiplexing. To use latching now, I need to add ANOTHER 5 pin outs to my monstrosity. (to drive a total of 3 4511's) (but what that many pinouts, latching, or blanking isn't needed)

    But the latch doesn't help me with my flickering/dim displays, due to me using a 7 seg display (4 digits) that acually has common anodes, and common cathodes. (segments are tied together, all a's, b's. etc...) Each digit has its own common anode.

    If I were using a display that had common anodes, and seperate cathodes for each digit, I would get away with using 3 4511's on the same 4 pin outs. Then I wouldn't need to blank each display, I would only need to latch each. Keeping me at my current 7 pin config.

    BUT to use the 4511's I need a common cathode type display. I only have common anode. NEXT!

    On to looking to see what I have for chips that match a 74HC595, or will I have the same issue using a common anode / common (segment) display type.
    Is the only difference between a 74LS164 and 74HC595, basically a latch? Because I only have a bunch of 74LS164's


    I am sure going to have some fun when more parts arrive. Allowing me to try out I2C, 1-wire, and 2-wire communications.

    Post Edited (BPM) : 6/30/2005 11:19:02 AM GMT
Sign In or Register to comment.