Feature Request - Scripting capabilities and host hardware interface libraries

[ghost]

Scripting capabilities – add possibility to define custom scripts for hardware initialization, communication etc. For example, some hardware devices can be configured, communicate with via custom scripts without need to develop special software support.

Support for host hardware interface libraries. Add possibility to communicate with hardware devices from the host. Porting libraries like WiringPI, WiringOP etc. to allow high speed interface to devices without need to go through MCU/s.

I tried adding WiringOP to current linux port, got very slow speed.

[dragonnn]

Most CPU with runs Linux aren't designed to have fast GPIO, so this will never work.

[ghost]

@dragonnn, Before posting such comments what will work or not, you should probably check what speed other people have achieved. For example, RaspberryPi - GPIO Speed Test on a Raspberry Pi (https://swehacker.com/?p=382). On OrangePI One with WiringOP I was able to toggle pin at about 1.7 MHz.

Based on the responses from other Issues #133, #485, I understand there is unwillingness about this, but in my opinion the serial connection between the CPU and MCUs, or actually the whole Klipper architecture currently is good enough just for slow speed applications. In other words, even the stepping rate results are quite high, when it comes to basic operations like toggling of a pin for engraving, a small AVR based GRBL controller can perform much faster in comparison to the whole Klipper system.

[KevinOConnor]

It's not clear to me what is being requested. In any case, I suspect you'll need to perform the development work to make it happen.

With respect to issues 133/485, there's no unwillingness. These types of things require a lot of hard work and (as far as I know) no one is currently interested in doing that work.

-Kevin

[ghost]

@KevinOConnor, I am not so good programmer, also do not like Python and the codding style of this project. To mention not that my quarrels with GitHub escalated and will have to delete this account.

Would you at least fix your linux port ? Currently the speed seems to be fixed to 20 MHz ? Also some delays are presented, that are not quite clear what are for. The whole implementation limits the execution speed.

[theopensourcerer]

@EmbDevices The file works fine. Copy and save the raw file into a plain text file on your computer using a simple text editor, not Word or something like that:

https://raw.githubusercontent.com/KevinOConnor/klipper/master/docs/prints/square.stl

If your Slicer still can't open it then you probably have a more fundamental problem. Perhaps try using a different slicer like the excellent Prusa edition of Slic3r, or Ideamaker?

[ghost]

@theopensourcerer, Thank you about your comment. Yes, the GPL license of this project to some extent is a problem. Many of those hardware companies have horrible licensing policies, they do not comply with GPL, have NDAs about accessing chips software, documentation etc. By the way that is one of the reasons I do not deal with Broadcom and will never purchase devices such as RaspberryPi. The Asians, in some cases similar issues, Allwinner, Nuvoton, Ingenic etc. have some models with publicly available software and documentation software, tools, cheaper etc.