Loading ...
Sorry, an error occurred while loading the content.
 

Accessing the on-board GPIO

Expand Messages
  • clerew5
    I am using Slugosbe v5.3 in a slug. The Xscale chip provides 16 GPIO connections, and nominally these are all used by the slug. Each provides facilities for
    Message 1 of 1 , Apr 29, 2010
      I am using Slugosbe v5.3 in a slug.

      The Xscale chip provides 16 GPIO connections, and nominally these are all used by the slug. Each provides facilities for input and/or output of one bit, plus the facility to cause a user-catchable interrupt upon input.

      However, we know perfectly well that slugos does not use them all. For a start, the two 'disc' leds are not used, and are in principle available for other hacks. Moreover, I am planning to implement the ForcePowerAlwaysOn hack, which means the power button and its green light are also available (indeed, by the time my slug has been embedded, there will be no way to press the power button even if you wanted to). I also intend to bring out the i2c bus, and what I want to do is to arrange that an interrupt can be sent back from the i2c bus (a facility provided by the bus expander ship I intend to use) so that, when a button is pressed an interupt will be generated and caught, avoiding the need to run a continuous polling loop.

      So the question is: is there some way within Slugos to interact directly with the GPIO (there must be some such mechanism somewhere, because the publicly accessible i2c interface must use it, but it might be well concealed within the system). For sure that would be the neatest way to implement what I want.

      But if that is not possible (without writing special Slugos drivers, which I would prefer to avoid), would the following ghastly hack work?

      The plan is to connect the interrupt signal from the i2c bus so that it effectively "presses" the unused power button (The INT signal is just a simple 'pulldown'). Currently, when that button is pressed, the ensuing interrupt is caught and causes a call to 'shutdown -h now'. So I shall simply remove shutdown (specifically shutdown.sysvinit) from /sbin and replace it with a script of my own choosing.

      Indeed, I have tried this, and pressing the button duly called my script, and the slug continued running regardless.

      And finally, if I do shut down the slug (by pulling the power plug, or when there is a power cut), is there some way to cause it to die graceffully. Presumably, a large capacitor across the 5V supply would be neede to buy time, but would I also need to tell it what was afoot, or would the cpmplicated power control system automatically do that for me (maybe that would simply call my "script", but I could probably detect that somehow)?
    Your message has been successfully submitted and would be delivered to recipients shortly.