Serial Port Detection for FTDI on Prop Proto USB?
davidsaunders
Posts: 1,559
How does one figure out which serial port the FTDI for the Propeller is attached to, using a Unixen (Linux in this case, with standard device tree)?
I am using file I/O to access the serial port, though keep getting the wrong serial port on my Raspberry Pi. If something more general than just for Linux could be given it would be helpful, as I do plan on redoing the Host system software to run in RISC OS instead of Linux.
The Project:
To be complete, the project that this information is need for is a 3D printer that uses a Propeller Proto Board as the controller, so I need to send it G-Code over serial. It is working well if I send the G-Code when uploading the firmware, though that is a limited way of doing things.
I am using Linux for now do to the availability of 3D modelers and Slicer software, though I am working on writing my own slicer that will get ported to RISC OS, and my own StL 3D modeler to port to RISC OS. The modeler that I am working on is a simple one that will just use simple flat shaded poly rendering with simple Z-sorting to help clip rendering correctly, I am thinking of making a version for a propeller based system in the future as well.
Once everything is working as I would like I will take things even further. I intend to make a simple Propeller based system using 3 P8X32A's to provide a system that can be used to edit the 3D models, slice for the G-Code, and control the printer. That is just so I can brag that I have a 3D printer that can be used Stand alone, and that I am pushing the limits of the P8X32A in the application of a computer. Though it will require a good amount of external RAM, to handle 3D modeling
.
I am using file I/O to access the serial port, though keep getting the wrong serial port on my Raspberry Pi. If something more general than just for Linux could be given it would be helpful, as I do plan on redoing the Host system software to run in RISC OS instead of Linux.
The Project:
To be complete, the project that this information is need for is a 3D printer that uses a Propeller Proto Board as the controller, so I need to send it G-Code over serial. It is working well if I send the G-Code when uploading the firmware, though that is a limited way of doing things.
I am using Linux for now do to the availability of 3D modelers and Slicer software, though I am working on writing my own slicer that will get ported to RISC OS, and my own StL 3D modeler to port to RISC OS. The modeler that I am working on is a simple one that will just use simple flat shaded poly rendering with simple Z-sorting to help clip rendering correctly, I am thinking of making a version for a propeller based system in the future as well.
Once everything is working as I would like I will take things even further. I intend to make a simple Propeller based system using 3 P8X32A's to provide a system that can be used to edit the 3D models, slice for the G-Code, and control the printer. That is just so I can brag that I have a 3D printer that can be used Stand alone, and that I am pushing the limits of the P8X32A in the application of a computer. Though it will require a good amount of external RAM, to handle 3D modeling
.
Comments
$ ls -l /dev/tty*
To get a list of serial devices. USB serial devices should show up a /dev/ttyUSxxx
On a Raspberry Pi you can connect a Propeller directly to the pins of the UART on the GPIO header. No USB adapter required!
That can be used for both programming the Prop and subsequently for serial communication with it.
That will show up as /dev/ttyAMA0
$ lsub
Is good for seeing what USB devices are detected.
$ dmesg
Gets you the kernel messages that happen when things are plugged and unplugged.
What I wish to know is:
What is a simple way to detect which serial port I have the propeller hooked to, with out effecting the other serial ports. Any suggestions?
If the FTDI is the only USB serial port then it will always be the first one available, which is ttyUSB0. If you need to make sure that it is the correct port then you can check that it is not locked by another program and maybe you should put in some unique ID response on the Prop as you will at sometime need to grab the port and confirm that is is the right one anyway. You could always just use the $05 ENQ character to keep it simple. But if you are writing Linux software then surely you would be aware of this simple detail surely???
Thank you very much. I think I will probably use a 5 char response string to verify the correct port. Thank you again.
If your propeller is un-programmed you will have to send it something that it will respond to. Like the Propeller programmer softwares do. That involves sending 250 or so "magic" bytes and getting the correct 250 or so "magic" bytes back again.
To see how this is done have a look at my version of the Propeller loader for the Raspberry Pi here: https://github.com/ZiCog/pi-propeller-load In the file src/PLoadLib.c you will find the function hwfind() that does Propeller detection.
I guess you could just have your app run a loader program with the detect prop option flag.
If however your Propeller is already programmed with your application, I imagine the best thing to do is have the application send out an "I am here" indication every second or so when no one is talking to it. That way you can discover where your Prop is just by opening and reading a port. Avoiding having to send something that may upset other connected gadgets.
Of course just opening a serial port can tweak DTR/RTS or whatever on some systems and cause issues occasionally.
Though I think I will add your idea of adding a periodic send of "3DPRNT" every 0.5 seconds until it has been sent the first command, then just have the host side software wait until immediately after receiving the string to send the first command (that will be a setup string for the printer).
It is kind of obvious in retrospect. Though 99.9% of the time I will only have a single USB Serial port, so someone else will end up having to test how well it does on systems with more than one USB serial device attached.
The Propeller Proto Board USB will reset if the Propeller sets either pin 30 or 31 high. The 3.3V on the I/O line is enough to power the FTDI chip which causes it to reset the Propeller.
You don't want the Prop sending debug messages when not connected to the PC. If this information is new to you, I can add some links to some workarounds.
I reread my post and I failed to make it clear this is only an issue when not connected to the PC. I'm finding the links. I'll add them in a few minutes.
http://forums.parallax.com/showthread.php/116711-Can-Parallax-do-something-about-the-FTDI-reset-bug
Ok thank you. I will also look at the link you give.