Author Topic: Using the queue system that's already in place  (Read 9129 times)

Offline alager

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Using the queue system that's already in place
« on: April 08, 2010, 07:45:56 PM »
Rather than make my own fifo system for some data, I'd like to leverage the queue system that is already in place.
Has anyone done this?  If so can you provide some guidance?
I know I need to add 1 to PHYSICAL_QUEUES, but after that I get lost.

Thanks,
Aaron

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Using the queue system that's already in place
« Reply #1 on: April 08, 2010, 08:06:33 PM »
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


Offline oneFranck

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Using the queue system that's already in place
« Reply #2 on: July 14, 2010, 08:20:57 PM »
Hi,

Is there a way to obtain the actual number of item in queue at any moments?

Thnx

Francois

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Using the queue system that's already in place
« Reply #3 on: July 14, 2010, 09:42:11 PM »
Hi Francois

You can request the number of bytes in the queue but this doesn't indicate the number of items. How many items this represents depends on the format of each item.

Internal messages between tasks are made up of a header plus optional data and so need to be read as header first to find out the length of the item and then the data content is read. The queue can however be used differently, where the situation could also be different; if each item has a fixed length the the number of items is also known but otherwise not.

Regards

Mark

Offline oneFranck

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Using the queue system that's already in place
« Reply #4 on: July 14, 2010, 10:52:38 PM »
Hi Mark,

Ok thanks

I'm not shure if I understand the queue system correctly.

1) is table.QueLength the max size in bytes of all data in the queue?

2) does the FIFO data can be accessed via indexes, or a read will return the full contents of the FIFO?

regards,

Francois

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Using the queue system that's already in place
« Reply #5 on: July 14, 2010, 11:16:40 PM »
Hi Francois

The QueLength is the size of the queue that is created on heap and so the queue can hold this many bytes of data (total, including any headers).

A read of the queue will always return content in the same order as it was written to the queue (FIFO). A read will return as many bytes as requested, as long as there are so many valid bytes fo content. The amount actually read (when less in teh queue as requested) is returned by the read function (fnread()).

Regards

Mark