Hello LQ Folk

Draxeo has provided me with some kind help, and I feel I should not tax him further.
I need to get clear what one needs to have present in the paths, in order to properly compile the USB Virtual Com Port driver offered --> Here http://www.ftdichip.com/Drivers/VCP.htm
The Linux 1.5.0 tar file is at
--> http://www.ftdichip.com/Drivers/VCP/...tdi_sio.tar.gz

The Makefile arrangement does not work at all with my Ubuntu (8.10)
I have the correct updated Linux Headers installed.
I have also the Linux Source installed.

The correct path to at least one of the unfindable headers is ..
The attempt to use the makefile yields many errors, but we settle now for just the first..

When I carefully follow the path down /lib/modules/2.6.27-14-generic/ I find that 'build' is a symlink, pointing to /usr/src/linux-headers-2.6.27-14-generic/include/config/modversions.h
OK - clearly some headers are in the 'config' directory and others are in 'linux'. Simply attempting to replace 'linux' with 'config' in the path causes massive misery further down the line.

I admit I am not so great at programming, being more of a applications user than a OS expert. I really needed the USB device to work.
Thanks for any help.
G.

From the command prompt you need to:

cd /usr/src

then

ln -s linux-source-(YOUR VERSION) linux

This creates the link to your source that I think you are missing and may fix your problem. (Check 'symlink' for more information)

Double check your steps if that doesn't work with the instructions on the following link to set it up:

http://beginlinux.wordpress.com/2008...tu-810-kernel/

Hope this gets you where you want. Lemme know if it doesn't work.

Hi Hern_28
One of the first things I did was put the 'linux' symlink in /usr/src
Checking.... which is indeed the kernel source, so far unused.

There are also the full set of header files in there, from before I installed the Ubuntu kernel source, these being ..
/usr/src/linux-headers-2.6.27-14-generic

I had believed that the full kernel source would include all the headers, but clearly modversions.h is at least one that seems to be only with the earlier headers set, and even then, down a path ..

/usr/src/linux-headers-2.6.27-14-generic/include/config/modversions.h

.. where the makefile is asking for 'linux' in place of 'config'.
Probably the makefile arrangements are a bit unfortunate.

As I showed in the original posting, when the compiler complains, it is using a longer path ..

cc1: error: /lib/modules/2.6.27-14-generic/build/include/linux/modversions.h: No such file or directory

.. where 'build' is a correct symlink back to the 'include' directory in the headers, and 'linux', while it does contain many headers, is not 'config', where many other headers are.

Thanks for the link to the wordpress article.

G.

This 3rd-party module should be unnecessary for you, as FT2232 support is included in the vanilla 2.6 kernel.

Thanks for the reply osor.
The hardware uses a FT232R, though I expect the kernel support is the same.

Is having "kernel support" for the chip in the hardware the same as expecting the USB device to "appear as an additional COM port" as soon as its is plugged in, in much the same way as a memory stick or digital camera would? If it does, how would I know? (Looking at Ubuntu network admin now..)

In a (borrowed!) Windows machine, one has to go through the "Found New Hardware" ritual, and point to the driver before the new Virtual COM Port appears in its Devices setup.

G.

In my case (I have some sort of ftdi-232 chip for programming a microcontroller), you just plug it in and a character device comes up as /dev/ttyUSB0 or similar (obviously the numbering might be different in your case). You use it almost exactly as you would a normal serial port (/dev/ttyS0, etc.).

To see if something weird is happening, look at the output of dmesg.

osor:
Some positive progress here!

When I have open /dev in a file manager window, I can see ttyUSB0 appear and disappear as I plug and unplug the USB cable to the device. This is not to say all is yet complete. The USB-I2C device is in two stages. First, the FT232R chip is a dedicated USB to UART (COM Port) device. A small PIC microcontroller then accepts serial COM port bytes, according to its own little set of rules, then to generate I2C clockings and data.

I may now be able to raid some of the example programs, using ttyUSB0 in place of "COM3" or "COM7" or whichever it is sometimes pleased to appear as in a Windows box. This is all good, but still leaves unanswered what is a good functioning setup to make programs in the knowledge that all the .h files one calls in with #include will be found OK.

If I use "automake" or Anjuta, or Geany, or similar, might it yield makefiles which do not get in a tangle finding stuff like 'modversions.h' ? Up to now, my simple needs have only required a text editor, and terminal to invoke gcc (try not to laugh - it worked OK)
Most times ./configure, make, and make install was all that was necessary.

G.

You have two problems here: find out how your windows/dos program works differently in linux (e.g., how would someone translate COM1 to ttyS0), and find out what is different between RS232 over serial and over usb (e.g., are there any different options between ttyS0 and ttyUSB0).
Your question does not make sense. I assume you are doing userspace work, yet you are looking for modversions.h (a kernel header). You should be able to do everything using the standard serial i/o control functions and read()/write() on your character device.

Hi osor

OK - we get to modversions.h because it is called in the Rules.make for the Virtual Com Port driver software supplied. Thankfully, I discovered there is already built-in Linux kernel support for the interface (FT232R) chip, and so there was no need for this "VCP driver"

The final product requires I-squared-C (I2C) interface to control it. Of the several ways possible, I chose to purchase a purpose-built product. It is a USB-to-I2C adapter that connects to a PC via a USB port. It comes with "drivers" for Windows/Linux. Looking closer, we find that it is a 2-stage thing that actually implements a Virtual COM Port (VCP) via the USB. The active chip is the Future Technologies USB-to-Serial FT232R. The second stage is that the resulting serial output is parsed by a PIC microcontroller into making I2C signals, by sending the PIC serial commands according to a command set in the maker's instructions.

The "VCP driver", when installed in Windows, makes a new serial port (COM3) appear when the USB is plugged in, though it might be (COM7) or (COM9) or (COM11) depending on what other ports were already used up. So, although we are using USB, to the user, it looks just like a serial port.


So I checked.. This was very good - so far, but it still left the question about the Makefiles, and why there are headers not all in one place. In time, I am sure I will learn why.

At this point I would have stayed with Windows, but example source program to actually wiggle the data lines was made in Microsoft Visual Studio, and is packed with Visual Studio Class Wizard stuff. Also, it would need some modification, and the abilities of the free "Visual Studio Express" did not extend to being able to compile it. I baulked at purchasing a Visual Studio. I would rather throw the interface away, and try bit-banging some printer port pins instead.

Now that I have found /dev/ttyUSB0, I have a chance at being able to get it to work, maybe even with just a little script.

I can post the errant Makefiles on box.net if we feel there is mileage in picking out their shortcomings, esp. calling on modversions.h so inapproprately, but somehow, I think you folk have more interesting things to get into.

The bad stuff is here --> http://www.box.net/shared/729hf72tzh

I still don’t understand. Are the Makefiles for the userspace programs themselves having the problems? Or is it only the drivers? For the drivers, I thought the problem was clear (you were trying to compile drivers for linux-2.4 with headers for linux-2.6, yet the build system has changed drastically from 2.4 to 2.6).

This is at the heart of what misled me. The driver page showed version 1.5.0 dated 14th May 2009. The text that accompanied it mentioned FT2232 support included in kernel 2.6.9 or greater. The ReadMe concerning the (different chip! FT232R), was less than clear. It would seem that there is explicit modern kernel support for FT232R after all.

In all of this, I failed to understand that this "driver" part could be skipped entirely, and that simply plugging in the device would make a /dev/ttyUSB0 appear in a Linux machine.

It would seem that trying to use programs made when kernel 2.4 was current, may need adjustments to the Makefiles to compile now. Finding what the modern Makefile norm is, is not so easy without opting to become a Makefile expert.

I was relieved to discover the main function I needed was now available as a kernel built-in feature, though I am sure that there are many programs out there now unavailable to a user unless he tackles a Makefile rework, or gets very clever with placing symlinks.

Well, 2.4 is still alive and kicking. It is used in some machines because of its “stable” nature. In fact, the lastest 2.4-series kernel was released around 25 days ago.

The new “Kbuild” system was created specifically because the 2.4 build system was so hairy. Here is an example of what your module’s 2.6 Makefile looks like (much cleaner and to-the-point). Of course only one line in that file is actually relevant to your specific driver.

osor

Firstly - my thanks for all your help, and the last Makefile example.
Using the Makefile from Linus' Kernel Tree just has to be one of the best choices possible, though thankfully, we now don't have to, given that Linus has already built it in.

You mentioned 'Kbuild'. There is also 'automake' I have heard of, and I guess any of the big development environment tools would produce Makefiles of varied sorts. The ones I see in the repository are KDevelop, Anjuta, Eclipse, Glade, Geany. Some I guess are optimized for maybe Java or Python. I have not much explored any of them yet. Up to now, 'Gedit' and a terminal have been enough.

Yes indeed - time for a experiment with a *very* simple C program. It may not even need much Makefile, if any at all

G