Archive

Archive for the ‘Programming’ Category

Graphics not working in L702X Dell XPS 17 while installing Linux Mint 12

January 30th, 2012 No comments

Looks like the faulty nouveau driver is creating the fault during boot up. Without nomodeset and/or acpi=off, booting leads to segmentation fault by the nouveau module. When I disable the nouveau module by blacklisting it under modprobe.d, I am able to boot up cleanly using the Intel Sandybridge Mobile graphics driver.  After updating the blacklist configuration, remember to run update-initramfs -u.

Code:
filename: /etc/modprobe.d/nvidia-nouveau

# disable nouveau driver
blacklist nouveau
options nouveau modeset=0
Tags:

Temperature Monitoring Device

January 1st, 2012 No comments

LM35 Temperature Sensor

The System.

The monitor.

The mixed water line:

The hot water line:

The cold water line:

monitor opened up:

the atmega8 microcontroller

the lcd unit:

theboard:

inside the monitor:

The AVR code.

const int COLD = 0, HOT = 1, MIXED = 2, CALIBRATE = 3;
const int PWMPORT = 5;

float SCALE = 5000.0/1024.0; // 10 bit resolution for ADC
const float LM35SCALE = 10; // 10mV per Centigrade

#include <LiquidCrystal.h>

LiquidCrystal lcd(13, 12, 11, 10, 9, 8 );

byte smiley[8] = {
  B00010,
  B00101,
  B00010,
  B00000,
  B00000,
  B00000,
  B00000,
};

float Calibrate( void )
{
  // write 5v to PWM port
  analogWrite(PWMPORT, 255);

  // read the 5v analog value in the calibrate port
  delay(500);
  int val = analogRead(CALIBRATE);

  // read again the 5v analog value in the calibrate port
  delay(100);
  val = analogRead(CALIBRATE);

  // whatever digital value we read is the range of output that we would get for 5v input.
  // so, set the scale appropriately.
  SCALE = 5000.0/(float)val;
  
  return SCALE;
}

void setup()
{
  pinMode(PWMPORT, OUTPUT);
  
  lcd.createChar(0, smiley);
  lcd.begin(16,2);
  
  lcd.setCursor(0,0);
  lcd.print(“Calibrating..”);
  float scale = Calibrate();
  lcd.setCursor(0,1);
  lcd.print(“Scale=”);
  lcd.print(scale);
  delay(1000);
}

int Temp( int inADC )
{
  float lm35volts = (float)inADC * SCALE;
  float temp = lm35volts/LM35SCALE;
  
  return (int)temp;
}

int ReadData( int port )
{
  int data = -1;
  for ( int i = 0; i < 3; ++i )
  {
    data = analogRead( port );
    delay(100);
  }
  
  return data;
}

void loop()
{
  int cold = ReadData( COLD );
  int hot = ReadData( HOT );
  int mixed= ReadData( MIXED );
  
  int cold_temp = Temp(cold);
  int hot_temp = Temp(hot);
  int mixed_temp = Temp(mixed);
  
  lcd.clear();

  lcd.print( “C=” );
  lcd.print( cold_temp );
  lcd.write(0);
  lcd.print(“C”);
  lcd.print( ” H=” );
  lcd.print( hot_temp );
  lcd.write(0);
  lcd.print(“C”);
  
  lcd.setCursor(0,1);
  lcd.print( “Mixed=” );
  lcd.print( mixed_temp );
  lcd.write(0);
  lcd.print(“C”);
  
  delay(1000);
}

kDevelop 4.2 Debugging

November 7th, 2011 No comments
    When I was using KDevelop 4.2 for debugging a process, I got perplexed having the inferior application closing down whenever I was setting a breakpoint on the fly.  On the contrary, the breakpoints there were setup before the start of the inferior application, things behave as expected.  With little bit of digging, it is found that whenever a new breakpoint is setup or removed (Toggle Breakpoint), kDevelop inherently issues a SIGINT to the inferior application, which in turn stops the application from debugging.  To handle this problem, setup a signal handler for SIGINT, to consume the Interrupt signal (Ctrl+C, Ctrl+Break).  But once the debugging is over, don’t forget to reset the SIGINT handler.

Hash Overflow due to 64 bit upcasting

October 28th, 2011 No comments
    Lately, I had to debug the following piece of code, where it caused overflow on the hash bucket design.  The code worked perfectly on a Windows machine while compiled for Win32, but failed to work on a Linux Mint x64 machine.  The code is listed below, which basically calculates hash value of an input 32 bit unsigned number, limiting the hash value to 2^10 (1Meg).

hash = ( fpArray*2654404609 )>>12; // Calculate the hash and limit the value to 2^20 (1 Meg)

   When the input value for fpArray was 1724463449 (0x66C93959), the hash value generated was 1779068547 (0x6A0A6E83), which is more than (0x000FFFFF) to cause the hash bucket overflow.

unsigned hash = fpArray * 2654404609;
hash = hash >> 12;

    When I rewrote the code like the above, the value of hash was 2800236889 (0xA6E83959).  Upon shifting right by 12 yields 638651 (0x0009BEBB), which is the correct and expected hash value.

    Overall, the first snippet of code appears to be correct.  Do you see a problem there?  I couldn’t find the issue, until I recalled the 32bit vs 64bit difference.  If you carefully look at the multiplier 2654404609 (0x9E370001), although appears to be a valid 32 bit number, what is the default assignment of type to this number by the compiler?  If it was assigned 64bits, what would happen to the results?  To validate this, I changed the 2nd snippet as the following.

unsigned long hash = (unsigned long)fpArray * 2654404609;
hash = hash >> 12;
unsigned h2 = (unsigned)hash;

    Now, when the input is the same 1724463449 (0x66C93959), the value of hash becomes 4577423727077636441 (0x3F8646A0A6E83959) and upon right shifting by 12 bits yields 1117535089618563 (0x0003F8646A0A6E83). Followed by downcasting to unsigned yield 1779068547 (0x6A0A6E83). Bingo!

    So, what is happening here? While performing (fpArray * 2654404609), the computation is upcasted to 64bit computation by the 64 bit compiler.  So, what is the solution? Just put a “U” at the end of the constant.

hash = ( fpArray*2654404609U )>>12; // Calculate the hash and limit the value to 2^20 (1 Meg)
(or)
const unsigned multipler = 2654404609; // here U suffix is not needed as the constant is explicitly made unsigned
hash = ( fpArray * multiplier ) >> 12;

    Now, the computation will happen with 32 bit numbers to get the expected outputs.

Lessons Learned here:

  1. While using constants, beware of the upcasting and downcasting. So use proper suffixes like U, L, F etc.
  2. Instead of using constants directly in expressions, use them as constant variables.
  3. Be conscious about the compiler type and the assumptions made by the compiler in different build modes.

kDevelop Editing Freezes Problem

August 20th, 2011 No comments
While working with KDevelop 4.2, I was quite disturbed by suddenly freezing of editing window. In the sense, the opening file is uneditable, “find” strings does not work and literally kDevelop becomes unusable. I had to restart kDevelop 4.2 to resume editing the code. I believed that kDevelop is going into Vi mode and was trying to undo that. But that’s not the problem.

When kDevelop loses focus, somehow the editing capability is disabled temporarily. When you switch context a couple of time by Alt-Tab and land is kDevelop again, the editing capability is resumed. I don’t know whether this is a bug, but context-switching has been my breather for now.

PROXIM ORINOCO 802.11 a/b/g/n

June 30th, 2011 No comments

Did you try this page for the driver?
http://list.driverguide.com/list/company861/LINUX/

Procedure for setting up proxim driver is given here:-
http://questier.com/howto.html#Proxim

If you want to try an alternate device, use this list linux compatible devices:-
http://www.cyberciti.biz/tips/linux-usb-wireless-compatibility-adapter-list.html

How to on Wireless networking:-
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch13_:_Linux_Wireless_Networking

If there is a windows driver, you can use “ndiswrapper” to setup a Linux module atop the windows driver sys and inf files. Try this as well.

no include path in which to search for limits.h

June 16th, 2011 No comments

Why compiling STLport 5.1.5 using g++-4.4, one might get an error like the following:-

Building CXX object libs/bgt/CMakeFiles/bgt.dir/error.o
In file included from /opt/projects/stl/stlport/limits.h:27,
            from /usr/include/c++/4.4/../4.4.5/climits:43,
            from /opt/projects/stl/stlport/climits:27,
            from /opt/projects/stl/stlport/stl/_algobase.h:42,
            from /opt/projects/stl/stlport/stl/_alloc.h:47,
            from /opt/projects/stl/stlport/stl/_string.h:23,
            from /opt/projects/stl/stlport/stl/_ios_base.h:34,
            from /opt/projects/stl/stlport/stl/_ios.h:23,
            from /opt/projects/stl/stlport/stl/_ostream.h:24,
            from /opt/projects/stl/stlport/ostream:31,
            from /opt/projects/dev/libs/bgt/error.cpp:18:
/usr/include/../include/limits.h:125: error: no include path in which to search for limits.h
In file included from /opt/projects/stl/stlport/stl/_num_put.c:26,
            from /opt/projects/stl/stlport/stl/_num_put.h:183,
            from /opt/projects/stl/stlport/stl/_ostream.c:26,
            from /opt/projects/stl/stlport/stl/_ostream.h:380,
            from /opt/projects/stl/stlport/ostream:31,
            from /opt/projects/dev/libs/bgt/error.cpp:18:
/opt/projects/stl/stlport/stl/_limits.h:148: error: ‘CHAR_BIT’ was not declared in this scope
/opt/projects/stl/stlport/stl/_limits.h:253: error: ‘CHAR_MIN’ was not declared in this scope
..

Looks like it is a bug in the STLport package itself as per the Release notes of STLport.  After updating to STLport-5.2.1, the issue got fixed automatically.

Symmetric Sigmoid

May 14th, 2011 No comments
When unknown signed intervals are expected to be normalized to -1 to +1, a symmetric sigmoid function could prove very useful.  A Symmetric Sigmoid function is a modified version of the Sigmoid function by stretching it across the Y axis.  As per wikipedia, it is defined as a symmetric function is a special case of logistic function whose plot appears like a ‘S’ with the Y-axis intercept as 0.5 and min/max as 0/1 respectively.

The function definition for a sigmoid is:

In programming languages the implementation should be in order to overcome the numerical overflow and underflow issues:

if ( t < 0 )
    exp( t ) / ( 1.0 + ::exp( t ) )
else
    1.0 / ( 1.0 + ::exp( -t ) )

 

 

 

 

 

 

 

 

 

 

 

 

In the plot, if the curve is stretched in Y-axis to make the Y-intercept at 0.0, the lower bound would get stretched to -1.0.
The function definition for a symmetric sigmoid is:
P symmetric (t) = 2.0 * P(t) – 1.0

The function can also be defined in terms of hyperbolic tangent as:
P symmetric (t) = tanh(t)

With sigmoid functions, it becomes possible to normalize any range in [-∞, +∞] onto [-1.0, +1.0].

Windows Server 2008 R2 Itatic font problem

May 5th, 2011 1 comment
    While doing some automatic windows updates, the default font for Windows 2008 R2 Server changed to Italics.  After getting perplexed about this problem and few hours of Internet searching, the solution was found at http://www.techsupportforum.com/forums/f217/problem-with-italic-fonts-everywhere-arial-233328.html.  Basically, it recommended a registry fix (see below), which seemed working perfectly. The replacement font prescribed in the registry fix sounded weird to me, so checked the name in http://en.wikipedia.org/wiki/Segoe and found that it belongs to the Sans-serif font category.
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
"MS Shell Dlg 2"="Segoe UI"
"MS Shell Dlg"="Segoe UI"
"Helv"="Segoe UI"
"MS Sans Serif 8,10,12,14,18,24"="Segoe UI"
"MS Serif 8,10,12,14,18,24"="Segoe UI"
"MS Sans Serif"="Segoe UI"
"System"="Segoe UI"
"Microsoft Sans Serif"="Segoe UI"
"Tahoma"="Segoe UI"
"MS Serif"="Segoe UI"
"Times New Roman"="Segoe UI"
"Times"="Segoe UI"
"Small Fonts"="Segoe UI"
"Tms Rmn"="Segoe UI"
"Arial"="Segoe UI"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts]
"Arial (TrueType)"="segoeui.ttf"
"Arial Italic (TrueType)"="segoeuii.ttf"
"Arial Bold (TrueType)"="segoeuib.ttf"
"Arial Bold Italic (TrueType)"="segoeuiz.ttf"
"Times New Roman (TrueType)"="segoeui.ttf"
"Times New Roman Italic (TrueType)"="segoeuii.ttf"
"Times New Roman Bold (TrueType)"="segoeuib.ttf"
"Times New Roman Bold Italic (TrueType)"="segoeuiz.ttf"
"Tahoma (TrueType)"="segoeui.ttf"
"Tahoma Bold (TrueType)"="segoeuib.ttf"
"Microsoft Sans Serif (TrueType)"="segoeui.ttf"
"MS Sans Serif 8,10,12,14,18,24 (VGA res)"="segoeui.ttf"
"MS Serif 8,10,12,14,18,24 (VGA res)"="segoeui.ttf"

[HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\Shell\MuiCache]
"@themeui.dll,-2037"="{Segoe UI, 8 pt}"
"@themeui.dll,-2038"="{Segoe UI, 8 pt}"
"@themeui.dll,-2039"="{Segoe UI, 8 pt}"
"@themeui.dll,-2040"="{Segoe UI, 8 pt}"
"@themeui.dll,-2041"="{Segoe UI, 8 pt}"
"@themeui.dll,-2042"="{Segoe UI, 8 pt}"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontMapper\FamilyDefaults]
"Swiss"="Segoe UI"
"Roman"="Segoe UI"

MongoDB C++ Wrapper

April 3rd, 2011 No comments

MongoDB has drivers in almost all language.  Being a C++ programmer,  although there is a C++ driver, I am stinged to see that the driver cannot be used with STLport.  The reason being, C++ MongoDB driver is compiled with Boost, which does not go well with STLport.  I could link my application in Release mode, but debug mode would not work.  Also, Boost says that STLport is not uniform across platforms, they don’t support STLport for linux platforms.

So, I am left out with only one option; that is to create a C++ driver myself.  I found the C driver working excellently (although there are design glitches!).  I am currently developing a C++ wrapper around the C driver to support fundamental operations on Mongo from an application compiled with STLport in C++ and cross platform.