How using 1 UART for 2 externals applications

Debugging as in using a special debugger that requires a serial port and a monitor program or debugging as in writing out trace output?

You can not connect two serial ports together using a Y cable. There can not be two transmitters on the same line. Most of the time, you can have two listeners - something that is regularly used to sniff serial data by protocol analyzers. But that requires that the two listeners can accept unknown data without being confused.

In theory, you can use discrete logic to connect two TTL-level signals to the RX of your processor. But the PC would then have to listen in on the GPS data, to be able to find the gaps between the GPS transmissions. That prohibits the use of existing programs, so you would have to spend the time writing your own. That costs a lot of time and money - most probably more than porting your application to a different '51 processor that has a second UART.

It also requires requires that the GPS in all situations sends all (ALL!) it's data in bursts once/second. If it has extra, spurious, output in between, then that data may be corrupted by a concurrent transfer from the PC.

Also, you should only tranmit the TX from the processor to the PC. If you connect the TX to both the PC and the GPS, the PC program may be able to separate init strings sent to the GPS from trace output. However, there is no way of knowing what the GPS will think about receiving any trace output.

In short: Do get a processor with two serial ports, or a processor that you can debug without consuming the UART. For trace output, it is possible to use other devices in the processor, but you would normally not be able to interface those signals with the PC.

Debugging as in using a special debugger that requires a serial port and a monitor program or debugging as in writing out trace output?

You can not connect two serial ports together using a Y cable. There can not be two transmitters on the same line. Most of the time, you can have two listeners - something that is regularly used to sniff serial data by protocol analyzers. But that requires that the two listeners can accept unknown data without being confused.

In theory, you can use discrete logic to connect two TTL-level signals to the RX of your processor. But the PC would then have to listen in on the GPS data, to be able to find the gaps between the GPS transmissions. That prohibits the use of existing programs, so you would have to spend the time writing your own. That costs a lot of time and money - most probably more than porting your application to a different '51 processor that has a second UART.

It also requires requires that the GPS in all situations sends all (ALL!) it's data in bursts once/second. If it has extra, spurious, output in between, then that data may be corrupted by a concurrent transfer from the PC.

Also, you should only tranmit the TX from the processor to the PC. If you connect the TX to both the PC and the GPS, the PC program may be able to separate init strings sent to the GPS from trace output. However, there is no way of knowing what the GPS will think about receiving any trace output.

In short: Do get a processor with two serial ports, or a processor that you can debug without consuming the UART. For trace output, it is possible to use other devices in the processor, but you would normally not be able to interface those signals with the PC.

Hi,

Thanks for all. But yes unfortunatly in the poject we have thinking to add data signals coming from GPS but not think on the UART apsect.

Anyway we are already realize and product this PCB with an AT89C51SNDC1 with only one UART. But I think we can resolve this problem without realizing a new PCB.

I think to 2 solutions to resolve this problem.

So my first possible solution (the one I ask you first) would be have a solution for my problem. In this solution we can use at different time the 2 externals data incoming for example I read data coming from GPS during a short time ( connecting only the RX pin and avoiding press on keyboard for not changing the data incoming from GPS to the µc ) in my infinite loop which look like this:

So my second possible solution will be by
In my PCB I have 4 dipswiches and I can use one of them to check if I am in debug mode or if I am in normal functionning mode. For example if the dipswitch 4 is ON i'm in normal mode (so I suppose to read data coming from GPS and here too only conncting the RX pin )
So in my software perhaps I can check if the dipswitch 4 is on if yes I display nothing ( no printf ) and i do polling on the GPS.

I don't know if you can help me it would be great to
use this same PCB with one UART only to suit this new GPS incoming data and so We will have reduce cost system and will avoid to make a new PCB and lost time.

Thank you.

Sems

Sorry I forgetted to add my infinite loop code:

  // INITIALIZATION

        while(1)
        {

      if ((P1_0 == 1)&&(P1_1 == 1)&&(P1_2 == 1)&&(P1_3 == 1)&&(P3_5 == 1))
          {
      //printf("dans if de while(1)\n");  //0805
           ADC_cpt++;

                if (ADC_cpt == ADC_cpt_end)
                {
                CAG();
                                if (set_tempo)
                    {
                        tempo_1(1/20000000);
                        }
                }
                if (ADC_cpt > ADC_cpt_end)
                {
                                ADC_cpt = 0;
                }
                        micro();
          }
          else
          {
       //  printf("dans else de while(1)\n");  //0805
            ADC_cpt1++;

                if (ADC_cpt1 == ADC_cpt_end1)
                {
                CAG();

                                if (set_tempo)
                    {
                        tempo_1(1/20000000);

                        }

                }
                if (ADC_cpt1 > ADC_cpt_end1)
                {
                                ADC_cpt1 = 0;
                }
                        micro();
          }

        } //End of infinite loop

//End of main program

But I don't know where in this loop to put exactly the reading from GPS. And for facilities i will red only the GPRMC message look like this :

$GPRMC,235952,V,5051.9116,N,00422.3928,E,0.000,0.0,280697,1.

Best regards,

Anyway we are already realize and produce this PCB with an AT89C51SNDC1 with only one UART. But I think we can resolve this problem without realizing a new PCB.
the usual problem: making the hardware before the thingy is thought out.
Also, the cost of another proto spin spread over thousand of units is virtually nothing. Is the fear of making another proto a fear of losing face or what is it?

some suggestions:
1) the simples and best: buy am ICE
2) disconnect the GPS and make it possible to feed "simulated" GPS data fron the debugger

Erik

Or, make it possible for the debugger to somehow "pass-through" real GPS data:

        +-------+
        |       |  Debug + "encapsulated" GPS
GPS --->+.......+-------------------------------> Your
        |       |                                 Device
        +-------+
         Debugger

A simplistic approach would be to simply double the baud rate and send alternate characters from debugger & GPS...

Your DIP switch would select between "real" and "debug" mode...

"We will have reduce cost system and will avoid to make a new PCB and lost time."

Remember that the total system cost must include the cost of developing and maintaining the software.

You need to carefully consider how much this single-UART software bodge is going to cost you - not just in developing it in the first place, but also how it will impact on all your other work:

A bodge like this is almost certain to make testing and debugging more cumbersome - in other words, it will add cost.

Maybe it will turn out to be cost-effective in your particular circumstances - but you must not just assume that!