All those ports

[ckoehler]

Hello,

Could someone explain to me (or point me to some docs) about all the ports and how they work? My board has 2 large serial ports UART0 and UART1, one smallish one that I can jumper to use instead of the big UART0, and an Ethernet port.

1. Looking at the Telnet example, there's still a serial port opened. What for? Debugging?

2. In my own setup I have UART0 connected to an external device that I want to control, UART1 goes to a laptop (for debugging I assume), and the ethernet also goes to the laptop.
I only open one serial port to communicate with the device, and also use it for the Telnet connection with CmdAddCommandFd. This right here may be my problem....

Now, why does Telnet need a serial port to work with? I thought it just opens a socket on the ethernet port. And where do I tell it to use UART1 for debugging output that I can connect the MTTTY to?

Anyway, as it is, when I connect to the Telnet socket, MTTTY shows stuff being sent to it constantly, which makes my device do things it's not supposed to . I assume that's because I use the same serial connection for both.

This probably sounds very silly, but if someone could explain these things to me, that'd be great I don't mind looking stupid for a bit.

Thanks!

Christoph

[tod]

I just took a quick look at the Telnet example. It has a define at the top for

Code: Select all

#define SERIALPORT_TO_USE (0) //0 for the main port, 1 for the 10pin aux serial port

So if you don't want the telnet example to use uart0 change that (0) to (1).



Down in UserMain you see the calls to

Code: Select all

   //Close the serial port incase it is already open.
   SerialClose( SERIALPORT_TO_USE );

   //Open the serial port
   int fdserial = OpenSerial( SERIALPORT_TO_USE,
                              BAUDRATE_TO_USE,
                              STOP_BITS,
                              DATA_BITS,
                              eParityNone );

   ReplaceStdio( 0, fdserial );
   ReplaceStdio( 1, fdserial );
   ReplaceStdio( 2, fdserial );

That will tell the NB to stop using the default uart0 for stdin, stdout and stderr and use SERIALPORT_TO_USE instead. Normally to make my life easy I reserve UART0 for debugging and use UART1 if I need serial port output to a device. That way using code like
cout << "some debug info" << endl;
or
iprintf("some debug info\n");
does just what you want without having to do any ReplaceStdio calls. In the Telnet example this code also gives you a fd handle you can use in the code that follows.

The telnet example then allows you to telnet in on SERIALPORT_TO_USE or an ethernet port. So to use the Enet port launch a DOS prompt window and type
C:> telnet
then type open and enter the ip address of your NB. Give it a user name, hit return for the password and type some garbage telnet commands.

HTH,
Tod

[rnixon]

I would recommend using uart0 for debug, that is what most of the examples do and what the monitor uses, so it would be less coding for you. I think part of the telnet example is to show that a file descriptor, fd, can be a serial or an ethernet port. A pretty cool thing that both can be treated the same way, and you can telnet through serial or ethernet. A serial telnet session might be useful as a console port for your product, which could be used to configure the device even if your network is not configured correctly (yet).

[Ridgeglider]

I'd start learning the serial ports first. Take a look at the C:\Nburn\examples\serial\SerialToSerial example. It shows how to get twoserial ports running in IRQ, mode, how to get fds for them, and how to use them with the select() function. Most of that background is needed for using either tcp or udp connections, but it is easier to understand on plain serial. Many of these calls (serial, tcp, udp) are described in C:\Nburn\docs\NetBurnerRuntimeLibrary\NetBurnerRuntimeLibraries.pdf in chapters 11, 18, 23, & 24 (I/O System Library, Serial Library, TCP & UDP). The rest of the PDF is pretty essential too. Finally, don't forget to learn about uCOS; use of the NB system hinges on it. See the C:\Nburn\docs\NetBurnerRuntimeLibrary/uCOSLibrary.pdf in conjunction with most of the examples at C:\Nburn\examples\RTOS.

[ckoehler]

Thanks guys, that helped.
I still don't understand why I need to give a serial port when I just want to use Telnet. Is it required, or just helpful for the debugging?

In my project I actually got it all working. I can telnet into the board and send commands to it that are then sent out via UART0 to the device. Intuitively, I should only need the ethernet and UART0 ports for that, not UART1, but I had to give UART1 to the telnet command processor, because the constant communication of the device over UART0 caused the telnet interface to try to interpret that data as telnet commands and send those back to the device Random movement ensued.
That makes sense, but I'd rather not give any serial port to telnet if I don't need to.

Hope that makes sense, and thanks for the great help here, these boards are very helpful!

Christoph

[tod]

You don't need to give up a serial port for Telnet. The example TelNet code is just showing you that you can use either a serial port or an ethernet port, and as rnixon pointed out it is also demonstrating how you can get a file descriptor for the serial port so that you can treat it just like the ethernet port. (That's why I told you to go to DOS and use the Telnet command to connect over the Ethernet port - so you could see it in action without using the serial port).

In all of my projects I don't allow (or want) the user to send commands via the serial port. I only allow them to conect via Ethernet. Most of the projects only have one serial serial port and that is never remapped it is always a one-way street used for debug info.

IMO, the examples provided by NB are just that, examples. They are meant to demonstrate various aspects of the intended topic. They are not meant to be used as templates for your project or to be copied and pasted wholesale into a project. The goals of maintainability, cohesion, encapsulation, reusability etc (the things you want in your final product) are often at odds with making a small, easily understood example of how to perform a specific task.