0

I'm trying to communicate on a com port on a single wire UART(Half Duplex). It's a C# Application with 8 bit MCU.

Here, Application is the master and MCU is a slave. On the MCU the RX is disabled while TX is sending.

The requirement is to make the com port disable the read function while I send data from the Application.

To do this, I tried to pull out from the buffer of RX after it transmits the number of bytes it transmits, but the MCU responds too fast and the last bytes of TX get in between with the response of the MCU.

Note: I can't change anything in the MCU

Here is my CODE:

    public int serialRX()
    {
        int b;
        if (serialPort.IsOpen && (serialPort.BytesToRead > 0))
        {
            try
            {
                b = serialPort.ReadByte();
            }
            catch (TimeoutException)
            {
                b = -1;
            }

            return b;
        }
        else 
        {
            return -1;
        }

    }

    public void serialTX(byte[] data)
    {
        if (serialPort.IsOpen)
        {
            serialPort.Write(data, 0, data.Length);

            byte i = 0;
            int read = -1;

            while (i < data.Length)
            {
                while (read == -1)
                {
                    read = serialRX();
                }
                read = -1;
                i++;
            }
        }
    }
dorin.petre
  • 101
  • 13
  • 2
    You want to hook the `DataReceieved` event instead of calling it (with serialRX). For example: https://stackoverflow.com/questions/466474/how-do-i-use-datareceived-event-of-the-serialport-port-object-in-c – BurnsBA Aug 31 '17 at 14:50
  • Possible duplicate of [How do I use dataReceived event of the SerialPort Port Object in C#?](https://stackoverflow.com/questions/466474/how-do-i-use-datareceived-event-of-the-serialport-port-object-in-c) – Patrick Aug 31 '17 at 15:09
  • Presumably at the PC end you have Tx & Rx connected - as what is being transmitted to the MCU is being received at exactly the same time by the PC then what you are doing should be correct. If the data from the MCU is getting mixed in with the data you are sending - then it is likely the MCU is responding to part of the message you are sending - so you need to break the message up & allow the MCU time to respond. If both the PC and the MCU are trying to transmit simultaneously then it is likely you will get garbage data as both are driving the single line. – PaulF Aug 31 '17 at 15:17
  • 1
    @Patrick: not really a duplicate - with single wire transmission the PC Tx & Rx are connected - if data is coming early from the MCU then the problem will be there whether the data is extracted from the buffer by polling as in the OPs code or event driven - as the data buffer is a FIFO. – PaulF Aug 31 '17 at 15:21
  • You could slow things down & transmit a byte from the PC & read it back before sending the next byte - rather than transmitting the entire message then reading it back byte by byte. – PaulF Aug 31 '17 at 15:24
  • @PaulF the MCU only waits for a CMD; I send a command from the C# app 0x11, 0x22, 0x33 and the MCU responds correctly to it with 0x44, 0x55, 0x66in the read buffer on the C# app I have 0x11, 0x22, 0x44, 0x33, 0x55, 0x66 – dorin.petre Aug 31 '17 at 15:27
  • @PaulF thanks for the suggestion with the transmission byte by byte, but it didn't work after the last byte transmitted I have the same problem – dorin.petre Aug 31 '17 at 15:37
  • This seems very odd, if the MCU is responding after the 3rd byte - this byte will already be in the PC serial buffer so the MCU response will be after. Try transmitting your command without reading & wait a suitable time & check the entire read buffer. You could try the event driven suggestion by BurnsBA. I would also try communicating with a terminal application - something like PuTTY http://www.chipkin.com/using-putty-for-serial-com-connections-hyperterminal-replacement/ or Hype!Terminal https://sourceforge.net/projects/hypeterminal/ & manually typing the commands and watching the response. – PaulF Aug 31 '17 at 15:59
  • Also - where are you reading the response from the MCU - all you have shown is the serialTX? – PaulF Aug 31 '17 at 16:09
  • @PaulF to read I use serialRX – dorin.petre Aug 31 '17 at 16:10
  • Is it on the same thread? – PaulF Sep 01 '17 at 08:58
  • yes is on the same thread, in the end I did implement a packet protocol and I am waiting for the hole packet to receive and it works ... I was hoping to be able to close the RX line while using TX – dorin.petre Oct 02 '17 at 07:21

0 Answers0