Re: may I commit this small umodem patch ?
On Saturday 05 July 2008, Luigi Rizzo wrote: On Sat, Jul 05, 2008 at 12:28:47AM +0200, Hans Petter Selasky wrote: On Friday 04 July 2008, Luigi Rizzo wrote: On Fri, Jul 04, 2008 at 11:33:15PM +0200, Hans Petter Selasky wrote: On Thursday 03 July 2008, Luigi Rizzo wrote: On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: On Thu, 3 Jul 2008 16:07:19 +0200 Luigi Rizzo [EMAIL PROTECTED] wrote: There was a discussion back in september about adding support for basic CDC tty devices in umodem.c. This lets you talk to a number of usb devices built around microcontrollers (e.g. Atmel), and puts us on par with Linux and Windows in terms of supporting these devices. Because this simply requires the small patch below to the probe/attach routine, so if there are no objections I plan to add this to the system (CURRENT then RELENG_7 and RELENG_6) in the next few days. What about flow control? Is flow control required for these devices? the ones I am talking about don't implement any form of flow control. I suppose they would otherwise match the previous check. luigi I mean, are you going to upload firmware through these interfaces? the OS only know about bytes. are firmware, software, data or random noise. if you want to know whether the sam7 uploader works, yes it does. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Yes, but you know that umodem can drop data, if the buffers overflow ? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Sat, Jul 05, 2008 at 09:57:06AM +0200, Hans Petter Selasky wrote: On Saturday 05 July 2008, Luigi Rizzo wrote: On Sat, Jul 05, 2008 at 12:28:47AM +0200, Hans Petter Selasky wrote: On Friday 04 July 2008, Luigi Rizzo wrote: On Fri, Jul 04, 2008 at 11:33:15PM +0200, Hans Petter Selasky wrote: On Thursday 03 July 2008, Luigi Rizzo wrote: On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: On Thu, 3 Jul 2008 16:07:19 +0200 Luigi Rizzo [EMAIL PROTECTED] wrote: There was a discussion back in september about adding support for basic CDC tty devices in umodem.c. This lets you talk to a number of usb devices built around microcontrollers (e.g. Atmel), and puts us on par with Linux and Windows in terms of supporting these devices. Because this simply requires the small patch below to the probe/attach routine, so if there are no objections I plan to add this to the system (CURRENT then RELENG_7 and RELENG_6) in the next few days. What about flow control? Is flow control required for these devices? the ones I am talking about don't implement any form of flow control. I suppose they would otherwise match the previous check. luigi I mean, are you going to upload firmware through these interfaces? the OS only know about bytes. are firmware, software, data or random noise. if you want to know whether the sam7 uploader works, yes it does. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Yes, but you know that umodem can drop data, if the buffers overflow ? yes i know. and there is another million things that can go wrong. bye luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Sat, Jul 05, 2008 at 10:56:14PM +0200, Hans Petter Selasky wrote: On Saturday 05 July 2008, Bernd Walter wrote: On Sat, Jul 05, 2008 at 09:57:06AM +0200, Hans Petter Selasky wrote: Yes, but you know that umodem can drop data, if the buffers overflow ? Do you mean the driver can loose data? It would be good if this is avoidable somehow. In fact those beasts have some kind of pseudo flow control in that they don't ack further packets. Basicly this is nothing more than using a pair of bulk pipes for raw data, but under the hood of CDC identification. I personally only use them for uploading firmware to AT91SAM7* controllers, as luigi does, but since Windows and Linux have generic drivers this is quite popular. From what I know the TTY layer which umodem uses will dump data when the buffers are full. But it there is some kind of framing in the protocol used, then this is no problem. Well - the problem is that there is not special protocol. This technology is used as a general purpose interface for almost every kind of application that. Most protocols are using smal transactions, but this is general purpos after all. This is quite similar as devices using embedded uart or something like the FT245 pseudo uart chips from FTDI. I asume even most modern cell phones don't use real uarts. I wonder what happens with real USB RS232 with activated RTS/CTS. The handshake is handled in the USB device and not under FreeBSD, because the USB devices have too large buffers for the OS to react fast enough. Can we loose data as well? If yes we have a problem there as well. If not, then there must be some kind of mechanism to sync TTY layer with the USB transport speed and we can use the same for pseudo uart. I don't think we should drop data ourself, since we have USB handshake for speed syncronisation. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Saturday 05 July 2008, Bernd Walter wrote: On Sat, Jul 05, 2008 at 09:57:06AM +0200, Hans Petter Selasky wrote: On Saturday 05 July 2008, Luigi Rizzo wrote: On Sat, Jul 05, 2008 at 12:28:47AM +0200, Hans Petter Selasky wrote: On Friday 04 July 2008, Luigi Rizzo wrote: On Fri, Jul 04, 2008 at 11:33:15PM +0200, Hans Petter Selasky wrote: On Thursday 03 July 2008, Luigi Rizzo wrote: On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: On Thu, 3 Jul 2008 16:07:19 +0200 Luigi Rizzo [EMAIL PROTECTED] wrote: There was a discussion back in september about adding support for basic CDC tty devices in umodem.c. This lets you talk to a number of usb devices built around microcontrollers (e.g. Atmel), and puts us on par with Linux and Windows in terms of supporting these devices. Because this simply requires the small patch below to the probe/attach routine, so if there are no objections I plan to add this to the system (CURRENT then RELENG_7 and RELENG_6) in the next few days. What about flow control? Is flow control required for these devices? the ones I am talking about don't implement any form of flow control. I suppose they would otherwise match the previous check. luigi I mean, are you going to upload firmware through these interfaces? the OS only know about bytes. are firmware, software, data or random noise. if you want to know whether the sam7 uploader works, yes it does. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Yes, but you know that umodem can drop data, if the buffers overflow ? Do you mean the driver can loose data? It would be good if this is avoidable somehow. In fact those beasts have some kind of pseudo flow control in that they don't ack further packets. Basicly this is nothing more than using a pair of bulk pipes for raw data, but under the hood of CDC identification. I personally only use them for uploading firmware to AT91SAM7* controllers, as luigi does, but since Windows and Linux have generic drivers this is quite popular. From what I know the TTY layer which umodem uses will dump data when the buffers are full. But it there is some kind of framing in the protocol used, then this is no problem. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Sat, Jul 05, 2008 at 11:50:32PM +0200, Bernd Walter wrote: On Sat, Jul 05, 2008 at 10:56:14PM +0200, Hans Petter Selasky wrote: On Saturday 05 July 2008, Bernd Walter wrote: On Sat, Jul 05, 2008 at 09:57:06AM +0200, Hans Petter Selasky wrote: Yes, but you know that umodem can drop data, if the buffers overflow ? Do you mean the driver can loose data? It would be good if this is avoidable somehow. In fact those beasts have some kind of pseudo flow control in that they don't ack further packets. Basicly this is nothing more than using a pair of bulk pipes for raw data, but under the hood of CDC identification. I personally only use them for uploading firmware to AT91SAM7* controllers, as luigi does, but since Windows and Linux have generic drivers this is quite popular. From what I know the TTY layer which umodem uses will dump data when the buffers are full. But it there is some kind of framing in the protocol used, then this is no problem. Well - the problem is that there is not special protocol. This technology is used as a general purpose interface for almost every kind of application that. Most protocols are using smal transactions, but this is general purpos after all. This is quite similar as devices using embedded uart or something like the FT245 pseudo uart chips from FTDI. I asume even most modern cell phones don't use real uarts. I wonder what happens with real USB RS232 with activated RTS/CTS. The handshake is handled in the USB device and not under FreeBSD, because the USB devices have too large buffers for the OS to react fast enough. Can we loose data as well? If yes we have a problem there as well. If not, then there must be some kind of mechanism to sync TTY layer with the USB transport speed and we can use the same for pseudo uart. I don't think we should drop data ourself, since we have USB handshake for speed syncronisation. After rethinking: I only remember having seen TTY layer dropped data in the receive path and I can't think that it was every reasonable to do for sending, since the local application can be throttled. However - we should not receive from USB if our tty buffer can't hold further data. It is up to the USB device to drop data if unavoidable, since only the device itsel can judge. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Friday 04 July 2008, Luigi Rizzo wrote: On Fri, Jul 04, 2008 at 11:33:15PM +0200, Hans Petter Selasky wrote: On Thursday 03 July 2008, Luigi Rizzo wrote: On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: On Thu, 3 Jul 2008 16:07:19 +0200 Luigi Rizzo [EMAIL PROTECTED] wrote: There was a discussion back in september about adding support for basic CDC tty devices in umodem.c. This lets you talk to a number of usb devices built around microcontrollers (e.g. Atmel), and puts us on par with Linux and Windows in terms of supporting these devices. Because this simply requires the small patch below to the probe/attach routine, so if there are no objections I plan to add this to the system (CURRENT then RELENG_7 and RELENG_6) in the next few days. What about flow control? Is flow control required for these devices? the ones I am talking about don't implement any form of flow control. I suppose they would otherwise match the previous check. luigi I mean, are you going to upload firmware through these interfaces? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Sat, Jul 05, 2008 at 12:28:47AM +0200, Hans Petter Selasky wrote: On Friday 04 July 2008, Luigi Rizzo wrote: On Fri, Jul 04, 2008 at 11:33:15PM +0200, Hans Petter Selasky wrote: On Thursday 03 July 2008, Luigi Rizzo wrote: On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: On Thu, 3 Jul 2008 16:07:19 +0200 Luigi Rizzo [EMAIL PROTECTED] wrote: There was a discussion back in september about adding support for basic CDC tty devices in umodem.c. This lets you talk to a number of usb devices built around microcontrollers (e.g. Atmel), and puts us on par with Linux and Windows in terms of supporting these devices. Because this simply requires the small patch below to the probe/attach routine, so if there are no objections I plan to add this to the system (CURRENT then RELENG_7 and RELENG_6) in the next few days. What about flow control? Is flow control required for these devices? the ones I am talking about don't implement any form of flow control. I suppose they would otherwise match the previous check. luigi I mean, are you going to upload firmware through these interfaces? the OS only know about bytes. are firmware, software, data or random noise. if you want to know whether the sam7 uploader works, yes it does. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Sat, Jul 5, 2008 at 5:39 AM, Luigi Rizzo [EMAIL PROTECTED] wrote: What about flow control? Is flow control required for these devices? the ones I am talking about don't implement any form of flow control. I suppose they would otherwise match the previous check. They are many of this device and they do not have flow control. I got two of them right here. One is for NXP LPC-P2148 and the other is using Microchip PIC18F USB PICs. Last time it was discussed here. http://lists.freebsd.org/pipermail/freebsd-usb/2008-April/004907.html I've tried the lpcusb based generic CDC-ACM device under Linux/Windows/NetBSD successfully but not FreeBSD. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Thu, 3 Jul 2008 16:07:19 +0200 Luigi Rizzo [EMAIL PROTECTED] wrote: There was a discussion back in september about adding support for basic CDC tty devices in umodem.c. This lets you talk to a number of usb devices built around microcontrollers (e.g. Atmel), and puts us on par with Linux and Windows in terms of supporting these devices. Because this simply requires the small patch below to the probe/attach routine, so if there are no objections I plan to add this to the system (CURRENT then RELENG_7 and RELENG_6) in the next few days. Index: umodem.c === RCS file: /home/ncvs/src/sys/dev/usb/umodem.c,v retrieving revision 1.57 diff -u -r1.57 umodem.c --- umodem.c31 Jan 2005 13:58:10 - 1.57 +++ umodem.c20 Aug 2006 17:05:34 - @@ -256,6 +260,15 @@ id-bInterfaceProtocol == UIPROTO_CDC_AT) ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; +#if 1 + if (ret == UMATCH_NONE + id-bInterfaceClass == UICLASS_CDC_DATA + id-bInterfaceSubClass == UISUBCLASS_DATA + id-bInterfaceProtocol == 0x00) + ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; + return ret; +#endif + if (ret == UMATCH_NONE) return (ret); Is there any reason to keep the #if 1 ... #endif? And why not just directly return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO rather than assigning it to ret first? --- Gary Jennejohn ([EMAIL PROTECTED]) ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: On Thu, 3 Jul 2008 16:07:19 +0200 Luigi Rizzo [EMAIL PROTECTED] wrote: There was a discussion back in september about adding support for basic CDC tty devices in umodem.c. This lets you talk to a number of usb devices built around microcontrollers (e.g. Atmel), and puts us on par with Linux and Windows in terms of supporting these devices. Because this simply requires the small patch below to the probe/attach routine, so if there are no objections I plan to add this to the system (CURRENT then RELENG_7 and RELENG_6) in the next few days. Index: umodem.c === RCS file: /home/ncvs/src/sys/dev/usb/umodem.c,v retrieving revision 1.57 diff -u -r1.57 umodem.c --- umodem.c 31 Jan 2005 13:58:10 - 1.57 +++ umodem.c 20 Aug 2006 17:05:34 - @@ -256,6 +260,15 @@ id-bInterfaceProtocol == UIPROTO_CDC_AT) ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; +#if 1 + if (ret == UMATCH_NONE + id-bInterfaceClass == UICLASS_CDC_DATA + id-bInterfaceSubClass == UISUBCLASS_DATA + id-bInterfaceProtocol == 0x00) + ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; + return ret; +#endif + if (ret == UMATCH_NONE) return (ret); Is there any reason to keep the #if 1 ... #endif? And why not just directly return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO rather than assigning it to ret first? in fact there are also missing braces that need to be added -- as is, the code after the #endif is completely disabled. thanks for the comment, but don't worry, the commit will be done the right way. cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
Gary Jennejohn wrote: On Thu, 3 Jul 2008 16:07:19 +0200 Luigi Rizzo [EMAIL PROTECTED] wrote: [...] +#if 1 + if (ret == UMATCH_NONE + id-bInterfaceClass == UICLASS_CDC_DATA + id-bInterfaceSubClass == UISUBCLASS_DATA + id-bInterfaceProtocol == 0x00) + ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; + return ret; +#endif + if (ret == UMATCH_NONE) return (ret); Is there any reason to keep the #if 1 ... #endif? And why not just directly return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO rather than assigning it to ret first? This patch also makes all statements below ''return ret;'' unreachable. I think it should be rewritten. -- ./lxnt ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
