So I have been using the loststone prototype for about a month, I have only been using my store bought mouse when I screw something up ūüôā

Aside from the occasional physical issue, mainly the buttons falling off, I have only been having one issue. Sensitivity. If I set the CPI high enough(ex 4500) for the courser to travel the full length of the monitor with a reasonable spin of the ball, It is next to impossible to move the courser over a specific character on the first try. Some times even the 4th or 5th try, VERY annoying. Setting the CPI low enough(ex 540) for really nice small movements and it takes multiple turns of the ball to move the full length of the screen.

I originally thought that some very complicated math would be required to solve this issue. So I figured I would start out small to get an idea of what I needed to do to accelerate the courser across the screen when moved fast enough and yet still allow small intricate movements. Much to my amazement the first equation I came up with did exactly what I needed it to do.

After some tweaking of the denominator and CPI values I came up with the CPI at 540 and the following equation.

f(x) = ( |x| / 40 + 1) * x

f(x) = x
f(x) = ( |x| / 60 + 1) * x
f(x) = ( |x| / 40 + 1) * x
f(x) = ( |x| / 20 + 1) * x

The red plot is the raw sensor input(both x and y coordinates). The rest are different values for the denominator, I am currently using the blue one.

One of the reasons this works so well is the way that rounding is done when casting a float to an int in C++. Well actually there is no rounding. For example if we solve for x = 6 we end up with 1.15 * 6 = 6.9 which when cast to and int is simply 6. When x = 7 we end up with 1.175 * 7 = 8.225 which then becomes 8. So the 6 smallest movements are not actually changed. And when the values do start changing it is a smooth progression to larger numbers.

Share Button

Custom PCB from OSHPark

Well after a very long break I finally ordered a custom PCB from  OSHPark. I am very pleased with the result, i needed to manually cut the board because had my cutouts on the wrong layer.  I am most impressed with the fact that I soldered on a MOSFET with .5mm pad the first try! After putting all the components on the board and rewiring the breadboard it worked. Hell yes. My code was all wonky and its completely unusable but the hardware is functioning.

On to some code clean up.



Share Button

Had an odd issue a few weeks back. A process was not behaving as it should. After doing some digging I found out that the the only way it could behave like it was, was if an environment variable was set incorrectly. The odd part was that /proc/$$/environ was showing that it was set correctly.

After doing some research and playing with gdb a bit (thankfully this was a test environment) I found out that /proc/$$/environ does not give you what you think it gives you!

on to the why.

When a process starts the create_elf_tables function gets called. This function creates and populates a mm_struct data structure. This structure, among other things, contains env_start and env_end, which are the memory address of the begging and end of the environment variable data in the stack.

To get the environment variable information the proc file system reads mm_struct to get he start and end values where the environment variables are located. This is done in the environ_read function.

So why is this not giving me what i want? Well when the process is created in memory there is no buffer in the stack to add more environment variables or to make existing environment variables longer.  So when the process creates a new environment variable or modifies an existing one the environment variables get moved to the heap and the environ symbol is changed to point to the new location. The mm_struct however, is not changed. Which is not necessarily a bad thing but since the proc file system looks at the mm_struct you get the environment at execution time and not the current environment.

this behavior is simple to see.

$ echo $FOO

$ cat /proc/$$/environ |tr '\0' '\n' |grep FOO
$ export FOO=BAR
$ echo $FOO
$ cat /proc/$$/environ |tr '\0' '\n' |grep FOO

For the hell of it I was playing around with ptrace and made an small program that attaches to a process parses the elf structure, finds the environ symbol and then prints out the
current environment variables. The code is crap and the thing barely works(well sometimes it barely works) I was just fooling around. Its allot easier (and safer) to start up GDB and do a “show environ“.

Share Button