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.
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.
No comments:
Post a Comment