At the company I work for we are thinking about redesign one of our devices adding more GPIOs to it. The exisiting device is based on Beaglebone black design (It is not a pure Beaglebone black, it has some changes). It was designed some time ago by staff that no longer belongs to the company. Currently we have no experts on Beaglebone in the company.
We are thinking about adding to this new design more GPIOs. These GPIOs are not in P8 or P9 expanssion headers. I mean, they are available GPIOs in the Texas AM335 that are not used in the Beaglebone so far (e.g: GPIO2_14, GPIO2_6, GPIO2_7, GPIO2_8 , GPIO2_9).
Which is the right way to add this GPIOs in the system? Is it possible to do it by means of sysfs? Do they work in the same way as the ones in P8 and P9? The orginal desing has a kernel version 3.8.13-bone81 and Ubuntu14. We performed some test with GPIO2_14 and it didn’t work (we were able to export it, set it as an output but the oscillospe dind’t show any change while we were setting it to high or low).
When you control your GPIO by libpruio, there’s no difference between header pins or any other CPU balls. Ie you can use the JTag or SD-Card slot pins as GPIO. And, of course, you can add further CPU pins not wired on the original hardware. All you need is the CPU ball# (from TRM).
Thanks for your answer. After reading it one question arose in my mind quickly: if libpruio is used to control new GPIOs , all the GPIOs of the system must be controlled by it? I mean, if I have other GPIO defined and controlled in my system previously (GPIOs from expanssion headers) should I remove them and control them by libruio? Thank you.
If your new design is going to use extra pins you will need to modify the dts file loaded if you want it to appear in the sys interface, as standard gpio’s, or whatever the pins are being used for. This is pretty simple to do, just look at how it is done in the BBB.
Depending on the requirements for the extra I/O, have you thought about using an I2C port expander chip ? If will be much easier to add this to an existing design rather than trying to track out extra I/O from the AM335x chip.
It’s not necessary to rewrite all your code. You can mix GPIO by sysfs and by libpruio. But this doesn’t make sence because it’s hard to maintain.
Once the libpruio part is running you’ll find out that the code is much more easy to develop. And it executes much faster. And once you removed the cape-universal DTS-blobs from the boot sequence, you’ll see your system booting much faster with a smaller memory footprint.
Regards
PS
Dealing with DTS-files isn’t simple at all (perhaps for benedict, but not for me). There’re a lot of pitfalls (ie bad docs or bugs in the dts-compiler). And right now you didn’t find the related TI-TRMs: ie GPIO2-14 is used so far. It’s wired to header P8_37 (as ball# 48 = 0x30).