fnRead with different message length

[fcereja]

Hi Mark,

I would like to monitor the ARP resolution for UDP sockets. So I've added a "case 'A':" in the task loop to gather the messages from the ARP task. These messages are 2 bytes longer than the timer and interrupts messages that are tested in the loop.
If I modify the length in the fnRead call from HEADER_LENGTH to HEADER_LENGTH+2, the application no longer works, the timer and interrupts events are not seen.
If I set the length to HEADER_LENGTH, the application works well but I can't access the ARP infos that are after the message header.

What happens in the fnRead function when the indicated length is greater than the message length? Howto write the program ith different length messages?

Thank you for your help.

Regards
Francis

Code sample :
-----------------
  unsigned char ucInputMessage[HEADER_LENGTH+2]; // +2 for ARP infos
 
  QUEUE_TRANSFER length;
  // loop
  while(fnRead(PortIdInternal, ucInputMessage, HEADER_LENGTH + 2))
  {
    switch(ucInputMessage[MSG_SOURCE_TASK])
    {
      case TIMER_EVENT: // timer event either periodic or command timer
        if(ucInputMessage[MSG_TIMER_EVENT] == E_TIMER_PERIODIC) // execute state machine
        {
....
     case 'A': // infos from ARP task
        length of ucInputMessage is HEADER_LENGTH + 2
...

[mark]

Hi Francis

You must always HEADER_LENGTH in the while (fnRead()). The reason is that it can otherwise cause corruption when there are two messages in the queue because the second message gets partly read when the first is read.

When you send messages with additional data you can send them with the last byte in the header indicating the number of additional bytes following the header, and follow the header with the data.

At the reception you read the HEADER_LENGTH and recognise that it is from your other task rather than an event message. In this case you also have the length of the additional data and so can perfom a second read from the queue with the exact data length.
 Like this no corruption can occur.

This is also explained on page 12 of http://www.utasker.com/docs/uTasker/uTaskerV1.3.PDF

Regards

Mark

Regards

Mark

[fcereja]

Hi Mark,
thank you for your explanation. After reading again the documentation, my mistake is evident. I had consisered that the fnRead was based on a complete message transfer and not on a per byte basis.
Now it works fine.

Regards
Francis