A Friend sent this to me. I am doing a similar project for school but instead of 8 bit input number I need 16bit input number with five 7segment displays output. What part of this do I need to edit to get that result and how?? pls HELP

 

Do you understand how each part of what your friend sent you works to display an 8-bit number?

Do you understand the relationship between binary and BCD representations?

There are multiple ways to convert binary to BCD. Do you understand any of them that you can build upon?

 

Does it actually say that you must display the number IN DECIMAL?
It would be a lot easier to display it in octal or hexadecimal!

 

Yes I do understand but I think I can just use elements from proteus like bin to bcd converter (74185). I dont have to make them in modul. Then I think that this that my friend has sent me is actually useless for this project. The only additional requirements are BIN->BCD->7SEG

 

Yes I do understand but I think I can just use elements from proteus like bin to bcd converter (74185). I dont have to make them in modul. Then I think that this that my friend has sent me is actually useless for this project. The only additional requirements are BIN->BCD->7SEG

You will need about sixteen 74185 chips to convert a 16-bit binary value to BCD.

 

You will need about sixteen 74185 chips to convert a 16-bit binary value to BCD.

Do you have another solution?

 

Do you have another solution?

What's wrong with that solution?

 

What's wrong with that solution?

Okay I will try something probably tomorrow because It's late right now and I will get back to you

 

The 74185 is obsolete and thus expensive to buy.

One other simple way to convert binary to BCD is to have a parallel-load binary down-counter and a BCD up-counter operating from the same clock.
You load the binary word in the binary counter, and then count that down to zero while clocking the BCD counter up from zero.
Thus when the binary counter reaches zero, the BCD counter will contain the binary number in BCD.
You could use a BCD counter with a 7-segment output such as the CD4026, CD4033, or CD40110 to minimize parts count.
That would require four 4-bit binary counters, and five BCD counter/drivers.

The conversion can be somewhat slow for large numbers [requiring 65,536 clock pulses for the maximum 16-bit count conversion (66ms for a 1MHz clock) ], but that's generally fast enough for a visual display, and it uses a (edit) minimum low amount of hardware that is relatively easy to implement.

Generating the load-count-reset timing circuitry to perform that function is left as an exercise for the reader.

 

I would think that the minimum hardware would be to use a ROM-based lookup table, with an MCU-based solution coming in second.

 

I would think that the minimum hardware would be to use a ROM-based lookup table, witch an MCU-based solution coming in second.

Well you still need added circuits to provide the 7-segment signals from the ROM or MCU (at a minimum).
And both those would seem to be more complicated to implement than the counter scheme.

But I will amend my post to say, a low amount of hardware, if that makes you feel better.

 

Well you still need added circuits to provide the 7-segment signals from the ROM or MCU (at a minimum).
And both those would seem to be more complicated to implement than the counter scheme.

Why? Particularly for the ROM based solution.

It's a shame that for 16-bits you need 35 segment signals, otherwise you could use a ROM with a 32-bit data bus and pretty much be done with it (provided the ROM outputs could supply the needed current, but that's an issue that has to be considered no matter how things are done). There are a few ways to skirt this, though. Perhaps the simplest is to pick one of the displays and use a 7447 driver for it, thus reducing the number of ROM output signals to 32. It's kludgy, but hey. Another is to multiplex the segments and drive either two or three at a time. If driving three at a time, you need 21 segment outputs and two enable outputs, so you either need a 32-bit data bus ROM or two 16-bit. You also need an oscillator to toggle the banks, but a 555 or other simple oscillator would work fine -- and the counter-based scheme not only needs an oscillator, but control logic to ensure the correct number of clock cycles to the counters. If you drive two at a time, you only need 14 segment outputs (and, thus, a single 16-bit I/O ROM will suffice), but you do need three bank signals and so generating those becomes a bit more involved, but a 7474 can handle the additional burden quite nicely.

 

I think I can just use elements from proteus like bin to bcd converter (74185).

That device can't be used for simulations in Proteus. Reference this post.

 

Why? Particularly for the ROM based solution.

The complexity is, you need the tools and equipment to program the ROM (unless you can buy one already programmed).

And your ROM solution doesn't sound all that simple to implement.

and the counter-based scheme not only needs an oscillator, but control logic to ensure the correct number of clock cycles to the counters.

That can be done with simple sequential logic.

The clock is inhibited to both counters when the binary count-down reaches zero (from the count-down counter carry-out signal) along with the BCD value being latched into the 7-segment register.
The binary counter is then parallel loaded at the next clock cycle with the new binary number, along with the BCD counter being set to zero.
The count-down then starts on the clock following that.

The complete logic can be done with two D flip-flops (one IC package).

 

I agree that the equipment/software to program the ROM are an additional burden, but they are effectively NRE that amortize very quickly. It only takes a small number of projects to fully recoup the investment in both time and money.

I don't see how the ROM solution is so hard to implement. For the 32-bit wide ROM, connect four data lines to a 7447 and the other 28 directly to the seven-segment displays via appropriate current limiting resistors. Apply the 16-bit value to the address line and hard tie the control bits on the ROM so that it outputs data. Not much else to it. If you want to ditch the 7447 and use 16-bit wide ROMs, then just put one ROM feeding two 7-seg displays and just use three ROMs, each having the same data applied to them. Can't get much simpler than that. Each ROM would have a different program, but data image can be generated from scratch with a simple program in almost no time -- a Python script could be written in about fifteen minutes.

 

a Python script could be written in about fifteen minutes.

For you perhaps.
For me it would be more like 15 days or perhaps weeks.

So, I guess which method to use will depend upon the TS's programming abilities and preferences.

 

For you perhaps.
For me it would be more like 15 days or perhaps weeks.

I think (hope?) that you are selling yourself short.

def seven_seg(v):
    #                   abcdefg
    if 0 == v: return 0b1111110
    if 1 == v: return 0b0110000
    if 2 == v: return 0b1101101
    if 3 == v: return 0b1111001
    if 4 == v: return 0b0110011
    if 5 == v: return 0b1011011
    if 6 == v: return 0b1011111
    if 7 == v: return 0b1110000
    if 8 == v: return 0b1111111
    if 9 == v: return 0b1111011
   
    return 0b0000000

for i in range(2**16):
    rom0 = (seven_seg((i//10)%10)<<8) + (seven_seg((i//1)%10))
    rom1 = (seven_seg((i//1000)%10)<<8) + (seven_seg((i//100)%10))
    rom2 = (seven_seg((i//10000)%10))
    print("%05d %05d %05d" % (rom0, rom1, rom2))

Not the most efficient code, but it took 13 minutes to develop and implement it. Most of that time was walking through the ten values and determining the segment values.

Instead of printing it to the console, you'd just write each romN value to a text file in the appropriate format for whatever programmer you are using.

It would be a minor tweak if you wanted leading zero blanking (the seven_seg() function just needs to have something other than 0-9 passed to it).

It would also be an easy tweak to map the data bits so that they match the natural PCB layout instead of the "obvious" logical mapping used here.

While Python makes some of this easier, there is nothing above that isn't easily done in C or Java or whatever your preferred language is.

 

I think (hope?) that you are selling yourself short.

I think you may be overly optimistic.
Since the only programming I've ever done is with Basic many years ago, with a very minor dabble with C, my time estimate is probably reasonable.
Likely programming to you seems simple ("easily done" as you said), the same way that analog and basic digital circuits to me seem (mostly) simple.
Other than the words If, For, In, Return, Range, and Print, the arcane notation in your example is mostly Greek to me, I suppose rather like a programmer looking at a circuit schematic.
If I said the analog circuits I design were "easily done", I imagine some would disagree.

It's largely a matter of experience in a given field.

 

I think you may be overly optimistic.
Since the only programming I've ever done is with Basic many years ago, with a very minor dabble with C, my time estimate is probably reasonable.
Likely programming to you seems simple ("easily done" as you said), the same way that analog and basic digital circuits to me seem (mostly) simple.
Other than the words If, For, In, Return, Range, and Print, the arcane notation in your example is mostly Greek to me, I suppose rather like a programmer looking at a circuit schematic.
If I said the analog circuits I design were "easily done", I imagine some would disagree.

It's largely a matter of experience in a given field.

There's certainly some validity to all of that, but one thing to keep in mind is that students in nearly any EE curriculum today are expected to take some programming courses, usually C, and that the logic in solving this is (or should be) covered in the first portion of any programming course. The only operators used are integer division, remainder, left-shift, and addition. The logic is very straightforward, whether it is being implemented in digital hardware or software, and translating the logic to C or Basic or Java or any other (at least imperative) language is also straightforward.

Here's the C translation:

#include <stdio.h>

unsigned seven_seg(unsigned v)
{
    //                            abcdefg 
    if (0 == v) return 0x7E; // 0b1111110
    if (1 == v) return 0x30; // 0b0110000
    if (2 == v) return 0x6D; // 0b1101101
    if (3 == v) return 0x79; // 0b1111001
    if (4 == v) return 0x33; // 0b0110011 
    if (5 == v) return 0x5B; // 0b1011011
    if (6 == v) return 0x5F; // 0b1011111
    if (7 == v) return 0x70; // 0b1110000
    if (8 == v) return 0x7F; // 0b1111111
    if (9 == v) return 0x7B; // 0b1111011
    
    return 0x00; // 0b0000000
}

int main(void)
{
    unsigned i;
    unsigned rom0, rom1, rom2;
    
    for (i = 0; i < 65536; i++)
    {
        rom0 = (seven_seg((i/10)%10)<<8) + (seven_seg((i/1)%10));
        rom1 = (seven_seg((i/1000)%10)<<8) + (seven_seg((i/100)%10));
        rom2 = (seven_seg((i/10000)%10));
        printf("%05d %05d %05d\n", rom0, rom1, rom2);
    }
    return 0;
}

Of course, the seven_seg() function screams out for the use of a switch() statement.

 

And all of this can be replaced with one line of code if you use an array.