Skip to content

Limitations & known issues

Jakob edited this page Mar 8, 2024 · 6 revisions

Interrupts

Since interrupts are managed by the specific hardware and not FreeRTOS, jes-core can't 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.

Dynamic memory

Since jes-core 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 jes-core might not be the best option for you. However, you can check out jes-core-light or jes-core-miniif you want to reduce or remove CLI support or dynamic capabilities.

Overhead

Safety

The world is your oyster. This also means that jes-core 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 lolxd = lol_array[MAX_LOL_ARRAY_LEN]. This will provoke your controllers natural error mechanisms and jes-core will die at this point.

Clone this wiki locally