One of the "improvements" that irks me, for a long time the ARRL handbook featured a morse code practice oscillator that consisted of two transistors, a resistor and capacitor, which I still possess. I use it to test PNP and NPN transistors, condition of batteries, and if I need to, demonstrate morse code signalling. That has since been replaced with a 555-Timer circuit... aargh!

There's a good example of moving in the wrong direction. Ham radio is about learning, especially if you are going to build your own code oscillator. The transistor circuit is fundamental and simple, it has a useful purpose but can teach some very good basics and I would certainly support that.

The 555 is fine, and learning them is fine, but why in this case? Does it really simplify construction enough to matter? Is it *better* in some practical way? I don't think so.

 

I quit discrete digital 30 years ago when cheap MCUs became available.

I quit discrete analog 20 years when those cheap MCUs became capable of reasonable DSP performance.

Today, even my precision analog "front ends" are usually a single high-performance A/D converter with nothing more than a cap on the input.

Personally, I have no use for discretes -- save for historical interest.

 

I think the false reasoning here is that someone wanting to build a project is going to spend their entire lifetime doing projects.

Expecting someone to learn how to code, and all of the things that go with that…selecting the proper micro, doing the actual programming…etc. for a one off project is silly at best. (oh, and yea, you will need some electronics as well)

Then there is the hobby aspect, the most fun I have is designing the circuits I use in them, and the challenge that goes along with it.

So yea, a micro may well be the “best” solution to a problem, but “best” is a subjective term.

BTW, I’m in the process of learning to do some basic coding, and I sure as hell wouldn’t want to wait the time needed to do my next project with it.

 

When someone says, "I want to do this without a microprocessor, I really need to hear the rationale for NOT using one before I feel I can help, since there is a very good chance they are confused about micros or avoiding learning what they consider "complicated" while it is actually the simplest and most effective answer in most cases today that seem to need one.

What makes you think that you need to approve of what someone wants to do or that they desire your approval?

Direct enough?

 

I have progressed from valves (Tubes.) to transistors to integrated circuits to microprocessors over the years.
Les.

Appears like many, you and I have traveled parallel paths.
And this highlights the point where someone is likely to say

, "I want to do this without a microprocessor,

When you have had no choice having to build a flip-flop with transistors and descrete components before the appearance of IC's etc,there is no way I would think of doing it this way today.
So having ran the whole gamut, it is natural now to generally look at a either small micro or a dedicated IC for many solutions,
For someone Now coming into the electronics arena, it is different ball game and makes sense to learn a few of the basics first.
Max.

 

Sorry if you took OP to be you. I meant OP in the general sense in my last post.

I take a much different approach than you in my work. I work to understand the problem including previous solution attempts (successful and otherwise) before attempting a new solution. Many times I find the requirements to be too strict in some places and too loose in the key requirements. I find myself usually bridging many disciplines other than my own to provide solutions.

unfortunately I don’t have the time for that level of detail here. So I try to help by understanding the requirements as posted and trying to direct the op to places they can do more research if they really desire to seek a solution. They will either solve their problem, seek other answers, or refine their requirements. Hopefully all three. But I am not being paid well enough here to try to figure it out for someone here.

As an aside, I have also noticed a steep increase in people seeking technical advice advice here on behalf of their companies. I try to stay out of those threads for many reasons.

 

I think the false reasoning here is that someone wanting to build a project is going to spend their entire lifetime doing projects.

Expecting someone to learn how to code, and all of the things that go with that…selecting the proper micro, doing the actual programming…etc. for a one off project is silly at best. (oh, and yea, you will need some electronics as well)

Then there is the hobby aspect, the most fun I have is designing the circuits I use in them, and the challenge that goes along with it.

So yea, a micro may well be the “best” solution to a problem, but “best” is a subjective term.

BTW, I’m in the process of learning to do some basic coding, and I sure as hell wouldn’t want to wait the time needed to do my next project with it.

I don't think this is reasonable. Arduino and its IDE made this

Sorry if you took OP to be you. I meant OP in the general sense in my last post.

I take a much different approach than you in my work. I work to understand the problem including previous solution attempts (successful and otherwise) before attempting a new solution. Many times I find the requirements to be too strict in some places and too loose in the key requirements. I find myself usually bridging many disciplines other than my own to provide solutions.

unfortunately I don’t have the time for that level of detail here. So I try to help by understanding the requirements as posted and trying to direct the op to places they can do more research if they really desire to seek a solution. They will either solve their problem, seek other answers, or refine their requirements. Hopefully all three. But I am not being paid well enough here to try to figure it out for someone here.

As an aside, I have also noticed a steep increase in people seeking technical advice advice here on behalf of their companies. I try to stay out of those threads for many reasons.

Just to be clear, I never suggested I didn't consider the previous attempts at solutions, only that the discovery phase was green field, since those attempts were done from a position of ignorance. The information from the attempts can often be useful after a thorough examination of the actual problem and the goals.

Many times I declined gigs because the client wanted me to "make our solution work" which is not the same as solving the problem the solution was intended to address.

A very common issue is that "solutions" replace and become the problem facing the consultant and when the dust settles, the original problem is not resolved, the consultant is blamed for it, and the "solution" is scrapped with the follow on solution possibly no better.

 

Debating over to "MCU or not MCU" is pointless....the solution is whatever the TS is comfortable using...

eT

 

Sometimes I like the challenge of using analog solutions and there are times it lowers part count and analog speed control is smooth, analog log controls are also amazing for volume and such. I hate my digital volume knobs. Analog comes with its own challenges.

Micros are so easy but they’re generally delicate. It maybe daunting to see a 200 page datasheet when someone just needs a simple timer and missing a vital limitation may be fatal. It really depends on the application. It takes time to learn how to program, limitations and how to troubleshoot and fix them whether using ISP or sockets. On the other hand analog has the advantage of just working and can be very dependable and easier to fix when a component goes bad.

in the words of Bob Widlar “every body can count to one”

I feel your frustration, I offer a micro solution when appropriate then let them continue with a 20 component solution to do something that can be done with a few. (All while saying they have limited space in their enclosure).
.

 

3) That a very large percentage of requests for X without a microprecessor don’t have a good rationale, usually based on ignorance. (e.g.: too complicated, hard to implement, expensive, hard to learn, etc.)

I suspect you're correct that many (or possibly most) of these requests are being made out of ignorance, although I don't agree that ignorance is never a good rationale. To me, it all depends on whether the ignorance is permanent and dogmatic ("I don't like microcontrollers and don't intend to ever learn how to use them") or whether the person is simply at a point in his learning about electronics where he isn't quite ready to tackle μCs yet, and wants to learn classical analog & digital design first.

I don't have much sympathy in the first case, nor much interest in helping, but I can easily relate to the second.

All practical projects will require learning discrete components and some basics of circuits for interfacing the µP to the world, and not knowing how to program is a major skills gap in the current world.

I strongly agree with the part I bolded above: anymore, being familiar with μCs and being able to use them when appropriate (and being able to tell when they're appropriate and when they're not) is an essential part of a designer's toolkit. Not having that is a serious limitation, IMO.

 

100% agree.
Programmable logic, whether microprocessors or FPGAs, is THE future of electronics.
Anyone desiring to have a meaningful job in electronics, must at least understand them, with the desire to become proficient.

This is similar to what engineers and students faced when transistors finally became mainstream: either you became proficient or would face your career rapidly waning.

Having said this..........for personal reasons you want a particular project to be designed with dicrete logic, transistors or perhaps vacuum tubes, then godspeed to you! It will be an exciting ride.

From time to time I like to design with discrete components, simply to exercise my mind like a puzzle.
I do enjoy the exercise, but it quickly reminds me how blessed we are nowadays, that cheap microcontrollers with simple interfaces are readily available!