Skip to content

Limitations & known issues

Jump to bottom
jake-is-ESD-protected edited this page May 20, 2026 · 6 revisions

Arduino's Serial.print()

jescore is intended to be a pure C library with possibilities to expand to more platforms. It does not rely on the Arduino FW and therefore needs its own serial hardware call implementation, which is different for many platforms. This is why jescore instead uses uart_unif_write, a generic UART TX function that compiles differently depending on the selected platform. Expanding to more platforms is planned. Since Serial.print() has its own implementation, it messes with the one in jescore, leading to missing print statements. If you want a response from jescore, use uart_unif_write() or uart_unif_writef(). Alternatively, you can use the new jes_print() macro which automatically prefixes output with the job name.

Interrupts

Since interrupts are managed by the specific hardware and not FreeRTOS, jescore can't yet cover them in a concise manner. You can notify jobs from within an interrupt by using jes_notify_job_ISR(), but other than that you will need your own ISRs and register them according to your system. If the CLI is enabled, the controller makes use of the systems UART interrupts or any similar mechanism. Unifying interrupts is planned.

Dynamic memory

Since jescore creates and ends jobs during runtime, it uses dynamic memory and takes a bit longer to start a job. Additionally, the native CLI support uses a lot of internal memory for strings which could just be enums without the CLI. If your goal is to build a fast, static and memory efficient software, the standard jescore might not be the best option for you. Creating a static and more lightweight option is planned. See the architectural improvement candidates for details on the planned static memory allocation API.

Safety

The world is your oyster. This also means that jescore won't check what sort of devilish things you do in the jobs you give to it and will happily run against a wall if you do something nasty like this

uint8_t* p = NULL;
uint8_t my_val = *p;

This will provoke your controllers natural error mechanisms and jescore will die at this point. Always validate your pointers and parameters!

Known Issues

  • ESP32 UART driver initialization is now idempotent (v2.3.0) - initializing twice no longer causes issues
  • Notifying a non-existent job will no longer crash (v2.2.3)
  • Shorter error messages reduce memory usage (v2.2.1)

Clone this wiki locally