I wish knw if there are someone working with the Octoprint on that board.
I could not find anywhere any topic/community on that matter.
The OctoPrint Wiki has an article on how to use it, the Replicape project using some OctoPrint on a BBB.
I’ve been attempting to get Octoprint working on a BBB as well. i have found that the wiki page is slightly incorrect in the methods to install the server and set everything up. Are you looking to use the USB port to interface with the printer or one of the UART serial connectors?
Personally, I have been able to complete a connection through the use of USB, but the serial port is an issue. (Seems like they automatically tie up with a console, which interferes with the communication between the printer and the server.) UART should work well once I find a method to remove the console tie-up.
AFAIK, there's only one serial console, and that's on the serial debug
port (the 6-pin header). You should be free to use any of the UARTs
connected to P8/P9 pins, but you'll probably need to enable them first
via a device tree overlay.
If you want to use the 6-pin serial debug header, you can disable the
console by editing /etc/inittab. Comment the line near the bottom
that looks like:
T0:23:respawn:/sbin/getty -L ttyO0 115200 vt102
...then you should be able to use the port for whatever you want, but
you'll still get some "garbage" spewed by the kernel and u-Boot at
boot. You could disable that too, but it's more complicated. If the
characters printed at boot are a problem, just use one of the ports on
P8/P9.
If you want to use the 6-pin serial debug header, you can disable the
console by editing /etc/inittab. Comment the line near the bottom
that looks like:T0:23:respawn:/sbin/getty -L ttyO0 115200 vt102
Not meant to berate anyone, but just like me sometimes I forget the newer images run Jessie, which default to using systemd as the systems init daemon. Anyway, with systemd there is no /etc/inittab, and serial or other things that were norally handled by inittab are instead written as startup services suppose . . .
So for those of you who run the latest testing image . . . there is not inittab unfortunately.
Feel free to update the wiki article. I wrote it originally but I switched my OctoPrint server to the RPi eventually because it's more common. I moved my BBB back to more experimentation.
Feel free to update the wiki article. I wrote it originally but I switched my OctoPrint server to the RPi eventually because it’s more common. I moved my BBB back to more experimentation.
Yeah, a RPi does seem a little easier and common to work with. Once all the kinks are worked out with the steps, I will see what I can do to update the wiki.
AFAIK, there’s only one serial console, and that’s on the serial debug
port (the 6-pin header). You should be free to use any of the UARTs
connected to P8/P9 pins, but you’ll probably need to enable them first
via a device tree overlay.
So I just did a quick test by connecting a RPi to the BBB UART1 (P9_24 = TX and P9_26 = RX) after enabling the UART and confirming its available via:
root@beaglebone:/dev# ls -l ttyO*
lrwxrwxrwx 1 root root 5 Jul 8 01:09 ttyO0 → ttyS0
lrwxrwxrwx 1 root root 5 Jul 8 01:09 ttyO1 → ttyS1
<\code>
I logged into the RPi and started a minicom session with a 115200 and 9600 baud just to see if I can grab any response from the port. I believe you are correct that a console is not tied with UART1 since I’m not receiving anything of interest (no login prompt or even garbage). To farther verify this, I was able to make a console connection from BBB UART1 to RPi. There was no odd ball junk popping out like it would if using UART0 while tied to the console.
On a side note, why is there a ttyS* tied with the ttyO*? I’d always assumed that those where devices indicating that there is a shell console tied with the UART port. After this quick test, it would seem like this is incorrect to assume. I was able to use either ttyO1 or ttyS1 to communicate from BBB to RPi without any issues. Why is this there?
ttyS* basically means "serial port", not "serial console". You won't
get a console unless you run getty (see the commented examples in
/etc/inittab for ttyS0 and ttyS1).
IIRC, the earlier BBB kernels used /dev/ttyO* port naming
(particularly prior to the TI Omap serial port driver being integrated
with the kernel serial driver). I believe the symlinks are a
convenience to keep older code/documentation working. Note the 3.x
series kernels have this somewhat confused with port names and
numbering changing between various kernel versions as the drivers were
being updated, but I believe the 4.x kernels should all use standard
/dev/ttyS* naming with consistent port numbering.