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.

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!

Apart from the cost of the PCB re-spin, the per-unit additional cost of a debug port is virtually nil:

All you need to provide on the board is a 3-pin header; the RS232 transceiver can reside off the board, as you only need it when actually connected to the debugger.
In fact, for production boards, you might not even fit the header!

Often, in places, where tools (e.g. ICEs) and respins are scarce, you will find that it is an accounting issue. The salary of those who work forever to manage without proper tools is in a different column than the cost of the tools/respins required for efficient work.

I recall a place, that shall remain unnamed, where the staff was (in my opinion) at least 3 times larger than it should be with proper support. A request for CodeWright (~$300) was refused "not room in the budget". Of course, things like respins, ICEs, faster PCs were totally out of the question. When I (quickly) decided that that was not a place for me, I had 'a talk' with the boss and his statement was "no competent IT person (yes he used that 'title' in an embedded shop) need stuff redone or fancy tools".
I recall the weeks of work (at ~$50/hour salary and benefits) spent poring over schematics to make sure that no respin (~$500 once) would be needed.

So I told him that my desire to be productive eveidently made me incompetent and left.

Erik

Thanks all,

Yes the software development can cost much too.

for the moment I can not realize a new PCB but in the future maybe anyway if I can use this new GPS application with the existent PCB it will be too an software investment for the new future project.

so your propositions are very interristing.

Using of an ICE ( I think to a JTAG system isn't it?) if yes how use it like simulation or debug?

And the encapsulated GPS data this is very interresting too (normally the data incoming from GPS on port com at 4800 baud/s) Knowing that the using of rx tx of the µc is at 19200baud/s. How must I encapsulate the gps data for using the debugging (seeing what happens in a console changing some settings etc..) and GPS data on the same UART ?

And finnaly using only GPS data on the single UART of the µC but this way will be difficult to debug (see what happens on a console) so difficult too to impement the receiving GPS data. (problem coming from problem :( ).

Could you help ùe to implement the good software for resolving this problem?

Thank you
Best regards,

Multiplexing the data could be done by limiting the two streams to 7-bit data, and using he 8:th bit as selector.
This would allow a PC program to send typed characters immediately to your application.

An alternative could be to multiplex a full line at a time, i.e. the first character received after a newline character is the mux character, specifying if the next line of text is NMEA data or debug data.

Both alternatives requires you do write a little application on the remote side, to pick up GPS data from an external GSM module (or simulate it) and feed in one mux channel, and to display some form of console or GUI for the monitor interface.

If you have existing code, it can be done fast and cheap. If you start from zero, the required time can be very high - especially if you have never worked with serial ports on Windows, Linux or whatever OS you run.

Which, of course, begs the question: would that time be better spent re-spinning the PCB...?

;-)

I would definitely have selected updated hardware. The spin-off from a better suited hardware can potentially lead to other market niches being available.