Question on Embedded Use

[rwbot]

Hi, I saw that PAPPL supported embedded environments, and Lprint uses PAPPL. But couldn’t find any documentation from either that went into embedded implementations. Could you shed some light on this?

Is there any existing workflow that enables deploying a print server on a microcontroller like (Arduino, RPI Pico)?

If not, what functionality from system packages would need to be ported in order to use a microcontroller as the target platform?

[michaelrsweet]

In general, you can run LPrint on any Unix-like embedded platform. I specifically test PAPPL on the first-generation Raspberry Pi Zero W, and from other experience know that it will run acceptably in as little as 64MB of RAM in a Linux environment on slower ARM CPUs. Less than that and it gets really hard to handle IPP, TLS, and the various networking bits.

As for microcontrollers like the Pico 2 W, LPrint and PAPPL just won't fit - 520k of memory isn't enough to support TLS and would require a very different IPP implementation (one that just streams IPP attributes and values rather than caching them in memory).

[rwbot]

Thanks for clarifying! I know you said 64MB was the minimum you’ve confirmed,l - it that a hard minimum or just the lowest you’ve been able to test? The highest RAM I can find on the market rn for microcontrollers is 8MB on the Seeed Studio XIAO ESP32S3 (8MB PSRAM, 8MB FLASH). Any chance it could manage to work with that?

For context my use case is adding AirPrint capabilities to USB label printers. Atm i’m using Pi Zero W’s running lprint, but the zero w is bulky, and relatively expensive at $20+ each. I’m trying to make a simpler, more compact solution, like a dongle but having trouble finding boards small and cheap enough that can run full Linux, hence my question on if it can be run on a microcontroller without Linux.

I’ve used the XIAO S3 as a video streaming server using standard Arduino libraries, and know projects like esp3d.io enable wireless print servers for 3D printers using similar boards, and I’ve used HTTPS/MQTT/modbus protocols on Arduino/ESP32 boards so my intuition was that getting a print server to run as well would be possible but I haven’t seen anything like that online. I’m not familiar with the specifics of IPP/CUPS/Lprint but could you give me some insight on why a full UNIX system is required? or specifically what UNIX level functionalities would need to be ported? I’m definitely intrigued by that functionality, but wanted to do a sanity check first before I went too far down that rabbithole.

Thanks again for getting back to me!

[michaelrsweet]

8MB might be enough sans Linux, but you'll need a POSIX-compliant embedded OS (VxWorks, QNX, etc.) to run in that envelope. The tricky part is often getting proper mDNS/DNS-SD/IPv4LL support as most FullMAC Wi-Fi chipsets that are used in embedded environments traditionally have very poor conformance for those things, making it very hard to certify an AirPrint implementation... :/

WRT the "bulk" of the Zero W, I'd say the worst of it is probably the positioning of the USB connectors, but you can get/make a micro B to B adapter to directly connect the Zero to the printer and do a 3D printed case to effectively create a dongle that plugs in the back of the printer. And one of the advantages of this hardware (or any of the other copycat boards) is that you can run the standard LPrint software on a (relatively) standard Linux installation rather than spending years (!) of effort doing a new implementation - unless you plan on selling 100k+ units, it would be hard to make up the different in cost...

As for why CUPS/PAPPL/LPrint require POSIX, that is because POSIX is the target platform and all of the open source mDNS/DNS-SD libraries also require it. CUPS was originally developed on a SGI 4D/25 Personal Iris workstation (20MHz MIPS R3000 with 8MB RAM running IRIX, and old commercial Unix), but its usage of IPP was significantly simpler and preceded the invention of mDNS/DNS-SD, the use of gzip for compressing raster data over the network, IPv6 networking, POSIX threads, etc., all of which added to the overhead of a minimal implementation.

No doubt you can develop a smaller implementation, but there will be tradeoffs/compromises. For reference, the PAPPL test suite uses 1.3MB of memory just for its own data for a single queue configuration on a 64-bit host. The amount will be slightly less on 32-bit systems, but you aren't going to reduce the total size without making major architectural changes to the code.

[matthijskooijman]

If you're looking for physically smaller linux boards, here's a few that I've seen so far (only worked with the milk-v ones):

• https://milkv.io/docs/duo/overview (especially nice since CPU datasheets are on github)
• https://www.luckfox.com/Luckfox-Pico
• https://wiki.sipeed.com/hardware/en/lichee/RV_Nano/1_intro.html (same CPU as the milk-v)

I think only the lichee model has a wifi option, so that would need to be added separately on the others, which might not be super-convenient. Some of these have an ethernet connector, but I think the ones without usually have the controller and phy, so can easily use an external ethernet connector.

There's also board like the Rock Pi S and Milk-V Duo S with a square form-factor, but maybe these are already too big for your purposes? I do think both of them have a wifi version available.