Looking for example network driver that uses serial port (2.6.34)
 

First off, I couldn't figure out if there was a better place for this question. I couldn't find a category specifically for driver development, so if there is a better place for this question, please let me know.

I've been asked to develop a driver for a network adapter that is currently being designed. I know very little about how the device will actually function at this point, I'm just trying to get something going that I can build on as I learn more details. What I have been told is that the driver should create a network interface so that software that currently makes use of Ethernet and WiFi networks can be changed to use this network device as seamlessly as possible. It will also likely connect through a serial (RS232) port. This hasn't actually been set in stone yet, but I've decided to move forward as if it has so that I can get something working.

The actual machine this is being written for is a TS-7800.
I've read most of "Linux Device Drivers" (3rd ed.) trying to learn the concepts of driver development, but the examples used in this book don't work in the 2.6.34 kernel. So I'm looking for more appropriate examples, hopefully well documented ones. If anyone has any suggestions about where I could look, or any other resources I could check for help with this, I'd really appreciate it.

Have you tried Technologic Systems documentation and read info about Linux on their boards?

http://wiki.embeddedarm.com/wiki/Lin...User%27s_Guide

The wiki indicates that their Linux is based off of Debian.

I'd break this down into two projects.

1.) Device driver for serial. Try to obtain one, or rebuild the one included with their board. Learn about it.
2.) Device driver for network. Same tactic as #1.

Then combine the two to make your intended result.

I've not done much device driver development. Mostly changed stuff to adapt it in very minor ways, or debugged to see why things worked differently than I expected. I mainly used printk() to see how things went as the driver did it's work.

Point to Point Protocol (PPP) is an IP protocol that works over a serial port which might fit your needs.

My advice is - don't do it!

Serial ports ( a vanishing antique these days) use RS-232, which is specified only to 9600 baud. PCs push their luck to 115200 baud, but that's way above spec. It requires + and - voltages which certainly are not the sort of thing usb wants to see. There is no clock recovery. Ethernet is run through a transformer. All of these other protocols have clock recovery (i.e guessing the clock from the signal). RS232 you agree in advance.

Don't waste time on it until they get real and firm up on specs. The basics of the deal is: They say what they want; you do it, and they give you $$$$.

to do X, you'll need this equipment and $$$.
to do A-Z, you'll need loads of equipment and $$$$$$ :-D.

Turning a serial line into a network connection has already been done:

http://www.linuxpronews.com/how-to-c...-linux-2003-07

Serial lines at high baud rates work just fine - as long as you have a GOOD SHIELDED communications cable with proper grounding with 115200 baud for up to about 20 feet. As distances increase, the baud rate decreases due to wire resistances which spread out the signals.

The problem is that the high quality communications cable is expensive. It is much cheaper to use an ethernet adapter.

A confusion on names. A driver is to get the serial chip to work. A protocol is a way to use the chip to communicate.

I'd only assume they use some version of a uart chip for the serial and 485 ports.
https://en.wikipedia.org/wiki/Univer...er/transmitter
As you can see, the later ones can get pretty fast.

The board is "The TS-7800 is shipped with Linux kernel 2.6 and the Debian distribution on on-board flash"

So, you shouldn't need a driver for the chipset. You only need to decide on what protocol you want or need to use for the associated supporting hardware. What will it be talking to and how fast does it need to be.

I suppose you can replace it with QNX maybe or another version of Linux.


Might as well read this too. http://www.embeddedarm.com/about/resource.php?item=459

I do high speed serial all the time. There's a lot of devices which use high speed serial connections. One case may be a network chip which has SPI and they've placed an embedded controller in front of it to provide a USB serial connection, /dev/ttyACMx, or even FTDI type /dev/ttyUSBx; they work fine.

I'm no stranger to high speed serial myself. My advice was to avoid rs-232.

It all depends on the communication cable used. From many points of view, even ethernet is serial.

I disagree slightly. RS-2323 seems to be the one everyone learned from. If there's an earthing problem anywhere, you can take out a serial port with an rs232 connection (it has happened to me); you have to set the clock speed at both ends, along with stop bits, flow control, etc. Your top speed is quite low. Designers fixed all these faults in other serial connections.

If you are running RS-232 far enough to introduce such grounding problems, I suggest you use RS232 over fiber connections. Extends the range to 2Km as well.

And if you are within the same building, you have rather severe wiring errors that need correction.

I am not. I was the techie who fixed other people's rs-232 connections, and replaced Maxim MAX232s and other chios and combinations of chips which had blown due to some little flashover. I always needed a stock of such items. My kids also blew a motherboard simply by connecting a battery operated laptop. I was trying to point the OP away from trouble, not get into a long debate with people trying to stand up a failed protocol.
I'm distracting from the original question at this stage.

/unsubscribes from thread

I appreciate the input on the use of the 232 connection, but I'm not sure if the concerns apply here (please, correct me if I'm wrong). The TS-7800 will be connected to a separate communications device which will likely be only a few feet away at most. Like I said before, the choice of connecting it though the 232 port isn't finalized, but I have no say in the matter, another team is developing the device. My goal is to get a network interface working that when information is sent to it, will package it up and send it along the serial line, along with monitoring the serial line for incoming traffic. I don't know much about networking, but I'm under the impression that I'll need to know more about the device to decide how to "package" and "unpackage" the information, but I'm not really worried about that until I get the specifics of the device later.

I've read up a little on PPP and the article linked that talks about SLIP, but both of these seem to be about directly connecting two computers. Can either of them be adapted for my purpose?

Serial rs-232 has been used for a very long time. It is still in use all over the globe in harsh environments. Most of the documentation that survived to be added to the internet is all very old stuff but still useful. You could run IP over serial or such if the endpoint uses it also.

What I said before is you need to pick a protocol or know what this ancillary device uses. We would need to know exactly what program is being used to talk to what device in order to make a better guess.


http://www.tldp.org/HOWTO/Serial-HOWTO.html

Aaron it really depends on what you're passing across that interface. You either have a stack, or not. By stack I mean an IP layer. If you don't have that, do you at least have the MAC layer present? You may not know based on the experience level that you've cited. The MAC layer is just about the first main layer of software/hardware interface.

The board support package; which you may be developing provides initialization of the physical device. So you may have to do this on your own; or the board may have that already done. On a PC, the BIOS initializes peripherals, or the chip itself comes up in enough of a state so that when the OS starts probing the resources, it can discern that you have a certain Ethernet chip and then determine if a driver even exists on in the system at all.

Can you boot Linux yet on this system, and if so; when you boot Linux, can you run "ifconfig -a"? Do you see the network interface which you need to talk too? If not then you either need to write and load, or find and load a driver which can talk to the specific Ethernet device you're using. That's why I suggested looking further into the TS-7800 documentation to find out what is there already and where you have to start.

As far as protocol, it may be that you're going to talk in raw Ether, which means not UDP or TCP transport, but instead using Ethernet protocol directly and then passing data using conventions that are only known to your systems? Or, you may be using a protocol that is transported via UDP or TCP. If so, and if you have a network stack in your system, then you can establish those types of communications as you would for any other network type of system. I.e. if you need to have someone FTP to your system, then you need to run an FTP server to host that, and also set up the network interface so that it will work with that.

Sorry, I realize it may sound confusing, however you don't as yet have a concrete description as to how you intend to use this interface. It's either going to run from Linux with some typical services already running; such as the network, and therefore you can set an IP address and configure things like a server or daemon to host session attachments from a remote device; or you're going to code a customized protocol and use none of the standardized IP protocols, but instead send data over the Ethernet using Ethernet frames

https://en.wikipedia.org/wiki/Ethernet_frame

My suggestion is to find out more about what you need to pass across that interface and further, to evaluate whether or not you have to expand or limit that. Because someone may be telling you that it's simple and all you have to do is talk raw Ethernet; however if the Linux you're running already has a full network stack, already has a driver which can talk to that interface, then you likely have full IP protocol capabilities and then it's more of a question as to why do a custom protocol? Privacy, or some other reason?