In all (external) methods accepting the TaskName parameter you can specify defCurrentTask to indicate you want to use it for the current task, if you do not know that name (for example when code is run from different tasks). Never use it as a number in your code Please be absolutely sure you are inside a real task. If you are inside an isr, inside init or bark routines, you are not in task space and the current task may not be what you expect. However, the system cannot warn you for this situation. Thus, only to be used inside code that was called from appLoop_XXX.

In all (external) methods accepting the uiTaskNumber parameter you can specify defCurrentTaskNumber to indicate you want to use it for the current task, if you do not know that number (for example when code is run from different tasks). Please be absolutely sure you are inside a real task. If you are inside an isr, inside init or bark routines, you are not in task space and the current task may not be what you expect. However, the system cannot warn you for this situation. Thus, only to be used inside code that was called from appLoop_XXX.

The highest delay time you may use. If your tick time is 1ms, and since we have a 16 bit tick counter, the maximum delay is about 65 seconds. In my opinion, this is long enough. If you want to delay tasks longer it is better to get a real time signal somewhere else.

In most file operation calls you can specify an offset. Instead of using the real file length (which you must know or obtain), you may use this constant to start writing the new bytes at the end of the file. This constant is only available if cfgUseFileSystemMaintainFAT is activated.

In most file operation calls you can specify an offset. Instead of using zero, you may always use this constant to make your intention clear that you want to start reading or writing from the file start.

If cfgUseFileSystemConcurrentRead is activated, it is required to specify if you want to open the file system in read only mode, or in read/write mode. Although, you can just use a boolean there, you may want to use this constant to make your intentions mode explicit.

If cfgUseFileSystemConcurrentRead is activated, it is required to specify if you want to open the file system in read only mode, or in read/write mode. Although, you can just use a boolean there, you may want to use this constant to make your intentions mode explicit.

Use this in for example a shell. They take less space than full strings. In you shell app on a pc you can translate them to string messages. All request/response bytes have predefined length for the associated data streams.

Use this value as restartMode when calling taskRestart(). It puts the task in the start mode as defined in the configuration. For tasks with a shared stack, this causes the task to start in a shared state, passing execution on to to the next task with shared stack. The result thus depends on the setting being cfgStartRunning, cfgStartSuspended of cgfStartSleeping.

Use this value as restartMode when calling taskRestart(). It restarts the task, and makes sure it starts running. This value overrides the value given in the configuration. For tasks with a shared stack, this causes the task to start in a shared state, passing execution on to to the next task with shared stack.

Use this value as restartMode when calling taskRestart(). It puts the task to sleep. Restart only takes place after the device has slept. This value overrides the value given in the configuration. For tasks with a shared stack, this causes the task to start in a shared state, passing execution on to to the next task with shared stack. Note that the shared stack is not rescheduled any more until the device has slept. Effectively the task is temporarily taken out of the pool of tasks with shared stacks.

Use this value as restartMode when calling taskRestart(). It restarts the task, and makes sure it starts suspended. This value overrides the value given in the configuration. For tasks with a shared stack, this causes the task to start in a shared state, passing execution on to to the next task with shared stack. Note that the shared stack is not rescheduled any more until resume is called on this stack. Effectively the task is temporarily taken out of the pool of tasks with shared stacks.

For testing purposes you can fill the stack with other values that 0x00. This may be handy to see if you are not misusing a register. For the shortest code, leave it to 0x00, so the compiler can rely upon the .bss section cleaning. For a discussion how to use this setting see also cfgSysRegisterCheckByte. Also see the discussion at defStackClean.

In most file operation calls you can specify an size. Instead of using the real file length (which you must know or obtain), you may use this constant to keep reading bytes up to the end of the file. This constant is only available if cfgUseFileSystemMaintainFAT is activated.

Operations for a particular file number are only allowed inside the EEPROM space reserved for that file. You tried to read or write outside the file. The lowest nibble of the info byte displays the task number.

The call you made expected to be the file in the read mode, when is was in write, or vice versa. Or, the call is not allowed in specific circumstances, for example with a file open in write mode. The lowest nibble of the info byte displays the task number.

Calling a method that may block, such as mutex, wait or a the opening of a file with a task that is dominant may lead to a permanent system deadlock. Therefore this is prohibited. Also, when restarting a task, it may not be dominant, for it's state cannot be retained. Also, you may not handle suspend requests in the dominant mode.

Each task is defined only with a particular set of capabilities, unless you defined to have all capabilities for all tasks. You tried to perform an operation in a task which does not have sufficient capabilities to act. The lowest nibble of the info byte displays the task number. The highest nibble represents the failing capability. -- 0001 cfgCapWatchdog -- 0010 cfgCapEvent -- 0011 cfgCapCritical -- 0100 cfgCapSynchronization -- 0101 cfgCapFileSystem -- 0110 cfgCapDelay -- 0111 cfgCapTimeout

Trying to write data on an already full queue. This is not an error in strict sense, since bytes put on a full queue are simply ignored. However, you asked to be noted when this situation occurs. This error occurred inside a task (not an isr). The lowest nibble of the info byte displays the task number, this highest the slot number.

Your are trying to read more data from a queue than the size of that queue. This call can never succeed and is therefore an error, the call would block indefinitely. The lowest nibble of the info byte displays the task number.

Trying to read data from an already empty queue. This is not an error in strict sense, since bytes put on a full queu are simply ignored. However, you asked to be noted when this situation occurs. This error occurred inside a task (not an isr). The lowest nibble of the info byte displays the task number, this highest the slot number.

Your are trying to write more data to a queue than the size of that queue. This call can never succeed and is therefore an error, the call would block indefinitely. The lowest nibble of the info byte displays the task number.

This error may arise if you relinquish more slots than where claimed. Locking and releasing must always be balanced. The lowest nibble of the info byte displays the task number, this highest the slot number.

On waits double slots are never allowed. The same applies for mutexes and queu's if cfgSyncDoubleBlock is not activated. This generates this error. The lowest nibble of the info byte displays the task number.

Adjust the slot use to include double slots, or change the logic or your code.

The slot stack, that is, the memory where the reserved slots are kept for each task is limited and has been exceeded. The lowest nibble of the info byte displays the task number, this highest the slot number.

The delay may not be any longer as 0xFEFF, directly or in internal calculation. Internally a to high delay time arose. The lowest nibble of the info byte displays the task number. This also might be the consequence of a faulty reconstruction of the tick counter after sleeping. The lowest nibble of the info byte displays the task number.

In a delayFromWake the task is not de-activated, because the wake time lies before the current time. This means this particular is running beyond the required reactivation moment. There was no time to put the task into a delay. Actually this is a dangerous situation, if it continues a little longer, the task may get into a very extensive delay. The lowest nibble of the info byte displays the task number.

Increase the delayFromWake time, or, reduce the execution time of the code.

Trying to call an synchronization primitive on a task that was not configured not to hold any slots (Slotsize == 0). This is an error. Define your task to with SlotSize_task to make use of one or more slots. The lowest nibble of the info byte displays the task number.

Registers that are not saved on the context have altered during execution of the task. This might be an incorrect error. Femto OS cannot determine with 100% certainty that a modified register is actually used, it assumes it is. If you are absolutely certain the register is not used, exclude it from the register check.

Overflow of the number of nesting levels of one of the critical sections. The number is a power of two minus one depending on the number of bits reserved for the counting. Counting is per type, being one of global, switch or tick. The lowest nibble of the info byte displays the task number.

Underflow of the number of nesting levels of one of the critical sections. You tried to exit a critical section while not inside one. Counting is per type, being one of global, switch or tick. The lowest nibble of the info byte displays the task number.

There are only eight priority levels in the Femto OS. You tried to use a higher priority (this also occurs at the use of a negative priority). The lowest nibble of the info byte displays the task number.

Femto OS calculated it will not be possible to save the context on the particular moment it tried to do so. That stack probably has not yet really overflowed, but the task cannot be restarted. Other tasks should be fine. The lowest nibble of the info byte displays the task number.

The tick counter is driven by a sub tick counter. The sub tick counter keeps running, even if no tick can be generated. However the sub tick counter itself may not overflow for that may lead to missed ticks. The lowest nibble of the info byte displays the task number.

Reduce the time slice for that particular task, or adjust the timing of the system to a lower tick frequency.

The OS takes more then 50% of the processor time regularly. In the equidistant timing model the system is at risk of immediate timer interrupts after context switch. Note that incidental high loads should not be a problem, for instance if a watchdog barks, or at heavy interrupt load. The information byte is unused.

You may only use valid task numbers. If you make use of task names only, there is no the risk of using undefined task numbers. The lowest nibble of the info byte displays the task number (of the running task, not of the call!)

The stack of the task was not large enough to accommodate the variables and/or the context. Since the task can not reliably be stopped, this error is fatal The lowest nibble of the info byte displays the task number.

A task is too long, or the OS took to long in the variable timing model, so that it may overflow the sub tick timer. This may lead to missed ticks. The lowest nibble of the info byte displays the task number.

Increase the time a sub tick takes, thereby lowering the tick frequency.