• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 467 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1310: Using RFQueue in the rfPacketRX

abdullah cinar
Intellectual 540 points
Part Number: CC1310
Other Parts Discussed in Thread: WMBUS,

Hi,

We are trying to implement a wmbus project at the top of the rfPacketRX example. Right now it is working well but I have some consideration about the processing speed of the packets to prevent packet miss.

I have added a second task to this project to parse the received RF packets. So I have 2 running threads now, first one is the original thread in the rfPacketRX example. When I receive a new packet, I'm copying it to a new buffer and raising a flag. The second thread polls for this flag and parses the received packet.

But when there are lots of wmbus devices around, sometimes I get a new packet before I process the old one. So I was thinking of adding a FIFO structure. I need to add received packets to the FIFO and pull them and parse in the second thread. There is already a dataQueue_t variable in the code "rfPacketRx.c" file and "RFQueue_getDataEntry" and "RFQueue_nextEntry" functions are called inside the callback. I'm trying to understand how these work. Are there any useful documents explaining these? Can I poll this queue in another thread?

Thanks.

  • 0
    TI__Guru 56590 points

    Hello User,

    I have assigned an expert to comment.

  • 0 in reply to Eirik V
    Intellectual 540 points

    Hi Eirik,

    Thank you, I will be waiting.

    Best Regards,

    Abdullah.

  • 0
    TI__Mastermind 23730 points

    Abdullah,

    Are you implementing your own WMBUS stack on top of the rfPacketRx example? Or, are you porting the WMBUS stack provided by TI on-top of the rfPacketRx example? Or, are you having both the WMBUS stack and the rfPacketRx example side-by-side in a mulitprotocol application?

  • 0 in reply to Severin Suveren
    Intellectual 540 points

    Hello Severin,

    We are implementing our own wmbus stack. We are getting benefit of the the TI's rfPacketRX examples.

    Thanks.

  • 0 in reply to abdullah cinar
    TI__Mastermind 23730 points

    Why do you not want to use the WMBUS stack provided by TI? It supports CC1310.

  • 0 in reply to Severin Suveren
    Intellectual 540 points

    Because there is a 16 device limitation on StackForce stack and we can not get any help regarding the StackForce stack. We need to listen to hundreds of devices and add device filters if needed. The upper layer is almost completed, we just want to improve performance by using queue or fifo implementation. I can write one but I just wanted to learn more about TI's implementations. If there is already a queue we can use, I don't want to add another one to the top of it and make another memory copy from RF fifo to my fifo.

  • 0 in reply to abdullah cinar
    TI__Mastermind 23730 points

    abullah,

    There doesn't exist an RX FIFO in the radio; it all relies on data queues stored in RAM. There exists several data queue types, all of which are detailed in the TRM, but the one used by the RFQueue implementation is the dataQueue_t type. If my memory serves me correctly, the RFQueue configured the dataQueue_t to be a circular queue with N number of entries. When an entry is ready, an RF callback is called with the RF_EventEntryDone event, which indicates the driver to search the dataQueue_t instance for the entry.

    What RFQueue does is simply abstract the allocation of dataQueue_t entries, configuration and initializion of the queue, as well as maintaining the current entry and searching for the next ready entry. That's it.

    If you need to increase the number of entries in the dataQueue_t, then there should be somewhere in the RFQueue.c that specifies how many entries to be allocated. Usually this is 4.

    In my experience, 4 dataQueue_t entries are usually sufficient for any stack. At this point the bottleneck is usually how long time it takes for the stack to process the entries at this point, and it could be the stack implementer has done some poor implementation design or have written poor performing code.

    I hope this clear things up.

  • 0 in reply to Severin Suveren
    Intellectual 540 points

    Hello Severin,

    Thanks for the answer. I increased the entry number to 4 and the results look good. I'm using Smart RF Studio Packet TX to act like a real wmbus meter. I'm sending 1000 packets at each 70ms to my CC1310 device and it can collect them and does the decode/parse very well. Sometimes 2 or 3 packets are missed in 1000.

    Since I'm new to the RTOS, I've just used the rfPacketRX and uartEcho example projects used with TI-RTOS. In the RF pack received task, I'm just raising a flag and copying the received packet to another buffer. In the uart thread, I'm polling for this flag to parse the packet and print it to the terminal. I'm not sure this is a good implementation, I'm reading the SYS/BIOS kernel user guide to understand the threads and data sharings between threads using semaphore, mutex etc. I think it would be good if I can use one of them. But I'm still trying to understand which one fits this application.

    As a next level, I want to have 3 threads. The RF RX thread will add the received packets to a Queue. The Parser thread will parse the packets in the queue and serialize them in another Queue. And the UART thread will print/push the parsed packets to UART from serialized Queue. I'm trying to understand some basic things reading the user guide of the kernel:

    - Which data sharing methods should I use? Semaphore, mutex or just global buffers/flags?

    - Which Queue or Fifo should I use?

    - How to decide how much stack should be used for these three threads? 

    Regards,

    Abdullah.

  • 0 in reply to abdullah cinar
    TI__Mastermind 23730 points

    If you are planning to share data between threads, then you should take a look at Mailboxes. This is essentially a FIFO queue of entries, which can be arbitrary data. Note that Mailboxes do not implicitly copy data between threads, so you should copy received data before sending them over Mailboxes.

    You can use the TI-RTOS ROV to inspect stack usage for all stacks, including detection of stack overflow. This should give you a rough estimate to how large of a stack is required for your tasks. See here on how to use ROV: https://processors.wiki.ti.com/index.php/Runtime_Object_View_(ROV)

  • 0 in reply to Severin Suveren
    Intellectual 540 points

    Hello Severin,

    Thank you for your answer. This information is enough for me!

    Regards.