magnetic field

[John_H]

"Silvester" <professor03@hotmail.com> wrote in message
news:1141738822.448393.96950@p10g2000cwp.googlegroups.com...

Electronics is not my field, so I scoured the internet to find counter
circuits, but none of what I found really hits my exact needs.


I'm looking for a 2 or 3 digit counter that will count down from a
predefined number to zero - with a RESET switch to send the count back
to
the max number.

From what little I know of binary, I firgure I could use DIP switches
to set
the maximum number that the count starts at - a bank of 8 DIP switches
gives me a max of 255.

I need to count objects passing a certain point and I figured I use a
LED emitter and receiver pair, probably IR.


Can any one offer me some help?

Silvester

You could use a simple CPLD - programmable logic - to implement your
function to even include a 7-segment display driver if you need. The $49
development board from Xilinx

http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=design_kit

should include everything you need to get a chip that does what you want.
If you wanted to buy the kit but not get into the details of logic design,
there are plenty of folks that could help, particularly at comp.arch.fpga
(even if it is a cpld).

You could use dip switches, 0-9 rotary swiches, even a "set" mode like on
your alarm clock though that method would lose its memory on power-cycle.

Logic design is fun these days.

 

[John Fields]

On Tue, 07 Mar 2006 17:08:41 GMT, "John_H" <johnhandwork@mail.com>
wrote:

Logic design is fun these days.

---
_Always_ has been, for me!

--
John Fields
Professional Circuit Designer

 

[Jasen Betts]

On 2006-03-05, Floatything <chrisknibbs@sinkthespamntlworld.com> wrote:

Every year, Shelly the tortoise gets lost or manages to escape the garden.
It can take days to find her. I would like to build a locating device so
that I can track her down.
The basic requirements are:

a) that the 'transmitter (transponder?) on the tortoise is as small as
possible.

b) that it can be made by an electronics numpty. I have basic soldering
skills, and can eventually work out a circuit diagram.

Telking Electronics (talkingelectronics.com.au) does kits and also publishes
schematics for a number of small transmitters... I think you need to pay to
see the schematics.

Bye.
Jasen

 

[Jasen Betts]

On 2006-03-07, Ken Smith <kensmith@green.rahul.net> wrote:

In article <440abe35$0$19703$8fcfb975@news.wanadoo.fr>,
BrunoG <noreply@micro-examples.com> wrote:
Hi,

I had many requests about pic timers, so that I wrote a little C example to
show how to make multiple non-blocking asynchronous delays with only one pic
timer :

http://www.micro-examples.com/public/microex-navig/doc/099-timers-delays.html


Is there something about a PIC that makes linked lists impractical?

depends on the PIC

The normal way to do this sort of thing is to only count away the shortest
time delay. The delays need to be in some sorted form for this to work so
a linked list is normally the way to go.

if there are potentially many, a heap may be better.

Bye.
Jasen

 

[Rich Grise]

On Mon, 06 Mar 2006 18:20:25 +0100, Ken wrote:

What exactly do you mean by an "oscillator-resonator"?
I looked over your schematic, and followed the
thread so far - but unless you really, really need to
have something that lets an LC tank "ring" all on its
on, and only kicks it again when the amplitude drops
down to some given point, this seems like an awful
lot of trouble to go to for a sine wave - you can do
THAT with a single transistor. What is it you're really
trying to do here?

Bob M.

HI Bob,
Good question:
One of the thing I am trying to do well.
I can only explain well using an analogy.
You get on a swing set, you generate enough energy so that you start swing
(oscillating) everutime you reach a peak value, you give yourself (or a
friend..) a small push to keep going the same amplitude.BUT if you keep
giving the same push everytime with the same strenght you did the first one,
you will reach a point where you will no longer get to go any higher, or
simply break and fall. In an oscillating mechanical system when you reach
that point, the machine simply over heat or break down. This is what I want
to do electrically.

You've just described an oscillator, almost perfectly. Try some of
these links - injecting a little energy each cycle is exactly what
oscillators do, and they go to the rails unless there's some kind of
negative feedback - the "Wein Bridge" (Wien?) is a good example of that:
http://www.google.com/search?hl=en&q=oscillator+tutorial

Cheers!
Rich

 

[J. Yazel]

On Mon, 06 Mar 2006 03:05:10 GMT, Christopher
<christopher@oldtemecula.com> wrote:

Hello Jack,
I have a circuit and PDF PC board layout that could be modified into
what you need, especially triggering off a low level lamp output. This
will be using a photo-transistor which is more sensitive. Also using a
low powered TLC555 gives you a CMOS Schmidt Trigger.

http://www.oldtemecula.com/theremin/rs-opticaltheremin/rs-opticaltheremin.htm

If you leave everything as I designed, it would pulse/buzz a small
speaker every flash of the dim lamp.
=======SNIP=========

Thanks very much. This looks very useful.

After a quick scan, I didn't see the photocell number. Do you have
it?

I'm going to drive an LED counter with it. I need to see when the
input lamp lights when I'm away and a rough count.

Thanks again.

Jack

 

[J. Yazel]

On Mon, 06 Mar 2006 12:17:06 -0600, John Fields
<jfields@austininstruments.com> wrote:

On Sun, 05 Mar 2006 12:01:58 -0500, J. Yazel <jyazel@ds.net> wrote:


I would like to find a schematic for a photocell feeding a schmidt
trigger (CMOS). This will input the light from a not-very-bright panel
lamp. It is also very slow speed (once-a-half-second).

Photovoltaic or photoresistive?
=================

I'm not familiar with the terms but if photoresistive indicates
a cell that acts as a resistor, that's what I'm thinking that I need.

If there is a generator cell that will trigger a CMOS Schmidt,
then maybe I could use that. I don't think that I could adapt
it to the input lamp since I don't have any way to measure
the lamp intensity (not smart enough in optics).

Thanks.

And thanks to all other the other responders.

Jack

 

[J. Yazel]

After a quick scan, I didn't see the photocell number. Do you have
it?

I found it. Sorry.

Jack

 

[The Real Andy]

On 7 Mar 2006 06:15:11 -0800, cbarn24050@aol.com wrote:

BrunoG wrote:
cbarn24050@aol.com> a écrit dans le message de news:
1141735663.356950.115790@e56g2000cwe.googlegroups.com...

BrunoG wrote:
Cbarn, I have nothing to defend. Your assumption about shortening this
code within 50 bytes may put beginners and newbies into confusion.
This is not the best service they can get from here.

Bruno
http://www.micro-examples.com/public/microex-navig/doc/099-timers-delays.html

Why would that confuse anyone?


They could believe that it is possible.
I'm afraid this discussion could bore other people, so if
you want to continue it, please give at least some technical argument
or discuss it in private :
http://www.micro-examples.com/forums/

Thanks,
Bruno

I allready gave you the algorithms, compile them and see for yourself.

In BrunoG's defence, what is being specified is no simple 50 line pic
assembler routine.

 

The Real Andy wrote:

On 7 Mar 2006 06:15:11 -0800, cbarn24050@aol.com wrote:


BrunoG wrote:
cbarn24050@aol.com> a écrit dans le message de news:
1141735663.356950.115790@e56g2000cwe.googlegroups.com...

BrunoG wrote:
Cbarn, I have nothing to defend. Your assumption about shortening this
code within 50 bytes may put beginners and newbies into confusion.
This is not the best service they can get from here.

Bruno
http://www.micro-examples.com/public/microex-navig/doc/099-timers-delays.html

Why would that confuse anyone?


They could believe that it is possible.
I'm afraid this discussion could bore other people, so if
you want to continue it, please give at least some technical argument
or discuss it in private :
http://www.micro-examples.com/forums/

Thanks,
Bruno

I allready gave you the algorithms, compile them and see for yourself.

In BrunoG's defence, what is being specified is no simple 50 line pic
assembler routine.

Well Andy I didnt say the whole program would be 50 bytes, just the
parts that gives you the functionality, I hate that word, you simply
cut and paste them into your existing program. 50 lines? oh no, 50
bytes, thats 25 lines max.

 

[BrunoG]

<cbarn24050@aol.com> a écrit dans le message de news:
1141774218.681222.134470@e56g2000cwe.googlegroups.com...

The Real Andy wrote:
In BrunoG's defence, what is being specified is no simple 50 line pic
assembler routine.

Well Andy I didnt say the whole program would be 50 bytes, just the
parts that gives you the functionality, I hate that word, you simply
cut and paste them into your existing program. 50 lines? oh no, 50
bytes, thats 25 lines max.

Good cbarn you are right, this time I do agree with you.

This is the same with only 7 lines :

http://www.micro-examples.com/public/microex-navig/doc/ultra-optimization.html

Thanks

Bruno

 

[Rich Grise]

On Wed, 08 Mar 2006 07:43:31 +1000, The Real Andy wrote:

On 7 Mar 2006 06:15:11 -0800, cbarn24050@aol.com wrote:
BrunoG wrote:
cbarn24050@aol.com> a écrit dans le message de news:

BrunoG wrote:
Cbarn, I have nothing to defend. Your assumption about shortening this
code within 50 bytes may put beginners and newbies into confusion.
This is not the best service they can get from here.

Bruno
http://www.micro-examples.com/public/microex-navig/doc/099-timers-delays.html

Why would that confuse anyone?

They could believe that it is possible.
I'm afraid this discussion could bore other people, so if
you want to continue it, please give at least some technical argument
or discuss it in private :
http://www.micro-examples.com/forums/

I allready gave you the algorithms, compile them and see for yourself.

In BrunoG's defence, what is being specified is no simple 50 line pic
assembler routine.

Not in a PIC, no. But oh, for the days of the Motorola 68HC05/08/11 timer -
you could do an arbitrary number of timings in about a dozen lines of
code, plus maybe five lines per timer.

I did two interleaved timers on an 8008 in about 1974 or 5 or so. It's
almost trivial - you have one main loop that's calibrated, and each pass
decrement each counter and test, then either change the bit or do a
NOP or as many as you need to not mess up the timing.

But the Motorola timer is a dream, once you figure out how to use it.

Cheers!
Rich

 

[Bill Bowden]

I can only explain well using an analogy.
You get on a swing set, you generate enough energy so that you start swing
(oscillating) everutime you reach a peak value, you give yourself (or a
friend..) a small push to keep going the same amplitude.BUT if you keep
giving the same push everytime with the same strenght you did the first one,
you will reach a point where you will no longer get to go any higher, or
simply break and fall. In an oscillating mechanical system when you reach
that point, the machine simply over heat or break down. This is what I want
to do electrically.

Well, you could use a L and C in parallel from the gate to ground of a
JFET. Wind a few turns of wire around the L and add a resistor in
series and connect the wire to ground and the other side of resistor to
the source of the JFET. Connect the drain to +V, turn it on and there
will be a nice sinewave at the gate. You can adjust the amplitude with
the resistor. Requires 4 parts plus battery.

-Bill

 

[Bob Monsen]

On Sun, 05 Mar 2006 11:30:56 +0100, BrunoG wrote:

Hi,

I had many requests about pic timers, so that I wrote a little C example to
show how to make multiple non-blocking asynchronous delays with only one pic
timer :

http://www.micro-examples.com/public/microex-navig/doc/099-timers-delays.html

Comments & questions are welcome

Bruno

One thing I don't like about this is that the callback happens at
interrupt level. This will force the callback user to lock his data
structures, and possibly cause interrupt latency problems if the 'user'
isn't careful about how long he keeps control in that callback.

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.

--
Regards,
Bob Monsen

Insanity: doing the same thing over and over again and expecting
different results.
Albert Einstein, (attributed)

 

[Deefoo]

<snip>

The fact is, writing program examples leads to make choices between their
clarity and effectiveness, and too much novelties in the same program may
muddle the user with a heavier source code.

Ah, how I agree with you. Did you ever look at an MFC example? You want to
know how to use printf and they point you to a huge MDI OLE database
application with streaming multimedia internet connectivity and what not.

--DF

 

[BrunoG]

"Bob Monsen" <rcsurname@comcast.net> a écrit dans le message de news:
pan.2006.03.08.06.48.44.860765@comcast.net...

On Sun, 05 Mar 2006 11:30:56 +0100, BrunoG wrote:


One thing I don't like about this is that the callback happens at
interrupt level. This will force the callback user to lock his data
structures, and possibly cause interrupt latency problems if the 'user'
isn't careful about how long he keeps control in that callback.

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.

Yes you are right, usual restrictions about timings & data within ISR
should be applied by user.

As you suggest, the user's function called by the interrupt may just set
a flag. The user will have to check it and reset it in the main loop.
With minor changes, the ISR can do it itself, instead of calling the
user's function.

Bruno
http://www.micro-examples.com/public/microex-navig/doc/099-timers-delays.html

 

[nospam]

"BrunoG" <noreply@micro-examples.com> wrote:

cbarn24050@aol.com> a écrit dans le message de news:
1141774218.681222.134470@e56g2000cwe.googlegroups.com...

The Real Andy wrote:
In BrunoG's defence, what is being specified is no simple 50 line pic
assembler routine.

Well Andy I didnt say the whole program would be 50 bytes, just the
parts that gives you the functionality, I hate that word, you simply
cut and paste them into your existing program. 50 lines? oh no, 50
bytes, thats 25 lines max.

Good cbarn you are right, this time I do agree with you.

This is the same with only 7 lines :

http://www.micro-examples.com/public/microex-navig/doc/ultra-optimization.html

Please. Stop digging a bigger hole for your self. There is a reason you
have not had a single positive comment about the example you posted.

 

[Ian Bell]

Bob Monsen wrote:

On Sun, 05 Mar 2006 11:30:56 +0100, BrunoG wrote:

Hi,

I had many requests about pic timers, so that I wrote a little C example
to show how to make multiple non-blocking asynchronous delays with only
one pic timer :


http://www.micro-examples.com/public/microex-navig/doc/099-timers-delays.html

Comments & questions are welcome

Bruno

One thing I don't like about this is that the callback happens at
interrupt level. This will force the callback user to lock his data
structures, and possibly cause interrupt latency problems if the 'user'
isn't careful about how long he keeps control in that callback.

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.

Absolutely right. What Bruno has done is to combine the scheduler and
despatcher into a single ISR. It would make better use of resources and
make the system more responsive if only the scheduler were in the ISR.

Ian

 

[Silvester]

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.

 

[Jim Thompson]

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 ;-)

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| E-mail Address at Website Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

It's what you learn, after you know it all, that counts.