I’m working on a project that requires a Photon to talk to an Arduino via serial. Normally, a serial connection is made to the Arduino to a computer host via the USB connection. The protocol is pretty simple, the Arduino receives short ASCII-encoded commands like READ 1 or WRITE 1 and then writes back any results. I want to use the Photon to play the role of the computer and let me use a simple web app to do this remotely.
The problem I’m having is figuring out exactly how to setup the serial connection between the Photon and the Arduino. It would be simple enough to use a logic level converter to talk between the 3.3v on the Photon and the 5v on the Arduino (there’s a nice tutorial around here for that…), but unfortunately all the GPIO pins are being used for other things on the Arduino so I’m left with just the USB serial connection.
So, would it be possible to directly connect the USB connection from the Photon to the Arduino? I should note that the Arduino is externally powered from a wall adapter, and provides the proper 5v over it’s USB connection to power the Photon.
Not sure how relevant this is, but the Arduino requires an 115200 baud rate. I read in the docs that the baud rate is ignored when used over serial on the Photon, (see the note here https://docs.particle.io/reference/firmware/photon/#serial). I’m assuming this means the host and the Photon have a way of negotiating a rate to use. If that’s the case how would that work when connecting directly to the Arduino?
Also, this will make development difficult, since I won’t be able to monitor the serial connection on my computer. I suppose I could connect the Arduino and Photon to my computer and write a script to send communications between the two while printing everything to a log file.
Unfortunately, no. I’m not a USB spec expert by any stretch of the imagination, but I think USB follows a sort of master-slave (host-client) relationship. I do not think either the Arduino or the Photon have the ability to function as a master or host.
If you could free up a couple of those GPIO pins (or the TX/RX ones), you could easily chat with the Photon via serial. Can you use something like a shift-out register to free up some pins on the Arduino?
I’m familiar with that one! Thanks for the kind words!
Thanks for the reply! Your tutorial was a really cool read, btw. Thanks for sharing it.
I was reading around and yes, you’re right about the host-slave relationship of USB. I would need the Photon to act as a host in my case. Apparently, there’s something in the works to make that possible natively, which would be awesome.
To shed a little light on the project I’m working on, I need the Photon to work over USB so it can talk to other devices that are not Arduinos (CNC mills, lathes, etc.) but share the same simple serial over USB protocol. On those devices, I can’t access a Tx/Rx bus directly.
I don’t suppose any of those other devices have TCP/IP networking capabilities, do they? They could easily communicate over some sort of common, telnet-like protocol (as long as you trust the network they’re on!). If not, it’d be tempting to have them all connected to a USB hub that’s connected to a single board computer like the Raspberry Pi 2. A simple NodeJS or Python script could easily traffic-cop all of those devices. It might be a little less temperamental if you have a bunch of devices talking at different speeds, too.
I hadn’t come across that one yet. I’d love to hear how it turns out!
How funny, I just read through the comment thread on your tutorial, and it looks like I’m doing something very similar to what you did with your 3D printer. I also have a reprap Prusa i3, and I’m trying to control it via the Photon. I could connect directly to the Tx/Rx on my mega that’s controlling it, but I’d also like to be able to control other G-code speaking devices.
[quote=“wgbartley, post:5, topic:17044”]
I don’t suppose any of those other devices have TCP/IP networking capabilities, do they?
[/quote] Not out of the box. My idea is to use the Photon’s easy wifi setup to enhance these devices so that they can be controlled remotely.
Beyond this issue, I’d also need to find a solid SD card library to store the G-code files to. Thankfully there’s now a great HTTPS library for the Photon so I can download the files without having to send them piece by piece through the spark cloud. Now, I just need a place to store them…
I ran into a snag with that setup. I don’t remember the exact details, but while I had it set up, RAMPS would occasionally pause for several seconds at many points in the print. I didn’t do any extensive testing, but my gut feeling was that the RAMPS serial output was waiting on something at the other end (the Core at the time) to read that serial data and drain the buffer. I cannibalized the Core for another project, so nothing was listening on the other end of serial. As soon as I disabled the serial output (it was on one of the higher serial pins–2 or 3 maybe?), things resumed normal operations.
If this is going into a critical production environment, do lots of testing with that in mind. Do lots of dry runs (no filament) to make sure those devices don’t choke if the serial data isn’t read quickly, properly, or at all!
I had originally considered streaming the G-codes to the Photon which would send them to the printer, but latency would cause issues for sure. I haven’t looked too closely at how the host interacts with the printer, but I image there must be a pretty steady flow of commands from the host to avoid the printer sputtering.
Thankfully RepetierHost is open source, so I’m looking at how things are done there to see how I might emulate that with the Photon. I may just use my RPi for now with a little TCP client until I can get a USB host interface working with the Photon.
Wow, OctoPrint does everything I was hoping to achieve and then some.
I wasn’t really planning on taking this idea to production, especially now that I know that there’s already some existing systems out there. I might just hook the Photon’s Serial1 to the mega’s Tx/Rx lines and hack on it for funnsies anyways. Thanks for all the great info!