Re: [Emc-users] USB - Serial question
Bingo! As suggested by John, I tested a trivial program on an Arduino Leonardo (ATmega32u4) that sets/unsets the UDCON bit0 every 20 seconds. PathPilot sees/loses/sees/loses... the USB port every 20 seconds. I need to do more testing but it appears that my problem is solved. Thanks for everyone's help with this! -Original Message- From: John Dammeyer Sent: December 4, 2020 7:02 PM To: 'Enhanced Machine Controller (EMC)' Subject: Re: [Emc-users] USB - Serial question I don't have an Arduino here that has the ATmega16U4 so I can't try this. Perhaps someone else can? Page 281 of the linked data sheet shows UDCON bit 0 holds the Detach Bit. Googling access to Arduino registers implies that you can just use the data sheet name to get to the register. So theoretically this statement in the init() function should disable the USB. Ie. It will disappear or won't show up. UDCON = UDCON & 0xFE; Now in the main line monitor one of the port pins that you have connected to a button and set up as an input. If the USB device doesn't show up then you know the DETACH bit has worked. When the mainline loop blinking the LED sees the button press execute this: UDCON = UDCON | 0x01; Now check the PC to see if the USB port shows up. If that works then you have an easy way to logically remove the USB connection. Initialize all hardware. Then logically plug the USB cable back in. John Dammeyer > -Original Message- > From: John Dammeyer [mailto:jo...@autoartisans.com] > Sent: December-04-20 10:22 AM > To: 'Enhanced Machine Controller (EMC)' > Subject: Re: [Emc-users] USB - Serial question > > Still requires an output. Whether it's DTR, Power, a Relay or the #RESET signal. > > Page 272 and 273 talks about the DETACH bit. > https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7766-8-bit-AVR- > ATmega16U4-32U4_Datasheet.pdf > > It's worth a try in that blink application working with that bit to see if Path Pilot no longer sees the serial port once the detach is set. > And then re-enumerated if cleared 120 seconds later. > > John Dammeyer > > > -Original Message- > > From: Martin Dobbins [mailto:tu...@hotmail.com] > > Sent: December-04-20 10:02 AM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > > > Hi Ken, > > > > PJRC's version of Arduino is somewhat different, I wonder if DTR is > > what you need? If you can read the serial.dtr as shown here, then I'm pretty sure you can hold DTR low until you are ready to send/receive data: > > > > https://www.pjrc.com/teensy/td_serial.html > > > > Martin > > > > > > > > > > Your suggestion sounded great so I did a few tests. I loaded a PCJR > > Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo > > (ATmega32u4) with the standard BLINK program -- > > > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > ___ > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > -- > > > > -users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
UDCON = UDCON & 0xFE; The above compiles without error for an Arduino Leonardo. I'll try it in the shop tomorrow. Thanks! -Original Message- From: John Dammeyer Sent: December 4, 2020 7:02 PM To: 'Enhanced Machine Controller (EMC)' Subject: Re: [Emc-users] USB - Serial question I don't have an Arduino here that has the ATmega16U4 so I can't try this. Perhaps someone else can? Page 281 of the linked data sheet shows UDCON bit 0 holds the Detach Bit. Googling access to Arduino registers implies that you can just use the data sheet name to get to the register. So theoretically this statement in the init() function should disable the USB. Ie. It will disappear or won't show up. UDCON = UDCON & 0xFE; Now in the main line monitor one of the port pins that you have connected to a button and set up as an input. If the USB device doesn't show up then you know the DETACH bit has worked. When the mainline loop blinking the LED sees the button press execute this: UDCON = UDCON | 0x01; Now check the PC to see if the USB port shows up. If that works then you have an easy way to logically remove the USB connection. Initialize all hardware. Then logically plug the USB cable back in. John Dammeyer > -Original Message- > From: John Dammeyer [mailto:jo...@autoartisans.com] > Sent: December-04-20 10:22 AM > To: 'Enhanced Machine Controller (EMC)' > Subject: Re: [Emc-users] USB - Serial question > > Still requires an output. Whether it's DTR, Power, a Relay or the #RESET signal. > > Page 272 and 273 talks about the DETACH bit. > https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7766-8-bit-AVR- > ATmega16U4-32U4_Datasheet.pdf > > It's worth a try in that blink application working with that bit to see if Path Pilot no longer sees the serial port once the detach is set. > And then re-enumerated if cleared 120 seconds later. > > John Dammeyer > > > -Original Message- > > From: Martin Dobbins [mailto:tu...@hotmail.com] > > Sent: December-04-20 10:02 AM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > > > Hi Ken, > > > > PJRC's version of Arduino is somewhat different, I wonder if DTR is > > what you need? If you can read the serial.dtr as shown here, then I'm pretty sure you can hold DTR low until you are ready to send/receive data: > > > > https://www.pjrc.com/teensy/td_serial.html > > > > Martin > > > > > > > > > > Your suggestion sounded great so I did a few tests. I loaded a PCJR > > Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo > > (ATmega32u4) with the standard BLINK program -- > > > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > ___ > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > -- > > > > -users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
I don't have an Arduino here that has the ATmega16U4 so I can't try this. Perhaps someone else can? Page 281 of the linked data sheet shows UDCON bit 0 holds the Detach Bit. Googling access to Arduino registers implies that you can just use the data sheet name to get to the register. So theoretically this statement in the init() function should disable the USB. Ie. It will disappear or won't show up. UDCON = UDCON & 0xFE; Now in the main line monitor one of the port pins that you have connected to a button and set up as an input. If the USB device doesn't show up then you know the DETACH bit has worked. When the mainline loop blinking the LED sees the button press execute this: UDCON = UDCON | 0x01; Now check the PC to see if the USB port shows up. If that works then you have an easy way to logically remove the USB connection. Initialize all hardware. Then logically plug the USB cable back in. John Dammeyer > -Original Message- > From: John Dammeyer [mailto:jo...@autoartisans.com] > Sent: December-04-20 10:22 AM > To: 'Enhanced Machine Controller (EMC)' > Subject: Re: [Emc-users] USB - Serial question > > Still requires an output. Whether it's DTR, Power, a Relay or the #RESET > signal. > > Page 272 and 273 talks about the DETACH bit. > https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf > > It's worth a try in that blink application working with that bit to see if > Path Pilot no longer sees the serial port once the detach is set. > And then re-enumerated if cleared 120 seconds later. > > John Dammeyer > > > -Original Message- > > From: Martin Dobbins [mailto:tu...@hotmail.com] > > Sent: December-04-20 10:02 AM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > > > Hi Ken, > > > > PJRC's version of Arduino is somewhat different, I wonder if DTR is what > > you need? If you can read the serial.dtr as shown here, then > > I'm pretty sure you can hold DTR low until you are ready to send/receive > > data: > > > > https://www.pjrc.com/teensy/td_serial.html > > > > Martin > > > > > > > > > > Your suggestion sounded great so I did a few tests. I loaded a PCJR Teensy > > LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo (ATmega32u4) with the > > standard BLINK program -- > > > > > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > ___ > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > -- > > > > -users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
Atmel Studio (the free development IDE for programming Atmel/PIC AVRs (windows only)) will import an Arduino project. This includes all the source for all the libraries that are used. This makes it easier to customise libraries. Programming without an ISP tool is a bit tricky - I think you need to do that from the command line. -Original Message- From: ken.stra...@gmail.com [mailto:ken.stra...@gmail.com] Sent: Saturday, 5 December 2020 2:45 AM To: 'Enhanced Machine Controller (EMC)' Subject: Re: [Emc-users] USB - Serial question Your suggestion sounded great so I did a few tests. I loaded a PCJR Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo (ATmega32u4) with the standard BLINK program -- the Arduino equivalent of the Linux HELLOWORLD. For those unfamiliar with the Arduino world both of these boards have native USB support rather than using a FT232 or other separate chip. The BLINK program requires no extra hardware but uses an Arduino pin to blink the onboard LED. The program is only a few lines and there is no explicit code to enable serial communication or do anything USB related. Hidden from the user, several thousand bytes of system routines to control interrupts, timers, USB, etc. are loaded together with the 5 line user program. Results: As soon as the Teensy LC is plugged in, lsusb shows a new USB device with VID/PID of 16c0/04d3. PathPilot shows a status message that a USB device has been connected. As soon as the Arduino Leonardo is plugged in, lsusb shows a new USB device with VID/PID of 2341-8036. PathPilot shows a status message that a USB device has been connected. Conclusion: The standard Arduino ecosystem does not easily allow USB enumeration to be delayed. Everything is open source software so I'm sure that one can disable/enable the on-chip USB but doing so is beyond my expertise. -Original Message- From: Chris Albertson Sent: December 3, 2020 12:49 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question On Thu, Dec 3, 2020 at 5:13 AM wrote: > Even if the FT232 RXD/TXD/DSR/CTS/etc pins are left floating it is > recognized by Linux as soon as it is plugged in. For example, lsusb > lists it. > I'm sorry I am still not clear.The FT232 has two ports. One has RS232 lines and the other has USB data lines. Letting the RS232 port float would do nothing, just like you are seeing. When you plug in the FT232 it starts a conversation with the PC even if there is nothing connected to the serial port and the FT232 chip is detected. so simple solutions *DO NOT USE AN FT232 CHIP*. The reason is that this chip does not do what you want. Simply use the USB pins that are built into the MCU Assuming you do this, now you have control over when and if the USB device talks to the Linux computer. Simply wait until you are ready. The FT232 chip was designed to do one simple job and that is allit can do. But it is not the job you need done, That said, holding the reset pin low might work but you better do that in hardware with a pull-down o there is no race condition between the MCU and FT232. But again why hassle with the FT232 chip? Every reasonable MCU has USB built-in. > -Original Message- > From: Chris Albertson > Sent: December 3, 2020 12:52 AM > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > Does it work that way? > > On Wed, Dec 2, 2020 at 8:12 PM wrote: > > > That would be great but if the USB-serial has power then it is found > > in the USB enumeration even if the MCU is busy > > > Really? How is it enumerated without the need for the MCU to send data? > Getting power is not enough. The Linux side needs to see an "ACK" > from the setup. > > > > > and ignoring the serial data stream. > > > > There is no serial data stream, not until after the USB device sends "ACK" > and is enumerated as a serial device. That has not yet happened > > That is why I was considering holding a FT232 in RESET > > > If you use an FT232 then maybe it is simply pre-programmed and some hack is > required because you can't access the code inside the chip. I think this > is an argument for not using FT232 Just connect the USB pins fom the MCU > directly. and then you have control over what happens. I would not > suggest a hardware solution when what needs to be done is in the > standard protocall. > > If this USB device is based on an MCU that is supported by Arduino IDE then > there is example code in the IDE. See where XXX.begin is called. Where > XXX is "mouse" or "keyboard" What you do is not call the .begin method > until you want Linux to notice the device.XXX is a wrapper of subclass > aroud something like "pluggableUSB".You can experimen
Re: [Emc-users] USB - Serial question
There are dozens of solutions. maybe the Udev rule tigers a Python scrip that waits for an "I'm ready" signal before it makes the device? Or the rules looks for a "myMill" device ID I suggest reading USB documentation and standards and also how Udev works on Linux. This is not bad https://linuxconfig.org/tutorial-on-how-to-write-basic-udev-rules-in-linux Wikipedia is not a bad intro to USB either https://en.wikipedia.org/wiki/USB_(Communications) On Fri, Dec 4, 2020 at 11:47 AM wrote: > You are correct. I have a udev rule to connect to my particular VID/PID. > The > problem is trying to talk before I'm really ready. > > -Original Message- > From: Chris Albertson > Sent: December 4, 2020 1:41 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] USB - Serial question > > So PP will try and "talk" to every serial port on your computer? I doubt > it is that dumb. I bet there is a Udev rule that triggers something and > you can edit the rules to look for the exact type of device or manufacturer > ID. > > On Fri, Dec 4, 2020 at 10:09 AM wrote: > > > Thanks for I'm unsure how that helps. My widget interfaces to > > LinuxCNC/PathPilot as a serial device rather than as a mouse or keyboard. > > What should my entry in udev/rules.d look like? > > > > -Original Message- > > From: Chris Albertson > > Sent: December 4, 2020 12:36 PM > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] USB - Serial question > > > > With Arduino, the test is not to simply plug in the device. Look at > > File->Examples->USB and run the sketch. > > > > While the Arduino itself shows as a serial device, the example shows > > you how to enumerate some other device, like a mouse, keyboard, or > > mass > > storage. This would be done only AFTER the .begin() is called. > > > > The idea is that you enumerate a "MyCNCmill" device or whatever else you > > want to call it. Verify it works by placing a 30 second delay in the > > example code. > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > -- > > Chris Albertson > Redondo Beach, California > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
You are correct. I have a udev rule to connect to my particular VID/PID. The problem is trying to talk before I'm really ready. -Original Message- From: Chris Albertson Sent: December 4, 2020 1:41 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question So PP will try and "talk" to every serial port on your computer? I doubt it is that dumb. I bet there is a Udev rule that triggers something and you can edit the rules to look for the exact type of device or manufacturer ID. On Fri, Dec 4, 2020 at 10:09 AM wrote: > Thanks for I'm unsure how that helps. My widget interfaces to > LinuxCNC/PathPilot as a serial device rather than as a mouse or keyboard. > What should my entry in udev/rules.d look like? > > -Original Message- > From: Chris Albertson > Sent: December 4, 2020 12:36 PM > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > With Arduino, the test is not to simply plug in the device. Look at > File->Examples->USB and run the sketch. > > While the Arduino itself shows as a serial device, the example shows > you how to enumerate some other device, like a mouse, keyboard, or > mass > storage. This would be done only AFTER the .begin() is called. > > The idea is that you enumerate a "MyCNCmill" device or whatever else you > want to call it. Verify it works by placing a 30 second delay in the > example code. > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
So PP will try and "talk" to every serial port on your computer? I doubt it is that dumb. I bet there is a Udev rule that triggers something and you can edit the rules to look for the exact type of device or manufacturer ID. On Fri, Dec 4, 2020 at 10:09 AM wrote: > Thanks for I'm unsure how that helps. My widget interfaces to > LinuxCNC/PathPilot as a serial device rather than as a mouse or keyboard. > What should my entry in udev/rules.d look like? > > -Original Message- > From: Chris Albertson > Sent: December 4, 2020 12:36 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] USB - Serial question > > With Arduino, the test is not to simply plug in the device. Look at > File->Examples->USB and run the sketch. > > While the Arduino itself shows as a serial device, the example shows you > how > to enumerate some other device, like a mouse, keyboard, or mass > storage. This would be done only AFTER the .begin() is called. > > The idea is that you enumerate a "MyCNCmill" device or whatever else you > want to call it. Verify it works by placing a 30 second delay in the > example code. > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
I don't think so when reading this from the link below, serial.dtr is not a standard Arduino ide function: "On a standard Arduino, the DTR and RTS signals are present on pins of the FTDI chip, but they are not connected to anything. You can solder wires between I/O pins and the FTDI chip if you need these signals." PJRC also has datasheets each of the chips he uses and for the LC additionally a manual with "all the useful programming info" https://www.pjrc.com/teensy/datasheets.html Isn't DTR a signal controlled by the host (LinuxCNC) rather than the micro? -Original Message- From: Martin Dobbins Sent: December 4, 2020 1:02 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question Hi Ken, PJRC's version of Arduino is somewhat different, I wonder if DTR is what you need? If you can read the serial.dtr as shown here, then I'm pretty sure you can hold DTR low until you are ready to send/receive data: https://www.pjrc.com/teensy/td_serial.html Martin Your suggestion sounded great so I did a few tests. I loaded a PCJR Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo (ATmega32u4) with the standard BLINK program -- > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- -users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
Still requires an output. Whether it's DTR, Power, a Relay or the #RESET signal. Page 272 and 273 talks about the DETACH bit. https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf It's worth a try in that blink application working with that bit to see if Path Pilot no longer sees the serial port once the detach is set. And then re-enumerated if cleared 120 seconds later. John Dammeyer > -Original Message- > From: Martin Dobbins [mailto:tu...@hotmail.com] > Sent: December-04-20 10:02 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] USB - Serial question > > Hi Ken, > > PJRC's version of Arduino is somewhat different, I wonder if DTR is what you > need? If you can read the serial.dtr as shown here, then > I'm pretty sure you can hold DTR low until you are ready to send/receive data: > > https://www.pjrc.com/teensy/td_serial.html > > Martin > > > > > Your suggestion sounded great so I did a few tests. I loaded a PCJR Teensy > LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo (ATmega32u4) with the > standard BLINK program -- > > > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > -- > > -users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
Isn't DTR a signal controlled by the host (LinuxCNC) rather than the micro? -Original Message- From: Martin Dobbins Sent: December 4, 2020 1:02 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question Hi Ken, PJRC's version of Arduino is somewhat different, I wonder if DTR is what you need? If you can read the serial.dtr as shown here, then I'm pretty sure you can hold DTR low until you are ready to send/receive data: https://www.pjrc.com/teensy/td_serial.html Martin Your suggestion sounded great so I did a few tests. I loaded a PCJR Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo (ATmega32u4) with the standard BLINK program -- > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- -users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
Thanks for I'm unsure how that helps. My widget interfaces to LinuxCNC/PathPilot as a serial device rather than as a mouse or keyboard. What should my entry in udev/rules.d look like? -Original Message- From: Chris Albertson Sent: December 4, 2020 12:36 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question With Arduino, the test is not to simply plug in the device. Look at File->Examples->USB and run the sketch. While the Arduino itself shows as a serial device, the example shows you how to enumerate some other device, like a mouse, keyboard, or mass storage. This would be done only AFTER the .begin() is called. The idea is that you enumerate a "MyCNCmill" device or whatever else you want to call it. Verify it works by placing a 30 second delay in the example code. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
Hi Ken, PJRC's version of Arduino is somewhat different, I wonder if DTR is what you need? If you can read the serial.dtr as shown here, then I'm pretty sure you can hold DTR low until you are ready to send/receive data: https://www.pjrc.com/teensy/td_serial.html Martin Your suggestion sounded great so I did a few tests. I loaded a PCJR Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo (ATmega32u4) with the standard BLINK program -- > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- -users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
With Arduino, the test is not to simply plug in the device. Look at File->Examples->USB and run the sketch. While the Arduino itself shows as a serial device, the example shows you how to enumerate some other device, like a mouse, keyboard, or mass storage. This would be done only AFTER the .begin() is called. The idea is that you enumerate a "MyCNCmill" device or whatever else you want to call it. Verify it works by placing a 30 second delay in the example code. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
John wrote: "But just as easily it can run for 7.654 to 8.765 hours and then suddenly hang with no apparent reason and no easy way to debug." There are lots of reasons for such random failures but in my experience they are often the result of over allocating RAM for data and thus leaving too little stack space. There is definitely a ton of stuff happening in the background and it is all orchestrated by thousands of lines of mostly uncommented and buggy C++ code. It was created by independent developers who, lacking clear documentation, are apt to introduce race conditions, out of bounds parameters and other gotchas. The situation is worsened due to premiums on execution speed and limiting RAM usage. This mess is never seen by the casual user and I dare not tread there to save a $1 chip! -Original Message- From: John Dammeyer Sent: December 4, 2020 11:57 AM To: 'Enhanced Machine Controller (EMC)' Subject: Re: [Emc-users] USB - Serial question Glad you did the tests to figure that out. There is a ton of stuff going on under the covers in the Arduino world which is why it's used by amateurs to do thousands of different projects. But just as easily it can run for 7.654 to 8.765 hours and then suddenly hang with no apparent reason and no easy way to debug. I have an ESP8266 Arduino compatible WiFi module that runs LED light shows like that. All works fine while you have a PC plugged into the USB connection. And then suddenly the show vanishes. And a while later restarts from scratch. But it sounds like you are back to your original premise. It's unlikely you could shut off the internal USB since it likely is identified by the PC before your program is ever run. What you could try in the init() function is to disable the internal USB and then sit in the blink while loop. See if then it's enumerated but lost so Path Pilot won't see it anymore until you do. Count 1000 blinks and then enable it again. Of course, you have to know what other things to set up since disabling it may also require other registers to be initialized again. Alternatively use an extra output on the Arduino module and either hold an FT232 in reset, pull that Data Line low, control power to the FT232H or control a relay to break the connection. I just built a module this week for a project that requires control over power. Photo attached. The cover is a tight fit and the long edges hold the PC board and connector firmly to the bottom. The blink LED status output in the module is used to drive a transistor which drives the relay. It's no longer used for blinky operations. John Dammeyer > -Original Message- > From: ken.stra...@gmail.com [mailto:ken.stra...@gmail.com] > Sent: December-04-20 7:43 AM > To: 'Enhanced Machine Controller (EMC)' > Subject: Re: [Emc-users] USB - Serial question > > Your suggestion sounded great so I did a few tests. I loaded a PCJR > Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo > (ATmega32u4) with the standard BLINK program -- the Arduino equivalent of the > Linux HELLOWORLD. > For those unfamiliar with the Arduino world both of these boards have > native USB support rather than using a FT232 or other separate chip. > The BLINK program requires no extra hardware but uses an Arduino pin > to blink the onboard LED. The program is only a few lines and there is > no explicit code to enable serial communication or do anything USB > related. Hidden from the user, several thousand bytes of system > routines to control interrupts, timers, USB, etc. are loaded together with > the 5 line user program. > > Results: > As soon as the Teensy LC is plugged in, lsusb shows a new USB device > with VID/PID of 16c0/04d3. PathPilot shows a status message that a USB > device has been connected. > > As soon as the Arduino Leonardo is plugged in, lsusb shows a new USB > device with VID/PID of 2341-8036. PathPilot shows a status message > that a USB device has been connected. > > Conclusion: > The standard Arduino ecosystem does not easily allow USB enumeration > to be delayed. Everything is open source software so I'm sure that one > can disable/enable the on-chip USB but doing so is beyond my expertise. > > -Original Message- > From: Chris Albertson > Sent: December 3, 2020 12:58 PM > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > The problem is with the USB device. If a FT232 chip is used it seems > to be doing the enumeration as soon as it is plugged in. > The simple solution is to avoid using the FT232 and use something else > where you have control over when and if enumeration occurs. > > The good news is that this "something else is free and you already > have it > -- the USB pins in the microcontroller
Re: [Emc-users] USB - Serial question
Your suggestion sounded great so I did a few tests. I loaded a PCJR Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo (ATmega32u4) with the standard BLINK program -- the Arduino equivalent of the Linux HELLOWORLD. For those unfamiliar with the Arduino world both of these boards have native USB support rather than using a FT232 or other separate chip. The BLINK program requires no extra hardware but uses an Arduino pin to blink the onboard LED. The program is only a few lines and there is no explicit code to enable serial communication or do anything USB related. Hidden from the user, several thousand bytes of system routines to control interrupts, timers, USB, etc. are loaded together with the 5 line user program. Results: As soon as the Teensy LC is plugged in, lsusb shows a new USB device with VID/PID of 16c0/04d3. PathPilot shows a status message that a USB device has been connected. As soon as the Arduino Leonardo is plugged in, lsusb shows a new USB device with VID/PID of 2341-8036. PathPilot shows a status message that a USB device has been connected. Conclusion: The standard Arduino ecosystem does not easily allow USB enumeration to be delayed. Everything is open source software so I'm sure that one can disable/enable the on-chip USB but doing so is beyond my expertise. -Original Message- From: Chris Albertson Sent: December 3, 2020 12:49 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question On Thu, Dec 3, 2020 at 5:13 AM wrote: > Even if the FT232 RXD/TXD/DSR/CTS/etc pins are left floating it is > recognized by Linux as soon as it is plugged in. For example, lsusb > lists it. > I'm sorry I am still not clear.The FT232 has two ports. One has RS232 lines and the other has USB data lines. Letting the RS232 port float would do nothing, just like you are seeing. When you plug in the FT232 it starts a conversation with the PC even if there is nothing connected to the serial port and the FT232 chip is detected. so simple solutions *DO NOT USE AN FT232 CHIP*. The reason is that this chip does not do what you want. Simply use the USB pins that are built into the MCU Assuming you do this, now you have control over when and if the USB device talks to the Linux computer. Simply wait until you are ready. The FT232 chip was designed to do one simple job and that is allit can do. But it is not the job you need done, That said, holding the reset pin low might work but you better do that in hardware with a pull-down o there is no race condition between the MCU and FT232. But again why hassle with the FT232 chip? Every reasonable MCU has USB built-in. > -Original Message- > From: Chris Albertson > Sent: December 3, 2020 12:52 AM > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > Does it work that way? > > On Wed, Dec 2, 2020 at 8:12 PM wrote: > > > That would be great but if the USB-serial has power then it is found > > in the USB enumeration even if the MCU is busy > > > Really? How is it enumerated without the need for the MCU to send data? > Getting power is not enough. The Linux side needs to see an "ACK" > from the setup. > > > > > and ignoring the serial data stream. > > > > There is no serial data stream, not until after the USB device sends "ACK" > and is enumerated as a serial device. That has not yet happened > > That is why I was considering holding a FT232 in RESET > > > If you use an FT232 then maybe it is simply pre-programmed and some hack is > required because you can't access the code inside the chip. I think this > is an argument for not using FT232 Just connect the USB pins fom the MCU > directly. and then you have control over what happens. I would not > suggest a hardware solution when what needs to be done is in the > standard protocall. > > If this USB device is based on an MCU that is supported by Arduino IDE then > there is example code in the IDE. See where XXX.begin is called. Where > XXX is "mouse" or "keyboard" What you do is not call the .begin method > until you want Linux to notice the device.XXX is a wrapper of subclass > aroud something like "pluggableUSB".You can experiment with an Arduino > and see that it can have any delay t like between being plugged in and > being noticed as a new device. > > until everything is > > ready to process commands. The relay in the USB cable suggested by > > John would do what you suggest. > > > > -Original Message- > > From: Chris Albertson > > Sent: December 2, 2020 10:33 PM > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] USB - Serial question > > > > So PP does
Re: [Emc-users] USB - Serial question
Your suggestion sounded great so I did a few tests. I loaded a PCJR Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo (ATmega32u4) with the standard BLINK program -- the Arduino equivalent of the Linux HELLOWORLD. For those unfamiliar with the Arduino world both of these boards have native USB support rather than using a FT232 or other separate chip. The BLINK program requires no extra hardware but uses an Arduino pin to blink the onboard LED. The program is only a few lines and there is no explicit code to enable serial communication or do anything USB related. Hidden from the user, several thousand bytes of system routines to control interrupts, timers, USB, etc. are loaded together with the 5 line user program. Results: As soon as the Teensy LC is plugged in, lsusb shows a new USB device with VID/PID of 16c0/04d3. PathPilot shows a status message that a USB device has been connected. As soon as the Arduino Leonardo is plugged in, lsusb shows a new USB device with VID/PID of 2341-8036. PathPilot shows a status message that a USB device has been connected. Conclusion: The standard Arduino ecosystem does not easily allow USB enumeration to be delayed. Everything is open source software so I'm sure that one can disable/enable the on-chip USB but doing so is beyond my expertise. -Original Message- From: Chris Albertson Sent: December 3, 2020 12:58 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question The problem is with the USB device. If a FT232 chip is used it seems to be doing the enumeration as soon as it is plugged in. The simple solution is to avoid using the FT232 and use something else where you have control over when and if enumeration occurs. The good news is that this "something else is free and you already have it -- the USB pins in the microcontroller. In the Arduino IDE what start the enumeration is the ".begin()" method that is called on the USB connection object. Look in the IDE File->Examples->USB to see an example The example that is built into the IDE uses a keyboard or mouse object but these are subclasses of something called (from my poor memory) "PluggableUSB" and the source code for PluggableUSB explains hove to make you own class that maybe you would call "MyCNC".Then when you call MyCNC.begin() the enumeration occurs and never before the call to MyCNC.begin() You can experiment with the examples provided. On Thu, Dec 3, 2020 at 5:23 AM wrote: > Les Newell wrote: > Another option is to regularly poll the serial buffer using > Serial.available() while you are initializing. If you don't spend too > much time in each loop() cycle, serialEvent() does most of the work for you. > > Polling with Serial.available is my current approach for normal > processing > -- moving steppers, actuating pneumatics, controlling pump, etc -- and > I'll probably extend it to handling initialization. > > -Original Message- > From: Les Newell > Sent: December 3, 2020 7:28 AM > To: emc-users@lists.sourceforge.net > Subject: Re: [Emc-users] USB - Serial question > > I'm a software guy so here are some possible software solutions. > Why not wait for PathPilot to send it's setup query then do your > initialization? You still have plenty of time to do your > initialization while the machine is being homed etc. > Another option is to regularly poll the serial buffer using > Serial.available() while you are initializing. If you don't spend too > much time in each loop() cycle, serialEvent() does most of the work for you. > The hardest option would be to write your own serial interrupt routine > and do all of your serial in the ISR. You need to be comfortable with > talking directly to the ATMega hardware registers to do this. > > Les > > > > On 03/12/2020 00:53, ken.stra...@gmail.com wrote: > > Chris wrote: I think USB takes care of this for you. "set up" > > packets are sent by the host (the PC) and never by the device > > (mouse, disk, or whatever) The device never starts doing anything > > until after it > hears from the host. > > > > You've precisely described my problem! I need to do somewhat time > > consuming initialization -- home some steppers, actuate a pneumatic > > cylinder, prime a pump, verify coolant pressure, etc. Soon after > > PathPilot starts it scans for my USB device and, if found, sends a > > query to ensure that I'm actually alive. If I ignore or reject the > > alive query then PathPilot ignores me until my USB disconnects and > > then > reconnects. > > > > My problem is that I may not yet know if I will ever be alive and > > ready when I'm first asked. I have a plan to queue any host requests > > received whi
Re: [Emc-users] USB - Serial question
The problem is with the USB device. If a FT232 chip is used it seems to be doing the enumeration as soon as it is plugged in. The simple solution is to avoid using the FT232 and use something else where you have control over when and if enumeration occurs. The good news is that this "something else is free and you already have it -- the USB pins in the microcontroller. In the Arduino IDE what start the enumeration is the ".begin()" method that is called on the USB connection object. Look in the IDE File->Examples->USB to see an example The example that is built into the IDE uses a keyboard or mouse object but these are subclasses of something called (from my poor memory) "PluggableUSB" and the source code for PluggableUSB explains hove to make you own class that maybe you would call "MyCNC".Then when you call MyCNC.begin() the enumeration occurs and never before the call to MyCNC.begin() You can experiment with the examples provided. On Thu, Dec 3, 2020 at 5:23 AM wrote: > Les Newell wrote: > Another option is to regularly poll the serial buffer using > Serial.available() while you are initializing. If you don't spend too much > time in each loop() cycle, serialEvent() does most of the work for you. > > Polling with Serial.available is my current approach for normal processing > -- moving steppers, actuating pneumatics, controlling pump, etc -- and I'll > probably extend it to handling initialization. > > -Original Message- > From: Les Newell > Sent: December 3, 2020 7:28 AM > To: emc-users@lists.sourceforge.net > Subject: Re: [Emc-users] USB - Serial question > > I'm a software guy so here are some possible software solutions. > Why not wait for PathPilot to send it's setup query then do your > initialization? You still have plenty of time to do your initialization > while the machine is being homed etc. > Another option is to regularly poll the serial buffer using > Serial.available() while you are initializing. If you don't spend too much > time in each loop() cycle, serialEvent() does most of the work for you. > The hardest option would be to write your own serial interrupt routine and > do all of your serial in the ISR. You need to be comfortable with talking > directly to the ATMega hardware registers to do this. > > Les > > > > On 03/12/2020 00:53, ken.stra...@gmail.com wrote: > > Chris wrote: I think USB takes care of this for you. "set up" > > packets are sent by the host (the PC) and never by the device (mouse, > > disk, or whatever) The device never starts doing anything until after it > hears from the host. > > > > You've precisely described my problem! I need to do somewhat time > > consuming initialization -- home some steppers, actuate a pneumatic > > cylinder, prime a pump, verify coolant pressure, etc. Soon after > > PathPilot starts it scans for my USB device and, if found, sends a > > query to ensure that I'm actually alive. If I ignore or reject the > > alive query then PathPilot ignores me until my USB disconnects and then > reconnects. > > > > My problem is that I may not yet know if I will ever be alive and > > ready when I'm first asked. I have a plan to queue any host requests > > received while I'm still initializing. > > > > Probably more explanation than you wanted! > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
On Thu, Dec 3, 2020 at 5:13 AM wrote: > Even if the FT232 RXD/TXD/DSR/CTS/etc pins are left floating it is > recognized by Linux as soon as it is plugged in. For example, lsusb lists > it. > I'm sorry I am still not clear.The FT232 has two ports. One has RS232 lines and the other has USB data lines. Letting the RS232 port float would do nothing, just like you are seeing. When you plug in the FT232 it starts a conversation with the PC even if there is nothing connected to the serial port and the FT232 chip is detected. so simple solutions *DO NOT USE AN FT232 CHIP*. The reason is that this chip does not do what you want. Simply use the USB pins that are built into the MCU Assuming you do this, now you have control over when and if the USB device talks to the Linux computer. Simply wait until you are ready. The FT232 chip was designed to do one simple job and that is allit can do. But it is not the job you need done, That said, holding the reset pin low might work but you better do that in hardware with a pull-down o there is no race condition between the MCU and FT232. But again why hassle with the FT232 chip? Every reasonable MCU has USB built-in. > -Original Message- > From: Chris Albertson > Sent: December 3, 2020 12:52 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] USB - Serial question > > Does it work that way? > > On Wed, Dec 2, 2020 at 8:12 PM wrote: > > > That would be great but if the USB-serial has power then it is found > > in the USB enumeration even if the MCU is busy > > > Really? How is it enumerated without the need for the MCU to send data? > Getting power is not enough. The Linux side needs to see an "ACK" from > the > setup. > > > > > and ignoring the serial data stream. > > > > There is no serial data stream, not until after the USB device sends "ACK" > and is enumerated as a serial device. That has not yet happened > > That is why I was considering holding a FT232 in RESET > > > If you use an FT232 then maybe it is simply pre-programmed and some hack is > required because you can't access the code inside the chip. I think this > is an argument for not using FT232 Just connect the USB pins fom the MCU > directly. and then you have control over what happens. I would not > suggest a hardware solution when what needs to be done is in the standard > protocall. > > If this USB device is based on an MCU that is supported by Arduino IDE then > there is example code in the IDE. See where XXX.begin is called. Where > XXX is "mouse" or "keyboard" What you do is not call the .begin method > until you want Linux to notice the device.XXX is a wrapper of subclass > aroud something like "pluggableUSB".You can experiment with an Arduino > and see that it can have any delay t like between being plugged in and > being > noticed as a new device. > > until everything is > > ready to process commands. The relay in the USB cable suggested by > > John would do what you suggest. > > > > -Original Message- > > From: Chris Albertson > > Sent: December 2, 2020 10:33 PM > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] USB - Serial question > > > > So PP does the scan of USB devices and does not see your device. It > > will not see your device because it is still initializing and is > > ignoring the "set up" > > packets. Finally, your device responds and then PP responds to the > > connection. The trick is to NOT connect until you are ready. You do > not > > want PP to see the USB device. So ignore the USB setups > > > > This way the device never completes the "plug-in" until it is ready. > > > > Eventually the device is done all the home and self-test operations > > and is ready and PP responds to the plug-in event. > > > > There are many other USB devices that do this. Think about any device > that > > is powered from the USB 5 volts supply. It is not even booted until > after > > the power is there so it must do the USB connection as the very last > > thing only after it is up and running. > > > > > > > > On Wed, Dec 2, 2020 at 4:55 PM wrote: > > > > > Chris wrote: I think USB takes care of this for you. "set up" > > > packets are sent by the host (the PC) and never by the device > > > (mouse, disk, or > > > whatever) > > > The device never starts doing anything until after it hears from the > > host. > > > > > > You've precisely described my problem! I need to do somewhat time >
Re: [Emc-users] USB - Serial question
Les Newell wrote: Another option is to regularly poll the serial buffer using Serial.available() while you are initializing. If you don't spend too much time in each loop() cycle, serialEvent() does most of the work for you. Polling with Serial.available is my current approach for normal processing -- moving steppers, actuating pneumatics, controlling pump, etc -- and I'll probably extend it to handling initialization. -Original Message- From: Les Newell Sent: December 3, 2020 7:28 AM To: emc-users@lists.sourceforge.net Subject: Re: [Emc-users] USB - Serial question I'm a software guy so here are some possible software solutions. Why not wait for PathPilot to send it's setup query then do your initialization? You still have plenty of time to do your initialization while the machine is being homed etc. Another option is to regularly poll the serial buffer using Serial.available() while you are initializing. If you don't spend too much time in each loop() cycle, serialEvent() does most of the work for you. The hardest option would be to write your own serial interrupt routine and do all of your serial in the ISR. You need to be comfortable with talking directly to the ATMega hardware registers to do this. Les On 03/12/2020 00:53, ken.stra...@gmail.com wrote: > Chris wrote: I think USB takes care of this for you. "set up" > packets are sent by the host (the PC) and never by the device (mouse, > disk, or whatever) The device never starts doing anything until after it hears from the host. > > You've precisely described my problem! I need to do somewhat time > consuming initialization -- home some steppers, actuate a pneumatic > cylinder, prime a pump, verify coolant pressure, etc. Soon after > PathPilot starts it scans for my USB device and, if found, sends a > query to ensure that I'm actually alive. If I ignore or reject the > alive query then PathPilot ignores me until my USB disconnects and then reconnects. > > My problem is that I may not yet know if I will ever be alive and > ready when I'm first asked. I have a plan to queue any host requests > received while I'm still initializing. > > Probably more explanation than you wanted! ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
Even if the FT232 RXD/TXD/DSR/CTS/etc pins are left floating it is recognized by Linux as soon as it is plugged in. For example, lsusb lists it. -Original Message- From: Chris Albertson Sent: December 3, 2020 12:52 AM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question Does it work that way? On Wed, Dec 2, 2020 at 8:12 PM wrote: > That would be great but if the USB-serial has power then it is found > in the USB enumeration even if the MCU is busy Really? How is it enumerated without the need for the MCU to send data? Getting power is not enough. The Linux side needs to see an "ACK" from the setup. > and ignoring the serial data stream. > There is no serial data stream, not until after the USB device sends "ACK" and is enumerated as a serial device. That has not yet happened That is why I was considering holding a FT232 in RESET If you use an FT232 then maybe it is simply pre-programmed and some hack is required because you can't access the code inside the chip. I think this is an argument for not using FT232 Just connect the USB pins fom the MCU directly. and then you have control over what happens. I would not suggest a hardware solution when what needs to be done is in the standard protocall. If this USB device is based on an MCU that is supported by Arduino IDE then there is example code in the IDE. See where XXX.begin is called. Where XXX is "mouse" or "keyboard" What you do is not call the .begin method until you want Linux to notice the device.XXX is a wrapper of subclass aroud something like "pluggableUSB".You can experiment with an Arduino and see that it can have any delay t like between being plugged in and being noticed as a new device. until everything is > ready to process commands. The relay in the USB cable suggested by > John would do what you suggest. > > -Original Message- > From: Chris Albertson > Sent: December 2, 2020 10:33 PM > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > So PP does the scan of USB devices and does not see your device. It > will not see your device because it is still initializing and is > ignoring the "set up" > packets. Finally, your device responds and then PP responds to the > connection. The trick is to NOT connect until you are ready. You do not > want PP to see the USB device. So ignore the USB setups > > This way the device never completes the "plug-in" until it is ready. > > Eventually the device is done all the home and self-test operations > and is ready and PP responds to the plug-in event. > > There are many other USB devices that do this. Think about any device that > is powered from the USB 5 volts supply. It is not even booted until after > the power is there so it must do the USB connection as the very last > thing only after it is up and running. > > > > On Wed, Dec 2, 2020 at 4:55 PM wrote: > > > Chris wrote: I think USB takes care of this for you. "set up" > > packets are sent by the host (the PC) and never by the device > > (mouse, disk, or > > whatever) > > The device never starts doing anything until after it hears from the > host. > > > > You've precisely described my problem! I need to do somewhat time > > consuming initialization -- home some steppers, actuate a pneumatic > > cylinder, prime a pump, verify coolant pressure, etc. Soon after > > PathPilot starts it scans for my USB device and, if found, sends a > > query to ensure that I'm actually alive. If I ignore or reject the > > alive query then PathPilot ignores me until my USB disconnects and > > then reconnects. > > > > My problem is that I may not yet know if I will ever be alive and > > ready when I'm first asked. I have a plan to queue any host requests > > received while I'm still initializing. > > > > Probably more explanation than you wanted! > > > > -Original Message- > > From: Chris Albertson > > Sent: December 2, 2020 6:20 PM > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] USB - Serial question > > > > I think USB takes care of this for you. "set up" packets are sent > > by the host (the PC) and never by the device (mouse, disk, or > > whatever) The device never starts doing anything until after it > > hears from the host. The host > > (Linux) is constantly polling the USB port > > > > So let's say the device was faster than the PC. then the device would > > wait for "setup packets" before enumerating. What if the PC sent "setup" > > b
Re: [Emc-users] USB - Serial question
I'm a software guy so here are some possible software solutions. Why not wait for PathPilot to send it's setup query then do your initialization? You still have plenty of time to do your initialization while the machine is being homed etc. Another option is to regularly poll the serial buffer using Serial.available() while you are initializing. If you don't spend too much time in each loop() cycle, serialEvent() does most of the work for you. The hardest option would be to write your own serial interrupt routine and do all of your serial in the ISR. You need to be comfortable with talking directly to the ATMega hardware registers to do this. Les On 03/12/2020 00:53, ken.stra...@gmail.com wrote: Chris wrote: I think USB takes care of this for you. "set up" packets are sent by the host (the PC) and never by the device (mouse, disk, or whatever) The device never starts doing anything until after it hears from the host. You've precisely described my problem! I need to do somewhat time consuming initialization -- home some steppers, actuate a pneumatic cylinder, prime a pump, verify coolant pressure, etc. Soon after PathPilot starts it scans for my USB device and, if found, sends a query to ensure that I'm actually alive. If I ignore or reject the alive query then PathPilot ignores me until my USB disconnects and then reconnects. My problem is that I may not yet know if I will ever be alive and ready when I'm first asked. I have a plan to queue any host requests received while I'm still initializing. Probably more explanation than you wanted! ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
Anno domini 2020 Wed, 2 Dec 23:10:38 -0500 ken.stra...@gmail.com scripsit: > That would be great but if the USB-serial has power then it is found in the > USB enumeration even if the MCU is busy and ignoring the serial data stream. > That is why I was considering holding a FT232 in RESET until everything is > ready to process commands. The relay in the USB cable suggested by John > would do what you suggest. You can just force USB line D+ to GND from the uC after a reset and initialite the USB stack when the uC has done it's setup work. As long as D+ is on GND, the device is not present, but it'll pop up in USB enumeration as soon as the line is released (1.5k pullup for normal operation). > > -Original Message- > From: Chris Albertson > Sent: December 2, 2020 10:33 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] USB - Serial question > > So PP does the scan of USB devices and does not see your device. It will not > see your device because it is still initializing and is ignoring the "set > up" > packets. Finally, your device responds and then PP responds to the > connection. The trick is to NOT connect until you are ready. You do not > want PP to see the USB device. So ignore the USB setups > > This way the device never completes the "plug-in" until it is ready. > > Eventually the device is done all the home and self-test operations and is > ready and PP responds to the plug-in event. > > There are many other USB devices that do this. Think about any device that > is powered from the USB 5 volts supply. It is not even booted until after > the power is there so it must do the USB connection as the very last thing > only after it is up and running. > > > > On Wed, Dec 2, 2020 at 4:55 PM wrote: > > > Chris wrote: I think USB takes care of this for you. "set up" > > packets are sent by the host (the PC) and never by the device (mouse, > > disk, or > > whatever) > > The device never starts doing anything until after it hears from the host. > > > > You've precisely described my problem! I need to do somewhat time > > consuming initialization -- home some steppers, actuate a pneumatic > > cylinder, prime a pump, verify coolant pressure, etc. Soon after > > PathPilot starts it scans for my USB device and, if found, sends a > > query to ensure that I'm actually alive. If I ignore or reject the > > alive query then PathPilot ignores me until my USB disconnects and > > then reconnects. > > > > My problem is that I may not yet know if I will ever be alive and > > ready when I'm first asked. I have a plan to queue any host requests > > received while I'm still initializing. > > > > Probably more explanation than you wanted! > > > > -Original Message- > > From: Chris Albertson > > Sent: December 2, 2020 6:20 PM > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] USB - Serial question > > > > I think USB takes care of this for you. "set up" packets are sent by > > the host (the PC) and never by the device (mouse, disk, or whatever) > > The device never starts doing anything until after it hears from the > > host. The host > > (Linux) is constantly polling the USB port > > > > So let's say the device was faster than the PC. then the device would > > wait for "setup packets" before enumerating. What if the PC sent "setup" > > before the device was alive. Then nothing happens and the PC keeps > "setup" > > until the device boots. > > > > I think this is done 1000 times per second so the connection is > > started only a millisecond after the slower end is running. Then the > > next thing is they have to agree on speed and power usage. > > > > The protocol takes care of one being faster, power, and which USB > > standard is to be used. > > > > I don't think you need to even fully understand if you use a USB > > library to handle it. > > > > On Wed, Dec 2, 2020 at 1:04 PM John Dammeyer > > wrote: > > > > > > > > > > > > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > > > > OK, then you likely don't need a FT232 chip. The microcontroller, > > > > whichever one you use, will likely have USB2 built-in. Or just make > > > sure > > > > it does, so many chips have this. > > > > On Wed, Dec 2, 2020 at 12:00 PM wrote: > > > > > > > > > To clarify: > > > > > I am working on an accessory for a Tormach
Re: [Emc-users] USB - Serial question
Does it work that way? On Wed, Dec 2, 2020 at 8:12 PM wrote: > That would be great but if the USB-serial has power then it is found in the > USB enumeration even if the MCU is busy Really? How is it enumerated without the need for the MCU to send data? Getting power is not enough. The Linux side needs to see an "ACK" from the setup. > and ignoring the serial data stream. > There is no serial data stream, not until after the USB device sends "ACK" and is enumerated as a serial device. That has not yet happened That is why I was considering holding a FT232 in RESET If you use an FT232 then maybe it is simply pre-programmed and some hack is required because you can't access the code inside the chip. I think this is an argument for not using FT232 Just connect the USB pins fom the MCU directly. and then you have control over what happens. I would not suggest a hardware solution when what needs to be done is in the standard protocall. If this USB device is based on an MCU that is supported by Arduino IDE then there is example code in the IDE. See where XXX.begin is called. Where XXX is "mouse" or "keyboard" What you do is not call the .begin method until you want Linux to notice the device.XXX is a wrapper of subclass aroud something like "pluggableUSB".You can experiment with an Arduino and see that it can have any delay t like between being plugged in and being noticed as a new device. until everything is > ready to process commands. The relay in the USB cable suggested by John > would do what you suggest. > > -Original Message- > From: Chris Albertson > Sent: December 2, 2020 10:33 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] USB - Serial question > > So PP does the scan of USB devices and does not see your device. It will > not > see your device because it is still initializing and is ignoring the "set > up" > packets. Finally, your device responds and then PP responds to the > connection. The trick is to NOT connect until you are ready. You do not > want PP to see the USB device. So ignore the USB setups > > This way the device never completes the "plug-in" until it is ready. > > Eventually the device is done all the home and self-test operations and is > ready and PP responds to the plug-in event. > > There are many other USB devices that do this. Think about any device that > is powered from the USB 5 volts supply. It is not even booted until after > the power is there so it must do the USB connection as the very last thing > only after it is up and running. > > > > On Wed, Dec 2, 2020 at 4:55 PM wrote: > > > Chris wrote: I think USB takes care of this for you. "set up" > > packets are sent by the host (the PC) and never by the device (mouse, > > disk, or > > whatever) > > The device never starts doing anything until after it hears from the > host. > > > > You've precisely described my problem! I need to do somewhat time > > consuming initialization -- home some steppers, actuate a pneumatic > > cylinder, prime a pump, verify coolant pressure, etc. Soon after > > PathPilot starts it scans for my USB device and, if found, sends a > > query to ensure that I'm actually alive. If I ignore or reject the > > alive query then PathPilot ignores me until my USB disconnects and > > then reconnects. > > > > My problem is that I may not yet know if I will ever be alive and > > ready when I'm first asked. I have a plan to queue any host requests > > received while I'm still initializing. > > > > Probably more explanation than you wanted! > > > > -Original Message- > > From: Chris Albertson > > Sent: December 2, 2020 6:20 PM > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] USB - Serial question > > > > I think USB takes care of this for you. "set up" packets are sent by > > the host (the PC) and never by the device (mouse, disk, or whatever) > > The device never starts doing anything until after it hears from the > > host. The host > > (Linux) is constantly polling the USB port > > > > So let's say the device was faster than the PC. then the device would > > wait for "setup packets" before enumerating. What if the PC sent "setup" > > before the device was alive. Then nothing happens and the PC keeps > "setup" > > until the device boots. > > > > I think this is done 1000 times per second so the connection is > > started only a millisecond after the slower end is running. Then the > > next thing is they have to agree o
Re: [Emc-users] USB - Serial question
That would be great but if the USB-serial has power then it is found in the USB enumeration even if the MCU is busy and ignoring the serial data stream. That is why I was considering holding a FT232 in RESET until everything is ready to process commands. The relay in the USB cable suggested by John would do what you suggest. -Original Message- From: Chris Albertson Sent: December 2, 2020 10:33 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question So PP does the scan of USB devices and does not see your device. It will not see your device because it is still initializing and is ignoring the "set up" packets. Finally, your device responds and then PP responds to the connection. The trick is to NOT connect until you are ready. You do not want PP to see the USB device. So ignore the USB setups This way the device never completes the "plug-in" until it is ready. Eventually the device is done all the home and self-test operations and is ready and PP responds to the plug-in event. There are many other USB devices that do this. Think about any device that is powered from the USB 5 volts supply. It is not even booted until after the power is there so it must do the USB connection as the very last thing only after it is up and running. On Wed, Dec 2, 2020 at 4:55 PM wrote: > Chris wrote: I think USB takes care of this for you. "set up" > packets are sent by the host (the PC) and never by the device (mouse, > disk, or > whatever) > The device never starts doing anything until after it hears from the host. > > You've precisely described my problem! I need to do somewhat time > consuming initialization -- home some steppers, actuate a pneumatic > cylinder, prime a pump, verify coolant pressure, etc. Soon after > PathPilot starts it scans for my USB device and, if found, sends a > query to ensure that I'm actually alive. If I ignore or reject the > alive query then PathPilot ignores me until my USB disconnects and > then reconnects. > > My problem is that I may not yet know if I will ever be alive and > ready when I'm first asked. I have a plan to queue any host requests > received while I'm still initializing. > > Probably more explanation than you wanted! > > -Original Message- > From: Chris Albertson > Sent: December 2, 2020 6:20 PM > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > I think USB takes care of this for you. "set up" packets are sent by > the host (the PC) and never by the device (mouse, disk, or whatever) > The device never starts doing anything until after it hears from the > host. The host > (Linux) is constantly polling the USB port > > So let's say the device was faster than the PC. then the device would > wait for "setup packets" before enumerating. What if the PC sent "setup" > before the device was alive. Then nothing happens and the PC keeps "setup" > until the device boots. > > I think this is done 1000 times per second so the connection is > started only a millisecond after the slower end is running. Then the > next thing is they have to agree on speed and power usage. > > The protocol takes care of one being faster, power, and which USB > standard is to be used. > > I don't think you need to even fully understand if you use a USB > library to handle it. > > On Wed, Dec 2, 2020 at 1:04 PM John Dammeyer > wrote: > > > > > > > > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > > > OK, then you likely don't need a FT232 chip. The microcontroller, > > > whichever one you use, will likely have USB2 built-in. Or just make > > sure > > > it does, so many chips have this. > > > On Wed, Dec 2, 2020 at 12:00 PM wrote: > > > > > > > To clarify: > > > > I am working on an accessory for a Tormach mill running > > > > PathPilot (a flavour of LinuxCNC). It is for personal use so I > > > > don't need to especially > > worry > > > > about product cost but obviously I'd rather not spend a lot on > > something > > > > that may eventually be abandoned when I get a better idea. I > > > > could > > modify > > > > the Tormach source code to solve my timing problems but I'd > > > > prefer to > > use > > > > it > > > > unchanged to ease the installation of their updates. > > > > It appears the issues isn't so much whether a processor with > > internal or external USB is used. Even an internal one can be > > disabled so it won't be enumerated by the PC OS. > > > > The
Re: [Emc-users] USB - Serial question
So PP does the scan of USB devices and does not see your device. It will not see your device because it is still initializing and is ignoring the "set up" packets. Finally, your device responds and then PP responds to the connection. The trick is to NOT connect until you are ready. You do not want PP to see the USB device. So ignore the USB setups This way the device never completes the "plug-in" until it is ready. Eventually the device is done all the home and self-test operations and is ready and PP responds to the plug-in event. There are many other USB devices that do this. Think about any device that is powered from the USB 5 volts supply. It is not even booted until after the power is there so it must do the USB connection as the very last thing only after it is up and running. On Wed, Dec 2, 2020 at 4:55 PM wrote: > Chris wrote: I think USB takes care of this for you. "set up" packets are > sent by the host (the PC) and never by the device (mouse, disk, or > whatever) > The device never starts doing anything until after it hears from the host. > > You've precisely described my problem! I need to do somewhat time > consuming > initialization -- home some steppers, actuate a pneumatic cylinder, prime a > pump, verify coolant pressure, etc. Soon after PathPilot starts it scans > for > my USB device and, if found, sends a query to ensure that I'm actually > alive. If I ignore or reject the alive query then PathPilot ignores me > until > my USB disconnects and then reconnects. > > My problem is that I may not yet know if I will ever be alive and ready > when > I'm first asked. I have a plan to queue any host requests received while > I'm > still initializing. > > Probably more explanation than you wanted! > > -Original Message- > From: Chris Albertson > Sent: December 2, 2020 6:20 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] USB - Serial question > > I think USB takes care of this for you. "set up" packets are sent by the > host (the PC) and never by the device (mouse, disk, or whatever) The > device > never starts doing anything until after it hears from the host. The host > (Linux) is constantly polling the USB port > > So let's say the device was faster than the PC. then the device would > wait for "setup packets" before enumerating. What if the PC sent "setup" > before the device was alive. Then nothing happens and the PC keeps "setup" > until the device boots. > > I think this is done 1000 times per second so the connection is started > only > a millisecond after the slower end is running. Then the next thing is they > have to agree on speed and power usage. > > The protocol takes care of one being faster, power, and which USB standard > is to be used. > > I don't think you need to even fully understand if you use a USB library to > handle it. > > On Wed, Dec 2, 2020 at 1:04 PM John Dammeyer > wrote: > > > > > > > > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > > > OK, then you likely don't need a FT232 chip. The microcontroller, > > > whichever one you use, will likely have USB2 built-in. Or just make > > sure > > > it does, so many chips have this. > > > On Wed, Dec 2, 2020 at 12:00 PM wrote: > > > > > > > To clarify: > > > > I am working on an accessory for a Tormach mill running PathPilot > > > > (a flavour of LinuxCNC). It is for personal use so I don't need to > > > > especially > > worry > > > > about product cost but obviously I'd rather not spend a lot on > > something > > > > that may eventually be abandoned when I get a better idea. I could > > modify > > > > the Tormach source code to solve my timing problems but I'd prefer > > > > to > > use > > > > it > > > > unchanged to ease the installation of their updates. > > > > It appears the issues isn't so much whether a processor with internal > > or external USB is used. Even an internal one can be disabled so it > > won't be enumerated by the PC OS. > > > > The problem appears to be that the Arduino project takes longer to do > > what it does on start-up than LinuxCNC does to send a couple of > > requests out the USB/Serial port. > > > > There are two problems as I see it. > > 1. If you wake up the USB too soon but don't listen to it then you > > miss the messages and hang then waiting for them. > > 2. If you don't initialize the USB port then from LinuxCNC perspective > > the device doesn't exist and it probably won't initi
Re: [Emc-users] USB - Serial question
The relay is a "thinking outside the box" approach. Not the most elegant but when we're focused on an electronic/software solution often the simple one is overlooked. John > -Original Message- > From: ken.stra...@gmail.com [mailto:ken.stra...@gmail.com] > Sent: December-02-20 5:51 PM > To: 'Enhanced Machine Controller (EMC)' > Subject: Re: [Emc-users] USB - Serial question > > Yes, unplug/replug works. I suppose that the 4PST would work but it seems a > little inelegant compared to a disable pin on the USB-Serial chip. > > I forget the timeout but you have to answer the HELLO poll in a second or > so. Motion commands potentially arrive very soon after responding to the > HELLO. Commands require an immediate OK_WORKING_ON_IT but there is no > COMMAND_COMPLETE. > > -Original Message- > From: John Dammeyer > Sent: December 2, 2020 8:21 PM > To: 'Enhanced Machine Controller (EMC)' > Subject: Re: [Emc-users] USB - Serial question > > So you do get the query again if you unplug and plug in your USB? If that's > the case the easiest is to disable your USB, whether done with a 4PST relay > on the USB pins or with signals to the USB device. > > Then when you are ready, effectively plug in the USB and wait for the query. > > It all depends on what Path Pilot sends to your module after you say I hi > I'm here. Whether you have to respond right away? And if you do, what does > PP do then? > > Will it want to immediately control your hardware? Does it expect an I'm > done moving hardware reply (handshaking)? Does it time out if it takes a > long time for the reply? > > Once you list the behavior for the various cases it will be easier to decide > how to proceed. > John Dammeyer > > > -Original Message- > > From: ken.stra...@gmail.com [mailto:ken.stra...@gmail.com] > > Sent: December-02-20 4:53 PM > > To: 'Enhanced Machine Controller (EMC)' > > Subject: Re: [Emc-users] USB - Serial question > > > > Chris wrote: I think USB takes care of this for you. "set up" > > packets are sent by the host (the PC) and never by the device (mouse, > > disk, or whatever) The device never starts doing anything until after it > hears from the host. > > > > You've precisely described my problem! I need to do somewhat time > > consuming initialization -- home some steppers, actuate a pneumatic > > cylinder, prime a pump, verify coolant pressure, etc. Soon after > > PathPilot starts it scans for my USB device and, if found, sends a > > query to ensure that I'm actually alive. If I ignore or reject the > > alive query then PathPilot ignores me until my USB disconnects and then > reconnects. > > > > My problem is that I may not yet know if I will ever be alive and > > ready when I'm first asked. I have a plan to queue any host requests > > received while I'm still initializing. > > > > Probably more explanation than you wanted! > > > > -Original Message- > > From: Chris Albertson > > Sent: December 2, 2020 6:20 PM > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] USB - Serial question > > > > I think USB takes care of this for you. "set up" packets are sent by > > the host (the PC) and never by the device (mouse, disk, or whatever) > > The device never starts doing anything until after it hears from the > > host. The host > > (Linux) is constantly polling the USB port > > > > So let's say the device was faster than the PC. then the device would > > wait for "setup packets" before enumerating. What if the PC sent "setup" > > before the device was alive. Then nothing happens and the PC keeps > "setup" > > until the device boots. > > > > I think this is done 1000 times per second so the connection is > > started only a millisecond after the slower end is running. Then the > > next thing is they have to agree on speed and power usage. > > > > The protocol takes care of one being faster, power, and which USB > > standard is to be used. > > > > I don't think you need to even fully understand if you use a USB > > library to handle it. > > > > On Wed, Dec 2, 2020 at 1:04 PM John Dammeyer > wrote: > > > > > > > > > > > > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > > > > OK, then you likely don't need a FT232 chip. The microcontroller, > > > > whichever one you use, will likely have USB2 built-in. Or just make > > > sure > > > > it does, so many chips have this. > &
Re: [Emc-users] USB - Serial question
Yes, unplug/replug works. I suppose that the 4PST would work but it seems a little inelegant compared to a disable pin on the USB-Serial chip. I forget the timeout but you have to answer the HELLO poll in a second or so. Motion commands potentially arrive very soon after responding to the HELLO. Commands require an immediate OK_WORKING_ON_IT but there is no COMMAND_COMPLETE. -Original Message- From: John Dammeyer Sent: December 2, 2020 8:21 PM To: 'Enhanced Machine Controller (EMC)' Subject: Re: [Emc-users] USB - Serial question So you do get the query again if you unplug and plug in your USB? If that's the case the easiest is to disable your USB, whether done with a 4PST relay on the USB pins or with signals to the USB device. Then when you are ready, effectively plug in the USB and wait for the query. It all depends on what Path Pilot sends to your module after you say I hi I'm here. Whether you have to respond right away? And if you do, what does PP do then? Will it want to immediately control your hardware? Does it expect an I'm done moving hardware reply (handshaking)? Does it time out if it takes a long time for the reply? Once you list the behavior for the various cases it will be easier to decide how to proceed. John Dammeyer > -Original Message- > From: ken.stra...@gmail.com [mailto:ken.stra...@gmail.com] > Sent: December-02-20 4:53 PM > To: 'Enhanced Machine Controller (EMC)' > Subject: Re: [Emc-users] USB - Serial question > > Chris wrote: I think USB takes care of this for you. "set up" > packets are sent by the host (the PC) and never by the device (mouse, > disk, or whatever) The device never starts doing anything until after it hears from the host. > > You've precisely described my problem! I need to do somewhat time > consuming initialization -- home some steppers, actuate a pneumatic > cylinder, prime a pump, verify coolant pressure, etc. Soon after > PathPilot starts it scans for my USB device and, if found, sends a > query to ensure that I'm actually alive. If I ignore or reject the > alive query then PathPilot ignores me until my USB disconnects and then reconnects. > > My problem is that I may not yet know if I will ever be alive and > ready when I'm first asked. I have a plan to queue any host requests > received while I'm still initializing. > > Probably more explanation than you wanted! > > -Original Message- > From: Chris Albertson > Sent: December 2, 2020 6:20 PM > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] USB - Serial question > > I think USB takes care of this for you. "set up" packets are sent by > the host (the PC) and never by the device (mouse, disk, or whatever) > The device never starts doing anything until after it hears from the > host. The host > (Linux) is constantly polling the USB port > > So let's say the device was faster than the PC. then the device would > wait for "setup packets" before enumerating. What if the PC sent "setup" > before the device was alive. Then nothing happens and the PC keeps "setup" > until the device boots. > > I think this is done 1000 times per second so the connection is > started only a millisecond after the slower end is running. Then the > next thing is they have to agree on speed and power usage. > > The protocol takes care of one being faster, power, and which USB > standard is to be used. > > I don't think you need to even fully understand if you use a USB > library to handle it. > > On Wed, Dec 2, 2020 at 1:04 PM John Dammeyer wrote: > > > > > > > > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > > > OK, then you likely don't need a FT232 chip. The microcontroller, > > > whichever one you use, will likely have USB2 built-in. Or just make > > sure > > > it does, so many chips have this. > > > On Wed, Dec 2, 2020 at 12:00 PM wrote: > > > > > > > To clarify: > > > > I am working on an accessory for a Tormach mill running > > > > PathPilot (a flavour of LinuxCNC). It is for personal use so I > > > > don't need to especially > > worry > > > > about product cost but obviously I'd rather not spend a lot on > > something > > > > that may eventually be abandoned when I get a better idea. I > > > > could > > modify > > > > the Tormach source code to solve my timing problems but I'd > > > > prefer to > > use > > > > it > > > > unchanged to ease the installation of their updates. > > > > It appears the issues isn't so much whether a processor with > > internal or exte
Re: [Emc-users] USB - Serial question
So you do get the query again if you unplug and plug in your USB? If that's the case the easiest is to disable your USB, whether done with a 4PST relay on the USB pins or with signals to the USB device. Then when you are ready, effectively plug in the USB and wait for the query. It all depends on what Path Pilot sends to your module after you say I hi I'm here. Whether you have to respond right away? And if you do, what does PP do then? Will it want to immediately control your hardware? Does it expect an I'm done moving hardware reply (handshaking)? Does it time out if it takes a long time for the reply? Once you list the behavior for the various cases it will be easier to decide how to proceed. John Dammeyer > -Original Message- > From: ken.stra...@gmail.com [mailto:ken.stra...@gmail.com] > Sent: December-02-20 4:53 PM > To: 'Enhanced Machine Controller (EMC)' > Subject: Re: [Emc-users] USB - Serial question > > Chris wrote: I think USB takes care of this for you. "set up" packets are > sent by the host (the PC) and never by the device (mouse, disk, or whatever) > The device never starts doing anything until after it hears from the host. > > You've precisely described my problem! I need to do somewhat time consuming > initialization -- home some steppers, actuate a pneumatic cylinder, prime a > pump, verify coolant pressure, etc. Soon after PathPilot starts it scans for > my USB device and, if found, sends a query to ensure that I'm actually > alive. If I ignore or reject the alive query then PathPilot ignores me until > my USB disconnects and then reconnects. > > My problem is that I may not yet know if I will ever be alive and ready when > I'm first asked. I have a plan to queue any host requests received while I'm > still initializing. > > Probably more explanation than you wanted! > > -Original Message- > From: Chris Albertson > Sent: December 2, 2020 6:20 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] USB - Serial question > > I think USB takes care of this for you. "set up" packets are sent by the > host (the PC) and never by the device (mouse, disk, or whatever) The device > never starts doing anything until after it hears from the host. The host > (Linux) is constantly polling the USB port > > So let's say the device was faster than the PC. then the device would > wait for "setup packets" before enumerating. What if the PC sent "setup" > before the device was alive. Then nothing happens and the PC keeps "setup" > until the device boots. > > I think this is done 1000 times per second so the connection is started only > a millisecond after the slower end is running. Then the next thing is they > have to agree on speed and power usage. > > The protocol takes care of one being faster, power, and which USB standard > is to be used. > > I don't think you need to even fully understand if you use a USB library to > handle it. > > On Wed, Dec 2, 2020 at 1:04 PM John Dammeyer wrote: > > > > > > > > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > > > OK, then you likely don't need a FT232 chip. The microcontroller, > > > whichever one you use, will likely have USB2 built-in. Or just make > > sure > > > it does, so many chips have this. > > > On Wed, Dec 2, 2020 at 12:00 PM wrote: > > > > > > > To clarify: > > > > I am working on an accessory for a Tormach mill running PathPilot > > > > (a flavour of LinuxCNC). It is for personal use so I don't need to > > > > especially > > worry > > > > about product cost but obviously I'd rather not spend a lot on > > something > > > > that may eventually be abandoned when I get a better idea. I could > > modify > > > > the Tormach source code to solve my timing problems but I'd prefer > > > > to > > use > > > > it > > > > unchanged to ease the installation of their updates. > > > > It appears the issues isn't so much whether a processor with internal > > or external USB is used. Even an internal one can be disabled so it > > won't be enumerated by the PC OS. > > > > The problem appears to be that the Arduino project takes longer to do > > what it does on start-up than LinuxCNC does to send a couple of > > requests out the USB/Serial port. > > > > There are two problems as I see it. > > 1. If you wake up the USB too soon but don't listen to it then you > > miss the messages and hang then waiting for them. > > 2. If you don't initialize the USB port then from LinuxCNC perspective &g
Re: [Emc-users] USB - Serial question
Chris wrote: I think USB takes care of this for you. "set up" packets are sent by the host (the PC) and never by the device (mouse, disk, or whatever) The device never starts doing anything until after it hears from the host. You've precisely described my problem! I need to do somewhat time consuming initialization -- home some steppers, actuate a pneumatic cylinder, prime a pump, verify coolant pressure, etc. Soon after PathPilot starts it scans for my USB device and, if found, sends a query to ensure that I'm actually alive. If I ignore or reject the alive query then PathPilot ignores me until my USB disconnects and then reconnects. My problem is that I may not yet know if I will ever be alive and ready when I'm first asked. I have a plan to queue any host requests received while I'm still initializing. Probably more explanation than you wanted! -Original Message- From: Chris Albertson Sent: December 2, 2020 6:20 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question I think USB takes care of this for you. "set up" packets are sent by the host (the PC) and never by the device (mouse, disk, or whatever) The device never starts doing anything until after it hears from the host. The host (Linux) is constantly polling the USB port So let's say the device was faster than the PC. then the device would wait for "setup packets" before enumerating. What if the PC sent "setup" before the device was alive. Then nothing happens and the PC keeps "setup" until the device boots. I think this is done 1000 times per second so the connection is started only a millisecond after the slower end is running. Then the next thing is they have to agree on speed and power usage. The protocol takes care of one being faster, power, and which USB standard is to be used. I don't think you need to even fully understand if you use a USB library to handle it. On Wed, Dec 2, 2020 at 1:04 PM John Dammeyer wrote: > > > > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > > OK, then you likely don't need a FT232 chip. The microcontroller, > > whichever one you use, will likely have USB2 built-in. Or just make > sure > > it does, so many chips have this. > > On Wed, Dec 2, 2020 at 12:00 PM wrote: > > > > > To clarify: > > > I am working on an accessory for a Tormach mill running PathPilot > > > (a flavour of LinuxCNC). It is for personal use so I don't need to > > > especially > worry > > > about product cost but obviously I'd rather not spend a lot on > something > > > that may eventually be abandoned when I get a better idea. I could > modify > > > the Tormach source code to solve my timing problems but I'd prefer > > > to > use > > > it > > > unchanged to ease the installation of their updates. > > It appears the issues isn't so much whether a processor with internal > or external USB is used. Even an internal one can be disabled so it > won't be enumerated by the PC OS. > > The problem appears to be that the Arduino project takes longer to do > what it does on start-up than LinuxCNC does to send a couple of > requests out the USB/Serial port. > > There are two problems as I see it. > 1. If you wake up the USB too soon but don't listen to it then you > miss the messages and hang then waiting for them. > 2. If you don't initialize the USB port then from LinuxCNC perspective > the device doesn't exist and it probably won't initialize or respond anymore. > > Since I don't know exactly what Ken is expecting from the Tormach > software it's hard to give really good suggestions. I'd make opening > the Serial Port for the USB connection the highest priority operation in the Arduino > project. Now at least you can get the messages. > > With this in mind what does the Tormach do if the USB is not plugged in. > Then after the Ardunio has powered up, done the motion control > operations it needs to do and is ready, you plug in the USB? > > Does the Tormach then evaluate that there is now a serial port and > send those one or two messages? > > Ie. First evaluate all the permutations on the Tormach side. You may find > you have no choice but to modify the Tormach.Or alternatively you lie > to the Tormach and tell it you are ready when you aren't. But then > hold off on any other commands from it until you are. > > Of course if that means "Is the Tool changer out of the way so I can > home?" question may need an NO even if it is. Then a YES after the > Arduino is done. > > John Dammeyer > > > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net &g
Re: [Emc-users] USB - Serial question
I think USB takes care of this for you. "set up" packets are sent by the host (the PC) and never by the device (mouse, disk, or whatever) The device never starts doing anything until after it hears from the host. The host (Linux) is constantly polling the USB port So let's say the device was faster than the PC. then the device would wait for "setup packets" before enumerating. What if the PC sent "setup" before the device was alive. Then nothing happens and the PC keeps "setup" until the device boots. I think this is done 1000 times per second so the connection is started only a millisecond after the slower end is running. Then the next thing is they have to agree on speed and power usage. The protocol takes care of one being faster, power, and which USB standard is to be used. I don't think you need to even fully understand if you use a USB library to handle it. On Wed, Dec 2, 2020 at 1:04 PM John Dammeyer wrote: > > > > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > > OK, then you likely don't need a FT232 chip. The microcontroller, > > whichever one you use, will likely have USB2 built-in. Or just make > sure > > it does, so many chips have this. > > On Wed, Dec 2, 2020 at 12:00 PM wrote: > > > > > To clarify: > > > I am working on an accessory for a Tormach mill running PathPilot (a > > > flavour > > > of LinuxCNC). It is for personal use so I don't need to especially > worry > > > about product cost but obviously I'd rather not spend a lot on > something > > > that may eventually be abandoned when I get a better idea. I could > modify > > > the Tormach source code to solve my timing problems but I'd prefer to > use > > > it > > > unchanged to ease the installation of their updates. > > It appears the issues isn't so much whether a processor with internal or > external USB is used. Even an internal one can be disabled so it won't be > enumerated by the PC OS. > > The problem appears to be that the Arduino project takes longer to do what > it does on start-up than LinuxCNC does to send a couple of requests out the > USB/Serial port. > > There are two problems as I see it. > 1. If you wake up the USB too soon but don't listen to it then you miss > the messages and hang then waiting for them. > 2. If you don't initialize the USB port then from LinuxCNC perspective the > device doesn't exist and it probably won't initialize or respond anymore. > > Since I don't know exactly what Ken is expecting from the Tormach software > it's hard to give really good suggestions. I'd make opening the Serial > Port for the USB connection the highest priority operation in the Arduino > project. Now at least you can get the messages. > > With this in mind what does the Tormach do if the USB is not plugged in. > Then after the Ardunio has powered up, done the motion control operations > it needs to do and is ready, you plug in the USB? > > Does the Tormach then evaluate that there is now a serial port and send > those one or two messages? > > Ie. First evaluate all the permutations on the Tormach side. You may find > you have no choice but to modify the Tormach.Or alternatively you lie > to the Tormach and tell it you are ready when you aren't. But then hold > off on any other commands from it until you are. > > Of course if that means "Is the Tool changer out of the way so I can > home?" question may need an NO even if it is. Then a YES after the Arduino > is done. > > John Dammeyer > > > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
> From: Chris Albertson [mailto:albertson.ch...@gmail.com] > OK, then you likely don't need a FT232 chip. The microcontroller, > whichever one you use, will likely have USB2 built-in. Or just make sure > it does, so many chips have this. > On Wed, Dec 2, 2020 at 12:00 PM wrote: > > > To clarify: > > I am working on an accessory for a Tormach mill running PathPilot (a > > flavour > > of LinuxCNC). It is for personal use so I don't need to especially worry > > about product cost but obviously I'd rather not spend a lot on something > > that may eventually be abandoned when I get a better idea. I could modify > > the Tormach source code to solve my timing problems but I'd prefer to use > > it > > unchanged to ease the installation of their updates. It appears the issues isn't so much whether a processor with internal or external USB is used. Even an internal one can be disabled so it won't be enumerated by the PC OS. The problem appears to be that the Arduino project takes longer to do what it does on start-up than LinuxCNC does to send a couple of requests out the USB/Serial port. There are two problems as I see it. 1. If you wake up the USB too soon but don't listen to it then you miss the messages and hang then waiting for them. 2. If you don't initialize the USB port then from LinuxCNC perspective the device doesn't exist and it probably won't initialize or respond anymore. Since I don't know exactly what Ken is expecting from the Tormach software it's hard to give really good suggestions. I'd make opening the Serial Port for the USB connection the highest priority operation in the Arduino project. Now at least you can get the messages. With this in mind what does the Tormach do if the USB is not plugged in. Then after the Ardunio has powered up, done the motion control operations it needs to do and is ready, you plug in the USB? Does the Tormach then evaluate that there is now a serial port and send those one or two messages? Ie. First evaluate all the permutations on the Tormach side. You may find you have no choice but to modify the Tormach.Or alternatively you lie to the Tormach and tell it you are ready when you aren't. But then hold off on any other commands from it until you are. Of course if that means "Is the Tool changer out of the way so I can home?" question may need an NO even if it is. Then a YES after the Arduino is done. John Dammeyer ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
OK, then you likely don't need a FT232 chip. The microcontroller, whichever one you use, will likely have USB2 built-in. Or just make sure it does, so many chips have this. Most chips like the STM32 will have quite a lot of peripherals built-in. USB, UARTS and analog and counters, and "whatever". You almost never need external chips. On Wed, Dec 2, 2020 at 12:00 PM wrote: > To clarify: > I am working on an accessory for a Tormach mill running PathPilot (a > flavour > of LinuxCNC). It is for personal use so I don't need to especially worry > about product cost but obviously I'd rather not spend a lot on something > that may eventually be abandoned when I get a better idea. I could modify > the Tormach source code to solve my timing problems but I'd prefer to use > it > unchanged to ease the installation of their updates. > > Possible transmission speed increases with USB3 or even USB2 are irrelevant > since the maximum data rate will be less than 100 bytes/sec. > > -Original Message- > From: Chris Albertson > Sent: December 2, 2020 12:41 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] USB - Serial question > > As said, you can simply have your device hold the ft232 reset pin low until > it needs to be high but if you look at the Arduino UNO the way they did > their USB/Serial interface design was to use an ATmega8U2 microcontroller. > Older Arduinos used the ft232 chip, then they switched to the ATmega8U2 > microcontroller because it offers better flexibility This chip has an > on-chip a USB2.0 interface. > > The trouble with holding the reset pin low is that you then need a > microcontroller to decide when to raise the pin. But if you do that, why > not use a microcontroller that can directly drive USB and not have to > install a ft232 chip. This is actually a really common design ad > maybe most engineers go this route. There is no need for the ft232 if your > microcontroller already has USB pins. > > One more thing, I don't know what you are building but if this is a new > product you might want to look at newer USB standards. > > On Tue, Dec 1, 2020 at 6:23 PM wrote: > > > I'm looking for a USB <-> Serial chip (something similar to the FT232R > > or > > CH340) that has an enable pin so it can be plugged into the computer's > > USB port but not initiate the connection process until the enable pin > > is activated. One possibility is to power up the widget, wait and then > > boot Linux but this is prone to operator error. Or perhaps someone can > > suggest an alternate approach. > > > > To explain: > > I am building an Arduino controlled widget that requires a lengthy > > initialization delay to home the axis and other tasks before it is > > ready to "talk" to Linux. I want to leave it plugged into the > > computer's USB port but unfortunately Linux boots before it completes > initialization. > > > > > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > -- > > Chris Albertson > Redondo Beach, California > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
To clarify: I am working on an accessory for a Tormach mill running PathPilot (a flavour of LinuxCNC). It is for personal use so I don't need to especially worry about product cost but obviously I'd rather not spend a lot on something that may eventually be abandoned when I get a better idea. I could modify the Tormach source code to solve my timing problems but I'd prefer to use it unchanged to ease the installation of their updates. Possible transmission speed increases with USB3 or even USB2 are irrelevant since the maximum data rate will be less than 100 bytes/sec. -Original Message- From: Chris Albertson Sent: December 2, 2020 12:41 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] USB - Serial question As said, you can simply have your device hold the ft232 reset pin low until it needs to be high but if you look at the Arduino UNO the way they did their USB/Serial interface design was to use an ATmega8U2 microcontroller. Older Arduinos used the ft232 chip, then they switched to the ATmega8U2 microcontroller because it offers better flexibility This chip has an on-chip a USB2.0 interface. The trouble with holding the reset pin low is that you then need a microcontroller to decide when to raise the pin. But if you do that, why not use a microcontroller that can directly drive USB and not have to install a ft232 chip. This is actually a really common design ad maybe most engineers go this route. There is no need for the ft232 if your microcontroller already has USB pins. One more thing, I don't know what you are building but if this is a new product you might want to look at newer USB standards. On Tue, Dec 1, 2020 at 6:23 PM wrote: > I'm looking for a USB <-> Serial chip (something similar to the FT232R > or > CH340) that has an enable pin so it can be plugged into the computer's > USB port but not initiate the connection process until the enable pin > is activated. One possibility is to power up the widget, wait and then > boot Linux but this is prone to operator error. Or perhaps someone can > suggest an alternate approach. > > To explain: > I am building an Arduino controlled widget that requires a lengthy > initialization delay to home the axis and other tasks before it is > ready to "talk" to Linux. I want to leave it plugged into the > computer's USB port but unfortunately Linux boots before it completes initialization. > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
As said, you can simply have your device hold the ft232 reset pin low until it needs to be high but if you look at the Arduino UNO the way they did their USB/Serial interface design was to use an ATmega8U2 microcontroller. Older Arduinos used the ft232 chip, then they switched to the ATmega8U2 microcontroller because it offers better flexibility This chip has an on-chip a USB2.0 interface. The trouble with holding the reset pin low is that you then need a microcontroller to decide when to raise the pin. But if you do that, why not use a microcontroller that can directly drive USB and not have to install a ft232 chip. This is actually a really common design ad maybe most engineers go this route. There is no need for the ft232 if your microcontroller already has USB pins. One more thing, I don't know what you are building but if this is a new product you might want to look at newer USB standards. On Tue, Dec 1, 2020 at 6:23 PM wrote: > I'm looking for a USB <-> Serial chip (something similar to the FT232R or > CH340) that has an enable pin so it can be plugged into the computer's USB > port but not initiate the connection process until the enable pin is > activated. One possibility is to power up the widget, wait and then boot > Linux but this is prone to operator error. Or perhaps someone can suggest > an alternate approach. > > To explain: > I am building an Arduino controlled widget that requires a lengthy > initialization delay to home the axis and other tasks before it is ready to > "talk" to Linux. I want to leave it plugged into the computer's USB port > but unfortunately Linux boots before it completes initialization. > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] USB - Serial question
Hello Ken, these usb to serial connections are are little weird. when you plug it in the linux side sees the serial USB port, even if there's nothing on the other end yet. On the arduino side, if it is rs232, you could just set all handshake signals low. I don't think you can "influence" the USB connection, from the serial side. The only thing you could do is make the computer side wait, until the arduino raises a DTR signal or so. ||Ron || On 12/1/20 7:20 PM, ken.stra...@gmail.com wrote: I'm looking for a USB <-> Serial chip (something similar to the FT232R or CH340) that has an enable pin so it can be plugged into the computer's USB port but not initiate the connection process until the enable pin is activated. One possibility is to power up the widget, wait and then boot Linux but this is prone to operator error. Or perhaps someone can suggest an alternate approach. To explain: I am building an Arduino controlled widget that requires a lengthy initialization delay to home the axis and other tasks before it is ready to "talk" to Linux. I want to leave it plugged into the computer's USB port but unfortunately Linux boots before it completes initialization. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
