http://www.nowthatsit.nl/?c=447&i=8877
Has anyone used one of these? I'm wondering how well they work, if they could replace the serial port on a board that didn't have one, etc.
You can find them for about $10 on ebay.
Thanks, Myles
On Mon, 21 Sep 2009 09:12:19 -0600, Myles Watson mylesgw@gmail.com wrote:
http://www.nowthatsit.nl/?c=447&i=8877
Has anyone used one of these? I'm wondering how well they work, if they could replace the serial port on a board that didn't have one, etc.
You can find them for about $10 on ebay.
Myles, I have one similar, and the USB is just used as power for the the LPT port.
http://www.nowthatsit.nl/?c=447&i=8877
Has anyone used one of these? I'm wondering how well they work, if they could replace the serial port on a board that didn't have one, etc.
You can find them for about $10 on ebay.
Myles, I have one similar, and the USB is just used as power for the the LPT port.
Too bad. I was afraid of that. Thanks for saving me $10.
Myles
Myles Watson wrote:
Thanks for saving me $10.
The only USB option is a Debug Class device. The Debug Class specs a USB->USB device, but it would also be possible to just implement the USB side which connects to the target, and have a different host interface.
The only Debug Class device I know of is the little blue NET20DC from PLX.
//Peter
On Mon, Sep 21, 2009 at 9:48 AM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
Thanks for saving me $10.
The only USB option is a Debug Class device. The Debug Class specs a USB->USB device, but it would also be possible to just implement the USB side which connects to the target, and have a different host interface.
The only Debug Class device I know of is the little blue NET20DC from PLX.
I was hoping for a PCI POST card that buffered codes so that they could be read from another computer by USB. Then it wouldn't depend on working USB or serial, just port 0x80.
Thanks, Myles
Myles Watson wrote:
I was hoping for a PCI POST card that buffered codes so that they could be read from another computer by USB. Then it wouldn't depend on working USB or serial, just port 0x80.
The USB debug port requires much less support than full blown USB and so can be used in restricted environments. PCI seems to be going away and even when it is present port 80h does not always work by default, it can need configuring.
Support for passing POST codes or even progress strings over USB debug devices would be very useful indeed.
Andrew
Andrew Goodbody wrote:
Support for passing POST codes or even progress strings over USB debug devices would be very useful indeed.
coreboot does support this since a few years already.
//Peter
Peter Stuge wrote:
Andrew Goodbody wrote:
Support for passing POST codes or even progress strings over USB debug devices would be very useful indeed.
coreboot does support this since a few years already.
On some chipsets... There is a certain amount of (non-trivial) chipset specific setup.
Peter Stuge wrote:
Stefan Reinauer wrote:
coreboot does support this since a few years already.
On some chipsets... There is a certain amount of (non-trivial) chipset specific setup.
What's that?
EHCI is always the same, but is there stuff to do so the EHC is reachable?
I have not figured it out yet. Our code is not working on Intel ICH, however. Grep the southbridge directories for usbdebug...
Stefan
Peter Stuge wrote:
The only Debug Class device I know of is the little blue NET20DC from PLX.
It appears that Ajays Technology, LLC now makes the Net20
http://www.ajaystech.com/net20dc.htm
http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083
In case anyone is still trying to find them.
-Bari
Peter Stuge wrote:
The only Debug Class device I know of is the little blue NET20DC from PLX.
AMI Debug Rx, info on the AMI site, direct links don't work. You're supposed to be able to buy it without the enhanced debug transport enabled so you just get the generic debug class device when in that mode. It's probably very pricey, well out of range of most hobbyists though. I have not seen any public specs on how the POST codes work either.
Andrew
Peter Stuge wrote:
Myles Watson wrote:
Thanks for saving me $10.
The only USB option is a Debug Class device. The Debug Class specs a USB->USB device, but it would also be possible to just implement the USB side which connects to the target, and have a different host interface.
Or the Artec LPC dongle - it can transport POST codes via usb-serial from the target... For someone with VHDL knowledge it might be possible to add a "fake serial port" to the dongle.
Stefan Reinauer wrote:
The only USB option is a Debug Class device.
Or the Artec LPC dongle -
Sorry, I meant for USB connection to system being debugged. :)
it can transport POST codes via usb-serial from the target... For someone with VHDL knowledge it might be possible to add a "fake serial port" to the dongle.
The way to get data out that I like the best is to use reads-mean-write, where a sequence of reading from certain addresses sends the lowest byte of the last read address via USB to the host and the user.
Unfortunately, the dongle is already a serial device so it is difficult to create another serial port. That would be done using a kernel line discipline.
Ideally, the USB descriptors and USB firmware in the dongle could be changed instead, which would allow for more channels besides the current communication.
But I don't think it's doable with the FTDI USB chips, they are much too simple.
It would of course be possible to use the existing USB-serial channel, just that the dongle would need to be reset before the next reprogram, once it has entered the reads-mean-write mode. That might be OK.
//Peter
-
Andrew Goodbody -
bari -
Joseph Smith -
Myles Watson -
Peter Stuge -
Stefan Reinauer