Glomation
 
Advanced Search
Welcome, Guest. Please login or register.

Login with username, password and session length
May 22, 2012, 04:00:26 AM
Home Help Calendar Login Register
News: Glomation introduces new GECM-9G25 SODIMM system on module
Pages: [1]
Topic Tools  
Read October 19, 2010, 05:48:37 AM #0
Jack

  • *****
  • Super Hero
  • Posts: 9
Handling the interrupt signals
I have written a program in c and I want it to be ineterrupted if I press a button. In the main() I have a sleep(1); and if the butten is pressed a function should should be carried out and then the sleep should continue. I know how to set the registers but is there someone who has an example of how to program a c-function that is controlled by the interrupt signal and that temporarly "overrules" the sleep(1)?
 
Read October 19, 2010, 08:49:58 AM #1
Jack

  • *****
  • Super Hero
  • Posts: 9
Re: Handling the interrupt signals
Oh I'm using the 9G20 by the way. And I thought that I only have to set the interrupt regs at the pio but I don't know if I also have to setup the aic regs. And the main problem is how to let these signals inetrrupt my program during sleep() and let it restart again at the same position.
 
Read October 19, 2010, 03:30:55 PM #2
admin

  • *****
  • Administrator
  • Super Hero
  • Posts: 342
Re: Handling the interrupt signals
The Linux kernel 2.6.30 and up includes a GPIO driver that can simplify GPIO handling.   It's possible to implement a simple GPIO program without using an "complicated" interrupt handling scheme.  Please see the following link,  http://bec-systems.com/site/281/how-to-implement-an-interrupt-driven-gpio-input-in-linux.
 
Read October 20, 2010, 06:39:48 AM #3
Jack

  • *****
  • Super Hero
  • Posts: 9
Re: Handling the interrupt signals
Thanks for the link. I hope I did understand it.
So when I enable the interrupt on the pio, I should be able to get an event0?
And this progrma should interrupt my program temporarly?
I'm going to try it, thanks a lot.
 
Read October 20, 2010, 08:25:34 AM #4
admin

  • *****
  • Administrator
  • Super Hero
  • Posts: 342
Re: Handling the interrupt signals
The Linux GPIO driver will handle the input level transition interrupt.  The application program should just use a blocking read call to read the input.  The program will be blocked and go to "sleep" until there is a input level change on the input line the program is reading.  In a high level OS such as Linux the application program should not handle the low level interrupt.  It should be a device driver's job to do the low level control.  In this case the GPIO driver is taking care of the input level transition.
 
Read October 20, 2010, 08:46:51 AM #5
Jack

  • *****
  • Super Hero
  • Posts: 9
Re: Handling the interrupt signals
Is this also possible with the linux 2.6.27.4 version that is already installed on the board? Or do I have to compile a completly new linux 2.6.30 image and add the 9G20 patches.
Is there also an easy way to handle the interrupts if I want to keep the original version of linux?
 
Read October 20, 2010, 09:07:55 AM #6
admin

  • *****
  • Administrator
  • Super Hero
  • Posts: 342
Re: Handling the interrupt signals
Only the Linux kernel 2.6.30 and up have the GPIO driver.  Custom driver is needed for 2.6.27.4 that is shipped with the board.
 
Read October 20, 2010, 10:07:54 AM #7
Jack

  • *****
  • Super Hero
  • Posts: 9
Re: Handling the interrupt signals
Oke I'm trying to make a new image for my 9G20. I downloaded the linux kernel 2.6.33.7 sourcecode from kernel.org and the corresponding patch from http://maxim.org.za/at91_26.html. I patched the kernel and it worked, but when I use ~/linux/linux-2.6.33.7$ make O=/home/user/linux/build CROSS_COMPILE=arm-unknown-linux-gnu- but it needs a .conig file. I don't know if the sourcecode is correctly configured for the arm and the sbc. I also don't know how to install the new kernel on the board and configure it in a way that the board keeps the same functionality that it has now.
 
Read October 20, 2010, 12:59:36 PM #8
Jack

  • *****
  • Super Hero
  • Posts: 9
Re: Handling the interrupt signals
I found the config files for arm in /linux-2.6.33.7/arch/arm/configs and I can find the config file for the arm 9G20 but not for the complete board.
 
Read October 20, 2010, 01:07:55 PM #9
admin

  • *****
  • Administrator
  • Super Hero
  • Posts: 342
Re: Handling the interrupt signals
The factory installed Linux kernel on the GESBC-9G20 uses default configuration file for the AT91SAM9G20-ek as the base configuration with some commonly used drivers added (USB to serial converter, WIFI, etc).   Same route can be taken to build customized kernel.

First,

make CROSS_COMPILE=arm-unknown-linux-gnu- at91sam9g20ek_defconfig

then,

make CROSS_COMPILE=arm-unknown-linux-gnu-  menuconfig

to select and de-select items for the customized kernel.
 
Read October 21, 2010, 08:20:16 AM #10
Jack

  • *****
  • Super Hero
  • Posts: 9
Re: Handling the interrupt signals
I compiled a new uImage and got a new emdebian file system from your website. I tried to test this by nfs but I don't know to which adress I have to send the kernel to. (Where is the ram part of the memory?) I followd the steps on http://billforums.station51.net/viewtopic.php?f=1&t=17 Where the adres 0x31000000 is used I don't know which adres I can use on the SBC.

Furthermore I have some questions about the filesystem I noticed that in the emdebian version (http://glomationinc.com/Support/9260/ramdisk.gz) there are a some folders missing. The /dev/input for example. And that is the folder I have to use for handling the interrupts. should I use the complete debian file system or are these folders and files generated automatically by the kernel?

The last question that I have is, is it possible to run the kernel plus file system from usb or preferably from an sd-card?
 
Read October 21, 2010, 11:06:20 AM #11
admin

  • *****
  • Administrator
  • Super Hero
  • Posts: 342
Re: Handling the interrupt signals
The exact kernel loading address is not very important as long as it is in the valid SDRAM address range and has enough room to load the kernel image.  The kernel will relocate itself as it decompresses.  0x3100000 is not valid on the GESBC-9G20.  The valid SDRAM range is 0x20000000 ~ 0x23ffffff if you have 64MB version.  Please see the example in the user's manual.

The RAMDISK image is not Emdebian based.  It is just a small embedded file system using Busybox.

You can create device node in /dev directory if you have the device major and minor with mknod command.  The GPIO driver actually uses /sys directory to read and write GPIO.   The /sys directory is created by kernel.

The U-boot can read DOS formatted USB drive but Linux file system does not work well on the DOS format drive.  It's better to keep kernel in FLASH memory and use SD card or USB drive as root file system.  Please see topics, http://glomation.net/smf/index.php/topic,215.0.html and http://glomation.net/smf/index.php/topic,99.0.html. 
 
Pages: [1]
« previous next »
Jump to:  

Theme Update by Runic Warrior Originally created by m3talc0re Powered by SMF 1.1.15 | SMF © 2006-2008, Simple Machines MySQL | PHP | XHTML | CSS