Libraries to make embedded development easier.
We’ve written a number of high quality libraries that work on an unprecedented number of boards, including Arduino, mbed, PicoSDK, STM32Cube, ESP-IDF and Raspberry PI. These libraries and frameworks are battle tested, having been used in literally thousands of live designs. Take a look at the “Products” section. See our production ready open-source libraries.
Not everyone wants to build commercial products on top of Arduino, and recently PicoSDK has been added to the list. If we get enough donations we’d consider supporting STM32Cube and ESP-IDF too.
We are audiophiles and as such like both listening to music and building audio equipment. TcMenu’s first use-case was an audio amplifier, and you’ll see many of the examples still show that. But rest assured, it has been used for many other purposes from Agriculture, Home automation, Model trains, Live audio control, Lighting control to name a few.
What people have said
Thank you, John, GitHub
Thank you for these libraries and for somewhere to discuss them. I have been using the various libraries for some years now as part of my activities...
From Tcc Forum
I had grand ambitions, and, with the support of my company, managed to execute on most of them. TFT_eSPI, tcMenu and taskManagerIO really made it happen....
GitHub Stars
We have over 500 stars on GitHub shared across all the repositories and several sponsors past and present, nothing says thank you quite like that.
Recently added..
Nutricherry.com domain
The domain nutricherry.com is owned by TheCodersCorner.com. The original site has now been closed out, and it now points to this website.
Building low latency Java applications with Java 22 and beyond
This article discusses my opinions around moderate latency and low latency applications built on the JVM using JDK 22 and greater. It is based on many years of trying various approaches. For years the regular way to build exceptionally low latency (or more correctly low GC pause) applications was to avoid memory allocations in the critical parts of the application, and ensure that any libraries used also minimise memory allocation too. We know how long algorythms take to execute, and we can be fairly confident about the time take to execute code, but we cannot be anywhere near as certain about garbage collection.
Does the native linker change the status-quo for JVM low latency?
This article discusses if the Java 22 foreign memory API and value classes change my view of the status quo for building applications that communicate with C++ components and the possible latencies in that approach.
In the past, with JNI as the C++ go between, there were enough disadvantages that sufficiently down voted this option to the basement. Let’s investigate a few, firstly JNI required complex arrangements to call out into native code, you had to either use a third party library, or alternatively implement a lot of native shell code that implemented each native method declared in Java. Even this was not the biggest drawback. The biggest drawback was until recently, JNI calls prevented GC - see GC region pinning, and therefore carried the risk of introducing latency (the very thing we are trying to reduce anyway), and additionally, every thread that wanted to interact with the JVM had to register with it. Further, to access Java objects the JNI C++ code had to “inspect” the object itself, let’s just say the performance was not particularly good. The last obvious disadvantage is that the C++ code does not run in a VM, so any major error can crash the process.
You'll also find me on:
