Another Surplus Store Gone...

[John Larkin]

On Thu, 16 Jul 2020 12:14:59 -0700, John Robertson <spam@flippers.com>
wrote:

On 2020/07/16 8:30 a.m., jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 10:27:51 -0400, Ingvald44 <noone@nowhere.com
wrote:

On Thu, 16 Jul 2020 02:15:56 -0700 (PDT), Michael Terrell
terrell.michael.a@gmail.com> wrote:

They had a website and the sold on Ebay. The website was meci.com. they weren\'t overpriced, or they wouldn\'t have lasted 75years.

I think Fair Radio Sales in Lima OH is still aliive. Maybe not for
long though. I have bought lots of Mil surplus stuff from them.

I bought a 4FP7 CRT from them when I was a kid, a WWII radar display
tube. I recently emailed them, and they still have some! I got one
just for fun. It glows in the dark.


When you say it glows in the dark I hope you aren\'t glowing yourself!

The P7 phosphor has a fast blue component that energizes a slow (zinc
sulfide?) amber one. If you shine a light on it, it glows with some
decay time constant, roughly 30 seconds maybe. Nothing radioactive,
although there were surplus radioactive gadgets available when I was a
kid.

I recall when a surplus store in Toronto (1960s) was selling off old
foot X-ray machines - originally used in shoe stores!

Those were killers.

John ;-#)#

 

[John Larkin]

On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno. Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly. It\'s possible to do a bad FSM in hardware, too.

 

[John Larkin]

On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno. Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly. It\'s possible to do a bad FSM in hardware, too.

 

[John Larkin]

On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno. Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly. It\'s possible to do a bad FSM in hardware, too.

 

[Tom Gardner]

On 16/07/20 21:02, John Larkin wrote:

On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno. Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly.

Stunningly badly, due to a combination of poor tools
and cargo-cult use of processes and tools.

Example: if-then-else clauses nested 10 deep.

Example mantra: \"code is difficult to change, but
configurations are easy to change\". That lead to the
conditionals in the if clauses being constants defined
in a configuration file. Think about that, and weep.

Add those two together, throw in Rational Clearcase
source code (but not configuration constants) control,
and the result was grim in all respects.


> It\'s possible to do a bad FSM in hardware, too.

Yes, but it would be difficult to beat the
example above!

 

[Tom Gardner]

On 16/07/20 21:02, John Larkin wrote:

On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno. Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly.

Stunningly badly, due to a combination of poor tools
and cargo-cult use of processes and tools.

Example: if-then-else clauses nested 10 deep.

Example mantra: \"code is difficult to change, but
configurations are easy to change\". That lead to the
conditionals in the if clauses being constants defined
in a configuration file. Think about that, and weep.

Add those two together, throw in Rational Clearcase
source code (but not configuration constants) control,
and the result was grim in all respects.


> It\'s possible to do a bad FSM in hardware, too.

Yes, but it would be difficult to beat the
example above!

 

[Phil Hobbs]

On 2020-07-16 20:22, Tom Gardner wrote:

On 16/07/20 21:02, John Larkin wrote:
On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno.  Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly.

Stunningly badly, due to a combination of poor tools
and cargo-cult use of processes and tools.

Example: if-then-else clauses nested 10 deep.

Example mantra: \"code is difficult to change, but
configurations are easy to change\". That lead to the
conditionals in the if clauses being constants defined
in a configuration file. Think about that, and weep.

Add those two together, throw in Rational Clearcase
source code (but not configuration constants) control,
and the result was grim in all respects.


It\'s possible to do a bad FSM in hardware, too.

Yes, but it would be difficult to beat the
example above!

That sounds more like a logic-driven hairball rather than an actual FSM.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Phil Hobbs]

On 2020-07-16 20:22, Tom Gardner wrote:

On 16/07/20 21:02, John Larkin wrote:
On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno.  Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly.

Stunningly badly, due to a combination of poor tools
and cargo-cult use of processes and tools.

Example: if-then-else clauses nested 10 deep.

Example mantra: \"code is difficult to change, but
configurations are easy to change\". That lead to the
conditionals in the if clauses being constants defined
in a configuration file. Think about that, and weep.

Add those two together, throw in Rational Clearcase
source code (but not configuration constants) control,
and the result was grim in all respects.


It\'s possible to do a bad FSM in hardware, too.

Yes, but it would be difficult to beat the
example above!

That sounds more like a logic-driven hairball rather than an actual FSM.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Phil Hobbs]

On 2020-07-16 20:22, Tom Gardner wrote:

On 16/07/20 21:02, John Larkin wrote:
On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno.  Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly.

Stunningly badly, due to a combination of poor tools
and cargo-cult use of processes and tools.

Example: if-then-else clauses nested 10 deep.

Example mantra: \"code is difficult to change, but
configurations are easy to change\". That lead to the
conditionals in the if clauses being constants defined
in a configuration file. Think about that, and weep.

Add those two together, throw in Rational Clearcase
source code (but not configuration constants) control,
and the result was grim in all respects.


It\'s possible to do a bad FSM in hardware, too.

Yes, but it would be difficult to beat the
example above!

That sounds more like a logic-driven hairball rather than an actual FSM.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[whit3rd]

On Thursday, July 16, 2020 at 1:02:15 PM UTC-7, John Larkin wrote:

On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:


I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly. It\'s possible to do a bad FSM in hardware, too.

Oh, yeah; one of my old lab-control function generators was set up
with a sequencer that relied on one monostable triggering another...
and every once in a while it\'d get into a forbidden state
with nothing happening.

A guru from down the hall advised me (too late; I\'d found and fixed the
problem) to read up on finite state machines... and synchronous logic,
too.

 

[whit3rd]

On Thursday, July 16, 2020 at 1:02:15 PM UTC-7, John Larkin wrote:

On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:


I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly. It\'s possible to do a bad FSM in hardware, too.

Oh, yeah; one of my old lab-control function generators was set up
with a sequencer that relied on one monostable triggering another...
and every once in a while it\'d get into a forbidden state
with nothing happening.

A guru from down the hall advised me (too late; I\'d found and fixed the
problem) to read up on finite state machines... and synchronous logic,
too.

 

[whit3rd]

On Thursday, July 16, 2020 at 1:02:15 PM UTC-7, John Larkin wrote:

On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:


I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly. It\'s possible to do a bad FSM in hardware, too.

Oh, yeah; one of my old lab-control function generators was set up
with a sequencer that relied on one monostable triggering another...
and every once in a while it\'d get into a forbidden state
with nothing happening.

A guru from down the hall advised me (too late; I\'d found and fixed the
problem) to read up on finite state machines... and synchronous logic,
too.

 

[gregz]

Michael Terrell <terrell.michael.a@gmail.com> wrote:

They had a website and the sold on Ebay. The website was meci.com. they
weren\'t overpriced, or they wouldn\'t have lasted 75years.

meci was sort of way back. I still have an electronic store close to my
house near Pittsburgh. Unheard of these days. They still have tube
selection. Barno Electronics. http://www.barnoelec.com/

Greg

 

[gregz]

Michael Terrell <terrell.michael.a@gmail.com> wrote:

They had a website and the sold on Ebay. The website was meci.com. they
weren\'t overpriced, or they wouldn\'t have lasted 75years.

meci was sort of way back. I still have an electronic store close to my
house near Pittsburgh. Unheard of these days. They still have tube
selection. Barno Electronics. http://www.barnoelec.com/

Greg

 

[gregz]

Michael Terrell <terrell.michael.a@gmail.com> wrote:

They had a website and the sold on Ebay. The website was meci.com. they
weren\'t overpriced, or they wouldn\'t have lasted 75years.

meci was sort of way back. I still have an electronic store close to my
house near Pittsburgh. Unheard of these days. They still have tube
selection. Barno Electronics. http://www.barnoelec.com/

Greg

 

[Tom Gardner]

On 17/07/20 01:46, Phil Hobbs wrote:

On 2020-07-16 20:22, Tom Gardner wrote:
On 16/07/20 21:02, John Larkin wrote:
On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno.  Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly.

Stunningly badly, due to a combination of poor tools
and cargo-cult use of processes and tools.

Example: if-then-else clauses nested 10 deep.

Example mantra: \"code is difficult to change, but
configurations are easy to change\". That lead to the
conditionals in the if clauses being constants defined
in a configuration file. Think about that, and weep.

Add those two together, throw in Rational Clearcase
source code (but not configuration constants) control,
and the result was grim in all respects.


It\'s possible to do a bad FSM in hardware, too.

Yes, but it would be difficult to beat the
example above!

That sounds more like a logic-driven hairball rather than an actual FSM.

That\'s more accurate than you might think!

I once, and only once, looked at the Rational Clearcase
source code control diagram showing the diagram of the
check in branches.

Up until v3, the diagram was the usual trunk and branches
you would expect to see.

At v4 and after it looked like a kudzu infestation. Not
only was there an uncontrolled explosion of branches,
but some of them looped backwards to other branches. I
have no idea what that might have meant, and I decided
not to enquire.

But the Domain Specific Language it was written in had
explicit condtructs for nodes, events and transitions to
other nodes. Hence it /was/ an FSM.

 

[Tom Gardner]

On 17/07/20 01:46, Phil Hobbs wrote:

On 2020-07-16 20:22, Tom Gardner wrote:
On 16/07/20 21:02, John Larkin wrote:
On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno.  Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly.

Stunningly badly, due to a combination of poor tools
and cargo-cult use of processes and tools.

Example: if-then-else clauses nested 10 deep.

Example mantra: \"code is difficult to change, but
configurations are easy to change\". That lead to the
conditionals in the if clauses being constants defined
in a configuration file. Think about that, and weep.

Add those two together, throw in Rational Clearcase
source code (but not configuration constants) control,
and the result was grim in all respects.


It\'s possible to do a bad FSM in hardware, too.

Yes, but it would be difficult to beat the
example above!

That sounds more like a logic-driven hairball rather than an actual FSM.

That\'s more accurate than you might think!

I once, and only once, looked at the Rational Clearcase
source code control diagram showing the diagram of the
check in branches.

Up until v3, the diagram was the usual trunk and branches
you would expect to see.

At v4 and after it looked like a kudzu infestation. Not
only was there an uncontrolled explosion of branches,
but some of them looped backwards to other branches. I
have no idea what that might have meant, and I decided
not to enquire.

But the Domain Specific Language it was written in had
explicit condtructs for nodes, events and transitions to
other nodes. Hence it /was/ an FSM.

 

[Michael Terrell]

For many of us, surplus stores or mail order were the only source for parts. Dayton was full of distributors who didn\'t sell to individuals. Some would only sell to industrial accounts.

 

[Tom Gardner]

On 17/07/20 01:46, Phil Hobbs wrote:

On 2020-07-16 20:22, Tom Gardner wrote:
On 16/07/20 21:02, John Larkin wrote:
On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 16/07/20 17:49, jlarkin@highlandsniptechnology.com wrote:
On Thu, 16 Jul 2020 12:12:41 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Dunno.  Maybe they can\'t decide whether they\'re HW or SW types.

Simon\'s in that camp too.

Being able to do both is cool. Almost mandatory.

Yes indeed. It baffles me that more people can\'t slide
between hardware and software.


The Brat wants to learn to code now. She\'s signed up for an expensive
online Python course from some college. After she gets into it a bit,
I\'m going to explain finite state machines to her. Maybe a company
lecture.

Softies can think FSMs are something to do with parsing
in compilers. At that point I realise there is a PEBCAK[1],
and I\'d rather they stayed away from the K.

I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly.

Stunningly badly, due to a combination of poor tools
and cargo-cult use of processes and tools.

Example: if-then-else clauses nested 10 deep.

Example mantra: \"code is difficult to change, but
configurations are easy to change\". That lead to the
conditionals in the if clauses being constants defined
in a configuration file. Think about that, and weep.

Add those two together, throw in Rational Clearcase
source code (but not configuration constants) control,
and the result was grim in all respects.


It\'s possible to do a bad FSM in hardware, too.

Yes, but it would be difficult to beat the
example above!

That sounds more like a logic-driven hairball rather than an actual FSM.

That\'s more accurate than you might think!

I once, and only once, looked at the Rational Clearcase
source code control diagram showing the diagram of the
check in branches.

Up until v3, the diagram was the usual trunk and branches
you would expect to see.

At v4 and after it looked like a kudzu infestation. Not
only was there an uncontrolled explosion of branches,
but some of them looped backwards to other branches. I
have no idea what that might have meant, and I decided
not to enquire.

But the Domain Specific Language it was written in had
explicit condtructs for nodes, events and transitions to
other nodes. Hence it /was/ an FSM.

 

[Phil Hobbs]

On 2020-07-17 02:25, whit3rd wrote:

On Thursday, July 16, 2020 at 1:02:15 PM UTC-7, John Larkin wrote:
On Thu, 16 Jul 2020 20:43:45 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:


I once did a \"company lecture\" to a group that was building
a telecoms project. They were so deep in the shit[2] that most
of them hadn\'t even noticed they were implementing an FSM

Probably badly. It\'s possible to do a bad FSM in hardware, too.

Oh, yeah; one of my old lab-control function generators was set up
with a sequencer that relied on one monostable triggering another...
and every once in a while it\'d get into a forbidden state
with nothing happening.

A guru from down the hall advised me (too late; I\'d found and fixed the
problem) to read up on finite state machines... and synchronous logic,
too.

A lab neighbour of mine in grad school, John Fox (who later went on to
do great things in beam cooling for particle accelerators), built an
acoustic microscope that did its sequencing like that.(*)

One monostable to gate the TX pulse, one for the round-trip delay, one
for the RX gate.

A digital delay generator would be the right way to do it for a
temporary setup. (Plug for the Highland P400, which I use quite a
bit--back at IBM I had one of the older SRS ones, which wasn\'t as good.)

Cheers

Phil Hobbs

(*) It might have been the other guy that shared his lab--Larry
somebody, I forget.

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com