Aamir Javaid is probably not concerned with issues of manufacturability, for now. He's probably not concerned with EMC, and he's probably not concerned with power consumption. He's probably not even concerned with efficiency, for now. He simply wants to get ONE of these displays to work.

I think we should help him get that done by offering him options and methods rather than solutions. If this is a homework assignment, it will help him learn. If it's a practical problem either work or hobby, he certainly needs to learn this stuff and to make these choices.

We all know that he can either drive his display directly or with multiplexing. That's a choice he will have to make.

Aamir Javaid doesn't care how many pins he uses. The MCU has at least plenty for his task. Aamir Javaid doesn't care how clever the design is, for now. He simply wants to make it work. I suspect he'd like it to be handed to him, ready to fabricate, but I am hostile to that notion. We can help him without doing his work/learning/thinking for him. Over the long-term, that will help him more.

Aamir Javaid has told us what his MCU is. He's told us what his display configuration will be. He's told us what he wants it to do. Aside from that, he's said precious little about the low-level details.

Aamir Javaid has to tell us what the LED array he's planning to use is, and how it's wired. His choice may considerably limit his options.

There's no question that he can multiplex his display. With the LED array that I foolishly chose for its packaging/appearance, as an example, it's unlikely he can drive it without multiplexing. He can multiplex by rows, which would lead, presumably, to 1/16 or 1/8 duty cycle, or by columns, where he'd have many options if his drivers are configured properly. He could drive columns with the ULN2803's he's implied he'd use in that incorrect schematic he posted and/or he could drive rows using a transistor of some sort(MOSFET of BJT).

There's little doubt that he can do this job if he provides some additional data memory via an external bus. If he has that bus, he can use it to attach latches of the '273 (for 7- or 8-bit field width) or '174 for 6-bit width (I mention 6-bit width because (a) he can provide the 6-bit width as in his posted illustration and (b) he can "borrow" the content of a commercial character generator ROM rather than having to create his own if he uses that width. The same is true with a 7- or 8-bit width, of course.)

With that parallel data path, he can then treat the LED array as an 80x16 array, ignoring the 8-bit width of a module, which might require he build a PCB.

The paths through the LED array, including current limits would be essentially the same as with the serial path previously discussed, i.e. whether he uses PISO and SIPO combination, just a SIPO set, with registers, is entirely arbitrary. This allows the LED interface to be isolated from the image generation and data transport.

Aamir Javaid has to tell us what the LED array configuration will be, that is, he has to tell us precisely how the LED's are interconnected with the drivers and supply.

Aamir Javaid seems to have issue with the business of driving a single LED. If he takes a transistor of the type he intends to use, using that to supply the positive rail to his single LED, computes the correct resistor value, and places that correct resistor in the cathode, then drives the cathode LOW through that resistor with his ULN2803A, he should be able to see the LED glow.

Aamir Javaid must determine whether he intends to multiplex his display or drive it in steady-state. Until he tells us that, we can go no further.

You, Per, and I can debate issues of practicality and manufacturability and economy until hell freezes over, but it will not address Aamir Javaid's query, so let's stop doing that. If you want to debate those matters, they should, I believe, appear in a separate thread. I'd request, however, that, in the future, you read ALL of my comment, and not just the early part, before replying. I believe, because of this, you assume facts not presented in the discussion, or contrary to facts already presented. This is a common mistake, and not a personal critique. Entirely too much bandwidth has been consumed by such error, here and elsewhere.

Let's not forget, the thread belongs to Aamir Javaid.

RE