Hi Aaron
Is this for a physical FIFO device of for an internal FIFO queue (for example a task to temporarily write data to and then retrieve it in the same order later)?
If it is for the second case there is a define called SUPPORT_INPUT_QUEUE_WRITE. This allows an internal queue to be written to - normally the queues are only used for reading from (eg. input queue of a task which is only read from by the application).
It is used as follows:
static QUEUE_HANDLE FIFOQueue = 0;
CHAR queue_name = 0xff;
TTASKTABLE table;
table.pcTaskName = &queue_name;
table.QueLength = 1024;
FIFOQueue= fnOpen(TYPE_QUEUE, FOR_READ, &table);
Note that the queue needs a name (the queue driver needs a task name and actually passes a pointer to it). Here 0xff is being used since it will tend not to collide with any tasks, which use normal strings. The next FIFOs could be 0xff - 1, then 0xff -2 etc. If using the MODBUS module, which also uses local FIFOs, it uses (0xff - ucMODBUSport) and so occupies the highest values - this may need to be considered to avoid conflict.
The open is for READ since the queue doesn't have separate buffers for writing into and reading out of - it is the same one.
Once the queue handle has been obtained, writes to the queue use the standard fnWrite() and reads back from it the standard fnRead() - in each case referencing the FIFO by its queue handle.
For each FIFO queue required, the value of PHYSICAL_QUEUES should be incremented so that they are available in the queue pool.
Regards
Mark