Hey Doug,

that's great.

My approach is a RasPiGPIO class which keeps track of the opened Pins 
and I2C buses. Then I have RasPiIoPin and RasPiI2C which do the actual 
I/O. I2C goes through OSProcess which I use to call the I2Ctools.

A Smalltalk process polls one I/O pin every 100 ms where I generate 
interrupts in Hardware. Only then I deal with the other pins or I2C.

The update of Raspbian which accommodated the RPi B2 broke may file 
interface to the GPIO pins by making the files for a freshly exported 
pin only accessible to root. So I'd have to export the pin, chmod its 
files as root and then deal with the the pins normally.

Do you need root permissions in your approach? Does an upgraded Raspbian 
break your approach?

I think before I want a speedier /dev/mem interface I'd try to get I/O 
events into Squeak. But not for this project.

If you like to discuss further (I do very much) we can take this to email.

Cheers,

Herbert


Am 05.02.2015 um 08:18 schrieb Douglas McPherson:
> I’ve done similar things too. I created a GPIOPin class which uses an abstract GPIOAccessor class to actually perform the access. I have two concrete subclasses of GPIOAccessor, one uses the file interface like you did for portability (so it works on the BeagleBone Black for example), and the other uses an FFI I developed based on a library called libbcm2835 IIRC.
>
> For I2C I took a similar approach. I developed an abstract I2CBus class which has two concrete subclasses depending on access method. One uses the portable SMBus file i/o style of accessing I2C, the other is an FFI interface again using libbcm2835.
>
> The /dev/mem interfaces (the ones using FFI) are not portable and only work on the RPi, but they are /much/ faster.
>
> I’ve got flashing LEDS, buttons and many kinds of I2C sensors hooked up; even a kind of mini weather station I demoed at Camp Smalltalk Vancouver Island. I planned to release this months ago but got tied up with other stuff. I also was trying to decide whether to publish as an FFI library or go ahead and write a plugin. I decided a plugin would be better, but haven’t got around to writing it.
>
> I believe Tim has followed a similar FFI approach, except instead of using libbcm2835 he is using WiringPi. I think long term we should use WiringPi since it has a lot of traction in the RPi community, but perhaps make a plugin based on it for ease of distribution.
>
> I am happy to share all this .. I just got bogged down trying to figure out the best way to release it.
>
> Best,
> Doug
>
>> On Feb 4, 2015, at 22:54, Herbert König <herbertkoenig at gmx.net> wrote:
>>
>>
>> Am 05.02.2015 um 05:06 schrieb tim Rowledge:
>>> It may well come to that, but at the moment I’m playing around and an ffi call is (usually) easy. I can make an led blink and read a button now! Pretty cool, eh?
>>>
>> Hi,
>> I'm blinking LED's and read buttons via the Linux file interface (that broke with one of the last updates to Raspbian).
>> Are you willing to share what you are doing? Need a tester?
>>
>> I use I2C through OSProcess and i2ctools, are you working on that too?
>>
>> Cheers,
>>
>> Herbert
>>
>