The Ugly…

ONLY for “safe” projects

🚫

If your project uses anything that might cause injury or is otherwise “dangerous”, such as controlling high voltages, using large high power motors, or driving potentially blinding light sources, you are NOT ALLOWED TO USE THE LCPF. So if you’re trying to build your own laser cutter or add a powered exoskeleton to help you walk around in your W40K Space Marine cosplay, the LCPF is not for you. More details on the Safety page.

it is NOT meant to help you “learn to program”

and might even make learning to program in the future harder
it makes a lot of “wibbly wobbly, timey wimey… stuff” just work, but that’s part of what you need to learn for traditional coding and it can get quite complicated. Forutunately the LCPF is bigger on the inside…
getting into how LCPF does things behind the curtain might be instructive for intermediate and advanced programmers, but even then it may be counter-intuitive as it intentionally "breaks the rules" in ways you usually shouldn’t

the LCPF Vocabulary is finite

The LCPF vocabulary is designed to be intuitive, and can make it seem trivial to add some very complex behavior to your projects
but it does not provide a way for you to add to the vocabulary in your project
if you want to do something “new” that isn’t already covered by the current LCPF vocabulary, it will not be easy
- and may be practically impossible, without some serious programming experience and a deep understanding of the LCPF architecture - which is unfortunately a very long journey for a “non-programmer”
- although you can request additions to the vocabulary, and if it fits well within the overall LCPF goals there’s a reasonable chance the LCPF developers will add it to the system

It can be slow, and may occasionally stutter or “freeze” for a moment

An LCPF project will run a bit slower than a properly designed and written CircuitPython version with the same functionality. In some cases, it may be significantly slower for simple tasks, especially if there’s no need for things like a Web UI.

It doesn’t “boot” quickly

the wait between powering on and when your project starts “running” can be significant - the more of the LCPF features you use, the longer it takes.
currently, with ESP32 S2 and S3 controllers, it ranges from around ten seconds to over a minute for “everything and the kitchen sink” with a slow WiFi router.
Parts of LCPF supporting some features and Shields / Devices don’t get loaded until you actually use them
Wifi / WebUI support requires both loading more code and time to “connect” to your Wifi and startup the internal WebUI server

There is very little you can do about this¹ other than using a faster controller.

And even with a fast controller, LCPF projects may occasionally “freeze” or stutter for short (less than a second) periods of time. While progress has been made (and efforts continue) to reduce both the frequency and duration of these freezes, it is effectively impossible¹ to eliminate them entirely. In some projects you might never really notice, but if you have a lot of anuimated lighting effects and especially audio effects active while using the WebUI, it will probably crop up occasionally.

Limited hardware choices

There’s not an easy way to effectively use any Controller, Shield, or Device in an LCPF project until specific support has been added for it.

The LCPF is still a new, single developer project.

While it’s already able to do alot, and it’s under active development, there’s no gaurantee that this will continue.

Tehcnically, it is still in part an experiment. One of the motivations for creating the LCPF was to see how close I could get to the Primary Goal using what is still technically just python/CirctuitPyhon code ( albeit with a lot of “magic pixie dust” pulled in with `from LumensalisCP.Simple import *). I think the LCPF achieves this, or at least comes close enough to be useful for many people, but I won’t really know until there enough “non programmers” actually give it a try and end up successfully using it on their projects. If it turns out that the LCPF fails to be useful for non-programmers (which I consider unlikely but not inconceivable, and I tend towards the optimistic), it may not get much additional attention, and possibly be discontinued or significantly reworked.

That said, making things go blinky with embedded systems and various twists and making programming easier have been behind “passion projects” of mine for a long time, and I’ll probably still be tinkering away long after I retire. It’s unlikely that I’ll stop working on anything like the LCPF if there’s active interest. But the amount of time I can devote to it may vary, and there’s no gaurantee that I’ll be able to keep up with demand for new features, hardware support, etc.

Potential for breaking changes

Some things may “change” in ways that break existing projects. This is not something that will ever be done lightly. But especially for “new” parts of the LCPF Vocabulary, things may evolve based on user feedback, especially when ideas which were meant to make things easier don’t actually end up doing so in practice.

The LCPF is NOT an Open Source project

Although the source is available and it’s intended to be “free as in beer” for people to use on their personal projects, the LCPF is not under an open source license. You can find more details on the License page, but be aware

Technically even sharing the “source” for your own project without permission might (and certainly will if it includes any additions to or modifications of the LCPF) violate the license, even when there’s no “profit” involved (although you can ask for permission)
Doing anything with the LCPF that generates revenue in any way is not allowed without a separate commercial license.

Unless you want it really bad, have very deep pockets, and are willing to subsidize the development to effectively “rebuild” the LCPF based on C++ - which is actually quite feasible as many ideas in the LCPF come from an earlier project of mine which would provide a substantial head start. But it would not be cheap ↩ ↩²