> On Feb 5, 2015, at 06:24, Herbert König <herbertkoenig at gmx.net> wrote:
> 
> 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.

Yes, interesting. I also used OSProcess when I was initially experimenting.

My design was similar: GPIOPin keeps track of open pins and attempts to close no-longer needed resources with functionality on the class side. The GPIO access was implemented in a separate hierarchy which as I mentioned has 2 concrete subclasses, one for sysfs based file i/o access and one for /dev/mem via FFI. 

For I2C, a class representing an I2CBus and another representing a I2CDevice which gets subclassed for different devices. An I2CDevice gets associated with a particular instance of I2CBus. 

> 
> 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?

For manipulating the GPIO files in  sysfs on Raspbian I did not need root. However, when used on BeagleBone Black Ubuntu root was required. That’s Linux for you. I have not tried on a recent Raspbian. The /dev/mem solutions all required root of course.

> 
> 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.
> 

The /dev/mem provided by the FFI interfaces is immensely faster. For example I hooked up photocell and capacitor on a GPIO as sort of a (very) poor mans ADC to read the resistance of the photocell. Driving the GPIO low and then reversing the GPIO direction and polling continuously until it comes high was a way to measure the relative time it takes the circuit to charge. Doing this using the file i/o GPIO access was impossible since it was far too slow … usually 1 or 2 polls and the GPIO had already returned to a 1. But with /dev/mem, I could get in the range of 200-400 or higher polls before logic high was detected. So the resolution was much much better. Of course, one could enable an interrupt on the pin but I wasn’t sure how to get that event quickly into Smalltalk.   

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

It would be great to collaborate on and publish a package to wrap GPIO, I2C, and PWM functionalities. I think we should combine our efforts with Tim’s too, as he has been using the wiringPi library via FFI for /dev/mem access, which is probably a better choice than the cobbled together library I used. I think we should include the file i/o based access methods for both GPIO and I2C since it gives some measure of portability to other Linux systems (such as the BeagleBone Black).

> 
> 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
>>> 
>> 
> 
>