The gpfsel_list (I maybe should have called it lsgpio) utility displays a list of the currently configured function selections across all available GPIO pins and, for pins configured as GPIO, the current state of the pins. For pins configured with ALTn functions, the selected function is listed according to the datasheet information.
It also shows the state of the PADS registers to display the configured drive current, hysteresis, and slew setting for the three groups of pins (GPIO 0-27, 28-45, and 46-53).
It’s been written to produce output that’s easy to grep and cut, and performs only read operations on the registers – it can’t be used to modify settings, though I suppose this could change in future.
Admittedly, it had been unused for quite a long time but, regardless, my LinkedIn profile had a few historical recommendations from people I actually knew and respected, so I hesitated before closing it.
The main reason I had for closing my LinkedIn account is to protest in some small way against the lawsuit that LinkedIn are pursuing against hiQ for scraping (automatically fetching and processing) public profiles of members.
I don’t know or care anything much about hiQ or their scraping antics, but LinkedIn pushing to criminalise accessing of public profiles, via a web server bound to a public TCP port, on a publicly visible computer is a dangerous step in the wrong direction. Continue reading
Having recently received my Raspberry Pi, one of the first things I wanted to do was hook up a real-time clock chip I had lying around (a NXP PCF8563) and learn how to drive I2C from the BCM2835 hardware registers. Turns out it’s quite easy to do, and I think makes a useful project to learn with.
So, here are some notes I made getting it to work, initially with Chris Boot’s forked kernel that incorporates some I2C handling code created by Frank Buss into the kernel’s I2C bus driver framework.
After getting it to work with the kernel drivers, I created some C code to drive the RTC chip directly using the BCM2835 I2C registers, using mmap() to expose Peripheral IO space in the user’s (virtual) memory map, the technique I learned from Gert’s Gertboard demo software, though my code’s simpler (hopefully without limiting functionality!).
Note: Revision 2 boards require the code to access BSC1 (I2C1) rather than BSC0 (I2C0), so changes to the peripheral base address may be required, or in the case if the Linux I2C driver, a reference to i2c-1 rather than i2c-0. It should be simple enough, but I don’t want to write about things I haven’t done or tested, so a bit of extra work by the reader may be required.
There’s been a lot written about the Raspberry Pi, a small single-board computer with I/O pins on the circuit board, and a small price tag (£25 or so). For me, the most exciting aspect of the Raspberry Pi is the fact that it has lots of methods of input and output of digital signals to and from the board.
Lots of people have reported good things about the toner transfer method of making printed circuit boards. Lots of other people have said it’s a waste of time. I have been trying to use this technique to produce decent quality boards, with quite a few successes so far. Continue reading
Some notes on the SmartAlpha module from RF Solutions, though these may have been superseded by a revised firmware that appears to have made it onto the device.
We have Dell R415 and R515 11G servers that have been rebooting sporadically. These restarts are seemingly random, but occur at approximate intervals of 6 weeks, 2 weeks, or 2 days. The messages in the BMC/iDRAC6 system event log seem to be misreporting various hardware problems. The problem appears to have been avoided by disabling the Event Message Buffer using ipmitool, but only time will tell.