c# code for interface between xbee meridian p micro controller devel

[tlhintoq]

i am using usb connection for the controller(meri dian P).

Then why are you doing all this to the serial port?

SerialPort serialPort = new SerialPort("COM1", 9600, Parity.None, 8, StopBits.None);
     byte[] outBuffer = System.Text.Encoding.UTF8.GetBytes("Hello World!\r\n");
     serialPort.Write(outBuffer, 0, outBuffer.Length);
 
     serialPort.Dispose();
     Thread.Sleep(Timeout.Infinite);

problem regarding my project is that i am writing my code for sending hello message in the controller for xbee

This was an LED flashing project. Now you are trying to send "Hello World"? You've totally lost me. Are you trying to flash "Hello World" in Morse code?

This code doesn't look anything like your earlier code, which was very close to what the developer of the controller used in his example. Why the big change? Did you try any of the suggestions I made earlier?

1. Do the project exactly the way the developer designed it to be done and see if the board works.
2. Once that code works, make a backup of it.
3. Slowly make changes from a known-good condition.
4. Make backup copies of your code at each stage so you can roll back if you need to.

[sagar45]

sorry to say that i have made the LED to glow .....now i am looking for sending hello msg from meridian(contro ller) to xbee .....the problem when i debug it say.""""unhandl e exception system.argument exception""""". ...

Thank you

sagar

[tlhintoq]

When you get the exception, and program execution stops it does so at the offending line and highlights that line. What line number does it stop on?

SerialPort serialPort = new SerialPort("COM1", 9600, Parity.None, 8, StopBits.None);
     byte[] outBuffer = System.Text.Encoding.UTF8.GetBytes("Hello World!\r\n");
     serialPort.Write(outBuffer, 0, outBuffer.Length);
 
     serialPort.Dispose();
     Thread.Sleep(Timeout.Infinite);

[sagar45]

SerialPort serialPort = new SerialPort("COM 1", 9600, Parity.None, 8, StopBits.None);

[tlhintoq]

You need to take the time to actually read about the controls you want to use.
The MSDN Page on SerialPort is here.

http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.aspx

You are trying to send data out of a serial port you have never opened, and you are disposing of it without closing it.

SerialPort serialPort = new SerialPort("COM1", 9600, Parity.None, 8, StopBits.None);
     byte[] outBuffer = System.Text.Encoding.UTF8.GetBytes("Hello World!\r\n");
// You need to open the serial port
     serialPort.Write(outBuffer, 0, outBuffer.Length);
// Close the serial port
     serialPort.Dispose();

There are two ways you can go about learning C#:
1) You can quickly glance at the function and start throwing a bunch of stuff at at and see what sticks. Then flail around for hours guessing and changing and guessing and changing and eventually throwing your hands up and ask for help.... or...
2) You can read the tutorials and do them as shown first, to get an education and understanding of how they work - *THEN* take the knowledge and apply it to your programming in a meaningful way.

You also need to start wrapping functions in Try/Catch blocks. You can't just let applications fail: You need to *expect* them to fail and make an effort to recover gracefully.


I can make some general suggestions that apply to good coding practice.

• Assume that everything is broken, or at least not ideal.
• Presume that the user is going to provide data in a format or manner that you just didn't expect. If you use a textbox for a number, the user will type "One".
• Assume that hardware breaks in the middle of what you are doing, so you have to recover.
• Take a few extra lines of code to get standards like the boot drive, the number thousands seperator etc. Don't assume that you have a C: drive or that a comma is the separator because not everyone is in America.
• Check that files/folders exist, even if you just did a call to make it: You may not have permissions.
• Don't assume the harddrive has room for what you are doing: They do fill up. Usually right in the middle of you writing to your log file.
• Get used to placing breakpoints and walking through the code line by line. Double check EVERYTHING on every line. Keep the "Locals" and "Autos" windows open so you can see your values.
  • Put a breakpoint on the first line of the method causing trouble.
  • When the code stops there, walk through line by line with F-10.
  • Check the values of your assumptions (looking at the Locals and Automatic variable windows as well as hovering the mouse over the variables in the code (hothelp will popup).
• Stop. Breath. Relax. Then reason out the problem. Cut it down by sections or halves. "The value was good here, then at this method it wasn't. Where did it go between 'A' and 'B'?"
• Range check and validate values. Confirm that you didn't get a zero when you are only set to accept 1-10. Confirm your objects and values aren't null. Initialize them to a known default if possible. If a selection can be from 0-10, then initialize to -1: Now you have something to check for.

Example:

Graphics g = Graphics.FromImage(m_Undo);

Presumes that m_Undo must be good (not null)(actually exists)(not in use)(you have permissions)(do esn't time out when accessed). If that assumption fails so does the program, because you can't make anything from a file if the file is null. Get used to validating data and assumptions in your code if you want it to be robust. For example:

if (m_Undo != null)
{
   bool bSuccess = false;
   // Do your thing here, for example:
   if (myObject != null) bSuccess = true;
   // or
   if (denominator > 0) bSuccess = true;
   // or
   if (MyFunctionReturn != Failed) bSuccess = true;
   // Hurray, your thing worked!

   if (bSuccess)
   {
      // Then do this other thing if it worked
   }
   else
   {
      // Then do the failure recovery part / user failure message
   }

   return bSuccess; // If you want the calling method to know if it worked.
}