further exploration

I continued in checking and find my way in the configuration files in the /etc directory. I saw some lines in the smb.conf that I found interesting to uncomment because they had NetBIOS in there name and could be useful when you work with samba server. Doing that had some serious influence on the OS behavior. The NGW went to almost 100% cpu load and the inetd deamon was printing error messages into the /var/log every second. This was certainly not a good thing to do. So I changed these back to original comment. I still not know exactly what causes the inetd daemon to run weird like that, but I was happy to saw the CPU load falling back again to 98% idle.

I also checked the possibility of accessing the web server of the NGW from the outside Internet. Therefore I had the setup the NAT of my router and rout the port 80 to the fixed IP of the NGW. This went smoothly. DMZ is also a solution but far less secure. Maybe I wont use this feature in the future because I have a dynamic IP address given by ISP that changes every 36h. I spoke to some friend of mine and maybe he has a solution for this with some DNS registry you can do in that case. I'll talk more on the subject when I have tried it.

I rewrote the led program, as it should be. Now all combinations of button presses/released are possible even at the same time. I just improved the state checking in the callback routine and introduced some enumerations for clearness and proper code styling. The avr32studio is my development platform I use on my laptop. A pity is that in that environment, based on eclipse, the "code assistant" feature doesn't work properly. Only if I declare includes with full path and not using the short form

this seems to work. Yesterday I tried to manage a remote debug session because the NGW also have a gdbserver installed. The connection seems to work, but in entering the elf executable avrstudio tries to read at address 0 and apparently there are no symbols loaded for that address. I even tried with static linking same result. This feature could be useful as development will progress of the new domotic program and difficulty degree will rise. For now a printf will do.

As you can see there’s plenty new tooling and stuff to explore.

This story continues next month...

Big step forward

My first application using i2c driver was a success. It must be said that the test board was not ideal because of the inputs together with the outputs in one single pcf8574 but I managed to check my proof of concept.

Than it was time to investigate a bit more on my SD card problems. I had to isolate a few possibilities in order to get a clear view.

These were my possible causes of error:

• SD card read/write wrong on my ubuntu host pc
• SD card read/write wrong on NGW using u-boot (1.1.4)
• A faulty distribution of linux using buildroot

So I approached this problem with eliminating as much as possible. I set up a NFS boot from my hard disk on the latop. After seeing the result was fine the old version of u-boot could be more an more the cause. I updated the u-boot holding my hands tight to the table. I restarted the board and saw the u-boot prompt popping up with a fancy 1.3.0 as version. This was great !

I continued in making my kernel and busybox (with fancy prompt) again to be sure I had a new distribution. I put it on the every SD/MMC card I have and guess what all worked properly ! This was indeed a great step forward.

Now I can be sure of the indispensable backup possibilty and the power of making my own distribution if I want too. I continued in configuring the board. I fixed the IP address. A little problem arose with the nameserver but quickly solved by the great avrfreaks forum. One of my next things todo is checking the access point and making it also a fix address. After that I will be able to test the complete network chain. I will do that in writing a small echo server.

Step by step sometimes 2 steps back but if you finally make 10 steps forward it was worth waiting.

Further news on I2C

All leds were up and running with 500000 255 read/writes done yesterday evening. Great news that I really needed to decide to continue in spending time in NGW100 and analyze the replacement possibility for my "domos" system (ATMEGA32)

Yesterday evening I wrote a C program using the POSIX interface. I used a the ualarm() function instead of iTimer because I couldn’t find it into the /avr32-linux/include directory. This was my first contact with callbacks in linux and I must say this is working pretty straightforward. I think if you have the basic knowledge of OS principles (like win32) than you can adapt yourself more quickly.

The program I wrote toggled all leds every 20ms and it worked great. This I did to able to measure with scoop on one of the outputs. The square wave I saw was pretty nice. I reduced the amount of time and ( 10 and 5 ms) I saw a small unevenness in square wave. This is probably due to the overhead on context switching of the kernel. But I considered this as a normal behavior in general purpose OS. This could be solved taking a real-time OS. But 20 ms is more than enough for my application.

I now started to write a small modification on previous program which will capture the state of the 4 buttons and act appropriate in toggling the 4 leds. This can't be too difficult but still as the inputs & outputs are more or less inverted care should be taken.

May the leds be with us.

Goody goody

Wonderful finally see some good results. After a weekend of struggling with i2c I succeeded in a read/write. After reading some code examples on the net I noticed that the address given to the driver was wrong. It must be shifted right by 1 because of the abstraction of the read/write first bit. This is more or less indicated in /linux/i2c.h as 7 bit address but still confused me in seeing only the specified address in front of my eyes. Sometimes indeed it's an excellent idea to just read some other code and suddenly you realize that you did something stupid. Call that the blindness of the idea fix you have. Nevertheless this address thing could be better documented!

Test is running now as we speak in making a verify (write/read/compare) . For a start I let this running for 24h and see the result this evening. Eager as I was this morning I just checked and we did already 200000 verify cycles in a scenario of 255 write/read per loop. Great!

Next step at code level will be investigating the timer object in C/C++. I would like a callback function, which is called every x time. This is not new for me I did plenty of that at win32 level but now i'm starting to learn linux as OS. Sounds like a great exercise.

There is also a lot to discover at the buildroot/kernel level. And I would like to start with flashing the root and usr JFF2 file system into flash. Like that I always have a backup system, the moment the SD card is failing I easily switch to the flash startup. I want to be able to quickly have a system up/running because it will work 24/7. So focus on robustness and backup guaranties is indispensable for me to have.

More news will following on the first real test running now.

Test print connected to NGW100

First tryouts

As the weekend is passed now I have a bit more experience in using the NGW board. First of all I did some testing with using the i2c driver of atmel this can be followed on the avrfreaks:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=58666

As expected, the usual problems that you have with everything for free and fed by a community, is also no exception here. The lack of a good API and functional documentation for instance is a real pain in the ass. You only have the stories of some good souls who wrote on several forum threads to help you out (or not). You always can write a driver yourself of course but that shouldn't be the objective as the linux framework lives long enough to provide something transparent and portable to easy adapt on new target cpu's.

So first you have the above problems in the free world and secondly you have a GCC based framework that sometimes is complex to work with. If I look at the buildroot compilation and linking of the avr32 linux and rootfs well this still has some great lack on documentation too.
As it is normal in this world to use config files it would be great to have a description available to use the several makefiles. This cannot be so hard todo. But still, I notice that people in this world think they are the gods or evangelists of computers and assume that you know all that stuff like them dominating to use linux. Maybe this is because they had to learn all by themselves so they expect that from others too. Yes I know I sound pretty negative here but if you spent almost a whole weekend in just figger out how you must make a call to a simple read/write i2c protocol. What expected to be transparent to the user is totally not case and suddenly you're lost in world full of open questions. You even start to doubt yourself and do some logic analyzer testing to finally be even more unhappy because it's not what you intend as result.

It's also true that i'm still quit a newbie in this stuff and have a long way to go. Good news is that TCP/IP sockets model work without any problem on the board. I tested it with some simple client/server echo model build as managed avr32 linux elf file in the avrstudio.

Also a pitty is that I still can't make any other SD card with linux dist. I even tried a MMC card but no luck. I only have the 512M for now. I even tried with copying the partion with gparted on a 1G SD. The copy succeeded but when u-boot starts up read error in decompressing the kernel. In my opinion the u-boot code can only handle a limited amount of cards although I'm not totally sure of the ubuntu drivers on my laptop.

I will also post a picture of the little I/O board based on PCF8574 I2C to test the NGW100.

Linux kernel up and running !

Since yesterday I succeeded in booting from a 512Mb SD card and having a new kernel running 2.6.23. I noticed that in the process of preparing the SD card with the buildroot distribution sometimes my ubuntu system had some problems with properly unmounting the EXT2 file system. This slowed down the process of testing a bit. Basically whenever I didn't get the message pop-up "you can safely remove" the card was corrupted. Finally I succeded in using a USB card reader in stead of having the internal card slot. I assume the device drivers of ubuntu are not working well on my thosiba for the internal slot.

Finally I saved my boot arguments into the enviroment space of U-BOOT to always start up from SD card. I configured following files:

• /etc/TZ into ETC-1
• /etc/samba/smb.conf to allow network 192.168.1.*
• added /etc/profile with $PWD to show path in busybox prompt

Next things todo still continue configuring the env eg IP fix :

• eth0 192.168.1.6 / eth1 192.168.1.7
• Adapting my router dhcp settings to lease addresses from 10-30 so I have 2-10 free to have them fix setup
• Configuring belkin access point to fix 192.168.1.5 without WEP --> need windows for it??

Perhaps it's also a good idea when I have a nicly setup ready to try to backup this using Ghost 2003.

So as you can see plenty things to write about in the future.

I changed the color to green to see the effect on black background.

Next step linux from SD card

As everything runs smoothly out the of box using the 8Mb parallel flash for root fs and the 8Mb serial flash to mount /usr I think it will be a good idea to move one step forward and try to boot from a SD/MMC media card. I started this process yesterday.

Right now I'm busy to making a linux distribution ready to boot and run from SD card. The buildroot run was quit nice only a bit long. Finally after having the binaries ready I copied the TAR archive to the EXT2 formatted SD card (1GB) from SanDisk. I encountered already some problems with reading this card in the target board. When I changed the SD card to a 256Mb from Pretec the boot was much better but still not running. I subscript the www.avrfreaks.net forums and start an issue on these problems and can be followed clicking this link:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=58549&sid=d74366e69f9ec41056e5e77ecd6d1bee

The reason to make this run possible is partially due ti the fact that the original kernel is a 2.6.18
and is rather old so better to go for the latest 2.6.23 and partially to solved problems in the I2C driver. In my project with the NGW100 I just need the I2C functionallity to interface an extern I/O board. I also need the ethernet in some way but not yet sure what kind of protocol I should use. I did some test already in c using the socket/pthread and there seems to be no problem at all. the first thing that I want to do if I have a fully running linux on SD card is trying to play with the GPIO first from teh linux shell and finally in some c code using simple files attached to the device.

All for now. Till later when I have more (good) news.

Picture of the NGW100

NGW100

Just have the evaluation kit NGW100 of atmel. In this blog I will write a few lines on making progress. It was a pity the AVR32freaks website was down this weekend so I had a missing source. Nevertheless the board works fine out of the box. I will post a picture later on.

Cheers
Guy