|
There are many mistakes in your message now, you really should brush up on C# IMO.
The other overload of Write() obviously is called Write() too, it differs by its parameter list (it takes a byte array instead of a char array).
There are basically two ways of operating a serial port:
- either you claim it all is text and let the system handle the details;
- or you take charge of each and every byte, i.e. you let the system treat it as bytes-not-to-be-touched.
WriteLine() is a text-oriented method, it deals with characters (which are 16-bit normally) AND appends a NewLine (which on Windows by default contains CR LF). That is NOT what you want.
I've had some trouble with SerialPort and ASCII (or any other single-byte) text. In my experience the default Encoding is Unicode, and NOT ASCII, no matter what the doc says; Unicode would send the low and high bytes of the 16-bit character value. Sometimes setting once Encoding=Encoding.ASCII explicitly before sending/receiving anything seems to suffice, however I generally prefer to take full control, hence use byte arrays.
In byte[] bytArr = new byte[] { p, i, n, 2, =, 2 }; the assignment is OK, it is the initialization that is faulty; you can't type letters like that, they need single quotes; and then the compiler would tell you a character doesn't fit in a byte.
One way would be:
byte[] bytes=new byte[6];
bytes[0]=(byte)'p';
...
|
|
|
|
|
Hi Luc,
You'll have to forgive my ignorance, serial data and byte arrays are something I have not ever done until now.
The byte array with the overload is not working, so it looks like I will just have to figure it out through attrition. For some reason the simpleserial object works, but I can't mimic that in my own test program, the only difference that I can see is that the keypress event is occurring and capturing each character and sending it that way. I don't know how this event changes things, but it appears that it does. When I port this over to the simpleserial object for testing, and use the byte array or char array, the simpleserial object breaks, when it put it back to the code below with writing a single char from a char array, it works fine.
private void textBox1_KeyPress(object sender, KeyPressEventArgs e)
{
if (!serialPort1.IsOpen) return;
char[] buff = new char[1];
buff[0] = e.KeyChar;
serialPort1.Write(buff, 0, 1);
}
|
|
|
|
|
You're still sending text, and so you are probably back now at sending two bytes, the one you intend and a NULL, as e.g. 'A' in ASCII is 0x41 but in Unicode it is 0x0041.
try this:
byte[] buff=new byte[1];
buff[0]=(byte)e.KeyChar;
serialPort1.Write(buff, 0, 1);
Once that works, fill an entire byte array as I told you before. That should work too, except there is a tiny chance your target isn't coping with a byte array at top speed, I noticed you are using a high baud rate, no parity, and a single stop bit, which is about the fastest you can hope for, however it might flood the target; remember for serial port, the source must use at least as many stop bits as the target is expecting, more is fine, less is not.
|
|
|
|
|
Yes your example did work correctly. I understand what you are saying with the preceding null character and sending a word instead of a byte.
The uC is set to 115200, 8N1 and it has been ok at this speed using prebuilt terminals.
I have been trying to fill a byte array as instructed, but it is not working as the previous example. I believe text is still being sent, but I am not sure as to why at this point.
byte[] buff = new byte[1];
buff[0] = (byte)'a';
serialPort1.Write(buff, 0, 1);
No luck with this either
byte[] buff = new byte[3];
buff[0] = (byte)'a';
buff[1] = (byte)'b';
buff[2] = (byte)'c';
serialPort1.Write(buff, 0, buff.Length);
|
|
|
|
|
Those two snippets look OK, they send bytes, not text. There may be text in the bytes, but technically it is binary data as far as the PC can tell. Two suggestions:
1.
doesn't the target expect some "end-of-command" indication, maybe a CR or a LF or both? If so, add it to the byte array in the exact same way you do other ASCII characters.
2.
Timing issues:
2a. you did not understand well I'm afraid; if the target accepts 8N1, the source is allowed to use 8N2 which slows down the communication by 10% but may be enough for the target to keep up.
2b. if you open the port, adjust it settings, and send something all in a row, without any delays, most targets I have encountered will just not hear the message, they are still getting ready to listen (opening the port is likely to set one of the control lines, which in turn interrupts the target, signalling something might be going to happen, etc). Hence, open the port in advance, wait 10 msec (NOT inside a button_click handler!), then communicate.
|
|
|
|
|
Luc,
You're the man. Thanks for sticking with me, I really appreciate it ... the CR was what was missing at the end of the byte array.
When I send that, I'm able to send data and have it recognize it. Thanks again for the lesson! I guess the keypress event sends that behind the scenes? I did not know that the chip looked for that before now.
byte[] buff = new byte[7];
buff[0] = (byte)'p';
buff[1] = (byte)'i';
buff[2] = (byte)'n';
buff[3] = (byte)'2';
buff[4] = (byte)'=';
buff[5] = (byte)'3';
buff[6] = (byte)13;
serialPort1.Write(buff, 0, buff.Length);
|
|
|
|
|
You're welcome. I'm glad you got it working.
turbosupramk3 wrote: I guess the keypress event sends
Not at all. Something else must have been going on.
turbosupramk3 wrote: I did not know that the chip looked for that
That should have been obvious: after receiving some digits, how would it know the number is complete? either there is a strict syntax (that many digits), or a time-out (not a nice idea), or there must be a terminator. Everything being ASCII, a CR terminator would be the obvious choice IMO.
turbosupramk3 wrote: I really appreciate it
Then start upvoting whatever message(s) actually helped you.
|
|
|
|
|
I have LED's that can turn on and off 10 times a second (resolution) inside of a program, and a clock speed on the uC of 80mhz, so I did not anticipate having any timing issues with this. It is sometimes skipping over commands to turn the LED's on and off. The uC can flash the LED's a 1000+ times a second, so the bottle neck has to be in the serial portion of it.
To expand on your 2., the uC only functions at 8N1. I have added the 10MS wait per your advice, do I need to have that in between serial command sends as well?
[EDIT]
It appears to be the code on the uC is what is slowing it down, this code below is not even processing correctly. I have terminal data coming back also, maybe that is effecting it?
serialPortWrite("pin16=1");
Thread.Sleep(100);
serialPortWrite("pin16=0");
serialPortWrite("pin17=1");
Thread.Sleep(100);
serialPortWrite("pin17=0");
serialPortWrite("pin18=1");
Thread.Sleep(100);
serialPortWrite("pin18=0");
serialPortWrite("pin19=1");
Thread.Sleep(100);
serialPortWrite("pin19=0");
serialPortWrite("pin20=1");
Thread.Sleep(100);
serialPortWrite("pin20=0");
serialPortWrite("pin21=1");
Thread.Sleep(100);
serialPortWrite("pin21=0");
serialPortWrite("pin22=1");
Thread.Sleep(100);
serialPortWrite("pin22=0");
serialPortWrite("pin23=1");
Thread.Sleep(100);
serialPortWrite("pin23=0");
serialPortWrite("pin22=1");
Thread.Sleep(100);
serialPortWrite("pin22=0");
serialPortWrite("pin21=1");
Thread.Sleep(100);
serialPortWrite("pin21=0");
serialPortWrite("pin20=1");
Thread.Sleep(100);
serialPortWrite("pin20=0");
serialPortWrite("pin19=1");
Thread.Sleep(100);
serialPortWrite("pin19=0");
serialPortWrite("pin18=1");
Thread.Sleep(100);
serialPortWrite("pin18=0");
serialPortWrite("pin17=1");
Thread.Sleep(100);
serialPortWrite("pin17=0");
serialPortWrite("pin16=1");
Thread.Sleep(100);
serialPortWrite("pin16=0");
serialPortWrite("pin17=1");
Thread.Sleep(100);
serialPortWrite("pin17=0");
serialPortWrite("pin18=1");
Thread.Sleep(100);
serialPortWrite("pin18=0");
serialPortWrite("pin19=1");
Thread.Sleep(100);
serialPortWrite("pin19=0");
serialPortWrite("pin20=1");
Thread.Sleep(100);
serialPortWrite("pin20=0");
serialPortWrite("pin21=1");
Thread.Sleep(100);
serialPortWrite("pin21=0");
serialPortWrite("pin22=1");
Thread.Sleep(100);
serialPortWrite("pin22=0");
serialPortWrite("pin23=1");
Thread.Sleep(100);
serialPortWrite("pin23=0");
serialPortWrite("pin22=1");
Thread.Sleep(100);
serialPortWrite("pin22=0");
serialPortWrite("pin21=1");
Thread.Sleep(100);
serialPortWrite("pin21=0");
serialPortWrite("pin20=1");
Thread.Sleep(100);
serialPortWrite("pin20=0");
serialPortWrite("pin19=1");
Thread.Sleep(100);
serialPortWrite("pin19=0");
serialPortWrite("pin18=1");
Thread.Sleep(100);
serialPortWrite("pin18=0");
serialPortWrite("pin17=1");
Thread.Sleep(100);
serialPortWrite("pin17=0");
serialPortWrite("pin16=1");
modified 2-Nov-11 17:22pm.
|
|
|
|
|
turbosupramk3 wrote: so the bottle neck has to be in the serial portion of it.
Nope. A lot of things could cause less than real-time behavior. The Windows serial port is heavily buffered, your outgoing data is copied several times, and collected, regrouped, eventually sent out; so it could cause delays. But then a number of Windows timers have their limitations (I wrote an article on the subject). And overall Windows isn't a real-time operating system, it is intended to either serve a single human being typing and clicking away, or (as a server) a number of non-time-critical requests from a lot of loosely connected clients. In either case, reaction times in the order of 10 to 100 msec are considered "good enough".
If you want a LED to flash, have your microcontroller do that, and have your PC just send one command to start it.
turbosupramk3 wrote: the uC only functions at 8N1
That means it uses 8 data bits, no parity, and will SEND using a single stop bit. It will receive and understand anything that has 1 or more stop bits.
turbosupramk3 wrote: I have added the 10MS wait per your advice
That was suggested between opening the port and sending the first message; I trust you keep the port open, so there normally would be no need once the port has been open for such period. Unless the target is "serially deaf" while executing your previous command, then your PC would require a fixed period in between serial commands. Either the target's doc, or some experiments, should point that out. Obviously, opening and closing the port all the time could be detrimental to the comm performance.
|
|
|
|
|
Ok, I stripped out the feedback data that I use to troubleshoot, and I put the 10mS wait when I first open the port and it is working with a resolution of 100ms, which I think will server my purposes.
Thank you very much Luc!
|
|
|
|
|
Nice.
Regards,
Rob Philpott.
|
|
|
|
|
Perhaps to add to what Luc is saying... perhaps you want to use System.Text.Encoding.ASCII.GetBytes ( string ) ?
|
|
|
|
|
Hi,
If you mean the following, this is not working either.
string asciiString = "abc";
byte[] buff = System.Text.Encoding.ASCII.GetBytes(asciiString);
serialPort1.Write(buff, 0, buff.Length);
|
|
|
|
|
turbosupramk3 wrote: If I send "pin1=2" via the simpleserial object, it is received
and the microchip code reacts. When I try and send it through the below method,
the data is not received by the microchip and it does not react.
Like Bob, I can't see any functional difference between the simpleserial code and your version.
Here are a few random ideas which may help.
1) Are you sending the correct message?
When you use simpleserial and type in the characters individually, how does the device know when it has a complete message? Does it respond as soon as the 2 of pin1=2 is typed in or do you have enter something more?
{EDIT} I see from your response to Luc that you must have been pressing the enter key.
2) Is the loop sending the message too quickly?
Test the effect of a delay (~300ms) between each character to simulate the transmission rate of a typed message.
foreach (char chr in lineToWrite)
{
char[] buff = new char[1];
buff[0] = chr;
serialPort1.Write(buff, 0, 1);
System.Threading.Thread.Sleep(300);
}
3) Is the port configured correctly?
In the simple serial class insert some code to log the values of all properties after the port has been opened.
e.g.
port.Open();
Debug.Print("Baud {0}", port.BaudRate);
and then make sure that your code uses the same settings.
Alan.
|
|
|
|
|
Hi Alan,
Thanks for the reply. I had to add the CR and verify some things. The port is configured correctly. The loop was sending data too quickly when I had the pipe clogged up with debug info, once I cleared that, 100mS resolution was good, and I believe that is sufficient, I may try 50mS later on.
It was responding to a single character push, without having to hit the enter key, with the event key press trigger. I'm not quite sure why I had to add a CR, maybe you have a theory?
|
|
|
|
|
In a C#.net 2010 application that I am suppose to maintain (since I am new to working with this language), I find code that looks like the following:
[^]try
{ //do something}
catch (ex){} [^]
In the visual studio ide, I see a a curly green under the ex.
I also do not see any using statement that I would think applies.
Thus can you tell me if this kind of code really catches any errors? if so can you explain it to me?
I put this kind of code around some of my new code and everything falls into the catch block.
Thus can you tell me what a "good" try catch block should look like aand what namespace should be included in the
using statement?
|
|
|
|
|
0.
your example is pretty bad, e.g. it is missing the type of the exception you're catching.
1.
the green curly indicates the variable "ex" isn't used anywhere. If you aren't going to use it, leave out the variable's name, so write:
...
catch(FileNotFoundException) {
log("Saving the customer data failed because the necessary file wasn't there");
}
2.
a good try-catch construct would have one or more regular statements in the try-block, and at least one in the catch-block.
3.
an empty catch block most often is very bad (it "swallows" the error information without leaving a trace). One should only catch things one can deal with, and it is always wise to log the exception.
4.
There is no connection between try-catch and using.
5.
And of course the C# reference material has told you you can have 0 or more catch-blocks and 0 or 1 finally-block; all with good examples in the doc.
|
|
|
|
|
Luc Pattyn wrote: And of course the C# reference material has told you
But of course... 
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
When I was talking about the using statement, I was wanting to know what namespace should be used.
|
|
|
|
|
"Exception" is part of the System namespace. (ie. System.Exception)
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Assuming you have a typical set of usings (Visual always gives you using.System to start with), there is nothing you have to add.
|
|
|
|
|
dcof wrote: catch (ex){}
You have to specify wich type of exception may handle by this try-catch. List of Exception
catch (Exception ex){}
dcof wrote: curly green under the ex.
Curly green indicate that variable is declared but not used inside catch block.So throw exception.
catch (Exception ex)
{
throw ex;
}
|
|
|
|
|
Your advice to just throw the exception isn't the best thing you can do. You should never catch an exception and rethrow it without doing something else with the exception. The reason for this is because all you have done is recreate what would happen if you didn't have any exception handling at all.
|
|
|
|
|
All you've done is get back to the same situation plus paid the cost of throwing another exception! So yeah, don't do that.
|
|
|
|
|
Luc gave you a very good answer.
Here's a quick simple example, but try the MSDN site or maybe the articles here on CP for proper exception handling.
try{
}
catch(Exception ex){
}
finally{
}
tip: Do not show technical Exception messages to the user. Instead, depending on the catch, form a nice message explaining what happened and if they need to take action.
Hope this helps.
V.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
