Home › Forums › TinyG › TinyG Support › Seperately powering the FTDI and/or XMEGA
Tagged: FTDI power
- This topic has 5 replies, 3 voices, and was last updated 10 years, 3 months ago by moeter.
-
AuthorPosts
-
July 11, 2014 at 10:26 am #6401moeterMember
Hello,
is there a way of seperately powering the FTDI chip? The reason behind this is, if we get a power outage (e.g. Emergency Stop) on the main power, the FTDI is also powered down, and it seems you have just unplugged the device from the PC, making the serial handle invalid. It’s quite annoying to code for such a behaviour in a platform independent way, as device removals are VERY OS-specific…
Thanks
July 11, 2014 at 11:48 am #6402cmcgrath5035ModeratorRiley or Alden will have to comment on tinyG specifics.
FYI, I have solved this issue with similar FTDI appliances (on another project) using udev rules to pre-assign a serial interface to the serial number of the FTDI device. Was claimed to work on Linux and Windows, I only implemented on Linux. I would guess that MacOS would be similar to Linux.
Unfortunately, I was following a guru’s detailed how-to, could dig that up if you cannot find.- This reply was modified 10 years, 4 months ago by cmcgrath5035.
July 12, 2014 at 7:54 am #6418aldenMemberWe actually did this on one experimental board and the results were not good. When we powered the FTDI from the USB Vbus the FTDI stayed connected to the host, but the chip would have difficulty connecting on the Xmega side when power was applied to the board. The whole thing was very dependent on the correct power sequencing, so we abandoned that approach. I’m afraid the FTDIs are what they are – which is one of the main reasons we went with native USB on the ARM development.
July 14, 2014 at 4:20 am #6430moeterMemberSorry to hear that… but still, this also means, something else is going wrong: If the setup only works if we have the correct power sequence, then most likely we also need the correct power seqence when using the serial interface on the board directly. Am I correct?
As for the cmcgraths suggestion: I have to try on Unix/Linux, but Windows preserves the Handle when a FTDI device is disconnected, but obviously gets no more replies. This is actually okay behaviour. However, if we replug the device, we are still connected to the Null Handle, and even if we replug the device, you get no more answers. Im very interested in your solution, but I have my doubts if that would work on Windows (udev and Windows sounds, well, unlikely).
Actually it would be quite helpful to know how Coolterm notices the connection loss, as it’s the only Windows terminal program, that even takes notice of an unplugged FTDI device.
On another note: what would happen, if we just powered the 3.3V using an arbitrary 3.3V Pin and an external power supply? In my opinion it should either burn everything (or just the lm2594) down or power the logic part of the board, but not the output stage. alden, can you shed some light on this?
Thanks!
July 14, 2014 at 7:43 pm #6433aldenMemberThe board as it stands is pretty independent of power sequencing. It connects pretty much regardless of the order you power up and/or plug in USB.
You could play with powering the FTDI independently, but I still think there would be problems with power sequencing. I suspect the FTDI serial flow control may be getting messed up. I’m not sure what’s going on in the Windows terminal program – we’ve never had any problems with Coolterm.
July 21, 2014 at 3:43 am #6443moeterMemberHm, but is it still power sequencing independent, if one would use the serial pins (J14) on the board?
And, is it safe to power the logic part on its own via one of the many 3.3V terminals and attach 24V to V_mot? I think this might destroy the LM2594 linear regulator, but I’m not sure…
And actually, I’m impressed with Coolterm, as it’s the only program I tried so far that gives you an error when you unplug the USB cable. All other programs just stop receiving answers. So: How does Coolterm find out, when the USB cable is unplugged?
-
AuthorPosts
- You must be logged in to reply to this topic.