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().

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 setting the common parameter from_ISR = true, 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 lighweight option is planned.

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.