Chip with simple program for Toy

Spehro Pefhany · Feb 27, 2009

On Tue, 24 Feb 2009 08:17:20 -0500, the renowned "jamesgangnc"
<james@nospam.com> wrote:

I'm ok with fixing and adapting circuits but not so good with design. I've
come up with an electronic switch circuit but I think it could use
improvement. The goal is to turn on a 12v relay with a switch that is
closed when off and open when on. The switch also has to have one leg
grounded. It's a pressure switch with a single terminal. I also want the
relay to stay closed (on) for a couple minutes when the switch goes from on
(open) to off (closed). Here's what I've got now and it does work. But I
had to use a pretty big capacitor and I'm still only getting about a minute
of delay when going to the off state. Because I can't make the 10k resistor
any bigger. I'm thinking that it is likely possible to get a longer delay
and do it with a smaller capacitor if I was better at designing this. The
other flaw is that this slowly lowers the voltage to the relay until it
drops. The relay stays pulled to about 3 to 4 volts. I also suspect there
is a better way to keep it fully on until the rc timer expires. Thanks in
advance for any suggestions

http://home.earthlink.net/~jamesgangnc/schematic.jpg

Here you go, my one 555 design for 2009:-

VCC
+
| 1N4005
+---+------+--+
VCC | | | | | |
+ | | | | o /o
| | | - C| /
| | | ^ C| /
.-. .-----------. | C| o
1K0| | | 4 8 | | | |
| | | | | |
'-' +-----| 6 | | |
| 1N4148 | | 3|-+--+
+---->|-----+------+-----| 2 |
| | | | TLC555 |
| | | | 7 |-
\ o | + .-. | |
\ ### | | | 1 5 |-
\. --- | | '-----------'
o 100uF | '-' |
| | | 1M5 |
| | | |
=== === === ===
GND GND GND GND

Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

John Fields · Feb 27, 2009

On Thu, 26 Feb 2009 15:51:15 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 13:35:10 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 08:45:47 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 10:32:55 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 09:14:12 -0600, John Fields
jfields@austininstruments.com> wrote:

---
But... something esle was running around in my head and here it is:
a _much, much_ better way to do it, Duh...

Or just...

+V>-----------+--------+-----+----+--------+
| |
[1M] [COIL]
| |
| e
____ | / -----b pnp darlington or
O O---+------------------/ c low threshold pfet
| | |
| [68ľF] |
| | |
GND>---+------+--------+-----+-------------+

---
Huh???

RTFM

JF

Keep working on your 555 thing. If you add enough parts, you may
eventually get it right.

---
Maybe, but you certainly don't have any room to criticize, what with the
paucity of parts on that abomination above.

Anyway, I opted out of the 555 solution and went for a comparator.

JF

John Fields · Feb 27, 2009

On Thu, 26 Feb 2009 16:19:20 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 18:08:03 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 12:48:34 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

+V>-----------+--------+-----+----+--------+
| |
[10k] [COIL]
| |
| d
____ | diode |
O O---+----ak--+-----+----------g-| nfet
|>>> | | | |
| 100uF ~1M s
| | | |
GND>---+---------------+-----+-------------+

Cute.

Wimpy contact release and consistency, though.

JF

Probably good enough for lots of apps.

---
Sure; it's a switch debouncer.

JF

krw · Feb 27, 2009

In article <plreq4ld0sglrav4qje96alvjiek2n8vh9@4ax.com>,
jjlarkin@highNOTlandTHIStechnologyPART.com says...>

On Thu, 26 Feb 2009 22:30:46 -0600, krw <krw@att.bizzzzzzzzzzz> wrote:

On Thu, 26 Feb 2009 20:24:11 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 15:46:00 -0600, krw <krw@att.zzzzzzzzz> wrote:

In article <UTDpl.1892$tw4.1160@nwrddc01.gnilink.net>,
bogusabdsqy@verizon.net says...
Rich Grise wrote:
On Thu, 26 Feb 2009 06:33:21 +0000, James Arthur wrote:
...
.SBTTL IRQ6 SERVICE

; The HITLOCK mechanism enforces a minimum irq-to-irq delay so
^^^^^^^^^^

IRQ-to-IRQ. There is no "irq". ;-)

Cheers!
Rich

Translating the original I paused at that line and pondered
nearly a full second, flipping it back and forth. It could
go either way.

IRQ_EN, IRQ1, or IRQ_HANDLER would certainly get capitals,
being actual hardware or software elements.

I wouldn't. To aid readability they'd be IRQ_En, IRQ1,
IRQ_Handler, or even InterruptHandler on my schematics, VHDL, and
embedded code.

Sorry, they violate the 6-character symbol limit.

Six characters? Only crappy tools had such draconian restrictions
thirty years ago.

Do I have to give all the money back?

For your coding transgressions, YES! ;-)

John Fields · Feb 27, 2009

On Thu, 26 Feb 2009 18:11:32 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 19:11:49 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 12:50:56 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 19:28:44 GMT, Rich Grise <rich@example.net> wrote:

On Thu, 26 Feb 2009 17:13:40 +0000, James Arthur wrote:
...
Maybe I misunderstood,

Nope.

but wasn't the goal to engage a
relay when a switch opens, then release the relay a minute
or two or three after the switch re-closes?

Yup:
"The goal is to turn on a 12v relay with a switch that is closed when off
and open when on."

O frabjous day! Callooh! Callay! Both Johns have scresed one up today!
;-D

The original description wasn't a model of clarity.

---
Onward through the fog. Seems a couple of us got it, you not included,
first time out.
---

But if you keep score and rejoice in mistakes, enjoy.

---
Oh, my... how passive aggressive.

A guilt trip you'd like to have laid on us for finding "the Larkin" at
fault?

It's not about rejoicing in mistakes, its about rejoicing in catching
those who profess to be free from making mistakes and, when they do,
blaming it on someone else.

I make mistakes all the time, some here. And I freely admit the ones
that are obvious. We just sometimes disagree on what's actually a
mistake.

Your: "The original description wasn't a model of clarity." is a prime
example, since you blamed the OP for _your_ inability to understand what
he was talking about, while at least two of us did.

JF

Get a life. You're turning into an old hen, strutting and clucking.

If I misunderstood the OP's polarities, so what?

---
You didn't just misunderstand the polarities, you misunderstood the
circuit's raison d'ętre.

Big difference.

Besides, you're the one who's always preaching about being careful,
checking your work, etc., etc., etc., so it seems sort of hypocritical
that you'd give this app a lick and a promise.
---

Get a life.

---
Translation "Get out of my face."

Even if mine doesn't please you, it does me, which is what matters.

JF

John Fields · Feb 27, 2009

On Thu, 26 Feb 2009 18:20:34 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 17:25:21 -0700, Jim Thompson
To-Email-Use-The-Envelope-Icon@My-Web-Site.com> wrote:

You threw stones at John F, then posted a very soft transition
solution... did you not?

I called him an old hen, which is pretty accurate.

---
That was later on, and it isn't accurate at all.

What you like to do is try to belittle anyone who catches one of your
errors in an attempt to make their position questionable and therefore
trivialize the error.

Typical cheater tactics.
---

What's wrong with
soft turnoff of a relay? The armature stays seated until it doesn't.

---
And if it leaves the contact slowly and it's breaking DC???
---

Hey, post a relay delay circuit of your own and quit clucking. You're
turning into the village gossip.

---
See?

JF

John Fields · Feb 27, 2009

On Fri, 27 Feb 2009 05:47:19 -0800 (PST), speff <spehro@gmail.com>
wrote:

Here you go, my one 555 design for 2009:-

VCC
+
| 1N4005
+---+------+--+
VCC | | | | | |
+ | | | | o /o
| | | - C| /
| | | ^ C| /
.-. .-----------. | C| o
1K0| | | 4 8 | | | |
| | | | | |
'-' +-----| 6 | | |
| 1N4148 | | 3|-+--+
+---->|-----+------+-----| 2 |
| | | | TLC555 |
| | | | 7 |-
\ o | + .-. | |
\ ### | | | 1 5 |-
\. --- | | '-----------'
o 100uF | '-' |
| | | 1M5 |
| | | |
=== === === ===
GND GND GND GND

---
Clever.

Damn fine use of the internal divider and the output sink.

Best one yet!

JF

speff · Feb 27, 2009

On Feb 24, 8:17 am, "jamesgangnc" <ja...@nospam.com> wrote:

I'm ok with fixing and adapting circuits but not so good with design. I've
come up with an electronic switch circuit but I think it could use
improvement. The goal is to turn on a 12v relay with a switch that is
closed when off and open when on. The switch also has to have one leg
grounded. It's a pressure switch with a single terminal. I also want the
relay to stay closed (on) for a couple minutes when the switch goes from on
(open) to off (closed). Here's what I've got now and it does work. But I
had to use a pretty big capacitor and I'm still only getting about a minute
of delay when going to the off state. Because I can't make the 10k resistor
any bigger. I'm thinking that it is likely possible to get a longer delay
and do it with a smaller capacitor if I was better at designing this. The
other flaw is that this slowly lowers the voltage to the relay until it
drops. The relay stays pulled to about 3 to 4 volts. I also suspect there
is a better way to keep it fully on until the rc timer expires. Thanks in
advance for any suggestions

http://home.earthlink.net/~jamesgangnc/schematic.jpg

(posted from google groups since it has not appeared after being sent
twice from
Forte)

Here you go, my one 555 design for 2009:-

VCC
+
| 1N4005
+---+------+--+
VCC | | | | | |
+ | | | | o /o
| | | - C| /
| | | ^ C| /
.-. .-----------. | C| o
1K0| | | 4 8 | | | |
| | | | | |
'-' +-----| 6 | | |
| 1N4148 | | 3|-+--+
+---->|-----+------+-----| 2 |
| | | | TLC555 |
| | | | 7 |-
\ o | + .-. | |
\ ### | | | 1 5 |-
\. --- | | '-----------'
o 100uF | '-' |
| | | 1M5 |
| | | |
=== === === == GND GND GND GND

Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the
reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

John Larkin · Feb 27, 2009

On Fri, 27 Feb 2009 06:42:57 -0600, John Fields
<jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 15:51:15 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 13:35:10 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 08:45:47 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 10:32:55 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 09:14:12 -0600, John Fields
jfields@austininstruments.com> wrote:

---
But... something esle was running around in my head and here it is:
a _much, much_ better way to do it, Duh...

Or just...

+V>-----------+--------+-----+----+--------+
| |
[1M] [COIL]
| |
| e
____ | / -----b pnp darlington or
O O---+------------------/ c low threshold pfet
| | |
| [68ľF] |
| | |
GND>---+------+--------+-----+-------------+

---
Huh???

RTFM

JF

Keep working on your 555 thing. If you add enough parts, you may
eventually get it right.

Maybe, but you certainly don't have any room to criticize, what with the
paucity of parts on that abomination above.

"Paucity of parts"? I'm trying to come up with the simplest circuit
that will work, and you're trying to come up with the most complex
one. Different design goal.

John

John Larkin · Feb 27, 2009

On Fri, 27 Feb 2009 07:43:27 -0600, John Fields
<jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 18:11:32 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 19:11:49 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 12:50:56 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 19:28:44 GMT, Rich Grise <rich@example.net> wrote:

On Thu, 26 Feb 2009 17:13:40 +0000, James Arthur wrote:
...
Maybe I misunderstood,

Nope.

but wasn't the goal to engage a
relay when a switch opens, then release the relay a minute
or two or three after the switch re-closes?

Yup:
"The goal is to turn on a 12v relay with a switch that is closed when off
and open when on."

O frabjous day! Callooh! Callay! Both Johns have scresed one up today!
;-D

The original description wasn't a model of clarity.

---
Onward through the fog. Seems a couple of us got it, you not included,
first time out.
---

But if you keep score and rejoice in mistakes, enjoy.

---
Oh, my... how passive aggressive.

A guilt trip you'd like to have laid on us for finding "the Larkin" at
fault?

It's not about rejoicing in mistakes, its about rejoicing in catching
those who profess to be free from making mistakes and, when they do,
blaming it on someone else.

I make mistakes all the time, some here. And I freely admit the ones
that are obvious. We just sometimes disagree on what's actually a
mistake.

Your: "The original description wasn't a model of clarity." is a prime
example, since you blamed the OP for _your_ inability to understand what
he was talking about, while at least two of us did.

JF

Get a life. You're turning into an old hen, strutting and clucking.

If I misunderstood the OP's polarities, so what?

---
You didn't just misunderstand the polarities, you misunderstood the
circuit's raison d'ętre.

Ooh, French.

Big difference.

Besides, you're the one who's always preaching about being careful,
checking your work, etc., etc., etc., so it seems sort of hypocritical
that you'd give this app a lick and a promise.
---

Get a life.

---
Translation "Get out of my face."

Even if mine doesn't please you, it does me, which is what matters.

JF

Yup, you're a real beauty.

John

John Larkin · Feb 27, 2009

On Fri, 27 Feb 2009 07:32:36 -0600, krw <krw@att.zzzzzzzzz> wrote:

In article <plreq4ld0sglrav4qje96alvjiek2n8vh9@4ax.com>,
jjlarkin@highNOTlandTHIStechnologyPART.com says...
On Thu, 26 Feb 2009 22:30:46 -0600, krw <krw@att.bizzzzzzzzzzz> wrote:

On Thu, 26 Feb 2009 20:24:11 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 15:46:00 -0600, krw <krw@att.zzzzzzzzz> wrote:

In article <UTDpl.1892$tw4.1160@nwrddc01.gnilink.net>,
bogusabdsqy@verizon.net says...
Rich Grise wrote:
On Thu, 26 Feb 2009 06:33:21 +0000, James Arthur wrote:
...
.SBTTL IRQ6 SERVICE

; The HITLOCK mechanism enforces a minimum irq-to-irq delay so
^^^^^^^^^^

IRQ-to-IRQ. There is no "irq". ;-)

Cheers!
Rich

Translating the original I paused at that line and pondered
nearly a full second, flipping it back and forth. It could
go either way.

IRQ_EN, IRQ1, or IRQ_HANDLER would certainly get capitals,
being actual hardware or software elements.

I wouldn't. To aid readability they'd be IRQ_En, IRQ1,
IRQ_Handler, or even InterruptHandler on my schematics, VHDL, and
embedded code.

Sorry, they violate the 6-character symbol limit.

Six characters? Only crappy tools had such draconian restrictions
thirty years ago.

Do I have to give all the money back?

For your coding transgressions, YES! ;-)

I like...

Flat structures

Everything global

Simple state machines; no RTOS tricks

Static memory assignment

Single source file

Monolithic assembly; no libs, no includes, no linker
(except for the thing that pokes in Xilinx configs)

Manual source control

Minimal abstraction, a few macros at most

Extensive program documentation *in* the source file

Mimimal, archived tool set; in my case, Crimson Editor, C32 assembler,
and a few homebrew utilities.

Lots of correct and relevant comments, based on the premise that no
code is self-documenting.

Programs managed and released just like any other engineering
document, by rev letter; firmware installed by manufacturing just like
hardware.

The process is fast to develop, fast to execute (as in microseconds),
easy to do and maintain, and produces bug-free, profitable products.
What's wrong with that?

John

Jim Thompson · Feb 27, 2009

On Fri, 27 Feb 2009 07:00:45 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Fri, 27 Feb 2009 06:42:57 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 15:51:15 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 13:35:10 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 08:45:47 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 10:32:55 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 09:14:12 -0600, John Fields
jfields@austininstruments.com> wrote:

---
But... something esle was running around in my head and here it is:
a _much, much_ better way to do it, Duh...

Or just...

+V>-----------+--------+-----+----+--------+
| |
[1M] [COIL]
| |
| e
____ | / -----b pnp darlington or
O O---+------------------/ c low threshold pfet
| | |
| [68ľF] |
| | |
GND>---+------+--------+-----+-------------+

---
Huh???

RTFM

JF

Keep working on your 555 thing. If you add enough parts, you may
eventually get it right.

Maybe, but you certainly don't have any room to criticize, what with the
paucity of parts on that abomination above.

"Paucity of parts"? I'm trying to come up with the simplest circuit
that will work, and you're trying to come up with the most complex
one. Different design goal.

John

krw · Feb 27, 2009

In article <250gq4hrqa3jq57lfvj2o52v0cpcirripi@4ax.com>,
jjlarkin@highNOTlandTHIStechnologyPART.com says...>

On Fri, 27 Feb 2009 07:32:36 -0600, krw <krw@att.zzzzzzzzz> wrote:

In article <plreq4ld0sglrav4qje96alvjiek2n8vh9@4ax.com>,
jjlarkin@highNOTlandTHIStechnologyPART.com says...
On Thu, 26 Feb 2009 22:30:46 -0600, krw <krw@att.bizzzzzzzzzzz> wrote:

On Thu, 26 Feb 2009 20:24:11 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 15:46:00 -0600, krw <krw@att.zzzzzzzzz> wrote:

In article <UTDpl.1892$tw4.1160@nwrddc01.gnilink.net>,
bogusabdsqy@verizon.net says...
Rich Grise wrote:
On Thu, 26 Feb 2009 06:33:21 +0000, James Arthur wrote:
...
.SBTTL IRQ6 SERVICE

; The HITLOCK mechanism enforces a minimum irq-to-irq delay so
^^^^^^^^^^

IRQ-to-IRQ. There is no "irq". ;-)

Cheers!
Rich

Translating the original I paused at that line and pondered
nearly a full second, flipping it back and forth. It could
go either way.

IRQ_EN, IRQ1, or IRQ_HANDLER would certainly get capitals,
being actual hardware or software elements.

I wouldn't. To aid readability they'd be IRQ_En, IRQ1,
IRQ_Handler, or even InterruptHandler on my schematics, VHDL, and
embedded code.

Sorry, they violate the 6-character symbol limit.

Six characters? Only crappy tools had such draconian restrictions
thirty years ago.

Do I have to give all the money back?

For your coding transgressions, YES! ;-)

I like...

Flat structures

Fine. ASCII, preferably.

Everything global

Ick! Too much chance for screw-up. A simplified OO approach is
far safer.

Simple state machines; no RTOS tricks

Agreed. State machines are simple. A common structure helps even
more.

Static memory assignment

Explain?

Single source file

Ick! Reuse is important to me. Once I have a module correct I can
concentrate on other things.

Monolithic assembly; no libs, no includes, no linker
(except for the thing that pokes in Xilinx configs)

Ick! (see above) How do you do FPGAs? Single file? <choke> I
try to limit VHDL to 1000 lines. If a module is over that it's not
designed well enough. Assembly I limit to about two pages, a
quarter of which tends to be header/descriptive comments.

Manual source control

I like MAKEs, though I've been converted to CVS, and the like.
I'll likely fight it for my next project though.

Minimal abstraction, a few macros at most

Again, macros, functions, procedures, etc. are not only good for
reuse, they're important for organization and readability.

Extensive program documentation *in* the source file

Agreed! It's hard enough to keep documentation and code in step
when they're in the same file. External documentation should be in
the form of a high level functional spec rather than
implementation. Where this breaks down is in very large designs,
though the concept still holds, just pushed further down the food
chain.

Mimimal, archived tool set; in my case, Crimson Editor, C32 assembler,
and a few homebrew utilities.

This si fine for very simple tools. It gets much harder with FPGAs
and impossible with ASICs. The larger the project the harder this
is to do. How do you handle schematics (one reason I favor VHDL
over schematics, BTW)?

Lots of correct and relevant comments, based on the premise that no
code is self-documenting.

Agreed! Mostly so I remember what I did the next week. ;-) I also
do the high level comments and flow (written in the header) before
the code so I can organize the work to be done in that module.

Programs managed and released just like any other engineering
document, by rev letter; firmware installed by manufacturing just like
hardware.

Not sure I follow exactly what you're saying here. In general,
manufacturing puts the boot loaders on the boards when they're
made. The functional code is flashed at final assembly (during
ICT, ideally).

The process is fast to develop, fast to execute (as in microseconds),
easy to do and maintain, and produces bug-free, profitable products.
What's wrong with that?

Nothing is wrong with the end. I don't agree with all of your
means to that end. Your process certainly WOULD NOT work in a large
project. Though I've had my fill of large projects. As an
engineer, they suck.

John Fields · Feb 27, 2009

On Fri, 27 Feb 2009 07:00:45 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Fri, 27 Feb 2009 06:42:57 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 15:51:15 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 13:35:10 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 08:45:47 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 10:32:55 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 09:14:12 -0600, John Fields
jfields@austininstruments.com> wrote:

---
But... something esle was running around in my head and here it is:
a _much, much_ better way to do it, Duh...

Or just...

+V>-----------+--------+-----+----+--------+
| |
[1M] [COIL]
| |
| e
____ | / -----b pnp darlington or
O O---+------------------/ c low threshold pfet
| | |
| [68ľF] |
| | |
GND>---+------+--------+-----+-------------+

---
Huh???

RTFM

JF

Keep working on your 555 thing. If you add enough parts, you may
eventually get it right.

Maybe, but you certainly don't have any room to criticize, what with the
paucity of parts on that abomination above.

"Paucity of parts"? I'm trying to come up with the simplest circuit
that will work, and you're trying to come up with the most complex
one. Different design goal.

---
Well, I'm trying to come up with the simplest circuit which will work
_reliably_, which is a bit different from just working.

JF

John Fields · Feb 27, 2009

On Fri, 27 Feb 2009 07:02:37 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

You didn't just misunderstand the polarities, you misunderstood the
circuit's raison d'ętre.

Ooh, French.

---
Yeah, just like 'soufflé'.

So what?
---

Big difference.

Besides, you're the one who's always preaching about being careful,
checking your work, etc., etc., etc., so it seems sort of hypocritical
that you'd give this app a lick and a promise.
---

Get a life.

---
Translation "Get out of my face."

Even if mine doesn't please you, it does me, which is what matters.

JF

Yup, you're a real beauty.

---
You ain't...

JF

John Larkin · Feb 27, 2009

On Fri, 27 Feb 2009 10:13:58 -0600, John Fields
<jfields@austininstruments.com> wrote:

On Fri, 27 Feb 2009 07:00:45 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Fri, 27 Feb 2009 06:42:57 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 15:51:15 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 13:35:10 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 08:45:47 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 10:32:55 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 09:14:12 -0600, John Fields
jfields@austininstruments.com> wrote:

---
But... something esle was running around in my head and here it is:
a _much, much_ better way to do it, Duh...

Or just...

+V>-----------+--------+-----+----+--------+
| |
[1M] [COIL]
| |
| e
____ | / -----b pnp darlington or
O O---+------------------/ c low threshold pfet
| | |
| [68ľF] |
| | |
GND>---+------+--------+-----+-------------+

---
Huh???

RTFM

JF

Keep working on your 555 thing. If you add enough parts, you may
eventually get it right.

Maybe, but you certainly don't have any room to criticize, what with the
paucity of parts on that abomination above.

"Paucity of parts"? I'm trying to come up with the simplest circuit
that will work, and you're trying to come up with the most complex
one. Different design goal.

---
Well, I'm trying to come up with the simplest circuit which will work
_reliably_, which is a bit different from just working.

JF

What's unreliable about either of my circuits? Neither does precise
timing, but this isn't an eximer laser or a picosecond-resolution ICCD
camera; it's a sump pump or something. The OP can always tweak the RC
until he's satisfied with the timing, or use a pot for the timing
resistor. The thing about a simple circuit is that he can grab a few
discrete parts from RatShack and connect them up quickly and easily.

Discretes are rugged and easy to use. The more complex a circuit, the
more bugs it could have, evidenced by the multiple times you corrected
your complex 555 thing.

Besides, circuit minimization is a fun game. Try it sometime.

Now *these* need serious timing...

http://www.cymer.com/products/product_detail.cfm?key=33

http://www.andor.com/scientific_cameras/istar/

https://lasers.llnl.gov/

John

Vladimir Vassilevsky · Feb 27, 2009

John Larkin wrote:

I like...

Flat structures
Everything global
Simple state machines; no RTOS tricks
Static memory assignment
Single source file
Monolithic assembly; no libs, no includes, no linker
(except for the thing that pokes in Xilinx configs)
Manual source control
Minimal abstraction, a few macros at most
Extensive program documentation *in* the source file
Mimimal, archived tool set; in my case, Crimson Editor, C32 assembler,
and a few homebrew utilities.
Lots of correct and relevant comments, based on the premise that no
code is self-documenting.
Programs managed and released just like any other engineering
document, by rev letter; firmware installed by manufacturing just like
hardware.
The process is fast to develop, fast to execute (as in microseconds),
easy to do and maintain, and produces bug-free, profitable products.
What's wrong with that?

Nothing wrong. This is a paradigm of the tiny projects and a one man
development teams.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

John Fields · Feb 27, 2009

On Fri, 27 Feb 2009 08:34:56 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Fri, 27 Feb 2009 10:13:58 -0600, John Fields
jfields@austininstruments.com> wrote:

On Fri, 27 Feb 2009 07:00:45 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Fri, 27 Feb 2009 06:42:57 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 15:51:15 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 13:35:10 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 08:45:47 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 10:32:55 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 26 Feb 2009 09:14:12 -0600, John Fields
jfields@austininstruments.com> wrote:

---
But... something esle was running around in my head and here it is:
a _much, much_ better way to do it, Duh...

Or just...

+V>-----------+--------+-----+----+--------+
| |
[1M] [COIL]
| |
| e
____ | / -----b pnp darlington or
O O---+------------------/ c low threshold pfet
| | |
| [68ľF] |
| | |
GND>---+------+--------+-----+-------------+

---
Huh???

RTFM

JF

Keep working on your 555 thing. If you add enough parts, you may
eventually get it right.

Maybe, but you certainly don't have any room to criticize, what with the
paucity of parts on that abomination above.

"Paucity of parts"? I'm trying to come up with the simplest circuit
that will work, and you're trying to come up with the most complex
one. Different design goal.

---
Well, I'm trying to come up with the simplest circuit which will work
_reliably_, which is a bit different from just working.

JF

What's unreliable about either of my circuits?

---
Well, one doesn't work at all like it's supposed to, and the other one
has a soft open, which is an invitation to disaster.
---

Besides, circuit minimization is a fun game. Try it sometime.

---
You're preaching to the choir.
---

Now *these* need serious timing...

http://www.cymer.com/products/product_detail.cfm?key=33

http://www.andor.com/scientific_cameras/istar/

https://lasers.llnl.gov/

---
Yeah, and???

JF

John Larkin · Feb 27, 2009

On Fri, 27 Feb 2009 10:04:24 -0600, krw <krw@att.zzzzzzzzz> wrote:

In article <250gq4hrqa3jq57lfvj2o52v0cpcirripi@4ax.com>,
jjlarkin@highNOTlandTHIStechnologyPART.com says...
On Fri, 27 Feb 2009 07:32:36 -0600, krw <krw@att.zzzzzzzzz> wrote:

In article <plreq4ld0sglrav4qje96alvjiek2n8vh9@4ax.com>,
jjlarkin@highNOTlandTHIStechnologyPART.com says...
On Thu, 26 Feb 2009 22:30:46 -0600, krw <krw@att.bizzzzzzzzzzz> wrote:

On Thu, 26 Feb 2009 20:24:11 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 26 Feb 2009 15:46:00 -0600, krw <krw@att.zzzzzzzzz> wrote:

In article <UTDpl.1892$tw4.1160@nwrddc01.gnilink.net>,
bogusabdsqy@verizon.net says...
Rich Grise wrote:
On Thu, 26 Feb 2009 06:33:21 +0000, James Arthur wrote:
...
.SBTTL IRQ6 SERVICE

; The HITLOCK mechanism enforces a minimum irq-to-irq delay so
^^^^^^^^^^

IRQ-to-IRQ. There is no "irq". ;-)

Cheers!
Rich

Translating the original I paused at that line and pondered
nearly a full second, flipping it back and forth. It could
go either way.

IRQ_EN, IRQ1, or IRQ_HANDLER would certainly get capitals,
being actual hardware or software elements.

I wouldn't. To aid readability they'd be IRQ_En, IRQ1,
IRQ_Handler, or even InterruptHandler on my schematics, VHDL, and
embedded code.

Sorry, they violate the 6-character symbol limit.

Six characters? Only crappy tools had such draconian restrictions
thirty years ago.

Do I have to give all the money back?

For your coding transgressions, YES! ;-)

I like...

Flat structures

Fine. ASCII, preferably.

Everything global

Ick! Too much chance for screw-up. A simplified OO approach is
far safer.

Safer? Once my stuff works, I can count on it not breaking. And I
haven't had a stack overflow in years.

Simple state machines; no RTOS tricks

Agreed. State machines are simple. A common structure helps even
more.

Static memory assignment

Explain?

Absolute assembly, ram variables all declared and nailed at assembly
time. Their memory address is right there in the listing.

Single source file

Ick! Reuse is important to me. Once I have a module correct I can
concentrate on other things.

My editor has advanced "copy" and "paste" features. I reuse code all
the time.

Monolithic assembly; no libs, no includes, no linker
(except for the thing that pokes in Xilinx configs)

Ick! (see above) How do you do FPGAs? Single file? <choke> I
try to limit VHDL to 1000 lines. If a module is over that it's not
designed well enough. Assembly I limit to about two pages, a
quarter of which tends to be header/descriptive comments.

Manual source control

I like MAKEs, though I've been converted to CVS, and the like.
I'll likely fight it for my next project though.

Minimal abstraction, a few macros at most

Again, macros, functions, procedures, etc. are not only good for
reuse, they're important for organization and readability.

Extensive program documentation *in* the source file

Agreed! It's hard enough to keep documentation and code in step
when they're in the same file. External documentation should be in
the form of a high level functional spec rather than
implementation. Where this breaks down is in very large designs,
though the concept still holds, just pushed further down the food
chain.

Mimimal, archived tool set; in my case, Crimson Editor, C32 assembler,
and a few homebrew utilities.

This si fine for very simple tools. It gets much harder with FPGAs
and impossible with ASICs. The larger the project the harder this
is to do. How do you handle schematics (one reason I favor VHDL
over schematics, BTW)?

FPGA configs are generated on the side, by my FPGA guy, usually a
top-level schematic and VHDL boxes. The Xilinx project is released as
a separate part number+rev from the uP firmware. I wrote a little
linker-like command-line program that builds a runtime image
(rom/flash file) from the assembler's absolute S28 output and one or
more Xilinx .RBT files. One batch file, GO.BAT, reassembles the source
and builds the final image. Typically takes a second or so to run.

Lots of correct and relevant comments, based on the premise that no
code is self-documenting.

Agreed! Mostly so I remember what I did the next week. ;-) I also
do the high level comments and flow (written in the header) before
the code so I can organize the work to be done in that module.

Programs managed and released just like any other engineering
document, by rev letter; firmware installed by manufacturing just like
hardware.

Not sure I follow exactly what you're saying here. In general,
manufacturing puts the boot loaders on the boards when they're
made. The functional code is flashed at final assembly (during
ICT, ideally).

Manufacturing does it all, from formally released files and
procedures. That may be an eprom or may be a flash procedure or may be
files installed on a drive. But it's never hacked or short-cut by
engineering, and the configuration of shipped products is absolutely
known. Bastard versions, like a wrong mix of code and FPGA configs,
don't happen.

The process is fast to develop, fast to execute (as in microseconds),
easy to do and maintain, and produces bug-free, profitable products.
What's wrong with that?

Nothing is wrong with the end. I don't agree with all of your
means to that end.

But the end is all that matters. Too many programmers, maybe most of
them, care about the means more than they care about the end. They
mainly want to play programming games.

Your process certainly WOULD NOT work in a large
project. Though I've had my fill of large projects. As an
engineer, they suck.

Yup. Part of the scheme for delivering reliable code is to restrict
the problem set. We do hard-embedded instrumentation, VME modules,
small embedded boxes, waveform generator type stuff. My methods
wouldn't scale to word processors or web browsers. But the OO methods
that make sense for them don't really make sense for a 6000 line
bare-metal ROM-based instrument controller program.

I got rid of my new Keithley DVMs, and wish I could return our new
Aeroflex spectrum anayzer, because they are both full of buggy,
nightmare code that the vendors are powerless to fix.

John

John Larkin · Feb 27, 2009

On Fri, 27 Feb 2009 10:42:52 -0600, Vladimir Vassilevsky
<antispam_bogus@hotmail.com> wrote:

John Larkin wrote:

I like...

Flat structures
Everything global
Simple state machines; no RTOS tricks
Static memory assignment
Single source file
Monolithic assembly; no libs, no includes, no linker
(except for the thing that pokes in Xilinx configs)
Manual source control
Minimal abstraction, a few macros at most
Extensive program documentation *in* the source file
Mimimal, archived tool set; in my case, Crimson Editor, C32 assembler,
and a few homebrew utilities.
Lots of correct and relevant comments, based on the premise that no
code is self-documenting.
Programs managed and released just like any other engineering
document, by rev letter; firmware installed by manufacturing just like
hardware.
The process is fast to develop, fast to execute (as in microseconds),
easy to do and maintain, and produces bug-free, profitable products.
What's wrong with that?

Nothing wrong. This is a paradigm of the tiny projects and a one man
development teams.

Two, usually. We do better work by interacting and checking one
anothers' work.

We are, after all, electronics design engineers, and we sell
functional hardware, not software. The uP and its code are *not* the
center of the show, they're just another support component that we
want to work reliably, like a power supply.

John

Chip with simple program for Toy

Spehro Pefhany

Guest

John Fields

Guest

John Fields

Guest

krw

Guest

John Fields

Guest

John Fields

Guest

John Fields

Guest

speff

Guest

John Larkin

Guest

John Larkin

Guest

John Larkin

Guest

Jim Thompson

Guest

krw

Guest

John Fields

Guest

John Fields

Guest

John Larkin

Guest

Vladimir Vassilevsky

Guest

John Fields

Guest

John Larkin

Guest

John Larkin

Guest

Log in

Welcome to EDABoard.com

Sponsor