I don't know C, learning a new language is going to take a lot longer, but I'm taking the long view. Whatever I have to learn I will attempt. So, is learning C a prerequisite? I need to pick a MCU to get the ball roiling.Whatever ch I use needs 7 Pins for the display and two or 4 pins for the common(maybe 6 for 6 digits) I saw a neat scheme using a 4017 (decade counter) for the common LED display pins it bring the common pins down to two, In addition 2 input pins, counter input, and display the count.

What chip has the required output and input pins?

 

I don't know C, learning a new language is going to take a lot longer, but I'm taking the long view. Whatever I have to learn I will attempt. So, is learning C a prerequisite? I need to pick a MCU to get the ball roiling.Whatever ch I use needs 7 Pins for the display and two or 4 pins for the common(maybe 6 for 6 digits) I saw a neat scheme using a 4017 (decade counter) for the common LED display pins it bring the common pins down to two, In addition 2 input pins, counter input, and display the count.

What chip has the required output and input pins?

There are about 10,000 chips that fit the bill.
Don't select the chip.
Choose the development platform, the chip family and the software you want to use.
This also means choosing the chip architecture if you want to learn ASM.

If you want to start with ASM, every chip family uses a unique ASM language.
If you choose C, the language is common to all chip families and manufacturers.

 

So, is learning C a prerequisite?

No.

Back in the day, that was essentially a college lab project. 4 digit display with a keypad. I forget what else we had to do.
That was done in 6800 assembly language.

What's fast? FAST might mean hardware only.

You can count in BCD or in binary and then display in BCD.

I had de-bouncing and scanning to worry about.

I had multiplexing to worry about. There was one gotcha for the display that's better to know before than find it out later.
That's "inter-digit blanking" You have to deselect the digit briefly and then load the next digit value, otherwise you get ghosting.
e.g. an "8" displayed before a "1" would show the barely lit segments of the "8".

"Leading zero blanking" is another counter issue. Is it needed or not?

is a 10 displayed as "0010" or " 10"?

Generally you need a plastic filter of the same color as the displays over the displays.

 

I don't know C, learning a new language is going to take a lot longer, but I'm taking the long view. Whatever I have to learn I will attempt. So, is learning C a prerequisite?

Personally, I'd learn a language like C that can be used on many platforms. If you get to the point where you think you can write more efficient code than a compiler, then use assembly for those portions.

I learned assembly language for several architectures and have little interest in learning another. I'm more interested in writing programs that do useful things. If there comes a time when I think I could improve some portion of a program by writing in assembly, I'll do it. But, that's as a last resort.

 

One of the applications is that of freq counter. If I build it I will see what the fastest counting speed is.

 

I would recommend you develop your product using something like this in a prototype design. If all is well you could consider your own bespoke solution.

https://www.ebay.co.uk/itm/1pcs-Fin...m=182781260130&_trksid=p2060778.c100290.m3507

The design of this unit is quite elegant, so unless your design includes a bespoke display user interface – you could consider it for production units.

 

While I might sell one or two, there is no way I'm going to sell them commercially. If I get one working I will have accomplished my project goal. The basic project is very open ended, leading to other possibilities. I really want 7 segment LEDs for the display.

 

That is like saying, "Let's build a Bloodhound SSC and let's see how fast this baby will go."

That is not proper engineering design.
You don't just say "build be a fast frequency counter that I can use to monitor heart rate".

You state your specifications and then design based on those specifications, for example, 1000Hz max, three digits, 1Hz resolution, 2% accuracy.

For a run-of-the-mill MCU, it can probably handle 1MHz count rate easily.

 

So,I want a counter 0-999999 7 seg LED digits, as for performance I'll pin that down when I have one, KISS rules.If I get one working I will go from there, This can be anything from a wire wind counter to whatever I dream up.

 

So,I want a counter 0-999999 7 seg LED digits, as for performance I'll pin that down when I have one, KISS rules.If I get one working I will go from there, This can be anything from a wire wind counter to whatever I dream up.

Still missing a crucial specification.
What is the maximum count frequency?

 

At this point I don't care, If it can handle 20KHz I am happy. If it can handle 1Khz good enough. Basically build one as simple and as easy as I can(KISS) and see what it does.

The exercise is in the final product, and learning how to do the basics. If I get a working counter decoder and it maxes out at 5 Hz I am in the game.

 

When programming an MCU sometimes one solution may be just as simple as another solution even though the solution can be totally different.

For count rates under 100kHz, one can use interrupts and increment on every clock pulse received.
For count rates 1-50MHz (depending on the MCU selected) one can chooses a hardware counter to do the counting.

In my opinion, you may as well just count every pulse detected using interrupts. This could be good to 1MHz (assuming that the interrupt service routine takes less than 500ns).

 

While I think I know what an interrupt is, The decoder seems like the big thing. Multiplexing is also a challenge. I've done all of this with hardware, but never with software.

 

While I think I know what an interrupt is, The decoder seems like the big thing. Multiplexing is also a challenge. I've done all of this with hardware, but never with software.

Slow down. Remember, take baby steps.

Firstly, let us take a look at your specifications.
You are looking for six digits, 000000 to 999999.

You are going to encounter two problems here.
(1) Refresh rate. Determine how much time (we call it the dwell time) each digit will be lit while not exhibiting flicker.
(2) Display brightness. As the dwell time diminishes, so does the display brightness.

I have found that beyond 4 digits the displays become noticeably dim.

One solution is to split the six digits into two groups of three digits.
The other option is to reduce the specification to four digits.

Edit: I see that 6-digit mulitplexed LED display modules are available. There is no harm in giving it a try and see the results. The nice thing about SW design is that most things are flexible.

 

Moved one project from an EEPROM state machine to the 8051 but as soon as I saw the Motorola MC68705 with built-on EEPROM socket and at a much lower price the project was switched again. It was the MC68705 that went into production.

I took an 8051 family part jumppered for external program memory and a few other chips and made a lawn sprinkler timer with it. Lasted until we sold the house. Didn't do much else with it, but it was easy enough to use.

 

I will explain the concept of multiplexing from both hardware and software perspectives. It is easier than what you may think.
Before I do that, let us look at the KISS principle.

Sure, we all strive to keep our designs simple.
To quote a saying often attributed to Albert Einstein, "Everything should be made as simple as possible, but no simpler".

Don't confuse elegance with complexity. Even though an elegant solution may appear to be complex, it may happen to be the simplest solution.

Let us look at the number of pins required of the MCU. The solutions range from 1 pin to 42 pins.

1 - The most elegant solution will consume 1 pin. This could be 1-wire, or UART. I have designed instruments with multiple displays using 1-wire interfaces. This is elegance to the max.

2 - SPI and I2C use 2-wire interfaces, simply implemented as clock and data lines

4 + 3 - Four BCD lines and three digit address lines.

7 + 3 - Seven segment output lines and three digit address lines.

7 + 6 - Seven segment output lines and six digit select lines.

6 x 7 - All forty-two 7-segment outputs, non-multiplexed.

Which design is the simplest?
Isn't the 42-line solution the simplest?

Bottom line - Never be afraid to think outside the box.

 

I can live with 6 digits. 7 X 6 = 42 pins + 1 count input. The reason I started this thread is to get a clue, including what MCU to use..

 

I can live with 6 digits. 7 X 6 = 42 pins + 1 count input. The reason I started this thread is to get a clue, including what MCU to use..

Doing that will limit your microcontroller choices. Many don't have that many I/O's.

If you multiplex, you can do it with 13 outputs. If you use some external logic, you can use fewer I/O's.

I have a scrolling clock/message program that uses a single 5x7 LED matrix. I chose to drive the rows directly (7 outputs) and use a CD4017 to drive the columns. That required 9 outputs; 1 each to clock/reset the CD4017, and 7 for the rows.

I'm using an SBC that has closer to 40 GPIO's, but I wanted to be able to control multiple circuits

 

Thinking Outside the Box

John Deere does not sell you lawn mowers. John Deere sells you a green lawn.

A 6-digit counter is not just a 6-digit counter. It is an information display.
I would like to think of it in terms of the front end and the back end.
Which is the front end and which is the back end?
In my view, the front end is the display. The back end is the count input.
Think of what you can do when you separate the two functions.

The Front End

This is the information display.
What are the units?
Where is the decimal point?
What about the +/- sign?
How would you display overflow and error conditions?

If you design this properly you can have some or all of the above.
Would an LCD character display be a better choice?
Would a graphic display be able to provide more information?
Would large digit LCD or LED 7-segment displays give higher visibility in low and high light conditions?
Would LED or LCD with back-lighting be more appropriate?

Once you have chosen the desired style of display, what are other applications for the display?
Why not make the front end flexible so that it can be utilized for those other applications?

(Note that this does not necessarily negate the KISS principle.)

 

Brightness control?

A design technique that I use which is did see eventually described in Intech magazine. A journal for automation professionals is to approach the problem as:

1. Assume you have all the money in the world and list all of the features you would want.
2. Design as if that was what you were building.
3. Decide on what features you absolutely have to have.
4. Build #3 with the "hooks" necessary to add features later.

Your program will take on a different sort of structure, but you generally will not have to do it completely over

There can be multiple ways of doing brightness:
1. A single level
2. A DIM type of level (i.e two levels)
3. Some knob or encoder.

With this example.
1. Nothing extra is required
2. Requires another input (switch possibly)
3. A/D and D/A converter and/or encoder interface.

If you have the pin functionality, you can add it.

When doing stuff purely based on cost, all sorts of stuff comes into play. Usually to reduce the product cost, development times goes up.