Searching \ for 'Single pulse input and led driving' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/displays.htm?key=led
Search entire site for: 'Single pulse input and led driving'.

Truncated match.
PICList Thread
'Single pulse input and led driving'
1999\06\15@223453 by Benjamin Marsh

flavicon
picon face
hiya,

I have a project where a geiger counter output is sent to a pic (don't
know which one yet) and is counted and then incremented on 4 7 segment
led displays, to a total of 9999. The geiger counter output is a short
burst to high whenever it counts and I have the app note from microchip
regarding the driving of leds from a pic16c71 but this counts from 1 to
9999 at 1 second intervals. How would I alter this to take a pulse from
the geiger counter in a way to increment the display, also software is an
issue in this case (ie. we know little about pic assembly and are
planning on just altering the existing code) thanks for your help.
regards

Ben Marsh

1999\06\15@231109 by Mark Willis

flavicon
face
What you'd want to do, then, is keep watching the output of the geiger
counter, when it goes high & stays high for a few samples update the
counter, then go back to watching the LED display.  This is called
"Polling" <G>

 With LED displays, no use using fancy "Port interrupt on change"
coding, etc. as those will eat FAR more power than the PIC does, period!
<G>

 Are you wanting just a total COUNT (might want a reset switch then?),
or a count RATE (as in .01 milliRoentgen per Hour)?  Different needs,
different code for each <G>

 (I used some meters when in a Search & Rescue group, we had a contract
with the State to help them with aerial monitoring in case of a problem,
so I've used those critters.)

 Mark

Benjamin Marsh wrote:
{Quote hidden}

1999\06\16@003829 by Benjamin Marsh

flavicon
picon face
On Tue, 15 Jun 1999, Mark Willis wrote:

> What you'd want to do, then, is keep watching the output of the geiger
> counter, when it goes high & stays high for a few samples update the
> counter, then go back to watching the LED display.  This is called
> "Polling" <G>
>
>   With LED displays, no use using fancy "Port interrupt on change"
> coding, etc. as those will eat FAR more power than the PIC does, period!
> <G>
>
>   Are you wanting just a total COUNT (might want a reset switch then?),
> or a count RATE (as in .01 milliRoentgen per Hour)?  Different needs,
> different code for each <G>
>
>   (I used some meters when in a Search & Rescue group, we had a contract
> with the State to help them with aerial monitoring in case of a problem,
> so I've used those critters.)
>
>   Mark
>
This is just a basic counter that records total count, is for a first
year uni physics class so doesn't need to be suitable for search and
rescue type stuff, just counting pulses. When 'polling' the gc sends its
first pulse which starts the pic counting, and then stops when pulses
stop???, or does it just count any high input and increment from that???
Power is not really an issue as we will be using 240V @50Hz mains.
Thanks
Ben

1999\06\16@014245 by Mark Willis

flavicon
face
Benjamin Marsh wrote:
{Quote hidden}

 Nope;  You want to count the occurences of PULSES, not the occurences
of SECONDS <G>  So you will need to make some circuit changes & some
code changes (Trying to help without overdoing it here.)

 Part of the basic idea I was talking about is for noise immunity;  If
your geiger counter has low enough impedance outputs, you may not need
to worry here, may just be able to "Level clock" the signals (i.e. on
the FIRST sample that's different from the last sample, take appropriate
action, then start waiting for the other state to happen.)

 As I've seen INTERNAL modems (back in 2400 baud days), that suffered
from RF noise so bad that I was asking the poor owner to buy a SHIELDED
cable (He reminded me, over the phone, that it was an internal modem -
Oops - hard to shield the entire ISA bus, much less the non-existent
cable from the card to it's ISA slot! - he lived under a Radio
transmitter tower's shadow in North Seattle!) and having worked with
switches, I tend to debounce things <G>  All it takes is a "False Click"
loud enough to level shift the geiger counters' output for too long, and
you get a false count;  maybe you don't need this to be made in a
life-critical fashion though <G>  If you get false triggers, think about
adding debounce code.  The PIC's probably PLENTY fast to do that, if you
run a 4MHz crystal you are running about 1 instruction per microsecond
<G>  Quite easy to handle audible clicks, at that rate!

 You'll want 16-bit counter code if you want to count over 255.

 The startup code could zero the counter & wait for a "Low" from the
geiger counter (Perhaps wait a second or so to let things stabilize, if
needed?)

 I put the "Debouncing Stuff" in curly brackets below. (i.e. {})

 Then, loop, reading some port bit (say RA0?) that the geiger tube's
attached to -  When you see a "High", {check to make sure it's been high
for more than one poll, then} jump to a code section that increments the
count & displays it, then waits, polling the bit until it's {been} low
{for more than one poll}.

 (Might just increment the counter on high transition, and separately
display the count when the input's low, if timing requires that.  If you
have 4 high transitions in fast sequence, you still want the count to be
right, even though the display might "glitch".  We're talking RANDOM
occurences here <G>)

 The PIC's so fast and the tube's discharge so long that you may not
need much debouncing unless you're near a source of lots of
interference.  Depends on the impedance of your geiger counter (Of which
I know nothing <G>  Could be 8 ohms or set for a 10k crystal earpiece!)

 Mark

1999\06\16@023115 by Benjamin Marsh

flavicon
picon face
{Quote hidden}

OK.
I will use say RB7 to sample the geiger counter (which is tube only) and
the rest of RB0-6 to run the seven segments, and RA0-5 to control each
LED unit. We thought we only needed 0-9999 but have since discovered we
need 0-99999. I looked inside the original counter boxes which were made
by the physics department here in 1975, it uses a decade counter and
decoder IC for each display - we want to get to only a single IC to
control all 5 digits - is the 16F84 suitable for this (@4Mhz or 10Mhz) or
is there a better PIC for the job, thank you again.
Ben

1999\06\16@024551 by Dennis Plunkett

flavicon
face
At 16:29 16/06/99 +1000, you wrote:

       <<Massive snip>>
>OK.
>I will use say RB7 to sample the geiger counter (which is tube only) and
>the rest of RB0-6 to run the seven segments, and RA0-5 to control each
>LED unit. We thought we only needed 0-9999 but have since discovered we
>need 0-99999. I looked inside the original counter boxes which were made
>by the physics department here in 1975, it uses a decade counter and
>decoder IC for each display - we want to get to only a single IC to
>control all 5 digits - is the 16F84 suitable for this (@4Mhz or 10Mhz) or
>is there a better PIC for the job, thank you again.
>Ben
>
>

Hello Ben,

Now is NOT THE TIME TO SELECT THE PROCESSOR, decide exactly what the
counter thingo has to do first, including all the other things that are
required (Reseting the count, providing a serial output of the count etc.)
other things including form factor etc.

Then and only then look at the processor to use, but don't forget
development tools and simulators etc (YOU WILL NEED them). The speed of the
processor is decided sometime around this point.

But I must say that from what I can see this is a simple requirement
especialy if it only has to replace the current counter box with no extra
features or functions added to it.

Dennis

1999\06\16@025005 by Tony Nixon

flavicon
picon face
Benjamin Marsh wrote:
> we want to get to only a single IC to
> control all 5 digits - is the 16F84 suitable for this (@4Mhz or 10Mhz) or
> is there a better PIC for the job, thank you again.

4Mhz should be plenty.

You may consider using RA4 as the test input because it is an open
collector output and may require extra electronics to multiplex the
displays. It will be a little more difficult in software, but not too
bad.

I've used 820R resistors to source the segment LEDs direct from the PIC
and they are bright enough to see, especially if you use a red perspex
cover.


--
Best regards

Tony

'The Engine' - Design your own programmer.

http://www.picnpoke.com
Email spam_OUTpicnpokeTakeThisOuTspamcdi.com.au

1999\06\16@030701 by Michael Rigby-Jones

flavicon
face
I agree, this is easily within the capabilities of a 16F84.  I would count
in BCD rather than in binary and then convert to BCD.  You will have loads
of space to do this so 1 byte per digit (i.e. non-packed BCD)should be ok
and will make the code easier.

Also, because I'm a bit lazy, and it makes the code simpler, I'd actually
use RA0-RA4 for driving the displays commons, but as Tony says RA4 is open
collector (an often overlooked fact) so it won't be able to source current.
However, if the displays are common cathode, this won't be a problem.

If the input is nice and square with no ringing or spurious pulses, then
consider using the external interupt on pin RB0 to detect the pulses.  Your
interrupt service routine would then increment the counter.  The main loop
would just step through the 5 BCD locations (clearing the appropriate bit on
port A), convert them to seven segment pattern (use a simple lookup table)
and output the result to RB1-RB7 which would be connected to the LED anodes.

The maximum count speed will then depend on how fast you can service the
interupts, but it should be pretty darn quick.

No port pins left for a counter reset button.  However you do have /MCLR
which will reset the whole processor.  As your counter variables will be
initialised on power up, this should be an ideal solution.

Regards

Mike Rigby-Jones

> {Original Message removed}

1999\06\16@033600 by Benjamin Marsh

flavicon
picon face
On Wed, 16 Jun 1999, Michael Rigby-Jones wrote:

{Quote hidden}

We measured the gc with a cro and it looked somewhat like this


    |
    |
    |
    |
_____|   _______
     \ /
      |

I have no idea what the -ve spike is but a diode should clean that up.
The +ve spike is about 1ms wide, we didn't measure the peak voltage rise
though. As a side note: This is the first PIC project we have started - I
haven't even got the flashing LED chaser going yet (have the pcb though
:)  ) The original circuit had a on/off (duh), a reset, a stop/start
selector which allowed the count to be stopped for reading and resumed
again, and a CRO output to test the gc tube. The stop/start should be
achievable by just switching the input on or off, I was going to use MCLR
as reset but that would reset the display??? I don't really want to have
to multiplex just yet!!! BTW may be a dumb question but what is BCD?
Thank you.
Ben

1999\06\16@041826 by Michael Rigby-Jones

flavicon
face
       <snip>


{Quote hidden}

Well, it looks fine.  The PIC inputs actually have clamping diodes in it's
inputs going to Vdd and Vss, however, I'm a big believer in using external
diodes, especially as they only cost penny's.

During reset the port pins are tristated, so the display will switch off.
However as soon as the button is released and the PIC re-initialises, the
display will reset to zero.  This dosen't seem like too much of a hardship
though.

As for multiplexing, you have no choice, there aren't enough port pins, so
unless you use some kind of port extender like a sh1t load of shift
registers or latches then you will have to multiplex the display.  It's not
at all difficult though.

BCD stands for Binary Coded Decimal.  It basically how you represent decimal
within a processor which is naturally binary based.  All it means is that
you only store the digits 0 to 9 in a byte.  This only takes 4 bits so you
can actually store 2 digits per byte, known as packed BCD.  Handling BCD is
a bit more tricky than straight binary, but not much.  You have two choices,
either store your count as a 24 bit binary number and then convert this to
BCD for display on the LED's, or just hold the count in BCD form to start
with.  Converting from binary to BCD is quite processor intensive and in
this case it just isn't justified.

To increment a number stored in BCD format:

ones++;
if(ones == 10)
{
       ones = 0;
       tens++;
}
if(tens == 10)
{
       tens = 0;
       hundreds++;
}
etc, etc...

If you need to manipulate BCD in other ways, addition, subtraction etc, have
a look around a few PIC web sites, there have been several BCD libraries
written by various people.

Hope this helps

Mike Rigby-Jones

1999\06\16@050817 by Benjamin Marsh

flavicon
picon face
> >
> Well, it looks fine.  The PIC inputs actually have clamping diodes in it's
> inputs going to Vdd and Vss, however, I'm a big believer in using external
> diodes, especially as they only cost penny's.

especially if something goes wrong - better a fried diode than a fried
chip :)
>
> During reset the port pins are tristated, so the display will switch off.
> However as soon as the button is released and the PIC re-initialises, the
> display will reset to zero.  This dosen't seem like too much of a hardship
> though.

since there was no memory in the original circuit the reset just cleared
the LED's, the PIC would need to be cleared fully so it doesn't start the
count again at the point the display was cleared (if it would do that)
>
> As for multiplexing, you have no choice, there aren't enough port pins, so
> unless you use some kind of port extender like a sh1t load of shift
> registers or latches then you will have to multiplex the display.  It's not
> at all difficult though.

If it came to that I was going to use the circuit in the app notes that
had the 4X4 keypad but only one switch - which I was going to use as the
input. I am starting to think one of the main problems I am going to have
with this is the software to run it...
{Quote hidden}

So in asm, numbers are stored in binary - unlike in C where you program
as though the numbers are decimal???

{Quote hidden}

at the moment anything helps thanks, i have learnt a fair bit today :)
Ben
>
> Mike Rigby-Jones
>

1999\06\16@060513 by Michael Rigby-Jones

flavicon
face
> > During reset the port pins are tristated, so the display will switch
> off.
> > However as soon as the button is released and the PIC re-initialises,
> the
> > display will reset to zero.  This dosen't seem like too much of a
> hardship
> > though.
>
> since there was no memory in the original circuit the reset just cleared
> the LED's, the PIC would need to be cleared fully so it doesn't start the
> count again at the point the display was cleared (if it would do that)
>
When to perform a hardware reset with the /MCLR pin, the processor puts
various registers in default states and start executing the code at the
reset vector (0000h in this case).  The RAM is not cleared by default and
this is where you will be storing your count, so the one of the first things
your program should do is to initialise (i.e. set to zero or to a known
value) all the variables that it uses.  This will mean the counter will
automatically start from zero after a reset.

{Quote hidden}

It would certainly be possible to multiplex the inputs for switches but
obviously it would be easier if you had more pins available.  Do you really
need the seven segment LED display?  If you could use an LCD module you
could save yourself a lot pins (LCD needs 7 pins total to drive it, or with
a simple interface on Myke Predko's web page, only 2 pins!)

> >
> > BCD stands for Binary Coded Decimal.  It basically how you represent
> decimal
> > within a processor which is naturally binary based.  All it means is
> that
       <snip>

> So in asm, numbers are stored in binary - unlike in C where you program
> as though the numbers are decimal???
>
Errr..maybe I wasn't too clear there :o)  When you use assembler you can use
whatever number base the assembler will let you use.  MPASM takes
binary,decimal, octal, hexidecimal and ASCII.  The number base is refered to
as the RADIX.  See the MPASM help for details.
What I meant was that the internals of a processor such at the PIC are
designed with register sizes based on powers of 2, not powers of ten.  They
don't naturally work in decimal, but with a bit of cunning you can persuade
it ;o)

Regards

Mike Rigby-Jones

1999\06\16@190841 by Tony Nixon

flavicon
picon face
Michael Rigby-Jones wrote:
> When to perform a hardware reset with the /MCLR pin, the processor puts
> various registers in default states and start executing the code at the
> reset vector (0000h in this case).  The RAM is not cleared by default and
> this is where you will be storing your count, so the one of the first things
> your program should do is to initialise (i.e. set to zero or to a known
> value) all the variables that it uses.  This will mean the counter will
> automatically start from zero after a reset.

Why do that?

Software can be quite good at getting around hardware limitations.

If the RAM registers still have the count value stored, why not display
them on reset. On powerup, these will be garbled, but who cares.

Write your code so that the 'first time' it gets a count state, clear
the registers and keep counting.

You can even do a double reset. Have another counter working that
detects two resets within a certain time, and then clear the counters to
give a ----0 display.

--
Best regards

Tony

'The Engine' - Design your own programmer.

http://www.picnpoke.com
Email .....picnpokeKILLspamspam@spam@cdi.com.au

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...