Well, not exactly ...

The option is always available to generate an external bus, which would allow the data to be shipped from P0 to 10 '273 types instead of 10 '595 types. From there it could, in fact proceed as with the SIPO registers. That way he could avoid having to disassemble the bytes in firmware. It would also reduce the load in other respects.


While it's possible that there might be other tasks for the MCU to accomplish, a self-contained sign wouldn't likely have much to do other than to receive characters and to display them. In any case, the O/P certainly hasn't indicated he had to accomplish anything else. Consequently I wouldn't think this task is particularly taxing for a typical 11.05 MHz 8052. With a character store of 160 bytes and having to store, in a circular buffer up to eight, and at least six bytes of pixel array per character to disassemble if he chooses to use the serial distribution path, I'd guess he already has to have an external memory bus. Further, I'd bet it takes less time and less code to ship them to the 160 external cathode-driver registers over a parallel bus rather than a serial bus. He then can use P1 to control the MOSFETs or BJT's that drive the rows of anodes.


Yes, but why? The O/P didn't ask how to do this with an ARM. He asked how to do this with an 89S51.


I hope you're right about those manufacturers, and I'm sure that's true of most of them. The rest will go away, a product of natural selection.


That's right! They didn't become clever designers by considering only one approach, though.

Further, the purpose of a discussion such as this one is not to demonstrate to the world how clever we are, but, rather, to bring as many considerations to the surface for observation and discussion, both the promising and sensible ones, and also the ones that are less-so. That way those who are interested and possibly learning about something new, will gain some understanding of why some things are summarily rejected while others are not. Simply seeing that they're rejected doesn't always tell the whole story.


The O/P's not worried about that ... yet ...


Signs and other indicators I see every day use multiple LED's. One local traffic engineer told me that the traffic signals they use, which have LED's rather than incandescent lights, multiplex their 480 or so LED's and have one driver per LED. That may not be true of every such item, but that's interesting just the same.

The hardware/firmware tradeoff is an important one. For a volume-manufactured product, it's only necessary to pay, through the nose, perhaps, but still, for the firmware development once, while the hardware has to be shipped in each product. Yes, there's upgrade and maintenance effort that will follow, but the hardware has to be bought for each product that's shipped.


"multiple output lines"? ... I'm not sure I understand what you mean here.



First of all, they are stupid for not considering all possible notions. Few of them do because they're busy trying to copy or improve on someone else's design because they know that with a bit of effort, that can be made to work successfully. There's more risk in trying something new. They fact that they, even briefly, consider something ultiately unworthy doesn't mean they're overthinking the matter. It simply means that they reject a concept after giving it some thought rather than simply rejecting it out of hand.

Successful designers do what they do because they've thought about it. They also have thought about the things that they don't do and know why they don't do them. Sometimes they choose a given path for expediency's sake, and sometimes for personal preference when there's no overwhelming advantage between multiple choices. They still know why they do what they do and why they don't do something else.

Most often manufacturers with a plan to produce a new product hire an engineering team that's done the job before, and let them go when the job's done. That leads to functional products but seldom leads to innovation. In the rare case in which the designers have actually thought over all the available options and tailored their solution to the current requirements, well, there's opportunity for innovation if they work to optimize their design, and not just to meet schedule and get paid. Sadly, the latter is much more common than the former.

As for why we bother to discuss this, in light of the fact the O/P hasn't provided enough information to allow any reasonable construct to be developed, well it's to force these issues to the surface for discussion where everyone who's interested can see them. Most people have an approach to this sort of task, but maybe they could benefit from seeing how someone else might attack the problem.

RE