Psychedelic GNU diary

Haxor's guide to perfect code

Fri, 06 Nov 2009 02:53:07 GMT

I'm trying to learn how to write readable and maintainable code for some time (but often have to deal with very broken one) and here is what I want to highlight for everybody whose code I might be reading in future.

Most of the people think that programming is a process where you sit in front of computer and type the code. For a most of the cases this is not true. There are sure situations when you sit and write, but most of the time, you need to think first. So the work starts a little bit earlier, usually when you are walking in the park, cooking dinner or taking a shower. When you are sitting in front of the computer you should at least have a general idea.

Do not create overcomplicated solutions. There are more and less complex problems to be solved, complex problems calls for complex solutions but still they should be clear and understandable. Make the code as simple as possible but not simpler.

Be consistent. The code you write should be consistent, especially when you are creating library interface. There is nothing more confusing that library with inconsistent interface. When you start using same naming convention, use it in whole project. For example when one data structure has method Delete, similar ones should name it same way.

Break complicated things into small parts. It's a good practice to build complicated functionality from small parts with well defined functionality. This is called encapsulation. This way you could think of parts of a code as they are black boxes that does something and the good part is that you don't need to focus on how it's done. However sometimes it's hard to find optimal cuts. In General you should optimize cuts so that your functions are not too long and have small number of parameters. Individual test for every black box is also good idea.

Avoid meaningless comments in code. Commenting code is good habit indeed but don't get overexcited, don't forget that you are writing code not poem. Also quite number of comments comes from silly named functions/variables. It's always better to name variable as iter_cnt instead of naming it g with comment /* this variable holds number of backwards iterations */. But beware names like my_little_iteration_counter, stay descriptive and short.

Found a dead end? Sometimes programmer finds out, in the middle of writing code, that one of the assumptions made on start is not correct anymore or wasn't correct at all, in that case don't be afraid to use delete key. But beware that delete is a powerful servant but a bad master.

When speed is not critical it's sometimes better to optimize for code readability and shortness than for speed. Typical example are initialization runtines that are called once at the start they could be a little bit slower, but on the other hand you should never write code that is way too slow if there is possibility to write it fast enough.

Okay that's all for today. May be more to come in the future.

lm2576 stepdown and PCB prototyping

Wed, 04 Nov 2009 23:40:29 GMT

I've finally had some time to write down some electronic howtos, see http://metan.ucw.cz/?page=electronics, more to come.

Debuggin programs in C

Tue, 06 Oct 2009 10:59:50 GMT

Well, I've never used to use all the shiny and colorful debuggers. Instead of that using simple printf() was enough in most of the cases. However sometimes the code doesn't have stdout to print to, or stdout is too bloated with meaningless messages. For that purpose I've been using simple library that could redirect debug messages either to file or socket. Lately I've been asked by a friend of mine for that functionality. So I've put the code on the internet. Follow here to download the library. Note that this is just my internal library and is released as it is but at least it's a nice example how to use C99 macros with variable number of parameters and va_list.

Widgets for C

Mon, 14 Sep 2009 17:19:58 GMT

Lately I've been trying to create quite simply application to test evfilter library. For that some drawing into single window with several text boxes is needed, however if you stick to plain C, there are just two possibilities. Either learn GTK+ with all that comes in the way or use SDL and SDL_gfx to draw lines and print text.

GTK+ GDK and friends are good when you need simple window with button, but is not that easy to create window to draw to. At least there is not too much documentation and the api looks bloated. But I've been told about devhelp and cairo now.

SDL is nice for graphics, but there are some issues too. It's currently limited to single window and SDL_gfx (that's needed when you are not willing to write functions for drawing lines yourself) has several problems. The most problematic one is that colors are not exchangeable with SDL itself. Just because SDL_gfx has fixed order of colors (RGBA) and SDL just uses the same order as SDL_Surface so on my pretty standard PC there are two different values for the same color accordingly to which library the function comes from. Also naming for functions is not consistent enough and there is no nice namespace as in SDL. Anyway you don't have all that widget functionality (like in GTK), however in such a simple case it's rather advantage than disadvantage.

lftp now usable alternative to scp

Mon, 14 Sep 2009 16:49:28 GMT

Lftp is great command line software to handle ftp functionality. It can handle automatic retry, background jobs and supports ftp, http, ftps, https...

This week I've been told by a friend that lftp supports file exchange over ssh. This could be done either using fish or by sftp ssh based subsystem implemented in lftp. To try it just type lftp fish://user@machine or lftp sftp://user@machine and you will be prompted for password.

evfilter library

Mon, 07 Sep 2009 13:01:47 GMT

Good news everyone, evfilter library, that I was working on for a long time, has it's git repository and documentation.

Basically it's library that extends linux input intefrace on the userspace side and makes it easy to develop any application using input devices.

It also creates filter interface so that events from hardware can be modified/filtered accordingly to configuration.

For any further information follow: http://metan.ucw.cz/evfilter/

pcb_utils on gedasymbols.org

Fri, 05 Jun 2009 19:55:08 GMT

My library for generating footprints for pcb is now officially on gedasymbols.org. Check it out!

pdb2txt

Sat, 03 Jan 2009 00:43:19 GMT

I've created a set of simple and clean utils for dumping data and content from pdb text document files. The tarball consists of the pdb-reading library and tools 'pdbdump' and 'pdb2txt'. Pdbdump allows you to see every part of the file or header in human readable format and it's also an example how to use the library. Pdb2txt is pdb to plaintext decompressor with a lot of sanity checks. Download GPLv2 code here pdb2txt.tar.bz2. The code is not finished yet but reading files works pretty well. Compression and ability to save changes are on my long term todo.

crossdev -t avr

Tue, 28 Oct 2008 20:49:57 GMT

Okay here is my struggle with avr-gcc on gentoo. After reading several bugreports you should do:

Edit /usr/sbin/crossdev and change line 334 to WITH_DEF_HEADERS="no"

Select version of binutils and gcc (as default ones doesn't compile) for example crossdev -t avr --b 2.18.50.0.9 --g 4.1.2

Create symlink for linker scripts on x86_64 use ln -s /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts/ /usr/libexec/gcc/avr/ldscripts

Kexec in debian armel

Tue, 14 Oct 2008 12:19:43 GMT

I need kexec to test new kernels (because flashing is too lazy) but there is no kexec-tools for debian armel. So I've had no choice but build it myself. I've taken debian sid source package and use apt-get to build it, however this fails because file kexec/arch/arm/kexec-zImage-arm.c is using deprecated include asm/page.h. Just changing this to unistd.h works and the compilation could be done after this change. To build this package you need to tweak kexec-tools-20080324/debian/control to include armel architecture.

Anyway package for sid armel is here.

See bug here.

cheap LCD usb displays III

Wed, 08 Oct 2008 19:30:08 GMT

After afternoon of playing with st2205 library code I've cleaned the code and more importantly fixed some nasty typos that prevented libst2205 from compiling and working on x86_64 and ppc. Patch against 1.4pre1 is on their wiki in section download. Enjoy!

debian on spitz IV: zaurusd

Wed, 08 Oct 2008 19:22:57 GMT

This time I wrote small daemon that changes backlight when you press appropriate buttons. Another task will be battery handling, I would like to have some kind of warning when battery is reaching critical level. I quite like idea of flashing with charge LED as my phone does. Anyway here is very small and quite hackish source, but it does what it should and could be easy cleaned. zaurusd source.

Another problems are spitz touchscreen and keyboard. Touchscreen data are noisy (yes I already wrote this) and pressure is clearly reversed. And the code corgi_ts.c looks more or less compatible with ads7846.c which looks much cleaner. I'll try to merge this two or at least fix corgi_ts.c. Codes the driver assigns to the function keys look more or less random to me and everybody is fixing this by loading keymap in userspace, it would be very nice to fix this.

/etc/mtab should be obsolete on linux

Wed, 08 Oct 2008 18:55:25 GMT

I've been wondering why df and friends was showing clearly bogus information in some situations. Imagine you are about to copy some files to usb flash disc for your friend. You insert it into computer, copy files and do unmount or "safe remove". From this time on, the filesystem doesn't exist anymore in the kernel, but it's still in mtab (till caches are flushed and umount returns from unmount() call) Running df will end up (as it uses stafs()) showing informations about another filesystem (most likely /). And there is /proc/mounts for some time providing the same and all the time correct informations. In my opinion applications on linux should be patched to use /proc/mounts instead.

gpim

Wed, 08 Oct 2008 15:56:55 GMT

As you know I've been playing with touchscreen and console, after some time spending with search for all the possibilities I've had a talk with Vojtech (who designed input layer in linux kernel) and after this discussion rewriting gpm from scratch seems to be the most sane decision. So I've started to work on this. Here is pre alpha tarball. Most of the work is done, now it just needs to add some small features and code cleanup. Project pages will be available soon.

debian on spitz III: tslib & gpm & nano-X

Tue, 02 Sep 2008 12:29:11 GMT

I've been playing with tslib today. Now X server mouse (configured to use tslib) behaves quite well, sadly code to emulate mouse clicks is not included in my version of xf86-input-tslib. And it looks like Kdrive used in OE uses tslib too. I'm wondering why there is no tslib filter to emulate buttons (and thus this code is duplicated in higher layers), looking into source internal data structures are not supposed to support this. I'll ask on tslib mailing list if they would be happy with patch.

Also I would like to have gpm working with tslib, quick googling shows one ugly patch to do this. May be this needs some effort to clean and put into mainstream.

I've successfully build nano-X on spitz, there are some problem with keyboard and mouse (TODO: look for tslib driver for nano-X). However nano-X seems to be stable and fast on this machine, maybe this is way to go. Open problem is xrandr like display rotatiton, I'll ask on nano-X mailing list.

cheap LCD usb displays II

Mon, 11 Aug 2008 12:17:07 GMT

I've bought some Coby dp151 photo frames on Amazone and played a bit with them. Whole communication works trough USB storage driver as reading and writing to the raw device. Software consist of library and command line tools (and patches for mplayer and lcd4linux), compiling didn't go well because for some reasons -fPIC wasn't passed while library was compiled (also it's in Makefile, so it looks like typo but I haven't time to investigate). After this small fix/hack compilation goes well. Frame was detected with phack. After successful attempt to load modified firmware (there is small typo in the script that's mentioned on the wiki talk page) I'm still able to communicate to the device, but loading images into the frame is not working, setpic tool segfaults somewhere in the library (Possibly because I'm using 64 bit system). Another problem is that after plugging into the usb port, the device must be manually switched to update mode, so it's not useable for diagnostic displays. There are some attempts to fix this in the firmware (and it should be quite easy). Just another TODO are buttons, they are not working yet, also I've seen some addresses that should be read to check buttons on wiki but as it's not designed to communicate with PC, it will probably require some polling.

Velleman pocket oscilloscope

Mon, 11 Aug 2008 10:56:44 GMT

Some time ago I've bought pps10, it's a small battery powered scope with serial data output to PC. It's pity you are not able to operate the scope from the PC (and it would be easy task for the manufacturer) but it's just not possible. Anyway I would like to use it at least as data logger, so I started to write small app that reads data from the scope. I've spent some time looking at the data from the scope and realized it looked more like random noise. According to serial cable it looks like optocouplers are powered from the serial port and for some reasons most of the modern serial ports don't have enough power and because of this some '1' bits are being lost in the communication. It's very close to working fine just with small (about 4.7uF) capacitor attached to the serial cable (on quite old dell desktop with generic serial ports) and works flawlessly with external power source (even on crappy USB<->serial converters). Next step is to build USB power cable in order to use pps10 with my notebook. Anyway if you are interested in unix opensource software for velleman scopes, I'm close to finish first version for pps10. I'll post here link to the project pages soon.

debian on spitz II

Fri, 27 Jun 2008 11:49:13 GMT

A quite long time ago I've decided to exchange HDD in spitz with CF card. As CF cards are quite cheap, bigger and consume less power it's IMHO much beter solution. So I made tar of MMC card with debian installed and then untar it into 8GB CF card. The exchange goes cleanly, after removing 6 screws on the back side (two of them are under battery cover) and then removing black back cower I got to the insides. there are four more screws that are holding board with all the chips. They are even marked with arrows on the PCB so that you don't mount them into holes for the black ones that holds back cower. After removing these screws main PCB can be taken out, there are three cables for touchscreen, keyboard and display that are connected into connectors but if you are skillful hardware hacker, you don't need to disconnect them, because they all are connected on one side of PCB. On the other side of PCB there is HDD that I wanted to exchange, but before this I needed to remove MMC/SD card slot. It's clipped on the main PCB with four small plastic pads. All I needed to do was to bend two of them slightly out and remove it. From now on it was all of this in reversed order. Comparing this to changing HDD in iBook it's piece of cake, I don't needed three types of screwdriver, no magnetic traps, etc...

After completing back the machine I've pressed the On/Off button and it booted into debian. But as there are no OE scripts anymore keymap was missing. To fix that I've did:

install kbd
cp /OE/etc/keymap-2.6.map /tmp/
cd /tmp/
gzip keymap-2.6.map
mv keymap-2.6.map /etc/console/boottime.kmap.bz2
/etc/init.d/keymap.sh start

This fixes the keymap on all for all subsequent boots. This can be also fixed with "loadkeys keymap-2.6.map" temporarily.

Now here comes history about struggle with various flavors of Xserver. I've tried to hack xserver more and here are the results. Mouse still not usable, I had no time for touchscreen hacking, however external usb mouse works fine. I've managed to rotate display with Option "Rotate" "CW" parameter to fbdev driver, it worked, but all the drawing is now terribly slow, looks like there is a glitch either in sa1100 framebuffer code or in xserver fbdev driver. And it looks like fbdev doesn't support xrandr, so no rotation on running X server. That's bad :(. Keymap is wrong, and xmodmaping suspicious files from OE like slcXXX.xmodmap didn't really help.

So I've decided to give a try to Kdrive xserver, in debian experimental it's listed as xserver-fbdev, but only compiled for arm (not armel), ouch. Okay used aptitude to compile these package:

#get packages needed for building
apt-get build-dep xserver-xfbdev
#build package
apt-get -b source xserver-xfbdev

And after the night xserver-xfbdev_1.4.99.902-1_armel.deb was build. But It doesn't work either. All I got from It is:

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/haruka-chan:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
Warning: mode not found, using default
error: Invalid argument

Fatal server error:
no screens found

Which doesn't make any sense to me, just any general error and no logs. However Xfbdev from OE starts well debian with:

LD_LIBRARY_PATH="/mnt/OE/usr/lib/" /mnt/OE/usr/bin/Xfbdev

Looks like the debian package wasn't compiled the right way. And now I'm wondering if it's easier to make Xfbdev working or to dive to framebuffer code in xserver and kernel.

debian on spitz

Thu, 19 Jun 2008 18:32:29 GMT

I played recently a bit with Debian and spitz as this machine is in fact faster than my first PC with debian it's not so silly to try it. I've installed Debian on 1GB mmc card via debootstrap, as OE is compiled with new arm binary ABI, architecture must be armel (in case you want to use OE kernel). Then I copied /lib/modules/ from OE to debian, and symlinked /sbin/init to /sbin/init.sysvinit (to be compatible with altboot). Next step was reboot and choosing boot form SD in altboot. Nice it booted well. Network via USB cable worked after modprobing g_ether. Then there was a place for second stage for debootstrap and filling all the basic files like /etc/hostname and /etc/fstab.

First impression was "wow this works faster that OE with GPE", running vim in virtual console does not require about 3 seconds to load. Sound works nice, fine, mplayer works too. Xserver works with "fbdev", modprobing input modules to emulate /dev/mice works but touchscreen seems to be as noisy as it was in collie, i bet it's the same broken code for ucb12xx/ucb13xx and the coordinates are flipped, so mouse is useless. I need to look again at the ubc1xxx related code, because this is third device where the touchscreen driver is broken. The last time I've played with this I changed this code to use interrupts instead of polling and in the end it worked on collie preciselly without any filtering in userspace.

cheap usb LCD displays

Thu, 19 Jun 2008 08:29:09 GMT

Good news everyone, people started to hack photo frames to act as cheap USB external displays. Currently a few of small ones is supported (http://picframe.spritesserver.nl/wiki/index.php/Devices). I really would like to have some of the big ones working. I can imagine 9' photo frame as external display for PDA or mounted with tape to ASUS wlan router, there is just to many possibilities.

why I hate blogging

Wed, 18 Jun 2008 12:53:52 GMT

This is my first attempt to create blog. I don't like much the ideas about blogging and telling people you don't know things they don't wont to hear... However in my opinion there are some valuable (mostly bad) experiences with software and hardware that are not easy to obtain and could save some time if you don't need to track them down by yourself. I know there is Google and you can get most of them by googling, but Google index these pages too. And as I work as QA for Linux, I get in touch with really scary bugs every day. So lets begin to scare people muhehehe.