MOD54415 UDP function ResetData()

[jediengineer]

I have a question about the function "ResetData()"

The Runtime Library pdf file only describes its function as "this function zero's the data buffer length"

My software utilizes IRQ ports and an ISR for each - When the ISR is employed, if there is pending data to be sent, I don't want the system to send it. I want to kill the packet. Is this function sufficient if I call it conditionally if the ISR is invoked? In other words, I'd set a flag if the ISR is called which would lead to some code like this:

If (ISR_FLAG)
{
// stuff
pkt.ResetData();
}

[pbreed]

If you have not yet sent the data you can reset....

If you have already called send don't touch the packet...

Paul

[jediengineer]

Thanks Paul, now that begs another question - if the ISR is run whenever the IRQ is tripped, I have no control over when the packet is being sent. Is there a way to verify? Sorry, a little new to this...

[jediengineer]

Actually, let me ask my question a little differently:


Take a look at the UDPReaderMain(void* pd) function (I'm looking at the UDPSendReceive example). In the while(1) loop, It creates a new packet every time the loop returns to the beginning. If I use pkt.ResetData(); to zero my data buffer, and never send the created packet, what happens when the loop returns and tries to create a new packet? Will it just eat up memory by creating new packets? If so, how can I cancel the packet all together? I understand that I cannot stop a packet during transmission, and if it transmits one packet before I can zero the buffer, that's fine with me.

[dciliske]

So, the thing you mention about UDPReaderMain uses/abuse a C++ scoping technique. So, when a UDPPacket is created (read, constructed) it obtains a PoolPtr (aka pointer to a PoolBuffer, aka a buffer). When it leaves scope/has its destructor called, if the UDPPacket has a PoolPtr it frees the buffer. Now, back to the loop: when you hit the end of the loop and then jump back to the beginning, you are actually leaving the scope of the loop, while the control logic is evaluated. This in turn causes the destructor for the UDPPacket to run, which will free the buffer.

Now, back to what you're really trying to do. It sounds like you're attempting to kill a report message because its invalid or you have other things that need to be happening or whatever. If you bookend the UDPPacket Send with a flag (volatile boolean), where it is true while running Send, then you can call the method 'ReleaseMethod' to free the UDPPacket's buffer before calling send. This will prevent send from doing anything, as it checks that there is actually a buffer there; 'ResetData' simply sets the data length of the udp payload to 0, which would have you transmit an empty udp message.

Your normal execution code would end up looking like

Code: Select all

SendGuard=true;
udpPkt.Send();
SendGuard=false;

and your ISR would have

Code: Select all

if (!SendGaurd) {
udpPkt.ReleaseBuffer();
}

Hope that helps.

-Dan

[jediengineer]

Thanks Dan,

After that explanation, I think my method was way off... I had a flag set by the ISR and at the end of the UDPReaderMain(), the pkt.Send(ipaddr) was conditionally run if the ISR flag was not set. Understanding what you just explained tells me just how much trouble I would have gotten into!! But this has actually answered a few more questions that I had as well... thanks!!!

[djrizzz]

Now, back to what you're really trying to do. It sounds like you're attempting to kill a report message because its invalid or you have other things that need to be happening or whatever. If you bookend the UDPPacket Send with a flag (volatile boolean), where it is true while running Send, then you can call the method 'ReleaseMethod' to free the UDPPacket's buffer before calling send. This will prevent send from doing anything, as it checks that there is actually a buffer there; 'ResetData' simply sets the data length of the udp payload to 0, which would have you transmit an empty udp message.

[jediengineer]

Oooh, interesting. Good to know, Thanks!