On Sep 20, 8:39 pm, Tim Wescott <t...@seemywebsite.com> wrote:

> Doesn't work -- oh well.  It's looking like the long range solution is
> to patch ftdi_sio.c with appropriate code and recompile.  I've found a
> page which lists a patch for the Olimex JTAG programmer, of which I
> think the Luminary part is a clone.

I would recommend pursuing that.  There is certainly a learning curve,
to compiling modules, but once you figure it you have a lot more
'control'
over your computer for the future, and are far less at the mercy of
other people.

Simon Clubley wrote:
> In article <ztGdnc8n4tomFU3VnZ2dnUVZ_rbinZ2d@web-ster.com>, Tim Wescott <tim@seemywebsite.com> writes:
>> It's 0403:bcd9.  The chip is a FT2232D, with one port being used for 
>> asynchronous serial and the other bit-banging JTAG debug.
>>
>> Is there a way to configure the driver to look for that chip?  Is there 
>> a way to tell it to use the right half and ignore the wrong one?
>>
> 
> Have you tried using modprobe usbserial, with the appropriate product and
> vendor arguments, to force usbserial to see the device ?
> 
> Major warning: Do this at your own risk and make sure that you have not
> got anything important running or unsaved when you do this. :-) There may
> be very good reasons why usbserial is not seeing your device.
> 
> Check the dmesg and lsmod output first to make sure that another module
> hasn't been loaded (which you will to first need to unload) instead of
> usbserial - I have a 3G modem that is initially loaded as a cdrom device
> until I unload the module (with rmmod) and then force usbserial to see it
> by specifying the vendor and product arguments to modprobe.
> 
> Simon.

Doesn't work -- oh well.  It's looking like the long range solution is 
to patch ftdi_sio.c with appropriate code and recompile.  I've found a 
page which lists a patch for the Olimex JTAG programmer, of which I 
think the Luminary part is a clone.

>> Do you need to implement control loops in software?
>> "Applied Control Theory for Embedded Systems" gives you just what it says.
>> See details at http://www.wescottdesign.com/actfes/actfes.html
> 
> PS: BTW, nice book (at least of what I've read so far).

I'm glad you like it, and hope that you're finding it useful.  The part 
that I'm building is in support of a seminar series from the book, if 
the implementation details don't drive me crazy.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

In article <ztGdnc8n4tomFU3VnZ2dnUVZ_rbinZ2d@web-ster.com>, Tim Wescott <tim@seemywebsite.com> writes:
> 
> It's 0403:bcd9.  The chip is a FT2232D, with one port being used for 
> asynchronous serial and the other bit-banging JTAG debug.
> 
> Is there a way to configure the driver to look for that chip?  Is there 
> a way to tell it to use the right half and ignore the wrong one?
> 

Have you tried using modprobe usbserial, with the appropriate product and
vendor arguments, to force usbserial to see the device ?

Major warning: Do this at your own risk and make sure that you have not
got anything important running or unsaved when you do this. :-) There may
be very good reasons why usbserial is not seeing your device.

Check the dmesg and lsmod output first to make sure that another module
hasn't been loaded (which you will to first need to unload) instead of
usbserial - I have a 3G modem that is initially loaded as a cdrom device
until I unload the module (with rmmod) and then force usbserial to see it
by specifying the vendor and product arguments to modprobe.

Simon.

> Do you need to implement control loops in software?
> "Applied Control Theory for Embedded Systems" gives you just what it says.
> See details at http://www.wescottdesign.com/actfes/actfes.html

PS: BTW, nice book (at least of what I've read so far).

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

Tim Wescott <tim@seemywebsite.com> writes:

> cs_posting@hotmail.com wrote:
>> On Sep 17, 12:34 am, Tim Wescott <t...@seemywebsite.com> wrote:
>>
>>> Is there a way to configure the driver to look for that chip?  Is there
>>> a way to tell it to use the right half and ignore the wrong one?
>>
>> Sure, it's open source after all (the version distributed with the
>> kernel at least).
>>
>> Find a kernel tree and look in linux-xx/drivers/usb/serial/ftdi_sio.c
>> and so on
>>
>> You may need to learn about how to compile kernel modules; it's a
>> little different doing it the debian (which ubuntu inherits) package
>> way than doing it on a raw kernel (though you could of course fall
>> back to that).
>>
>> It's also possible that you can hex edit the module without
>> recompliing it... but
>>
>> Another little issue: kernel drivers don't usually mknod the entires
>> in /dev/ - usually they just listen at the chosen device numbers, and
>> it's up to someone else (once upon a time _you_) to make the
>> approrpiate /dev entries as handles to them.  Today there are some
>> daemons that do some of that, but don't seem to work perfectly.
>>
>> Also, with a multifunction device it may not be obvious what driver
>> should be auto loaded - serial, jtag, etc.
>
> At this point I'd be happy with just the serial and broken jtag.
>
> I think I'm going to have to end up using a Windows laptop, or hack in
> an RS-232 chip and use a regular cable.  (I'm not even sure if the
> Windows machine doesn't work because of drivers that came hidden in
> the eval board installation package -- so I may have to install the
> dang thing on my cruddy old Windows laptop -- sigh).

I use debian, but for some windows-only tasks I have setup a virtual
machine under it running windows. I used to use vmware, but now use
Suns VirtualBox. It works great, and you can install windows USB
drivers under it fine. They provide a debian repository for it too.

(I would guess that your problem is due to them programming in custom
VID/PID values so that the proper drivers are not being loaded. There
is probably a udev config file somewhere that you could edit, but I
don't know enough about it to really help here).

-- 

John Devereux

> I think I'm going to have to end up using a Windows laptop, or hack in
> an RS-232 chip and use a regular cable.  (I'm not even sure if the
> Windows machine doesn't work because of drivers that came hidden in the
> eval board installation package -- so I may have to install the dang
> thing on my cruddy old Windows laptop -- sigh).

It's just a mess.  Are you using the Keil evaulation CD that come with
the board?  I got two versions that looks identical on the labels.
First of all, they only work on Win2000 or XP, not Win98 (too old) or
Vista (too new).  The first version work only if I keep the clock in
2007.  The second version compile but would not download the flash.

Althought I am using the boards all the time , I only update the code
occasionally, so I keep a separate PC with XP running in 2007 for
programming it.  The boards and uC (M3) are nice, but the "free" tools
are horrible.

>
> Any good pointers to building Linux kernel modules, specifically for Debian?
>
> --
>
> Tim Wescott
> Wescott Design Serviceshttp://www.wescottdesign.com
>
> Do you need to implement control loops in software?
> "Applied Control Theory for Embedded Systems" gives you just what it says.
> See details athttp://www.wescottdesign.com/actfes/actfes.html

cs_posting@hotmail.com wrote:
> On Sep 17, 12:34 am, Tim Wescott <t...@seemywebsite.com> wrote:
> 
>> Is there a way to configure the driver to look for that chip?  Is there
>> a way to tell it to use the right half and ignore the wrong one?
> 
> Sure, it's open source after all (the version distributed with the
> kernel at least).
> 
> Find a kernel tree and look in linux-xx/drivers/usb/serial/ftdi_sio.c
> and so on
> 
> You may need to learn about how to compile kernel modules; it's a
> little different doing it the debian (which ubuntu inherits) package
> way than doing it on a raw kernel (though you could of course fall
> back to that).
> 
> It's also possible that you can hex edit the module without
> recompliing it... but
> 
> Another little issue: kernel drivers don't usually mknod the entires
> in /dev/ - usually they just listen at the chosen device numbers, and
> it's up to someone else (once upon a time _you_) to make the
> approrpiate /dev entries as handles to them.  Today there are some
> daemons that do some of that, but don't seem to work perfectly.
> 
> Also, with a multifunction device it may not be obvious what driver
> should be auto loaded - serial, jtag, etc.

At this point I'd be happy with just the serial and broken jtag.

I think I'm going to have to end up using a Windows laptop, or hack in 
an RS-232 chip and use a regular cable.  (I'm not even sure if the 
Windows machine doesn't work because of drivers that came hidden in the 
eval board installation package -- so I may have to install the dang 
thing on my cruddy old Windows laptop -- sigh).

Any good pointers to building Linux kernel modules, specifically for Debian?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:

> It's 0403:bcd9.  The chip is a FT2232D, with one port being used for 
> asynchronous serial and the other bit-banging JTAG debug.
> 
> Is there a way to configure the driver to look for that chip?  Is there 
> a way to tell it to use the right half and ignore the wrong one?
> 
Seems as though the key to this is in

/lib/modules/<linux-version>modules.alias

With our FTDI FT232B, ID 0403:6001, this file has a line:

alias usb:v0403p6001d*dc*dsc*dp*ic*isc*ip* ftdi_sio


It's possible that a similar line with "b0403pBCD9" would recognize the 
FT2232D

	Maybe,		Mel.

On Sep 17, 12:34 am, Tim Wescott <t...@seemywebsite.com> wrote:

> Is there a way to configure the driver to look for that chip?  Is there
> a way to tell it to use the right half and ignore the wrong one?

Sure, it's open source after all (the version distributed with the
kernel at least).

Find a kernel tree and look in linux-xx/drivers/usb/serial/ftdi_sio.c
and so on

You may need to learn about how to compile kernel modules; it's a
little different doing it the debian (which ubuntu inherits) package
way than doing it on a raw kernel (though you could of course fall
back to that).

It's also possible that you can hex edit the module without
recompliing it... but

Another little issue: kernel drivers don't usually mknod the entires
in /dev/ - usually they just listen at the chosen device numbers, and
it's up to someone else (once upon a time _you_) to make the
approrpiate /dev entries as handles to them.  Today there are some
daemons that do some of that, but don't seem to work perfectly.

Also, with a multifunction device it may not be obvious what driver
should be auto loaded - serial, jtag, etc.

DJ Delorie wrote:
> Did you (or they) reprogram the ftdi chip to have a different
> vendor/product ID?  The ftdi chips have eeproms in them, and if you
> change the ID (for example, so that the eval software can recognize
> its own board), the generic drivers won't recognize it.
> 
> FTDI has software on their web site to program those chips, and you
> can view and/or reset the IDs if needed.
> 
> My FTDI chips are ID 0403:6001
> 
> If you "lsusb" after plugging yours in, you can see what it's ID is.

It's 0403:bcd9.  The chip is a FT2232D, with one port being used for 
asynchronous serial and the other bit-banging JTAG debug.

Is there a way to configure the driver to look for that chip?  Is there 
a way to tell it to use the right half and ignore the wrong one?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

Did you (or they) reprogram the ftdi chip to have a different
vendor/product ID?  The ftdi chips have eeproms in them, and if you
change the ID (for example, so that the eval software can recognize
its own board), the generic drivers won't recognize it.

FTDI has software on their web site to program those chips, and you
can view and/or reset the IDs if needed.

My FTDI chips are ID 0403:6001

If you "lsusb" after plugging yours in, you can see what it's ID is.