Am 27.06.2013 19:14, schrieb Reinhard Max: > Thanks for jumping in, Frank. > > Frank Schäfer <fschaefer.oss@...> writes: > >> I didn't read the whole thread yet, but what I can say for sure is that >> the device I tested did _NOT_ support any non-standard baud rates. > Then I'd be interested if it really was a PL2303X as you wrote in your > comment, because Prolific says X and HX are identical except for the pinout > and non-standard rates worked fine for me on a HX chip that was manufactured > in 2007. Yes, it's definitely a X or HX, bought in 2005 or 2006. >> IIRC, the datasheet I was looking into said something like "the >> following baud rates are supported: ..." and "please contact the >> manufacturer if you need further baud rates". > Yep, next to the baud rate table some of them say "For special baud rate > requirements, please contact Prolific FAE for support.", and some newer ones > extend that to "... for *driver* customization support.". But the same > datasheets also contain the statement I cited before, that the baud rate > generator can be programmed to *any* baud rate between 75 and the limit of > the respective chip. Well, all I can say is that the latter doesn't apply to my device. When has this datasheet been released ? > >> Maybe they sold custom versions of their chip supporting other/further >> baud rates at that time. > This might have been the case for pre-X variants of the chip, but IIRC all > datasheets I found for X and newer said the hardware supports arbitrary > rates while still explicitly listing the standard ones and someimes stating > that these are supported by the driver. I don't know anything about the pre-X variants, I never had such a device. > >> As a developer of automotive applications that are using non-standrad >> baud rates (e.g. 10400 baud), I need to find out which baud rates a >> device actually supports. >> The fact that the device silently runs at 9600 baud if unsupported baud >> rates are selected can cause trouble... > Well, now the device silently rounds the requested baud rate up or down to > the next standard value, which still lets your communication fail. Wouldn't > it have been better to at least throw an error instead, if the driver thinks > the hardware doesn't support the requested rate? No, I also fixed the driver to report the baud rate it actually uses. ;) Applications can check the resulting baud rate and decide if it is sufficient for their purpose. Throwing an error if the device can not be set exactly to the requested baud rate isn't a good idea, because a) even good hardware usually doesn't allow real continuous baud rate adjustment b) communication works fine as long as the baud rate deviance is within an acceptable limit (which differs between applications) >> Of course we want to support all baud rates a chip supports. So we need >> to find out how to distinguish between versions that support custom baud >> rates and the ones that do not support them. >> Any ideas ? Chip type/revision ? USB-IDs ? :D > Well, the USB-IDs seem to be identical over the whole family, but the driver > already has code to distinguish between three variants of the chip (0, 1 and > HX) based on some details in the USB descriptors. For some newer variants > the content of the bcdDevice field is documented in the datasheed (e.g. 3.00 > for X and HX and 4.00 for HXD). Does your device use a generic (Prolific) USB ID ? Regards, Frank > > cu > Reinhard > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
