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 <albertson.ch...@gmail.com> 
Sent: December 3, 2020 12:49 PM
To: Enhanced Machine Controller (EMC) <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] USB - Serial question

On Thu, Dec 3, 2020 at 5:13 AM <ken.stra...@gmail.com> 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 <albertson.ch...@gmail.com>
> Sent: December 3, 2020 12:52 AM
> To: Enhanced Machine Controller (EMC) 
> <emc-users@lists.sourceforge.net>
> Subject: Re: [Emc-users] USB - Serial question
>
> Does it work that way?
>
> On Wed, Dec 2, 2020 at 8:12 PM <ken.stra...@gmail.com> 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 <albertson.ch...@gmail.com>
> > Sent: December 2, 2020 10:33 PM
> > To: Enhanced Machine Controller (EMC) 
> > <emc-users@lists.sourceforge.net>
> > 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 <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!
> > >
> > > -----Original Message-----
> > > From: Chris Albertson <albertson.ch...@gmail.com>
> > > Sent: December 2, 2020 6:20 PM
> > > To: Enhanced Machine Controller (EMC) 
> > > <emc-users@lists.sourceforge.net>
> > > 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 
> > > <jo...@autoartisans.com>
> > > 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 <ken.stra...@gmail.com> 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
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
>
>
> _______________________________________________
> 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

Reply via email to