Hi Hervé
This is something that can't be done at the moment but it is quite easy to add:
In the driver function static QUEUE_TRANSFER fnWriteInternal(unsigned char *output_buffer, QUEUE_TRANSFER nr_of_bytes) locate the following code (it is at the end of the subroutine).
ptQUEQue = (struct stQUEQue *)(que_ids[newDestID - 1].input_buffer_control); // set to input control block - write directly to input
nr_of_bytes = fnFillBuf(ptQUEQue, output_buffer, nr_of_bytes);
uTaskerStateChange(NewWakeTask, UTASKER_ACTIVATE);
return (nr_of_bytes);
Now make the following change:
ptQUEQue = (struct stQUEQue *)(que_ids[newDestID - 1].input_buffer_control); // set to input control block - write directly to input
if (output_buffer[MSG_SOURCE_TASK] == 0) { // check on destination's queue
return (ptQUEQue->buf_length - ptQUEQue->chars); // remaining space in queue (before adding new message)
}
nr_of_bytes = fnFillBuf(ptQUEQue, output_buffer, nr_of_bytes);
uTaskerStateChange(NewWakeTask, UTASKER_ACTIVATE);
return (nr_of_bytes);
This will allow you to call using something like:
unsigned char int_message[HEADER_LENGTH];
int_message[MSG_DESTINATION_NODE] = INTERNAL_ROUTE;
int_message[MSG_SOURCE_NODE] = INTERNAL_ROUTE;
int_message[MSG_DESTINATION_TASK] = TASK_DEBUG;
int_message[MSG_SOURCE_TASK] = 0; // setting the source task to zero causes the write to return the available queue size (before any extra data is entered)
return (fnWrite(INTERNAL_ROUTE, int_message, HEADER_LENGTH));
Also the following can be generally used to cause the same return value:
fnEventMessage(TASK_DEBUG, 0, 0);
The only thing to bear in mind is the fact that the value returned may not always be correct if an interrupt were to post a message to the same task just after (or during) the call. This is because the interrupt's message would reduce the available space. Either calls can be protected by disabling interrupts (if it is known that interrupts may also be posting messages to the same task) or else the queue can be increased a little in size and the check be made for larger message size to take in account such a possible occurrance.
Regards
Mark