MOD54415 UDP issue

Discussion to talk about software related topics only.
jediengineer
Posts: 192
Joined: Mon Dec 17, 2012 6:24 am

MOD54415 UDP issue

Post by jediengineer »

Hey all, so I'm using a modified UDP SendRecieve demo program to send out a reading of J1[5] every second, and upon reading an incoming packet, send out the word "received". So far, it works perfectly... except.. when it receives the packet, it still sends out the reading on J1[5] before it sends out the word "received". How can I prevent this, and make the UDPReaderMain while(1) loop take priority until it returns its package?

Thanks!

Tony
barttech
Posts: 135
Joined: Fri Feb 20, 2009 12:59 pm

Re: MOD54415 UDP issue

Post by barttech »

Have you looked at OSLock(), or the semaphore or flag features?
I usually manage this sort of problem with a global bool Flag that I set, clear and check as needed.
Set Flag when you receive your packet, clear it after you send your message, and check it before you send out the J1[5] reading.
Sam
jediengineer
Posts: 192
Joined: Mon Dec 17, 2012 6:24 am

Re: MOD54415 UDP issue

Post by jediengineer »

Thanks Sam, I actually have not looked at those. You might have to be more specific... I'm still a little new to CPP and am learning my way around it as I go. I'll look those up, but if there's a way you could describe a little more, that would be great!!

Tony
jediengineer
Posts: 192
Joined: Mon Dec 17, 2012 6:24 am

Re: MOD54415 UDP issue

Post by jediengineer »

Ok, so I've looked up OSLock() and OSUnlock(), I understand how to use them (I'm pretty sure at least...) but now my question is this: I have a timer interrupting to run a subroutine 10x per second. It will be sending a packet on its own. Will OSLock prevent the interrupt from running the subroutine?

I can't post code here because at this point int he game, there's some company secrets that will be exposed, so I have to do my best to describe what I'm doing. Refer to the UDPSendRecieve.cpp file. I have made the while(1) loop in the UserMain() (Call it "loop 1") send a UDP packet out 1x every 5 seconds. And the UDPReaderMain() task created to receive the UDP incoming packet (Call it "loop 2") will take the packet, perform the instructions, and send a packet back out. I'm hoping that they don't conflict with eachother. Now nested in the incoming packet is a "run" command that enables a timer to interrupt 10x/sec that polls the GPIO, and creates and sends a packet of data.

So I guess what I need to know is this: Will the interrupt routine interfere with loop 2 if the OSLock is enabled until that lop finishes? Also, I'm assuming that the OSLock feature would work like this:

if (upkt.Validate())
{
OSLock();

// some code

OSUnlock();
}

IF I got that right, that should protect the code from being interrupted by the main while(1) loop in UserMain(), I'm just not sure about the timer interrupt. Thanks

Tony
Ridgeglider
Posts: 513
Joined: Sat Apr 26, 2008 7:14 am

Re: MOD54415 UDP issue

Post by Ridgeglider »

Take a look at the OSFlags documentation in C:\nburn\docs\NetworkProgrammersGuide\NNDKProgMan.pdf, section 15.1.6
and the OS Flags example at C:\nburn\examples\RTOS\OSFlags

Consider having the ISR the runs upon timer completion set an OS flag. Then have three tasks:
1st sends a packet every 5 secs
2nd does packet Rx and Parse
3rd pends for a flag set by the timer ISR. Upon receipt, does packet Tx and clears the flag.

Sounds like you could get a way w/ a semaphore here instead of a flag, but flags seem to allow lots more future flexibility w/o much overhead. Task switch time from ISR setting flag to task responding to the flag should be ~10usec.
jediengineer
Posts: 192
Joined: Mon Dec 17, 2012 6:24 am

Re: MOD54415 UDP issue

Post by jediengineer »

Thanks RidgeGlider! Sounds like a better idea than what I had. I'll see if I can figure the rest of that out. If anyone else has other suggestions, I welcome those as well.

Tony
jediengineer
Posts: 192
Joined: Mon Dec 17, 2012 6:24 am

Re: MOD54415 UDP issue

Post by jediengineer »

In searching through the suggested materials (thanks all!) I have found that OSLock() does not disable interrupts, for anyone that was looking for it... page 100 of the NNDKProgMan.pdf

If anyone knows where to look to find the timer interrupt flags, please let me know..

Thanks!! Virtual beers for everyone!!
rnixon
Posts: 833
Joined: Thu Apr 24, 2008 3:59 pm

Re: MOD54415 UDP issue

Post by rnixon »

I just took a quick read over this thread, so I may have missed something, but you want to be careful what you do in an interrupt routine. Should be very very fast. The alternative is to set a flag that wakes up a task. Not sure how much time it takes for you to send a packet along with whatever other processing you do, but you might want to check it by doing some thing like setting a gpio pin when you enter and clearing it when you leave.
Ridgeglider
Posts: 513
Joined: Sat Apr 26, 2008 7:14 am

Re: MOD54415 UDP issue

Post by Ridgeglider »

There may be some confusion here...

Rnixon is right: keep the code inside an ISR (in this case, presumably, servicing a timer IRQ) SHORT. So instead of sending the packet from the timer ISR, like both Rnixon and I said earlier, set an "OS Flag" in the ISR and exit the ISR. The OS Flag will in turn trigger a separate task that is pending for that flag. This is VERY different than clearing a timer interrupt flag which you also need to do during the ISR. I think you will see examples of how to clear the timer interrupt flags in any of the DMA or PIT timer examples for the various platforms. The examples describing OS Flags (or more simply, OS Semaphores) are described in the RTOS secton of the previously mentioned NNDK manual. The detailed descriptions of the OS calls (Including the OS Lock you mentioned are described in C:\nburn\docs\NetBurnerRuntimeLibrary\uCOSLibrary.pdf Please note that although OS Flags can be set (posted) from an ISR, they can also be (and are more typically) set (posted) from a task as a means to signal the occurance of an event by one task (or ISR) to another task.

Finally, Rnixon's suggestion to toggle an IO bit during an ISR (or during a task) is a really useful way (along with a scope or logic analyzer) to debug these processes.
seulater
Posts: 445
Joined: Fri Apr 25, 2008 5:26 am

Re: MOD54415 UDP issue

Post by seulater »

This may be of some help or not... I yanked this and snipped it from some of my older stuff. It uses the IRQ5, but it should give you an idea.
I have not tried using flags as Ridgeglider suggested, so i leave that up to you to determine what is best for you.

Code: Select all


// Semaphores
OS_SEM 	Task1Wait;

//********************************************
//*******************  IRQ 5  *******************
//********************************************
INTERRUPT(irq5_isr, 0x2500)			
{
	// Clear IRQ
	sim.eport.epfr |=0x20;

	//allow Task 1 to run
	OSSemPost(&Task1Wait);
}

//*****************************************************
//*********************  Task1  ***********************
//*****************************************************
void Task1( void *pd )
{

	while(1)
	{

		// Wait here until we are signaled to run
		OSSemPend(&Task1Wait,0);

		// Set i/O pin low here for scope timing
		// Can use J1[5].set(); & J1[5].clr(); but they are slower than direct access to pins
		// if using this method dont forget to make them a output pin first.
		sim.gpio.pclrr_feci2c = ~0x01

		// Do what you have to here 
		iprintf("Task 1 Has Just been Called\r\n");

		// Set i/O pin high here for scope timing
		// Can use J1[5].set(); & J1[5].clr(); but they are slower than direct access to pins
		// if using this method dont forget to make them a output pin first.
		sim.gpio.ppdsdr_feci2c = 0x01;

		// Now loop back and wait again for post signal. 

		// Just for habit use
		OSTimeDly( 2 );
	}
}

Post Reply