Redirect printf

Following link discusses how we can opt for a standard printf function for Explorer16 board from Microchip. Similar steps can be used for other Microchip controllers
http://www.microchip.com/forums/m289179-print.aspx

Select in linux/termios in lnux

While searching for information on termios , I came across following link. This link contains info and examples on
1) Canonical and non-canonical mode of termios
2) select call with simple two file descripters
3) By setting attributes of termios we can have read to be completed either on specified no of characters or if specified inter-character timeout occures. 

http://tldp.org/HOWTO/Serial-Programming-HOWTO/x115.html

Manage an application’s priority in Linux

Recently I came across a nice article on how to mangae(get/set) linux application priorities using command line and also throuh GUI. Thanks to Ghacks.net 

http://www.ghacks.net/2011/01/11/manage-an-applications-priority-in-linux/



In the land of Linux applications have what is called their “nice” value. This value sets the priority that any given application receives. The nice value ranges from -20 to 19. The lower the number the higher the priority. The higher the priority the the more CPU time a program will get. This comes in handy, say if you are rendering a video that is going to take a long time and can consume a good amount of your CPU cycles. You can set the nice value to give that process a lower priority so it won’t consume that much of your CPU. The job will take longer, but you won’t notice the huge hit on your processor. But how is this done? Let’s take a look at how you can manage the priority of an application.
“nice” and “renice”
We’ll start this with the command line method of changing these values (I’ll demonstrate the GUI method in a moment). There are two commands you need to know: nice and renice. You use nice to launch a command with a specific nice value. You use renice when you want to change the priority of a program that is already running. Let’s see how those commands are used.
In order to launch an application with a specific nice value you would issue the command:
nice APPLICATION NICE_VALUE
Where APPLICATION is the command used to launch the application and NICE_VALUE is the priority (from -20 to 20) that you want to launch the application with.
Now, to change the nice value of an application already running you would use the renice command like so (NOTE: If you are wanting to renice a service or an application that was started with administrative privileges you must have administrative privileges to run renice, so you’ll need to either su to root or use sudo):
renice NICE_VALUE APPLICATION_PID
Where NICE_VALUE is the new nice value you want to assign to a process and APPLICATION_PID is the process ID of the application. NOTE: You can’t renice with an application name like you can with nice.
Using a GUI

Figure 1

There is, of course, a much easier way of handling this task. If you open up the System Monitor you will notice a Nice column (see Figure 1). If you select an application and right-click it you will notice the Change Priority entry in the menu. Select that and a new window will appear with a slider allowing you to change the nice value from -20 to 20. Once you have changed that value click the Change Priority button and the new nice value is set.
You will probably notice that the majority of applications nice value is set to 0. That is normal priority. You will only want to change this value for certain circumstances – such as a run-away application or when an application will consume a good amount of CPU cycles. Other than that, Linux does a fairly good job managing the priority of the applications both the system and the users run. But it’s always nice to know you can step in when necessary.
Enjoyed the article?: Then sign-up for our free newsletter or RSS feed to kick off your day with the latest technology news and tips, or share the article with your friends and contacts on Facebook or Twitter.

How to implement realtime periodic tasks in Linux applications

Nice article on how to use high resolution timers in linux app scheduling. Please have a look at it. 

http://bec-systems.com/site/175/how-to-implement-realtime-periodic-tasks-in-linux-applications


Have you ever wondered what is the best way to implement periodic tasks in Linux applications — something better than usleep()? This article covers a number of issues related to this subject including real-time tasks, the different timers available, timer resolution, and how to implement periodic tasks accurately so that error is not accumulated. The recent inclusion of the high-resolution timers in the mainstream kernel makes this a very interesting subject.

High Resolution Timers

Historically Linux has done all timing off the OS timer tick which is usually between 1ms and 10ms. While this is adequate for many tasks, it is really nice to have a high resolution timer for timing tasks. With the integration of the high resolution timers into the mainstream Linux source tree, this is now possible. From a user space perspective, there are no API changes. The only difference you will notice is that now you can sleep for less than OS timer tick period. clock_getres() can be used to check the timer resolution and will tell you instantly if you have high resolution timer support. If the clock resolution is 1ns, you have high res timer support. Realistically, you can’t delay for 1ns in a Linux application, but delays in the range of 100us should be possible, and depending on the configuration, much better performance is possible. The kernel config entry for high resolution timers is CONFIG_HIGH_RES_TIMERS.

The difference between CLOCK_REALTIME and CLOCK_MONOTONIC

Some of the Linux timer functions take a clockid_t argument that can be specified as CLOCK_REALTIME, or CLOCK_MONOTONIC. The big difference between these two is that changing the system time will have an affect on CLOCK_REALTIME, thus affecting your timers. Changing the system time will have no affect on CLOCK_MONOTONIC — it will always count upward. For periodic tasks, CLOCK_MONOTONIC may be more applicable. The best way to get burned using CLOCK_REALTIME is when your application takes a timestamp, does something, takes another time stamp and then compares them. If you are using CLOCK_REALTIME, and the system time gets changed between the two timestamps, your comparison will not be valid. For most timeouts and relative timekeeping in Linux, use CLOCK_MONOTONIC. This issue becomes more important as many systems now have a process that periodically sets the time automatically from network time servers, and you have no idea when this might happen.

Preemption

Kernel preemption (http://bec-systems.com/web/content/view/69/9/ ) makes a huge difference in the performance of real time applications by allowing the kernel to be preempted by higher priority application processes. Historically, any kernel code that was runnable ran before the kernel returned control to applications. This all changes with kernel preemption. Kernel preemption has been available in mainline kernels for some time now (I think since 2.6.16). The worst offender I’ve found for locking the kernel for long periods of time have been flash drivers — especially proprietary ones. But, even jffs2 can cause problems in realtime applications without kernel preemption.

The PREEMPT_RT patch

Much of the realtime work being done for Linux is maintained in the PREEMPT_RT patch. Bits of this patch have already been merged into the mainline kernel, but there is still a lot of very useful functionality in the patch and it should be considered if you are doing any type of realtime work. More details will be presented in a future article.

Absolute vs Relative timekeeping

When implementing a periodic task, you really want to base your timekeeping off an absolute time, versus relative delays such as usleep(). It is not possible to achieve precise periodic activation with a relative sleep such as usleep(). The reason for this is you must first get the current time, make a calculation to determine how long to sleep, and then call the relative sleep function. If your process gets preempted between the time you acquire the timestamp, and the sleep, your relative sleep time will probably be wrong. This problem is solved by using the clock_nanosleep() function. clock_nanosleep() can be called with the TIMER_ABSTIME value in the flags argument. If the TIMER_ABSTIME flag is set, then clock_nanosleep() will sleep until the absolute timer value is reached. It does not matter if you get preempted between the time you take a timestamp, and the sleep function.

Summary

In summary, if you want to implement accurate, realtime, periodic tasks in a Linux application, consider the following:

• Use high resolution timers. Although Linux is still limited in its response time, at least the scheduling resolution is now quite high.
• Enable kernel preemption. This makes sure long kernel processes don’t get in the way of your real-time application process.
• Use the CLOCK_MONOTONIC for relative timekeeping. You don’t want your application to lock up due to the system time changing.
• use the clock_nanosleep() function instead of relative delays like usleep(). This is the only way to accurately schedule periodic tasks.
• if needed, apply the PREEMPT_RT patch.

The clock_nanosleep man page also includes a lot of useful information about timer functions.