From the BTT board design (Octopus for example) the STM32 is connected directly to TX/RX, and the entire STM32 device is 3.3V, so they are going to be 3.3V. Given that the TFT35 is made to work with these, it must work with 3.3V TX/RX, meaning it should also work with the ESP32 expansion port.
A short pigtail that connects +5V, TX, RX, and GND from the expansion header to the corresponding TFT35 connector pins should be all that’s needed as far as hardware.
This is interesting to me because I want to go the other way and plug the pendant into one of these Marlin boards someday maybe.
I don’t see any level translation on there so would definitely assume that it’s 3.3V logic. In general, that’s probably the safe assumption anyway, these days. If a board has 3.3V on it anywhere, unless there is a deliberate level translation stage then it’s almost certainly 3.3V logic.
I’m sorry to say, after the initial excitement, I’ve been having a hard time getting motivated to continue.
I am not sure why it has fallen in priority. Maybe part of it is that I’m only using FluidNC for testing, not to do any real work, and at the moment I’m not anticipating switching. That means I don’t feel the pain of not having a pendant when I’m trying to accomplish something.
Also, the FluidNC philosophy of having one executable with everything configured at runtime is not really amenable to experimental features. I don’t know specifically what I would want to add to FluidNC, but I get the feeling that special features are frowned upon. It is aiming to contain only what “most people” are going to need, and everything else is a liability since it eats up flash space and RAM.
Marlin takes the opposite approach, where all kinds of stupid ideas are okay to add, and they cost nothing to people who don’t enable the feature. It’s much more open to dumb or rarely-used features.
Maybe I can get everything working with no modifications to FluidNC, so that would be a non-issue.
I don’t know. Maybe I can at least start with a simple keypad to get some macros going without the Web UI. Maybe then extending to do jogging will not seem like such a big job.
to use as a starting point, but so far, I haven’t found much that I want to do that’s not simple enough from the FluidNC interface.
I may still pick it up one day just as an exercise. It would be cool to work on making a little TFT touch screen interface, if nothing else, to be able to see status and start jobs, etc with having another device nearby
Guessing they don’t have a .DLL concept, dynamically loaded libraries at runtime (based on runtime config). e.g. Build everything, but store non core LIBs on SD card, load/unload Libs into precious mem based on runtime config?
That said, seems like a lot of engineering time/labor is being spent hitting, and working around memory limitations of a ~$5 device. Limiting features and progress velocity. Are these limits hit on 16MB ESP32 even? If so, if not now, then when is a good time to port to more memory rich capable devices aren’t significantly more expensive, e.g. elusive Pi Zero 2 W?
I like Jackpot’s modular design with ESP32 not part of the Jackpot PCB, so many options
Happy to have discovered Klipper for my MP3DP, love being able to change config and macro at runtime. Running on a Pi with glorious amounts of GBs. Fluid/Marlin on devices not be frequently reconfigured and experimented with (e.g. LR3) makes sense to me. Although, if experimenting wasn’t a PITA, more experimenting/progress would happen…
I’ve been following their Discord/Github for a bit, and they are not very inviting at all. I get that their support might be a nightmare, but Mitch is very rough with people.
I am usually onboard to try to help out with stuff that I’m interested in, but they completely turned me off from even trying with FluidNC.
I had grand ambitions tooand ran out of money. Life slapped me in the face. But hopefully things will slow down for winter. Kids cost so much anymore!! I started a lr3 but quickly stopped. I always wanted joystick/controller!
