Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Transfer data's of seven segment

Status
Not open for further replies.
I would guess your problem is therefore that the signals are inverted. With no segments in the data you get them all turned on instead of turned off. This is probably to do with the drive waveform to the original LEDs being active low.

If it's a problem, just invert the data in software before writing it out to the TX port.

Brian.
 

betwixt said:
I would guess your problem is therefore that the signals are inverted. With no segments in the data you get them all turned on instead of turned off. This is probably to do with the drive waveform to the original LEDs being active low.

If it's a problem, just invert the data in software before writing it out to the TX port.

Brian.
Click to expand...

Hi.. i tried my way out...
now i am able to send data and read it to y RX Board.
but now what my problem is, i am not able to send all the simultaneousely, due to which the display of RX Board gets delay of near about 2 to 3 seconds and sometimes even some data's are missed out.
Code: 
while(1)
	{
		if(segment1==1)
		{
			segment1_var=1;
			seg_data1=P0;	
		  UART_TxChar('1');
		  UART_TxChar(seg_data1);
		}
		if(segment2==1)
		{
			segment2_var=1;
			seg_data2=P0;	
			UART_TxChar('2');
			UART_TxChar(seg_data2);
		}
		if(segment3==1)
		{
			segment3_var=1;
			seg_data3=P0;	
		  UART_TxChar('3');
		  UART_TxChar(seg_data3);
		}
		if(segment4==1)
		{
			segment4_var=1;
			seg_data4=P0;	
			UART_TxChar('4');
			UART_TxChar(seg_data4);
		}
	}

this is the basic code i used to send the data's, so using this code, i am able to print the data in RX board in proper segment.
but as i told you my problem of many a times i miss out some data's.

- - - Updated - - -

i even tried timer0 interrupt for sending the data's and scan the port pin in main().
so what happen here is when the controller sends the data in timer0 interrupt, again some of the data's are missed out while sending.
 

Hi,

our problem is: We see only snippets of code, we can´t know the timing and we can´t see your idea and how you use the variables.

example1:
Code: 
if(segment1==1)
* We don´t know what "segment1" is. It may be a variable, it may be a port...
* you check for status "1". But we don´t see that it changes. Who changes this value? and what´s the timing? How long is it "1" and how long is it NOT "1"?

example2:
Code: 
segment1_var=1;
seg_data1=P0;
* We don´t know what this means. They seem to be two variables. But what are they used for?
* "segment1_var" set to "1" but never set to any other value. This makes no sense to me.
* what is "seg_data1" used for?

example3:
Code: 
UART_TxChar('1');
UART_TxChar(seg_data1);
How do you prevent that this data is sent many times repeatedly?

example4:
i even tried timer0 interrupt for sending the data's
Click to expand...
Is not very useful information as long as we don´t know timer0 period time (and the timing mentioned before)

****
Please understand it´s really difficult to help with this lack of informations.

Klaus
 

KlausST said:
Hi,

our problem is: We see only snippets of code, we can´t know the timing and we can´t see your idea and how you use the variables.

example1:
Code: 
if(segment1==1)
* We don´t know what "segment1" is. It may be a variable, it may be a port...
* you check for status "1". But we don´t see that it changes. Who changes this value? and what´s the timing? How long is it "1" and how long is it NOT "1"?

example2:
Code: 
segment1_var=1;
seg_data1=P0;
* We don´t know what this means. They seem to be two variables. But what are they used for?
* "segment1_var" set to "1" but never set to any other value. This makes no sense to me.
* what is "seg_data1" used for?

example3:
Code: 
UART_TxChar('1');
UART_TxChar(seg_data1);
How do you prevent that this data is sent many times repeatedly?

example4:

Is not very useful information as long as we don´t know timer0 period time (and the timing mentioned before)

****
Please understand it´s really difficult to help with this lack of informations.

Klaus
Click to expand...
Code: 
#include<reg51.h>

sbit segment1 = P2^4;         // SEGMENT - 1 SELECTION PIN
sbit segment2 = P2^5;         // SEGMENT - 2 SELECTION PIN
sbit segment3 = P2^6;         // SEGMENT - 3 SELECTION PIN
sbit segment4 = P2^7;         // SEGMENT - 4 SELECTION PIN

unsigned int segment1_var=0, segment2_var=0, segment3_var=0, segment4_var=0;
char seg_data1, seg_data2, seg_data3, seg_data4, seg_data_copy;

void UART_Init()
{ 
    SCON = 0x50;  // Asynchronous mode, 8-bit data and 1-stop bit
    TMOD = 0x20;  //Timer1 in Mode2.
    TH1 = 0xF7;     // Baudrate 9600
    TR1 = 1;      //Turn ON the timer for Baud rate generation
    PCON=0x80;  
}

void UART_TxChar(char ch)
{
    SBUF = ch;      // Load the data to be transmitted
    while(TI==0);   // Wait till the data is trasmitted
    TI = 0;         //Clear the Tx flag for next cycle.
}

void main()
{
       UART_Init();
	while(1)
	{
		if(segment1==1)         
		{
			segment1_var=1;
			seg_data1=P0;	
		  UART_TxChar('1');
		  UART_TxChar(seg_data1);
		}
		if(segment2==1)          
		{
			segment2_var=1;
			seg_data2=P0;	
			UART_TxChar('2');
			UART_TxChar(seg_data2);
		}
		if(segment3==1)
		{
			segment3_var=1;
			seg_data3=P0;	
		  UART_TxChar('3');
		  UART_TxChar(seg_data3);
		}
		if(segment4==1)
		{
			segment4_var=1;
			seg_data4=P0;	
			UART_TxChar('4');
			UART_TxChar(seg_data4);
		}
	}
}

Sorry... for previous information which was partly provided.
this is the complete code which i am using to scan the port pins for which segment is selected and also scanning the PORT-0 for the status. and sending it to other controller using serial communication.

- - - Updated - - -

so in this case many a times, i am missing out some data's, because at the time of sending the data's serielly, the controller is not able to scan the ports for that specific time, due to which i am getting data loss
 

Still doesn't make much sense to me. Segments and digits still seem to be crossed over too.

Try it like this:
Electrical
Connect the SEGMENTS (the connection to the individual bars on one digit) to one port on the TX,
Connect the DIGITS to another port on the TX.
TX software
Convert the 10 possible combinations of segments (0-9) into the binary numbers 0-9.
Wait for a change in the digit value so you know the next segment data is available.
Convert the digit value into binary 0-3 (four combinations, one for each digit).
Shift the digit value 4 places to the left then AND it with the segment value. The result is bits 00DDSSSS.
Send it to the UART or at least hold it until the UART is free to send more.
go back to looking for the next change in digit value.

RX Software
Get the byte from the UART.
Split it into upper and lower 4 bits. Upper is the digit number, lower is the value that digit should display.
Decode the digit number into 4 port bits. These are replicas of the original digit drive signals.
Decode the digit value into the corresponding 7-segment values.
Output both values to ports.
Go back to looking for more data from the UART.

It should only be a few lines of code. Use look-up tables to do the segment decoding.

Brian.
 

betwixt said:
Convert the 10 possible combinations of segments (0-9) into the binary numbers 0-9.

Brian.
Click to expand...

yes, but the combination will be more than 10 because it also print Alphabets like: 'A', 'C', 'L', 'F', 'H', 'P', 'S', 'E',
 

No problem, all it has to do is recognize the different segment patterns and encode them into the minimum number of bits. There are only 80 possible combinations of segments plus 'none' so every possible digit, character and shape can be represented in 7 bits at most but I suspect most combinations are meaningless so you can shorten it to 6, still leaving two bits to carry the digit number.

Look here for clues:
https://puzzling.stackexchange.com/...ou-create-with-only-one-seven-segment-display

Format the data through the UART as DDSSSSSS and it will still work.

Brian.
 

betwixt said:
No problem, all it has to do is recognize the different segment patterns and encode them into the minimum number of bits. There are only 80 possible combinations of segments plus 'none' so every possible digit, character and shape can be represented in 7 bits at most but I suspect most combinations are meaningless so you can shorten it to 6, still leaving two bits to carry the digit number.

Look here for clues:
https://puzzling.stackexchange.com/...ou-create-with-only-one-seven-segment-display

Format the data through the UART as DDSSSSSS and it will still work.

Brian.
Click to expand...
I agree with your concept.
but what the problem might be is when the controller will send data through UART, again he will miss out some scanning for that particular time. which i am already facing a problem
Let me put a try on this. because in my case i need to send data twice, one for segment location and then again segment data. so might me in your case, where i am sending the data only once, might reduce the data loss.
please help me for the code.
initially what i have to do is:
Code: 
char seg_no
char seg_data
so now here i can use seg_no to store the segment No and seg_data for segment data's.
now i will scan for which segment is selected.
suppose we assume that segment 1 is selected.
so the code would be :
Code: 
if(segment1==1)  // scan is segment 1 is selected
{
  seg_no=1;            write 1 to seg_no as segment 1 is selected.
 seg_data = P0;      write port status to seg_data.
}
but now how can i convert this 8 bit of seg_Data and 1 bit of seg_no to 7 bit of data which i need to transfer.
 

I understand what you are trying to do but you complicate things by confusing segments and digits.

A segment is an individual bar making up the shape of a number. A digit is the whole single number.
So for each digit there are 7 segments plus a dot. Your whole display has four digits.
That means you have to TX a value that identifies which segments are lit and also a value identifying which of the four digits the segment value came from. By encoding the values you can fit them into a single byte.

I can't help you with 8051 coding because the last time I used one was about 30 years ago and I do not presently have a compiler suitable for 8051 source code but the same principle applies to all processors.

At the TX end:
Step 1:
First list all the possible combinations of segments you are going to use, you should have a list like 0,1,2,3,4,5,6,7,8,9,A,b,c,C,d,E,f,H,h,-,L,P and possibly other special shapes.
Convert the segment patterns into binary 'on/off' bits so a '1' is for a segment lit up and '0' is for one un-powered. I strongly advise you to use the convention of segment 'A' being the top then working clockwise to 'F' with 'G' being the center bar. Make segment 'A' the least significant bit of the binary number so it looks like this 'GFEDCBA' and if you need the decimal dot add it as the MSB.

Step 2:
Sending the binary representation of segments can be done but is would need all 8 bits if you use one bit per segment. It makes sense to ignore the segment combinations you are not going to use. For example, if you only use the ones I listed earlier there are only 22 combinations used and you can squeeze that into 5 bits if you encode them. Use a look up table to convert each of the segment combinations you need into a unique number, something like this:
displayed -- segments -- binary -- unique number (x = not lit)
0 -- xxFEDCBA -- 00111111 -- 00000
1 -- xxxxxCBx -- 00000110 -- 00001
2 -- xGFxDxBA -- 01101011 -- 00010
.
.
H -- xGFExCBx -- 01110110 -- 01100

So now for each possible character you display there is a unique 5-bit number.

Step 3:
You have four digits so you need to identify which of them the segment data refers to. Read in the four digit select signals from the display driver. Encode the four signals into two bits:
0001 = 00
0010 = 01
0100 = 10
1000 = 11
so you now have a two bit number that identifies which display was active when the segment data was valid.

Step 4:
Combine the 5-bit segment data with the 2-bit digit data. Do this by shifting the digit data (call it DD) to the left then ANDing it with the segment data (call it SSSSS) so you get a single byte of '0DDSSSSS'. This contains 'which digit' and 'what it displayed' data.

Step 5:
Transmit the 0DDSSSSS byte through the UART.

Step 6:
The digit select signal and the segment data on the display is constantly changing so you need to be sure you don't read them while they are showing half of one number and half of another. The easiest way to do that is to wait until you see the next digit select signal appearing so monitor it for change. When you see it change, immediately read in the segment values.

At the RX end:
Step 1:
Read the next byte from the UART.

Step 2:
Split the bits so the two 'DD' bits and the five 'SSSSS' are in different variables.

Step 3:
Convert the DD bits back to four pin signals, these will drive the digit selects at the receiver display.
Use a look-up table to convert the SSSSS bits back to their original segment patterns (the reverse of what was done at the TX end)

Step 4:
Output the signals through appropriate drivers to the four digits at the RX end.


Brian.
 

betwixt said:
I understand what you are trying to do but you complicate things by confusing segments and digits.

A segment is an individual bar making up the shape of a number. A digit is the whole single number.
So for each digit there are 7 segments plus a dot. Your whole display has four digits.
That means you have to TX a value that identifies which segments are lit and also a value identifying which of the four digits the segment value came from. By encoding the values you can fit them into a single byte.

I can't help you with 8051 coding because the last time I used one was about 30 years ago and I do not presently have a compiler suitable for 8051 source code but the same principle applies to all processors.

At the TX end:
Step 1:
First list all the possible combinations of segments you are going to use, you should have a list like 0,1,2,3,4,5,6,7,8,9,A,b,c,C,d,E,f,H,h,-,L,P and possibly other special shapes.
Convert the segment patterns into binary 'on/off' bits so a '1' is for a segment lit up and '0' is for one un-powered. I strongly advise you to use the convention of segment 'A' being the top then working clockwise to 'F' with 'G' being the center bar. Make segment 'A' the least significant bit of the binary number so it looks like this 'GFEDCBA' and if you need the decimal dot add it as the MSB.

Step 2:
Sending the binary representation of segments can be done but is would need all 8 bits if you use one bit per segment. It makes sense to ignore the segment combinations you are not going to use. For example, if you only use the ones I listed earlier there are only 22 combinations used and you can squeeze that into 5 bits if you encode them. Use a look up table to convert each of the segment combinations you need into a unique number, something like this:
displayed -- segments -- binary -- unique number (x = not lit)
0 -- xxFEDCBA -- 00111111 -- 00000
1 -- xxxxxCBx -- 00000110 -- 00001
2 -- xGFxDxBA -- 01101011 -- 00010
.
.
H -- xGFExCBx -- 01110110 -- 01100

So now for each possible character you display there is a unique 5-bit number.

Step 3:
You have four digits so you need to identify which of them the segment data refers to. Read in the four digit select signals from the display driver. Encode the four signals into two bits:
0001 = 00
0010 = 01
0100 = 10
1000 = 11
so you now have a two bit number that identifies which display was active when the segment data was valid.

Step 4:
Combine the 5-bit segment data with the 2-bit digit data. Do this by shifting the digit data (call it DD) to the left then ANDing it with the segment data (call it SSSSS) so you get a single byte of '0DDSSSSS'. This contains 'which digit' and 'what it displayed' data.

Step 5:
Transmit the 0DDSSSSS byte through the UART.

Step 6:
The digit select signal and the segment data on the display is constantly changing so you need to be sure you don't read them while they are showing half of one number and half of another. The easiest way to do that is to wait until you see the next digit select signal appearing so monitor it for change. When you see it change, immediately read in the segment values.

At the RX end:
Step 1:
Read the next byte from the UART.

Step 2:
Split the bits so the two 'DD' bits and the five 'SSSSS' are in different variables.

Step 3:
Convert the DD bits back to four pin signals, these will drive the digit selects at the receiver display.
Use a look-up table to convert the SSSSS bits back to their original segment patterns (the reverse of what was done at the TX end)

Step 4:
Output the signals through appropriate drivers to the four digits at the RX end.


Brian.
Click to expand...

Thanks for the great explanation.
as per your concept, i have a question, rather than increasing the software part and making the controller busy in doing the calculations and conversions, cant we use 2 encoder IC where we can covert 16 bit to 8 bits and that 8 bits can be transferred to RX board and again can interface 2 decoder ic at RX side.
 

Hi,

rather than increasing the software part and making the controller busy in doing the calculations and conversions,
Click to expand...
comparing a byte with the informations form the segments with a table of - let´s say 32 bytes (table items) of possible codes (sadly you don´t give the count of different codes)
* It takes time for you to write the table (32 bytes?)
* maybe takes less than 10 instructions and can be processed within some tens of microseconds

...
Then some AND and ORs to combine it with the "digit" informations.
* takes another processing time in the range of 1us..
* and a couple of instructions.

*****
Now compare this time and effort with the time for this thread. I lasts now for more than a week...

And compared to your uncontrolled_sending_out_bytes_code....it may easily take less than 1/1000 of processing time.

*****
If you followed the given recommendations ... it should run now at least for 6 days.

*****
Thus again my recommendation:
First things first:
* Decide all the given informations, like timing (did you give a single timing information til now?) and signal levels and so on . from the existing display.
* Then decide your requirements. How often do you want a display update on the Rx side and so on....
* do some decisions about tranission time (baud rate, amount of data)
* draw a flow chart. At first a flow chart just for the informations (data). just two boxes (Tx, Rx) with a line inbetween (UART transmission) and write all known informatons to it.
* then go into details
* then draw a flaow chart for your software
* and afther there you have all the details...Yes.. then at least start to write code.

I know this sounds boring and maybe you think it´s a waste of time ... But without a plan you still will struggle in a couple of weeks.

Klaus
 

Bottom line: Yes you can do it in hardware but you already have a processor and software is free.
Follow Klaus's advice - define the problem accurately and you find the optimal solution.

Brian.
 

betwixt said:
Bottom line: Yes you can do it in hardware but you already have a processor and software is free.
Follow Klaus's advice - define the problem accurately and you find the optimal solution.

Brian.
Click to expand...

Thanks...
i will definately follow your's and Klausst advice..
will try implementing the same in the software.. if any problem arises, will be back
 

If my memory serves me well, there is (was?) a device for converting 7 segment data back to BCD, I think it was numbered 74C915 but it probably hasn't been made for many years. These days if it has to be done in hardware a simple programmable device can do the job easily and cheaper. I'm not sure it could decode the extra characters you need anyway.

Brian.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top