Re: Raspberry Pi as an inexpensive embedded LCDproc server

On Friday 24 August 2012, Markus Dolze wrote:
> I haven't done any research yet - is there a GPIO framework for Linux
> one can use instead of rolling our own?

As far as I'm aware, there is no "generic" GPIO framework used across 
the assortment of kernels and architectures - On the Arm SoC systems, 
it gets even worse with each chip (seemingly) having a different memory 
map.

> How does the 'uname' of a Pi system looks like? Can $host in
> configure.in be used to detect the Pi?

I'd prefer using a $target rather than $host to allow for 
cross-compilation. But within mature/established projects, this may end 
up being more trouble than it is worth if cross-compilation wasn't part 
of the original project brief. As the patch currently stands, there 
shouldn't be anything that breaks a regular x86 or BSD build.

> Before adding support for I2C you should really consider using
> hd44780-i2c instead, as Jannis pointed out that it already can drive
> displays on the Pi. I'd like to avoid rolling our own I2C thing if
> one already  works.

Agreed - No point in reinventing the wheel, and (after a casual look) it 
would appear that the existing hd44780-i2c driver would work on a Pi 
without any modifications. Subject to the i2c kernel driver being 
loaded. I don't have any suitable i2c peripherals, so can't test..

> If possible I would like to get rid of the global *gpio_map. I try to
> keep sub-drivers clean from things like these if possible. If you
> need a 'private' pointer put it in hd44780_private_data. This is
> crowded already - anyway, I will be fine with it.

It did cross my mind to make it part of a private data struct but kinda 
got carried away with other details - I'll take the comment on board 
and ensure it is no longer a global when I prepare another patch.

> Regarding delays and timings: Unless you need 'exact' timings (like
> 150 CPU cycles), uPause() should be sufficient and is easier to
> understand.

The BCM2835 datasheet is not clear if the required delay is in CPU 
cycles or clock ticks - I suspect the latter, in which case, the 150 
cycle delay is some 200nS (based on a 700MHz clock). Agreed, the use of 
uPause() would be easier to read but it does not provide the required 
granularity. I felt the comment accompanying the while loop sufficed, 
but I could expand on it if greater clarity is required.

On Friday 24 August 2012, Ethan Dicks wrote:
> On Adafruit's tutorial... [..] ... they recommend the package
> rpi.gpio.

The rpio.gpio package is a python extension rather than a C library. 
There are a number of other GPIO C libraries under development for the 
Raspberry Pi platform - Time will tell which, if any, gains dominance 
and becomes a de-facto standard. In the meantime, mapping GPIO to 
memory is trivial enough and avoids the hassle of writing a configure 
test for a supporting library... In that respect, it is no worse than 
say the hd44780-i2c driver.


Regards, Paul.