Raspberry Pi

I've been playing with Raspberry Pi for a while, it's quite fun. Once we know how to program it well, then things are much more easier. For me, I use C as my language, it supports C++ but it needs c++ library to be installed, C is enough powerful for my application. So, here's what I have done so far:

1. I/O, I use BCM2835 library (http://www.airspayce.com/mikem/bcm2835/) for the GPIO and SPI. This library is quite straightforward, easy to use, and understand. About this library, only the pinout assignment a little bit tricky, it seems that the pinouts for Raspberry Pi v2 is not usable, I have to use RPI_BPLUS_GPIO_J8_XX for pins more than 26, when I tried to use RPI_V2_GPIO_P1_XX I got a compilation error showing that it is not defined. When using this library, make sure to add "-lbcm2835" for compiling your program.
2. Threads. In most of my program, I always use threads for doing the task because I don't want to have one task blocking the other tasks. If the tasks can be performed separately, then it must be run under threads. Critical sections must be used for making all the threads safe. For thread, I use pthread library. Make sure to add "-lpthread" for compiling your program.
3. Sockets. For socket, I use standard unix socket programming, socket transfer is run in a thread with a state machine for controlling the connection state. This is quite straightforward. 

Unfortunately, at the moment I don't have any simple application that I could share here. If you have any difficulties just feel free to ask, I might be able to give you a clue. 

Happy Coding!:)

Debugging Multi-Thread Application

Most of the application I develop are running more than one thread with different task for each thread. It might sound ok if the threads are running properly, all the critical sections are not dead locked, and memory are well controlled.

But, sometimes due to deadlines, we forget some parts of the codes and it leads to application crash, memory leak, and the most difficult part is data race problem. These are sorted based on difficulty in debugging.

These several months, I've been struggling hard to read others' code, interpret what they are trying to achieve with the code, how the threads work, how do they synchronize, and how to add another feature to the existing program. And here because it's almost the end of the year, I want to summarize what I learned so far this year.

1. Application crash is the easiest to debug among all of the three problems I mentioned above. This can be traced quite easily by setting debug points on object creations, every function calls, and object destructions. Usually the error messages gives a clue on what to debug, it takes experience to know what the problem is from the error messages. The more mistakes you make, the more experience you have in interpreting error codes :), but this is not a justification for making mistakes.
2. Memory leaks is more difficult when it comes to multi threaded applications because the problem might spread with the thread instantiation. The only way to debug this is by checking the source code line by line, making sure that there's always a delete or delete [] for every new or new[].
3. The data race can be traced by checking all the critical sections and writing a log file for every threads. This is difficult to check because the more threads in the software the more complicated the debugging process is. It become more complicated when the thread is dealing with arrays. Some compilers are not very good in debugging multi threaded application, because the application itself might crash. So, what I did is writing the algorithm into dll, then write some debugging string then use another software to catch the debug strings. In this way, the main threads are not interrupted during debugging and it's much easier to debug the software. The software I am using is called DebugView (https://technet.microsoft.com/en-us/sysinternals/debugview.aspx). It's very convenient to use in debugging algorithm, especially when it is run in thread.