@flash

I agree with walkero, too

@skynet

Sorry, currently I have to provide a link. A thought I succeeded with setting up a build job on github, but that was juts hopeful thinking of me.

I will come back in upcoming days with a new link for donwloading, If I forget it again, just repost here.

@skynet

I wrote some information about how to use etc at
https://github.com/migthymax/pl2303.device

I hope it is understandable, if not ask here any question and I will try to answer.

@msteed

Quote:

Or (another suggestion) Snork doesn't pass the invalid pointer but passes on a valid string like "DEADSTRING\0". Than at least
no DSI , still the string could mess up other stuff. But still some additional steps before a potential crash.

@SinanSam460

I see that your exec.library version is 54.69 ? Are on any beta stuff?

@sinisrus

Don't know the model but the serial chip is a FTDI (vendor ID 0x2341 and product ID 0x0043)

The arv toolchain can probably be cross compiled with clib4 maybe even easy.

@SinanSam460

Thanks

@all

I uploaded the source on github. And now the the driver and source can be downloaded from github.

@sinisrus

Well my arduinos aren't pl2303 based, so this driver won't help reaching that goal.

@SinanSam460

Nice to hear that it works. Can you give me again an update crash log? Maybe I can figure out the crash.

@SinanSam460

I found time to investigate your logs. You have a variant of the pl2303 chip which is named HDX (resp. HDX clone).
My isn't of that kind, but yours need special handling, which I now implemented.

I don't now why unplugging your USB gadget triggers a crash, but I'm proved the unplug handling too,
hoping that it avoids the crash at your setup.

For all here is the latest version, if your are to late DM me.

@tekmage

I don't think so, because the driver doesn't check for matching product and vendor id.
So just editing the pl2303.fdclass file to have the product/vendor id of your usb gadget,
the driver will tried the best to talk with it.

So having ENV variables will just add a an additional layer of complexity

BTW. I plan to release the source, because

* Everyone can take a loo and improve the code
* There is no example for an USB driver, which again register another device in the system
* An most of the work is based on open source, so it should be open source

@graff

Even a solution for end of June, would be in Amiga time measurement an immeasurable of warp 20

@graff

Hi Thomas Graff, I'm assume you are the author of the USB stack?

If so you might answer me the following question:

The driver is heavily bases/inspired on the linux driver, which supports a variety of usb device (product/vendor) combinations.

As long I understand it I need for each product/vendor combination a fdclass file? Is there a way to group them within a sub drawer or can a fdclass file contain multiples entries?

Max

@tekmage

For that device you need an adopted pl2303.fdclass (It's a text file)

Just change the VENDOR and PRODUCT entries os that the file content looks like this:



With that file the driver should pick up your device and the than everything
works as expected/hoped a device will be register in os with the name "pl2303.device".

@tekmage

For me it was the same, I think Term was hiding on its own Screen in background. So just toggle through the screens.

You can change the behavior of Term in the setting to let it open its window on a public screen, like the workbench.

@jabirulo

I didn’t knew of that. Is there a documentation somewhere?

@SinanSam460

Thanks for testing. About whats the best way. I started to use Term for testing. The general
problem seems to be that a lot of software using a serial port assumes that the device will
always be the serial.device.

So I was thinking about a configure option to let the pl2303.usbfd register the device as
"serial.device". Thus most old programs would than work without the need to be patched/modified.
But I don't know if that would work reliable. At least that should work as long the real "serial.device" hasn't been opened.

Can even provided me with the log output which is happening before the crash?

@sinisrus

That's what I actually wanted to achieve, to talk with my Arduino(s) and Adufruit Tinkerboards.

But I haven't checked if Arduino uses the PL2303 chip?

@all

For all having a USB gadget based on a PL2303 chip here a beta driver for these devices.

The driver is far from finished! So your mileage vary and be prepared that it crashes.
The driver writes a lot of debug message to via the Exec DebugPrintF (normally written
to the serial port), so if it crashes or don't behave as expected, include the debug
output with the description what failed.

If you have a variant of PL2303 you can / must adopt the pl2303.fdclass file (is a text file)
and adjust the vendor/product id.

To see a list of theoretically supported variants take a look at the linux sources.

Have fun and I hop get a feedback to improve the driver.

Hi,

the following dongles use a different chip and won't work with this driver:

FT231X USB UART. -> uses FTDI chip
USB2.0-Ser! -> uses CH340 chip

The other mention should work. I will polish my driver a little bit more and provide it for testing. (Takes some time)

@kas1e

Yes it's a OS4 driver, I thought that was clear beacsue of selected forum.

A lot is taken form the (link->:) linux sources, so any found vendor/product id should work, or at should be doable.

Do you have an PL2303 based Serial-USB adapter? And if so what Vendor/Product Id does it have?