It was a bit of work, but I got it.
Octoprint running on the pocket beagle.
1 Like
Excuse my ignorance but - what is a Pocket Beagle? Tiny Beagleboard?
It looks like an arduino nano based on a beagleboard
The pocket beagle is a shrunk version of the beagle bone black.
https://beagleboard.org/pocket
It is designed to fit in the smaller Altoids tin. A company called Octavo Systems makes a System in Package that contains the vast majority of the parts needed to build a beagle bone black onto one unit, to simplify design and production. It lines up with the Rpi Zero, but no on board WIFI (or ethernet). Its about the same size too.
Right, so the reason I posted this was a prelude to performance questions.
I expect Octoprint to perform about the same as it would on the RPI Zero. To that end what kind of problems/limitations should I expect to see? I know that video streaming is going to take a hit. Apart from that, what else? It doesn't need to be comprehensive, I just need to know what to expect as I develop my thing.
How many cores does it have?
1 arm core + 2 PRU's ... pru's are totally useless for octoprint but maybe could be interesting board as "cpu board" for 3d printer 
(maybe being operative word)
1 Like
If you're using Raspbian on that then it's unlikely that the drivers would take advantage of them.
That's exactly right. Imagine 200Mhz Arduinos with DMA access to main memory.
The OS is Debian.
irrelevant to OS, OS is not using PRU's, but you can use them, for e.g. look at redeem for e.g. (you get it with Umikaze OS that's debian based) it comes in 2 parts, one part talks to the "world" (ideally octoprint), interprets G-code and calculates motion, ( and is done iirc in python 
) and the other part written in asm for those PRU's that's a step generator and state machine that handles all the IO at high rates ... more here: https://replicape.github.io/index.html and here: https://github.com/intelligent-agent/redeem
I know replicape. Reedem though. I guess this is what I'm trying to do but for a different stepper chip that uses SPI to communicate (so no bit banging of the step pins).
In case of a single core I'd be wary of on board webcam. CPU should in principle be fine. Will definitely be slower to start and reload and such than eg a pi3, and I also can't vouch for any third party plugins.
1 Like
tbh I don't understand those SPI & ModBus drivers at all .. the configuration trough SPI/ModBus/RS485 is cool, clear and actually great, but all I seen wrt actually moving motors trough any of the serial protocols is "move at this speed for X counts using this trapezoid curve for acceleration/deceleration" and "move till count reaches X" .. but how do you get them in sync?! you want to move at least 3 motors in perfect sync so something like
A - you go x steps at y speed following L curve when I say "go"
B - you go z steps at w speed following Q curve when I say "go"
C - ...
and then you trigger a "go" IO
but none of the serial controlled drivers I used have the "go" pin, so you actually tell them all as fast as you can "go do this" and they go, but there's no sync ... not to mention if the clock on each of them is "bit off" ...
so, if you do it 
share ..
maybe you can add on to KLIPPER ? https://github.com/KevinOConnor/klipper
So, I have that code already in c#. The line that you want to travel is a trapezoid. Each motor travels that distance as a percentage of the total which varies on the angle of the line. In the case of my SPI driver, chip select is active low. So when chip select goes high, it signals all the drivers to start their movement. That's how it stays in sync. Further, you can drive the internal logic via an external clock source, which would ensure that the calculations to generate the stepper pulses are in sync. You don't have to use it though, but it's there if you want. Already have working code to do it (for the L6470 stepper motor driver by ST Micro). The sharing part however, I haven't decided on. I just don't know if I should.
hm, I was using "big drivers" that are "closed box" so had no CS .. but cool, so you disable CS and they take that as "go go go" signal ... cool, that makes sense. The following speed curve is ok, that part I know how to do
need to check that driver, thanks .. I was using some "ready" drivers (xinje and similar) but didn't spend too much time on them as for that project I only needed to drive 2 axes and they had no requirements to be in sync and had completely different control mechanism .. but going trough all the documentation didn't see anywhere how to get them in sync ... what you write here totally makes sense
one need to decide that for oneself .. I for e.g. must share most of my work under different aliases as my employer is heavy on that type of stuff trying to own everything.. so sharing is a fight, but one has to share if one expect to receive .... anyhow, sharing knowledge is imo way more important then sharing code so ...
Humm... you make a very good point. Perhaps I have been selfish. 
you need to decide, noone knows that better then you.... sharing knowledge is enough in my book, sharing code is better but not always necessary ... I'm bit biased as I'm working on foss project for 11+ years but hey if you don't feel like it, don't get pressured by others, you should do things the way you feel about them, not they way other ppl expect you to do them
Sigh, gpu_mem? It doesn't have a GPU. I thought that setting was to limit how much memory python would use. Is there is limiter for that?