Books

Just for the record I publish my 3 books I'm reading for the moment:

GNU/Linux Application Programming (Programming Series) (Purchased on 01/27/2008)
by M. Tim Jones

Linux Kernel Development (2nd Edition) (Novell Press) (Purchased on 01/27/2008)
by Robert Love

CGI Programming in C and Perl (Purchased on 01/27/2008)
by Thomas Boutell

Reviews will follow later on as promised.

Adding audio why not

Due to the fact that I use an audio player with the existing domotic system I checked out the possible ways on the NGW. I was quit surprised to see there were a few possibilities to go for. I had the choice out of:

1. ABDAC
   
2. I2S
3. AC97

I tried the rebuild my kernel with sound enabled. I had to play a bit around with the options in the menuconfig window to finally get some device to play. I also installed the IPKG install tool to get small binary packages more easy already compiled for the AVR32 target. I installed the madplay as a player to try out the sound device. I managed to play a MP3 song from the command line but only to the /dev/null dummy sound driver. Of course this normal because I haven't connect a codec chip yet. I asked a few opinions on the freaks forum and apparently the AC97 was the one to go for. I tested the ABDAC output and that seems to be ok because it has the build-in capacity to convert a 1 bit stream. But the quality of sound is poor. I left alone the I2S option this is used in the other larger development kit STK1000.

So I decided to take the AC97 option widely spread in PC sound cards. I browsed to the Cirrus site and found a suited codec chip that could be easily connected to the AVR32. The drawing in my previous blog must change in order to get the sound on board but this should be finished as we speak. See the final drawing in this log. The board will be soon in production now. It must be said that it will be a large board (10x21cm) but there's plenty on it. I also limited the amount of layers to 2. Al I/Os are very good isolated against any disturbance from the out site so I took the risk.

As soon the board is ready I take some picture and post them.

In the meanwhile I'm still busy reading in my purchased books. The subjects of the books and the reason why I read them:

• GNU application development ( for general development )
  
• Linux kernel development ( to get a better view on the inside )
  
• CGI in C and perl ( to consider the web server possibility )
  

To soon to give a small review on them but I will do it when I finished them all. For the moment it's very important that I get a more in depth view on the linux OS in general because it's my first time that I develop some stuff for linux. I was used to work against the windows win32. But as I already can say now their are plenty of things in common like the use of libc and OS basic principles like processes, threads and synchronization. But still much to learn ! My proof of concept that I have in mind is still growing everyday as we move on learning. I try to do some examples from the accompanied CDs as well. The results of using CGI from a C program on the NGW is quit great I must say. But I will write some dedicated blogs on a few topics that I learned or found amazing to discover from reading the books.

drawing general purpose I/O board for ngw100

design I/O board for ngw100 ready

As promised in one of my previous blogs the I/O board drawing is ready to go in production. I post a complete picture separately for better view. What are the features of this i2c board:

• 40 inputs
• 40 outputs
• 8 digital to analog outputs

The inputs are totally interrupt driven and will be handled by the user space program on the ngw. The board splits up the inputs / outputs by two 26 pin connectors for each. This was done to provide some compatibility with the older system. There will be a main supply of 12V which will also be used for the ngw. Leds are provided for input as well as for the outputs. This is useful specially in the test phase. Finally this board connected with ngw will act as the domotica heart of the system. I will release some more picture when the board is really made and soldered.

preparation of I/O

In anticipation of the brand new PCB that is going to take care of 40 inputs and 40 outputs I did already some useful research. It will be necessary to have not only the related i2c signals available but also some i/o pins which are going to deal with interrupts and output enabling. Therefore I must have 4 signals connected to the gpio of the ngw. To be able to do this kind of signal capturing there are 2 possibilities:

1. Writing a kernel module
2. Userspace access via configfs

I preferred the user space to take. This has the advantage of having everything central and easy to debug if necessary. It took some time to finger it out how the configfs was working but finally it became clear. I wrote a little start up script to add the files under the appropriate directory. I took a c example of the avr freaks site and compiled it in the avr studio. This example showed the different approaches you can have when working with gpio as a character device. So it was excellent to start with. I set things up to work with the dedicated PA pins also needed for my new i/o board. I tested the 4 lines in having 0/1 and all state changes popped up very well on my screen. I was bit scared tough because the 4 pins where located on the same port as i2c. But I ran the led program together with the i/o program for 12 hours and things didn't interfere at all ! This was good news because the proof of concept now is almost complete.
This week I expect some good linux books. They will be used to get a more in-depth view on programming applications using the unix framework/kernel like signals , threads ,... I will have some blogs on them later on to review a few chapters. Now I can start thinking of the program structure I will use to write domotic program.

So always preparing for next steps in small well-aligned pieces is the way I like to make progress in complex systems.

public web access

After having a discussion on the possibilty that the IP address from your ISP was unique or not I investigate this matter in more depth. And I must admit it's unique but taken from a dynamic pool in my case changed every 36h. If you don't have something to solve this, than the option of working remotely on the ngw via a web interface isn't that wonderfull at all. You must have something fix that always points to your address whatever it is at that moment. The solution is finding an instance which hold your IP address and link it to an URL. Also having a client running that at regular basis updates your IP address to that instance.

I took www.no-ip.com as the solution for my problem. Register with your email and fill in the free option of DNS host and off you go. I also downloaded the linux client package which comes with the source of the client. I compiled and linked it against the AVR32 libraries in the avr studio. I installed the new client as a daemon on the board. It works really great ! I tried it from work today and went smoothly.

Now I can be sure the ngw board is accessible from wherever I will be I just need an internet connection and a web browser but these are common things these days. The reason I wanted to investigate this matter is that I'm still thinking on how I'm going to build up the user interface. Now HTML becomes a good candidate to include in the list.

Next step is perhaps a smtp client. Not needed absolutely but still handy if you can send something out there when some events arise. This can of course also be logged and send by the cgi-bin if I like.

Still have to look into some security stuff also. I noticed that the root level directory of the web server isn't protected even if I put user/passw in the config file. And security you must have if you are open to accept connection on port 80 coming from the internet.

GDB on NGW

As stated in previous blog my learning cycle still grows with a reasonable speed. I struggled a few days in finding my way in the world of GDB, the linux debugging tool. Not only GDB was new for me but also the fact of doing the session remotely from within avr32 studio.

So I first started in making the Belkin access point up and running. This was still configured as DHCP and WEP encrypted. I changed my Philips router to the WEP again because I suppressed encryption due to the new ubuntu on my laptop. But in fact this was easy to enable again and now all my network devices work with the same WEP password. I connected the NGW on the access point but it the fix IP was not visible anywhere on the network. After a bit searching I suddenly realized that I didn't add the MAC of the NGW in the remote access table of the router yet. That solved indeed the problem. Happy as I was to have my chain completely set up, as it will be running live. I tried a few basic protocols over the network like a simple telnet session, NFS, samba and HTTP all seems to work properly. Now I don't have the NGW on my desk anymore but it locates in the electrical closet now, which is in the garage. I will shoot a picture later on and post it. Fully operational I must say!

At the same time setting this up I was also experimenting with remote debugging because the linux distribution on the NGW had a gdbserver installed. I tried and tried and tried but still having errors the moment gdbserver started the application. Sometimes I got "cannot access address ..." sometimes "segmentation fault". I changed several properties on the debug tab in the studio but still the same. I posted something on the avrfreaks network but no answer. Yesterday finally I saw where the problem could come from. Until now I always used the default "gdb" as client program to start within the studio. I did a find on my laptop and I got 100 hits on gdb like programs! Of course I had the wrong client, which works only with i86 gdbserver. I changed this by pointing to avr32-linux-gdb and oeps I was in ! This can be signaled as an error to the developers of the avr studio in my opinion. I tried a few debug features and all seems to work, even the viewing of the default register bank of AVR32 like R0-R12, SP,PC and LR. The special AVR32 registers like PIOA were undefined which is kind a normal without a JTAGICE and running in linux user space.

Doing al this I’d realized that a good understanding of the principles of linux permission is indispensable. I noticed for instance that if a C program tries to access a driver by IOCTL function and the user who started this program has no RW permissions on the driver modules all calls fail. It's easy to solve in doing chmod o=rw [driver] so that "others" can access too, assumed that the driver was started by root. But still if you are not familiar with that kind of protection it takes some time to get used to.

In the meanwhile a friend of mine is also started on the new IO board, which will be connected to the NGW. Totally based on the i2c protocol. I will dedicate a few blogs on this item in a few weeks when the PCB is finished and when I can go into details.

Maybe the first I’m going to try now is registering the no-ip.com site to be able to access my webserver on the NGW from anywhere on the internet. This works already but every time my ISP address changes I must use another address. I will start trying to compile and link the client daemon against the AVR32 chain because it’s really necessary to have this running undependably of any laptop or desktop pc.