Engineering Types

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Ok, so I'm working on an open ventilator project that actually has about th
e same chance of making it to market as Trump has getting reelected.  So we
 get a new guy in to help with the FPGA.  He is from a background of high s
peed comms and radar type work.  Clearly he can handle this easily.  We are
 using a 33 MHz clock rate but most of the processing is MUCH slower.  ADCs
 sampling at 1 kHz sort of stuff.  

So does the guy take a piece of the project and run with it?  No, he starts
 niggling about the choice of FPGA.  He's worried that a startup company's  
product is being used.  The tools seem ok so far, but the docs pretty well  
suck.  There is a US guy who can help with various issues or he acts as the
 go between for tech support when you have a question he can't answer.  So  
far, it's all pretty good.  

The guy is even questioning the clock rate.  Because there is a technical r
eason?  No, because he thinks 50 MHz is more available... really?  That's t
he issue of importance?  There are any number of questionable decisions mad
e on this project, but ones that have more impact on the outcome.  

I've responded to most of his stuff, but I'm getting a bit tired of it.  I  
think I'm going to ask how he work is going and ignore the trivial stuff.  
At least he isn't like one of the volunteers who I'm having to hold his han
d while getting the tools setup and point him to web sites for VHDL-2008.  
Whatever.  I guess I should focus on getting my bits done and not worry abo
ut the higher level issues.  

It is pretty interesting to see new companies selling FPGAs now.  I think t
here are at least three and this one has the packaging I prefer and great p
ricing.  9,000 LUTs for $5.  That's pretty durn good.  

Xilinx can't touch that, er, I mean AMD.  

I wonder how much that will change the company.  I bought some of the stock
 a couple of weeks ago on the rumor.  Now it's just a matter of waiting for
 the deal to close, then I'll own AMD stock at a 17% increase.  :)  

--  

  Rick C.

  - Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Engineering Types
On Friday, October 30, 2020 at 3:23:53 PM UTC+11, Ricketty C wrote:
Quoted text here. Click to load it
the same chance of making it to market as Trump has getting reelected. So w
e get a new guy in to help with the FPGA. He is from a background of high s
peed comms and radar type work. Clearly he can handle this easily. We are u
sing a 33 MHz clock rate but most of the processing is MUCH slower. ADCs sa
mpling at 1 kHz sort of stuff.  
Quoted text here. Click to load it
s niggling about the choice of FPGA. He's worried that a startup company's  
product is being used.

You only have to build one project around a part that didn't end up staying
 available to get very nervous about buying stuff from start-ups.

It doesn't sound as if you couldn't make the project work with a part from  
somebody more likely to keep it in production.

<snip>

--  
Bill Sloman, Sydney

Re: Engineering Types
On Friday, October 30, 2020 at 3:31:58 AM UTC-4, Bill Sloman wrote:
Quoted text here. Click to load it
t the same chance of making it to market as Trump has getting reelected. So
 we get a new guy in to help with the FPGA. He is from a background of high
 speed comms and radar type work. Clearly he can handle this easily. We are
 using a 33 MHz clock rate but most of the processing is MUCH slower. ADCs  
sampling at 1 kHz sort of stuff.  
Quoted text here. Click to load it
rts niggling about the choice of FPGA. He's worried that a startup company'
s product is being used.
Quoted text here. Click to load it
ng available to get very nervous about buying stuff from start-ups.

Yes indeed.  I've been hit by a critical part going EOL after a well establ
ished company lost access to a fab from another reputable company.  Clearly
 reputable companies are inferior to startup companies as you say... wait,  
that's not what you said.  So anecdotal evidence, aka "one" experience is n
ot worth much.  


Quoted text here. Click to load it
m somebody more likely to keep it in production.

As is not uncommon with you, an assumption is drawn that is not based on kn
owledge of the facts.  

Ok, thanks anyway.  

--  

  Rick C.

  + Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Engineering Types
On Sunday, November 1, 2020 at 10:47:38 AM UTC+11, Ricketty C wrote:
Quoted text here. Click to load it
out the same chance of making it to market as Trump has getting reelected.  
So we get a new guy in to help with the FPGA. He is from a background of hi
gh speed comms and radar type work. Clearly he can handle this easily. We a
re using a 33 MHz clock rate but most of the processing is MUCH slower. ADC
s sampling at 1 kHz sort of stuff.  
Quoted text here. Click to load it
tarts niggling about the choice of FPGA. He's worried that a startup compan
y's product is being used.  
Quoted text here. Click to load it
ying available to get very nervous about buying stuff from start-ups.
Quoted text here. Click to load it
lished company lost access to a fab from another reputable company. Clearly
 reputable companies are inferior to startup companies as you say... wait,  
that's not what you said. So anecdotal evidence, aka "one" experience is no
t worth much.

This can happen, but ti doesn't happen often, and most "reputable" companie
s stay in business, and can - and mostly do - negotiate a new supplier. Whe
n a start-up goes bust, it's usually gone.

Quoted text here. Click to load it
rom somebody more likely to keep it in production.
Quoted text here. Click to load it
knowledge of the facts.  

The whole point of a programmable part is that you can get it to do what yo
u want. Nothing in what you have written (and you haven't written all that  
much) has suggested that your start-up offered a unique selling point that  
let it do something that nobody else could offer, and your project doesn't  
seem to be pushing any technical limits.

I obviously don't know much about the facts - since you haven't given us al
l that many - but you haven't bothered to tell us why the FPGA from the sta
rt-up was good enough to justify going for a single-sourced part. You new g
uy doesn't seem to think that it was , and you seem to be peeved about the  
implicit criticism rather than cross about his lack of comprehension.

--  
Bill Sloman, Sydney



Re: Engineering Types
On Saturday, October 31, 2020 at 9:23:01 PM UTC-4, Bill Sloman wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
about the same chance of making it to market as Trump has getting reelected
. So we get a new guy in to help with the FPGA. He is from a background of  
high speed comms and radar type work. Clearly he can handle this easily. We
 are using a 33 MHz clock rate but most of the processing is MUCH slower. A
DCs sampling at 1 kHz sort of stuff.  
Quoted text here. Click to load it
 starts niggling about the choice of FPGA. He's worried that a startup comp
any's product is being used.  
Quoted text here. Click to load it
taying available to get very nervous about buying stuff from start-ups.
Quoted text here. Click to load it
ablished company lost access to a fab from another reputable company. Clear
ly reputable companies are inferior to startup companies as you say... wait
, that's not what you said. So anecdotal evidence, aka "one" experience is  
not worth much.
Quoted text here. Click to load it
ies stay in business, and can - and mostly do - negotiate a new supplier. W
hen a start-up goes bust, it's usually gone.
Quoted text here. Click to load it
 from somebody more likely to keep it in production.
Quoted text here. Click to load it
n knowledge of the facts.  
Quoted text here. Click to load it
you want. Nothing in what you have written (and you haven't written all tha
t much) has suggested that your start-up offered a unique selling point tha
t let it do something that nobody else could offer, and your project doesn'
t seem to be pushing any technical limits.
Quoted text here. Click to load it
all that many - but you haven't bothered to tell us why the FPGA from the s
tart-up was good enough to justify going for a single-sourced part. You new
 guy doesn't seem to think that it was , and you seem to be peeved about th
e implicit criticism rather than cross about his lack of comprehension.

Your statement is about level 1 of understanding FPGAs.  They are much more
 involved than that.  There are any number of considerations involved.  I h
ave no need to discuss that with you.  This is not a design review.  The ch
oice of FPGA is not the topic I'm posting about.  

I love your mention of a single sourced part as if any FPGA is not a single
 sourced part.  LOL  

Actually, I asked about the LQ100X package they have.  It is so the pin out
 of one of their parts matches a competitor's part so they can steal socket
s in production.  Not a bad strategy.  

I've always been amazed that no one does that even with their own lines, bu
t it's not in the FPGA maker's interest.  They operate on "design wins".  O
nce you have designed their part in those sales are pretty much a lock.  Wh
en a new family is out all focus is on the new family and they don't try to
 sell the older parts at all even if the new ones are not quite as suitable
 for some particular app.  Making a new family pin compatible with an old o
ne doesn't get them any NEW design wins.  

--  

  Rick C.

  -+ Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Engineering Types
On Sunday, November 1, 2020 at 1:37:00 PM UTC+11, Ricketty C wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
s about the same chance of making it to market as Trump has getting reelect
ed. So we get a new guy in to help with the FPGA. He is from a background o
f high speed comms and radar type work. Clearly he can handle this easily.  
We are using a 33 MHz clock rate but most of the processing is MUCH slower.
 ADCs sampling at 1 kHz sort of stuff.  
Quoted text here. Click to load it
he starts niggling about the choice of FPGA. He's worried that a startup co
mpany's product is being used.  
Quoted text here. Click to load it
 staying available to get very nervous about buying stuff from start-ups.
  
Quoted text here. Click to load it
stablished company lost access to a fab from another reputable company. Cle
arly reputable companies are inferior to startup companies as you say... wa
it, that's not what you said. So anecdotal evidence, aka "one" experience i
s not worth much.  
Quoted text here. Click to load it
anies stay in business, and can - and mostly do - negotiate a new supplier.
 When a start-up goes bust, it's usually gone.  
Quoted text here. Click to load it
rt from somebody more likely to keep it in production.  
Quoted text here. Click to load it
 on knowledge of the facts.  
Quoted text here. Click to load it
t you want. Nothing in what you have written (and you haven't written all t
hat much) has suggested that your start-up offered a unique selling point t
hat let it do something that nobody else could offer, and your project does
n't seem to be pushing any technical limits.  
Quoted text here. Click to load it
s all that many - but you haven't bothered to tell us why the FPGA from the
 start-up was good enough to justify going for a single-sourced part. You n
ew guy doesn't seem to think that it was , and you seem to be peeved about  
the implicit criticism rather than cross about his lack of comprehension.
Quoted text here. Click to load it

The discussion here is entirely level 1.

Quoted text here. Click to load it

Of course they are.

Quoted text here. Click to load it

None of which you have mentioned.

Quoted text here. Click to load it

Nor probably the capacity,

Quoted text here. Click to load it
ing about.  

Not exactly. You did post a complaint about someone who didn't like your ch
oice  of FPGA, but your complaint was about his temerity in having his own  
opinion on the subject. The idea that he might have been onto something doe
sn't seem to have entered your mind.

Quoted text here. Click to load it
le sourced part. LOL  
Quoted text here. Click to load it
t of one of their parts matches a competitor's part so they can steal socke
ts in production. Not a bad strategy.  

So the LQ100X wouldn't be a single sourced part if you constrained the desi
gn enough that the competitor's part could replace it.

It's going a back a long way, but the Place ICT7024 was a drop-in replaceme
nt for a 22V10 - I first got to use one when I was cleaning up after a desi
gner who never bothered to tolerance the timing in his designs.
I was never all that enthusiastic about larger programmable logic chips bac
k then - most of them drew enough current that they ran hot.  The Philip's  
CoolRunner range was attractive, but I never got to design them into anythi
ng.
  
Quoted text here. Click to load it
, but it's not in the FPGA maker's interest. They operate on "design wins".
 Once you have designed their part in those sales are pretty much a lock. W
hen a new family is out all focus is on the new family and they don't try t
o sell the older parts at all even if the new ones are not quite as suitabl
e for some particular app. Making a new family pin compatible with an old o
ne doesn't get them any NEW design wins.  

The world is full of people with serious tunnel vision.

--  
Bil Sloman, Sydney

Re: Engineering Types
Ricketty C wrote:


Quoted text here. Click to load it
Yes, very good point.  But, with certain FPGA vendors, even if one of their  
parts goes out of production, it MIGHT be easier to migrate/upgrade to  
another of the same manufacturer's parts.  My only experience is with  
Xilinx, and I've migrated some IP several times to newer FPGA families.
It really wasn't too difficult.

Jon

Re: Engineering Types
On Thu, 29 Oct 2020 21:23:47 -0700 (PDT), Ricketty C

Quoted text here. Click to load it

If Your expert has experience, use it and don't  
ridicule reservations gained through hard, if not  
actually painful experience.

I'm sure, if you ask him/her, he should be able to  
explain 'why I can't do that'.

RL

Re: Engineering Types

Quoted text here. Click to load it

Why would 1-Hz mechanical system need an FPGA?

And why now?

Clown show.



--  

John Larkin         Highland Technology, Inc

Science teaches us to doubt.

We've slightly trimmed the long signature. Click to see the full one.
Re: Engineering Types
On Fri, 30 Oct 2020 07:47:28 -0700, snipped-for-privacy@highlandsniptechnology.com
wrote:

Quoted text here. Click to load it

It might have been one of the first things the 'expert'  
would have pointed out, if they were not actually desperate  
for work, but people tend not to be able to even hear  
advice, that early in a business relationship.

Wading in and telling your prospective employer that he doesn't  
know what he's doing isn't usually very constructive. There's  
always a chance that the boss does know what he's doing -  
might not be easy to ascertain.

RL

Re: Engineering Types

Quoted text here. Click to load it

Sounds to me like there is no boss.



--  

John Larkin         Highland Technology, Inc

Science teaches us to doubt.

We've slightly trimmed the long signature. Click to see the full one.
Re: Engineering Types
On Fri, 30 Oct 2020 08:20:37 -0700, snipped-for-privacy@highlandsniptechnology.com
wrote:

Quoted text here. Click to load it

When he uses words like niggling and trivial, it's  
almost a sure bet.

RL

Re: Engineering Types

Quoted text here. Click to load it

Managing a serious, many-person technical project is hard. The boss
may be a good manager or a good engineer but rarely both.


Re: Engineering Types
On Saturday, October 31, 2020 at 7:54:11 AM UTC+11, John Larkin wrote:
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
e:  
Quoted text here. Click to load it

<snip>

Quoted text here. Click to load it
e a good manager or a good engineer but rarely both.

The boss has to be a good enough manager to keep track of all the activitie
s, and a good enough engineer to keep track what's going on in each of the  
activities.

If they can't do both jobs, their competence in one or the other doesn't re
ally matter - they'll screw up  the project  as whole.  Trying to separate  
the job of orginising the work  from the job of comprehending what's happen
ing is the kind of idiocy you get from people who go through management tra
ining, and think that the skill extends to managing demanding technical pro
jects.

--  
Bill Sloman, Sydney

Re: Engineering Types
On 10/30/2020 1:53 PM, John Larkin wrote:
Quoted text here. Click to load it

But a good manager can collect engineering ADVICE from good engineers
and use that to tune his handling of the project.  By contrast, a
good engineer (acting as manager) is far less likely to have
access to good MANAGERIAL advice -- esp from the staff of engineers
that he's managing.

The area of expertise also plays a huge role in understanding the
nature of the problem you're facing -- and the likely potential
risks that you'll encounter, going forward.  Managing hardware
projects is a piece of cake as they are reasonably well defined
and you can "see" the extent of the progress (risks are mainly
associated with how close to the bleeding edge you're operating).

OTOH, software projects are fraught with all sorts of unknowns
(will the algorithm work?  will it be fast enough?  will the
hardware resources available be sufficient?  do we understand
the types of data/conditions that will possibly (in any oddball
combination of circumstances imaginable and UNimaginable) be
presented?)  And, the PAST engineering experience from which
a manager might benefit quickly fades, over time (IME).

Add to this the lack of "good practices" in MEASURING the
performance of the developers as a predictor of their completion
(and integrity of product) and many projects just stumble into
production (before their ready).

[Ask yourself what metrics you put in place to measure YOUR
teams' performances!]

Re: Engineering Types
On Sat, 31 Oct 2020 07:23:19 -0700, Don Y

Quoted text here. Click to load it

The boss's problem, if he can't make the technical judgements himself,
is deciding who to trust. He can do that based on previous sucesses
(assuming blame can be accurately assigned) or on personality
judgements. I've recently worked with a manager who is wrapped around
the pinkie of a person who makes terrible technical judgements but
sounds authoratative. It's not going well. Phil Hobbs could do in a
couple of hours what she has been getting wrong for eight months so
far. The same outfit is redesigning one of our products their way. So
far, they have had two teams on it in two countries, maybe 20
engineers, for three years. They have lots of management and
procedures.

Quoted text here. Click to load it

Software has zero visibility to management. Worse than hardware.

Quoted text here. Click to load it

99% done for 10 months now?

Quoted text here. Click to load it

Whiteboards. Schematics. PCB layouts. Oscilloscope screens. A box that
I can punch buttons on.




--  

John Larkin         Highland Technology, Inc

Science teaches us to doubt.

We've slightly trimmed the long signature. Click to see the full one.
Re: Engineering Types
On 10/31/2020 8:20 AM, snipped-for-privacy@highlandsniptechnology.com wrote:
Quoted text here. Click to load it

Exactly.  But, there's no "science" to that approach.  He just
*hopes* his advisor has a good handle on the CURRENT problem.
If you're always breaking new ground on new projects, then
past projects don't correlate as well with the current project
(I've never worked on "Version 2" of a product; there's never
been a previous example of the current product on which to
base assessments)

Quoted text here. Click to load it

You force the person to make commitments, publicly.  So, their
credibility is appraised in a very visible way.  If you (the
manager) then continue to give credence to their pronouncements,
YOUR credibility becomes publicly compromised.

Quoted text here. Click to load it

That's the case for firms that don't have good process and
metrics in place.

Would you design a piece of hardware without a spec to tell
you "where you are headed"?  Or, to tell you "when you'd
arrived"?  Would you have, in place, test procedures that
you'd used to make that assessment?  See how many software
projects even begin to address these issues...

Quoted text here. Click to load it

Or, worse -- a pronouncement that "we're done, now" without
anything to back up that claim (metrics).

Quoted text here. Click to load it

That's for HARDWARE.  What metrics do you have for the SOFTWARE?
Or, do you rely on developers' "self assessments" of their progress
(as well as the correctness of their code)?  How confident are
you that a bug *won't* be found by the first purchaser?

Re: Engineering Types
On Sat, 31 Oct 2020 10:55:43 -0700, Don Y

Quoted text here. Click to load it

Sometimes. I've done a bunch of good products just by doing it.

http://www.highlandtechnology.com/DSS/J270DS.shtml

Quoted text here. Click to load it

Both of those were unplanned weekend projects, design and layout. They
just sort of evolved. More complex stuff, group projects, we usually
write the manual first as the design goal. We'll need a manual
eventually anyhow. We sometimes send the manual to potential buyers
and ask their opinion. That's a sales tool too.

We recently put up the web page for the J270 and someone ordered one a
couple of days later. I was stunned. I need to contact the end user
and ask him/her why.


 Or, to tell you "when you'd
Quoted text here. Click to load it

We do a FAT, first-article test, on a new design, and leave FAT notes.
Later on we pass it to the test group so they can do formal test
procedures, test sets, test software. In a small company, we can talk
a lot.

Quoted text here. Click to load it

Boxes with software inside, I punch the buttons and make sure
everything works. And ask other people to do it too, help test
specifics. A box can have bugs in hardware, software, and FPGA.
Luckily, my embedded programmer guy is very good.

Users aren't shocked by a bug in a new product. They just want us to
admit it and fix it. Lots of big-name outfits won't do either.







--  

John Larkin         Highland Technology, Inc

Science teaches us to doubt.

We've slightly trimmed the long signature. Click to see the full one.
Re: Engineering Types
On 10/31/2020 1:40 PM, snipped-for-privacy@highlandsniptechnology.com wrote:
Quoted text here. Click to load it

Hardware is almost always easier to "wing it".  You only need a
spec if you have software that is going to run on/in the device.
You can typically summarize the performance of a piece of
hardware in a few pages of figures because hardware does a few
well defined things.

I have 22 hardware designs in my current project.  I can keep most
of the details of all of them in my head at the same time.  I can't
keep the details of ANY of the software running on them *entirely*
in my head (complex:  something that can't be contained in a single
mind); I know what the software does in general terms but can't
recite how each special case is handled (or, recall what all of the
special cases can be!)

Anything bigger than about 20K LLOC tests my ability to recall
details well enough to be able to guard against "dark corners".

Quoted text here. Click to load it

My Design Documents are a combination of User Manual and Design Rationale.
They contain details regarding what hazards exist in the (future!) design
that have to be addressed and how they should be addressed -- along with
"why".

E.g., each of my current designs supports an RGB LED as a status/diagnostic
indicator.  I have more than 20 pages describing how the indicator is
used, what "colors" signify, the legitimate transitions between colors
(device states), how folks with different types of color-blindness are
accommodated in the color encoding, how blind/deaf folks perceive the
indicator state, how I convey a *failure* of the indicator (or one of the
emitters within) to the user, etc.

And, that's for a "feature/mechanism" that isn't intended to see use in
normal operation!

Quoted text here. Click to load it

How do you test DURING the development?  Do you just put all the software
together and hope it works?  Do you know what sorts of things are likely
to cause problems (because the developer identified them as he was writing
the code and deliberately created test cases to ensure he's addressed them
in the final product)?

What metrics do you cite (to yourself) to assure yourself that this
test will reveal "very few" defects AND be sufficiently comprehensive?

[I can't count the number of times I've walked up to "finished"
products and uncovered bugs just by casually tinkering:  "what's
it do if I unplug this cable while I'm doing <whatever>?"]

I have a pair of Nakamichi Dragons (high-end cassette decks from decades back).
They are "autoreverse" decks that work by switching the head coils used
so the tape can remain in a fixed position.  There is a servo mechanism
that drives the angular alignment of the head to follow the recorded "tracks"
on the actual tape media.  (i.e., they shouldn't be considered "cheap",
cost-cutting products).

When the tape reaches the end of side A, the drive/capstan motors reverse
direction, the head coils are swapped (and the head alignment tweeked)
and side B plays.  The tape counter begins counting BACKWARDS as it
starts to return to the position where you started side A, earlier.

Except when it doesn't!  (oops!)

It's a bug because it can be reproduced on BOTH of my decks.  Obviously,
someone hadn't carefully considered all of the ways the decks could be used!

Quoted text here. Click to load it

I'm sure they "punched the buttons" on the Therac-25 before releasing
it to production!  But, if you're only punching the buttons the way
you'd EXPECT folks to punch them, you don't uncover latent bugs that
a "stupid" user will uncover -- in his ignorance/carelessness/haste.

Part of the reason for measuring WHILE developing is to see how your
"defect detection rate" changes, over time.  Ideally, you'd expect it
to peak long before "release" and asymptotically approach "zero" as
your development/testing progresses.

Quoted text here. Click to load it

When you're developing for regulated industries (medical, pharma,
gaming, etc.) there is a high cost to "fixing it" as the device
has to go through a formal REvalidation procedure, again.  The
initial validation was supposed to prove you'd dotted all your
i's and crossed all your t's -- yet here you are FIXING something!
Has your "fix" broken anything that had worked, previously?
Do we have confidence that the process you defined to assure us
of that correct functionality isn't inherently flawed?  A slot
machine can't download it's "monthly update" whenever its
convenient -- and risk paying out at an incorrect rate until
that happens!

[Think "Boeing" and the costs they are incurring because they're
bugs were so publicly visible]

If you're product is used in a process control application, your
customer(s) may find their lines shut down while you're trying to
address that bug.  (a single tablet press can produce in excess
of a million tablets per hour.  imagine how many tablets don't get
produced in the day or week it takes you to sort out "what you
did WRONG"!)

And, in each case, their level of confidence that there won't be
MORE bugs falls ("How do we know that you've got all of the bugs,
NOW?")

[I maintain my own development tools.  Not because I'm "best qualified"
to do so but, rather, because I want to be sure I know what is changing
each time the tool(s) are revised.  If I have a problem with a tool,
I want to know if I can work around it and NOT tweek the tool's
implementation.  The LAST thing I want to do is accept a tool that
has a bunch of changes bundled into it and wonder what else may have
been broken -- or, simply changed (in a way that isn't well documented)
in the process.]

Re: Engineering Types
On Sat, 31 Oct 2020 15:29:16 -0700, Don Y

Quoted text here. Click to load it

A new definition of "reverse engineering" :

Find an interesting new part or concept. Scribble away a couple of
pads of paper, fooling around with possible circuits. If it looks like
a product is emerging, do a serious schematic and build one. Write a
manual and put up a web page and see what happens.

It might sell. It might attract a customer who wants something
similar. It might be a dud but you learn something that could be
useful years later.

The trick is to do it often and not spend a lot of time on any one
project, at least until there seems to be real interest.


Quoted text here. Click to load it

I used to write embedded code, but I have a guy for that now. Circuit
design is more fun. Code is a lot more complex than it used to be.


Quoted text here. Click to load it

20 pages seems like a lot for one normally invisible LED. I don't use
bicolors so I don't worry about color blindless. Lately we use some
really slick light pipes on a box or panel.



Quoted text here. Click to load it

I try everything I can think of, and all the tricky stuff that we
whiteboarded. Most of our stuff ships without bugs. The formal
production tests sometimes turn up a bug too.



--  

John Larkin         Highland Technology, Inc

Science teaches us to doubt.

We've slightly trimmed the long signature. Click to see the full one.

Site Timeline