MOD54415 HiResTimer

[rnixon]

Hi Mark,

I may be missing something here, but if you can't accomplish everything you need to before the next interrupt occurs, it would not matter if an interrupt was re-entrant or not. You would keep falling behind. Isn't the purpose of the 4ms interrupt to schedule the next activity? If you can't do the activity in 4ms then the time needs to be longer, or you need to modify what occurs to keep it under 4ms.

[dciliske]

Here's you're problem:

I use setInterruptFunction(SendToUart) to configure the interrupt function. Within SendToUart() there are calls to OSSemPend()

I may have been overly broad with my followup post, but I'll clarify here. You cannot call any system function that a) waits (such as OSSemPend) or b) does I/O inside an interrupt. If you look at the internals of HiResTimer, you will see that the setInterruptFunction sets the function to call when an interrupt occurs; this function is called within the processor interrupt. Based on what you are trying to do, you MUST have a secondary task that waits on a semaphore to wake it up. This is NONOPTIONAL.

-Dan

[mbaybutt]

Hi all,

I solved this issue a while back and realized I never followed up on the forum in case others are running into similar issues... here we go. The points that Dan and Tod brought up were certainly true. I was getting lucky in some threads that I could get in and out of the ISR before meltdown, but other tasks (specifically CAN) caused issue.

The solution I implemented sets the timer interrupt function to one that just performs a OSFlagSet() call. As I setup the timer(s), I create a separate task for each bus (CAN, UART, I2C in my case) which simply pends on their respective flag to be set ( OSFlagPendAny() ). Once the flag is set, the separate tasks then call the appropriate function to push data out the comm ports. This way the timer ISR function is in and out quickly making one call to OSFlagSet and then bulk of the heavy lifting is isolated in their own tasks.

I was looking for 4ms timer rates and I have observed this on CAN and I2C buses (the functional nature of the UART is more of a one shot functionality).

Hope this helps anyone who is trying to track down a similar problem...

Best,

- Mark

[nicobari]

Since everyone here is talking about competing task taking up the same resources, I thought I might also throw in what I learned to date while working on my MOD54415. My goal is to read data from IMU, read PWM signal, save data to the on board sd card and run control algorithm which changes my PWM values. My first version of code used interrupts to read IMU data and PWM data and it worked but the only problem was it was too noisy for any practical application. I figured I would face these problem due to competing interrupts (both were 50 Hz period signal) but it was way way bad. The first place to look for the solution to these kind of problem is to always look at how efficient your code is, for me I don't have anything concrete to decided what is efficient and what is not so I just tried to remove unnecessary part from my code and also reduce the amount of tasks in interrupts, I played with changing the priorities of the interrupts. Results was slightly less noisy data but I had gaps in my crucial data. Then I decided to give Ostaskcreate() a try, I knew about it before but I didn't completely understood how it works,but didn't want to use it to avoid getting unknown errors. I tried it I was running my read IMU and control algorithm task inside new task polled at 50 Hz using PIT1 configured as free running and I was still reading PWM on interrupt. The result was near perfection, except for few IMU data losses here and there everything else in my data looked satisfactorily clean. Although I am happy with the result but I would still appreciate if someone can give me a description of how OStaskcreate() works.

Thanks,
TM

[dciliske]

Right, so to explain how OSTaskCreate works, let's back up a level and talk about OSes, Schedulers, and Tasks in general. At a fundamental level, an OS is simply a control system that controls access to limited processor resources and saves the state of actions when people get swapped in and out. The Scheduler is the portion of the OS that decides who gets to run and when. The Tasks are the things vying for a spot in the processor to actually run.

In the Netburner environment, the OS uses what's known as a "Preemptive Scheduler", meaning that which task gets to run is based on a strict priority; the task with the lowest priority that wants to run wins. The normal list of tasks in the world goes something like this: Ethernet, IP, TCP, HTTP, UserMain. When the scheduler runs and the active task changes, the OS saves the state of the processor registers onto the previous task's stack and loads the state of the registers from the new tasks's stack. This way, no state is ever lost.

Now, when you make a call to OSTaskCreate(), you are telling the OS to add a task to its list and give it the priority you passed. Without knowing what priority you passed, I can't know what effect is causing your improvements.

Did this answer your question?

-Dan

[nicobari]

Yeah that was helpful, when you say the task with the lowest priority gets to run first shouldn't it be the task with higher priority? also the priority of my new task is MAIN_PRIO+1. Also I just have a while loop and PWM reading interrupts setup in main task and I noticed that if I don't print anything in my main task while loop my new task also doesn't work. Also when I set my new task to run at 400 Hz it actually runs at 100 Hz.

[mx270a]

The lower the number, the higher the priority.

[mbaybutt]

Debug printf statements really kill performance. I've found implementing debug statements to a telnet session isn't quite as bad of a hit of performance.

[roland.ames]

Debug printf statements really kill performance. I've found implementing debug statements to a telnet session isn't quite as bad of a hit of performance.

SysLog is worth checking out.

You can use this without having to reestablish the TCP session whenever the NetBurner module resets.

[nicobari]

It still doesn't explain why not printing in main task would make my new task not run!!!