magnetic field

Thanks, but I need a display.
Preferably 3 digits using 7-segment LEDs.

I have a schematic from an OLD Radio Shack book that uses a 555 to
drive a 7490 that dumps into either a 7447 or 7448 and then into a
7-segment LED. I'd like to get THIS to count down and it would be great
if I could get it to use DIP switches to preset a number using binary.

I'm going to use an IR LED emitter and receiver to count objects
passing a point (piantballs leaving the barrel or hopper).
 
First off, join the 21st Century and use 'HC parts ;-)
At the suggested speeds, the CD4000 series would be a better option. >You don't need to worry as much about the voltage regulation.

What ever it takes...
I just need a schematic.

Really, I'm not looking to count more than 15 objects per second...
 
In article <r9rt02h2ekrua8m6ims64kf8gvfoh8an9j@4ax.com>,
Jim Thompson <To-Email-Use-The-Envelope-Icon@My-Web-Site.com> wrote:
On 8 Mar 2006 06:36:02 -0800, "Silvester" <professor03@hotmail.com
wrote:

This is something I would like to build.
It will not be a timer, it will count objects passing a point.

I have several chips on order: 7447, 7448, 74192, etc...
I'm looking for something I can work up on a bread board and then
possibly put on a small project PC board from Radio Shack.

It will eventually go into a paintball marker that has been built to
look like the Pulse Rifle from Aliens.

First off, join the 21st Century and use 'HC parts ;-)
At the suggested speeds, the CD4000 series would be a better option. You
don't need to worry as much about the voltage regulation.
--
--
kensmith@rahul.net forging knowledge
 
In article <pan.2006.03.08.06.48.44.860765@comcast.net>,
Bob Monsen <bob_monsen@hotmail.com> wrote:
[....]
PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.
I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.

--
--
kensmith@rahul.net forging knowledge
 
In article <1141830557.591676.314030@j52g2000cwj.googlegroups.com>,
Silvester <professor03@hotmail.com> wrote:
Thanks, but I need a display.
Preferably 3 digits using 7-segment LEDs.

I have a schematic from an OLD Radio Shack book that uses a 555 to
drive a 7490 that dumps into either a 7447 or 7448 and then into a
7-segment LED. I'd like to get THIS to count down and it would be great
if I could get it to use DIP switches to preset a number using binary.

I'm going to use an IR LED emitter and receiver to count objects
passing a point (piantballs leaving the barrel or hopper).
Check out the 74HC192. It may be the right part for you.


--
--
kensmith@rahul.net forging knowledge
 
In article <1141831052.926208.121770@j33g2000cwa.googlegroups.com>,
Silvester <professor03@hotmail.com> wrote:
First off, join the 21st Century and use 'HC parts ;-)
At the suggested speeds, the CD4000 series would be a better option.
You don't need to worry as much about the voltage regulation.


What ever it takes...
I just need a schematic.

Really, I'm not looking to count more than 15 objects per second...
Do you want the up-down feature too at this time?

It makes a difference in what I'd suggest.


--
--
kensmith@rahul.net forging knowledge
 
Try here:

http://www.mallory-sonalert.com/catalog_start.htm

Navigate to tech data. They have (or used to) sample tones.
 
"sashi" <natrajbhat@gmail.com> wrote in message
news:1141724460.311551.309510@i39g2000cwa.googlegroups.com...
Hello folks, could u please send me the necessary material bout the
Front-End Design, supporting verification, validification,..........and
stuffs li that.
Google for "front end engineering design" and you can read various
descriptions ... none of which are a basic definition but after some reading
you will have a grasp of the technique.
 
On Wed, 08 Mar 2006 15:11:19 +0000, Ken Smith wrote:

In article <pan.2006.03.08.06.48.44.860765@comcast.net>,
Bob Monsen <bob_monsen@hotmail.com> wrote:
[....]
PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.
I don't know about the larger PICs, but for the 12 and 16 series, the call
stack is in hardware, and is not accessible to the programmer (it is also
limited to 8 calls, and wraps. Sigh...).

--
Regards,
Bob Monsen

If my theory of relativity proves to be correct, Germany will claim me
a German, and France will claim me a citizen of the world. However, if
it proves wrong, France will say IĄÇm a German, and Germany will say
that IĄÇm a jew.
Albert Einstein (1879 - 1955)
 
"Bob Monsen" <rcsurname@comcast.net> wrote in message
news:pan.2006.03.08.21.53.12.302275@comcast.net...
On Wed, 08 Mar 2006 15:11:19 +0000, Ken Smith wrote:

In article <pan.2006.03.08.06.48.44.860765@comcast.net>,
Bob Monsen <bob_monsen@hotmail.com> wrote:
[....]
PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that
ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your
timed
routines will be harder to code.


I don't know about the larger PICs, but for the 12 and 16 series, the
call
stack is in hardware, and is not accessible to the programmer (it is
also
limited to 8 calls, and wraps. Sigh...).
The 18 chips, have larger stacks. Typically perhaps 20 deep (still not
large to handle anything other than call/return operations). You can also
access the 'top of stack' value, and the stack pointer. This allows you to
write a software stack, to extend the existing stack if required. However
it takes several instructions to access a single value (typically three
read or write operations on the larger chips - the stack is 21 bits wide
on these), then the I/O to the pointer.

Best Wishes
 
"Ken Smith" <kensmith@green.rahul.net> a écrit dans le message de news:
dums6n$3fl$2@blue.rahul.net...
In article <pan.2006.03.08.06.48.44.860765@comcast.net>,
Bob Monsen <bob_monsen@hotmail.com> wrote:
[....]
PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.
Yes, push and pop instructions do not exist on pic MCUs, they have to
be made by software.
Otherwise, cheating with stack return values is a good assembler trick,
but it would be risky to use it with a high-level language as C because
low-level registers are controlled by compiler.

Bruno
 
In article <440f63e4$0$6645$8fcfb975@news.wanadoo.fr>,
BrunoG <noreply@micro-examples.com> wrote:
"Ken Smith" <kensmith@green.rahul.net> a écrit dans le message de news:
dums6n$3fl$2@blue.rahul.net...
In article <pan.2006.03.08.06.48.44.860765@comcast.net>,
Bob Monsen <bob_monsen@hotmail.com> wrote:
[....]
PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.


Yes, push and pop instructions do not exist on pic MCUs, they have to
be made by software.
Otherwise, cheating with stack return values is a good assembler trick,
but it would be risky to use it with a high-level language as C because
low-level registers are controlled by compiler.
Some of the 8051 C compilers have special "not really C" stuff added to
them to make such stuff safe to do. They usually appear as some sort of
magic variable.



--
--
kensmith@rahul.net forging knowledge
 
["Followup-To:" header set to sci.electronics.misc.]
On 2006-03-08, Ken Smith <kensmith@green.rahul.net> wrote:
In article <pan.2006.03.08.06.48.44.860765@comcast.net>,
Bob Monsen <bob_monsen@hotmail.com> wrote:
[....]
PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.
thatr method has disadvantages too, what if the routine that's being called
should be uninterruptable?

Bye.
Jasen
 
In article <3dcc.440fb6e3.7d1c1@clunker.homenet>,
Jasen Betts <jasen@free.net.nz> wrote:
On 2006-03-08, Ken Smith <kensmith@green.rahul.net> wrote:
In article <pan.2006.03.08.06.48.44.860765@comcast.net>,
Bob Monsen <bob_monsen@hotmail.com> wrote:
[....]
PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.

thatr method has disadvantages too, what if the routine that's being called
should be uninterruptable?
RoutineName:
CLR EA
... etc ...



--
--
kensmith@rahul.net forging knowledge
 
On Tue, 07 Mar 2006 03:12:08 GMT, "Brad Velander"
<bveland@SpamThis.com> wrote:

You know what, I really don't get where all of you idiots start making up
your own rules and telling others that they have follow them? Have you
actually read the Usenet FAQs? Seemingly not because they refer specifically
to the behavoir that you are demonstrating and they directly refute your
"rules". There are no rules, get it idiot? So take the gist of people's
posts and reply to them or not, at your discretion. Don't try imposing your
rules where they don't belong and requested.

As for your comment about multi-posting, sure I agree it is legitimate
in some cases. However there are too many alter-trolls out there that will
also complain about that, seen it often enough. So where does that leave the
less initiated, at the mercy of the whole lot of you that make up your own
rules and try shoving them down everyone's throats.
---
All newsgroups evolve and develop a culture which suits most of the
"members" of the various groups.

On the sci.electronics.* groups and on
alt.binaries.schematics.electronic we have evolved to the point
where most of us who have been here for a while generally bottom
post, in-line post where it's appropriate, trim prior posts for
context in replies, and crosspost instead of multi-posting since
that makes life easy for all of us.

It works for us, and when anyone posts here and obviously hasn't
taken the time to learn the culture before barging in with a badly
malformed reply to a post, they're usually told, gently at first,
what the customs are here.

Then there are always the antagonistic types, like you, who come
barreling in here and, with their first or second post, try to upset
things by proclaiming that there should be no rules here. The
laughable part of that is that you want _that_ to be the rule, LOL,
and that everyone should kow-tow to your desires. Can you
understand how idiotic that is and what an untenable position it
puts you in?

--
John Fields
Professional Circuit Designer
 
On Tue, 14 Mar 2006 07:57:56 -0600, John Fields wrote:
On Tue, 07 Mar 2006 03:12:08 GMT, "Brad Velander"

You know what, I really don't get where all of you idiots start making up
your own rules and telling others that they have follow them?
....
Then there are always the antagonistic types, like you, who come
barreling in here and, with their first or second post, try to upset
things by proclaiming that there should be no rules here. The
laughable part of that is that you want _that_ to be the rule, LOL,
and that everyone should kow-tow to your desires. Can you
understand how idiotic that is and what an untenable position it
puts you in?
Probably not. ;-)

Cheers!
Rich
 
In article <Xns9776C01FBED6Creyuhdfghdfy@130.133.1.4>,
Joe Soap <me@privacy.net> wrote:
In response to what <cs_posting@hotmail.com> posted in
news:1140978884.155392.113690@v46g2000cwv.googlegroups.com:

Well, if you had a fast scope, and a pulse generator, and pulled the
end out of the breaker box and drove it like an RF transmission line,
you might learn something by plugging a simple "nightlight" load into
each outlet while watching the scope.

Or maybe use a Time Domain Reflectometer.
And just what is that, and what does it do?

Thanks,

David
 
Plug a large load like a hair blower into the plug, turn on and measure the
voltage with a digital voltmeter. Plug with highest voltage should be the
first.


"David Combs" <dkcombs@panix.com> wrote in message
news:dv9351$7h1$1@reader2.panix.com...
In article <Xns9776C01FBED6Creyuhdfghdfy@130.133.1.4>,
Joe Soap <me@privacy.net> wrote:
In response to what <cs_posting@hotmail.com> posted in
news:1140978884.155392.113690@v46g2000cwv.googlegroups.com:

Well, if you had a fast scope, and a pulse generator, and pulled the
end out of the breaker box and drove it like an RF transmission line,
you might learn something by plugging a simple "nightlight" load into
each outlet while watching the scope.

Or maybe use a Time Domain Reflectometer.

And just what is that, and what does it do?

Thanks,

David
 
In response to what Jeff <jrw8888@yahoo.com> posted in news:4H%Rf.566845
$qk4.181980@bgtnsc05-news.ops.worldnet.att.net:

Or maybe use a Time Domain Reflectometer.

And just what is that, and what does it do?
If you type "Time Domain Reflectometer" into the Googlebox, and hit Return,
all will be revealed.

--
Joe Soap.
JUNK is stuff that you keep for 20 years,
then throw away a week before you need it.
 

Welcome to EDABoard.com

Sponsor

Back
Top