I could use some help troubleshooting here. I wrote and tested some code that uses the SerialPort class to communicate with my FT232…both sending and receiving worked great when tested. I am now trying to get the same class working with a PIC. When I open the comport, my TX line on the G30 goes low as it should but when writing a buffer to the comport the line is dormant. This was not the case before and the only things that changed were baudrate and stop bits. All of the writing, receiving, and data handling is the same. It should be noted that I can receive strings from my PIC perfectly fine on the G30’s RX line. Is it possible to have just 1 COM pin short out?
Here is my code that handles the SerialPort() class:
using System;
using System.Text;
using System.IO.Ports;
public class MySerialDevice
{
protected SerialPort commport = null;
protected string commerr;
protected string inbuffer; //local input buffer
protected string newline; //newline character or string
protected object buflocker=new object();
public MySerialUSBDevice(string portName, int baudRate, Parity parity, int dataBits, StopBits stopBits, string newline)
{
inbuffer="";
this.newline=newline;
commport= new SerialPort(portName, baudRate, parity, dataBits, stopBits);
commport.DataReceived += new SerialDataReceivedEventHandler(DataReceivedHandler);
commport.Open();
}
private void DataReceivedHandler(object sender, SerialDataReceivedEventArgs e)
{
const int BUFFER_SIZE = 128;
byte[] buffer = new byte[BUFFER_SIZE];
int amount = commport.Read(buffer, 0, BUFFER_SIZE);
if (amount > 0)
{
char[] characters = Encoding.UTF8.GetChars(buffer);
string received = new string(characters);
// string received = BitConverter.ToString(buffer, 0, buffer.Length);
lock(buflocker){inbuffer += received;}
}
}
public void SendLine(string outstr)
{
try
{commport.Write(Encoding.UTF8.GetBytes(outstr), 0, outstr.Length);}
catch (Exception ex)
{commerr = ex.Message;}
}
public string GetLine() //return last line received or null
{
int pos = -1;
string buffercopy;
// if (inbuffer != null)
// {
buffercopy = inbuffer; //no need to lock when copying a reference (atomic operation)
// }
// else
// { buffercopy = ""; }
if (buffercopy.Length > 0) { pos = buffercopy.IndexOf(newline); }
if (pos >= 0)
{
lock (buflocker)
{
//here inbuffer may have changed and be different from buffercopy but pos is still valid (new characters appended at the end)
string line = inbuffer.Substring(0, pos); //line without terminating string/char
StringBuilder tmp = new StringBuilder(inbuffer);
tmp.Remove(0, pos + newline.Length); //remove line+term. string/char
inbuffer = tmp.ToString(); //save as new buffer
return line;
}
}
else
return null;
}
}Do Jedi Masters @Brett or @Justin have any advice?
To reiterate: the RX line is working fine connected to another device. However, TX is not changing voltage other than when opening the COM port (it did when talking to the FT232). I disconnected the TX line that was going to another device and still the G30 was not transmitting other than the initial opening of the port.
How can I test if the pin was shorted? There is a chance that one of my prototype boards I built shorted it but I am not sure if it would still be able to go low and open the COM port if it were shorted (it clearly is successful in opening the port since it can receive messages).
What are you setting stop bits too.
MySerialDevice dev1 = new MySerialDevice("COM2", 57600, System.IO.Ports.Parity.None, int data bits 8, System.IO.Ports.StopBits.Two, "\r\n");
Whats wrong???
The PIC I am communicating with is set to use two StopBits by the fellow who gave me his GPIB converter design.
AFAIK StopBits.Two is a no go in NETMF but i am happy to be proved wrong.
You mentioned that it worked until you changed Baud rate and StopBits.
Ok that makes sense. I will see if he can change the hex file for me and retry.The person who wrote the PIC code only knows how to read C#, nothing about NETMF. Why does two stop bits cause problems?
Dunno, never tried it - you tell me 
Apparently so if that is indeed the issue.
What happens if you do a simple loopback test?
As in connect the G30 TX line to the RX pin?
yes (10 chars)
what do you mean by 10 chars?
The loopback worked…I could transmit fine (when I tried to isolate TX I didn’t have it plugged into RX, just a scope on the TX pin).
That brings me back to my original theory that the RX line of my co processor has a short (hence why I got the same behavior as when I had TX was unplugged).
@Justin What do you think?
Without seeming your hardware setup i dont see how i can add any value.
What is the co processor?
So your G30 can run a loopback test fine and the issue is on another board?
The co processor (currently on another board for the prototype) is a PIC18F2550. G30 can run a loopback test fine as well as talk to an FT232 perfectly with the same exact code. The board with the issue is a proven design that someone has been making awhile…it just uses the PIC to convert from GPIB/parallel to serial for sending to my micro controller.