# 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](https://github.com/jesdev-io/jescore/wiki) 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 
```c
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)