'drivers' for CFA-10036

[pwhalley]

Greetings all,

I am hoping someone can give me a little guidance regarding the CFA-10036. I find this board of particular interest because of it's lack of display hardware and (I think) potential for relatively low power operation and most of all the large number of I/O pins (think PLC). Some of the interfaces also are of particular interest.

I am not asking for detailed directions just some general guidance so that my further efforts will be maximally productive. A handful of sentences will take me a long way...


I am wanting to purchase one of these kits for use in home automation with MisterHouse (MH) running on Ubuntu 12.4. MH runs headless and has a web interface. At the moment I have this running on a regular PC using USB to communicate with a power line modem for lighting control and to connect to a 1-wire interface. I am using the PC sound card for audio and this will need to change but is not a priority. I can send audio over the network to my server, USB audio dongle, or R3 shield CODEC. I can't afford to purchase without high confidence that I will end up with an easily sustainable - system software wise - platform that I can expand as I intend (discrete I/O). Having the ability to use 12.4 goes a long way to achieving that goal. I have tried the GSG directions and believe I am ready to burn an uSD card - I just have to determine how big it needs to be and then do it. But that won't do much good unless I have the board to put it in to run. Assuming there are no hitches in burning and booting the card, there are still some things I need some clarity on before I commit. I need to learn a bit about what I will need to do to get the facilities on this board working in this particular application before I spend any more coin on another platform. on to the substance.

I will want to have a lot of discrete I/O very soon. I am not at all clear how this is or can be accomplished. Can someone point me in the right direction here? I need to be able to change a single bit output without impacting other bits that might be on the same 'port'. I need to change single bits in a way that any necessary masking is handled 'behind the scenes' with respect to the main code for the automation. I need to know that a bit that is a discrete device can't be stepped on by another process writing a byte to the port that contains that bit etc. I assume protection mechanisms to prevent such accidents will be present in any libraries that exist for this platform correct? There are other concerns such as how scanning inputs is handled in terms of frequency etc. but I hope I will have those answers when I have the answer to my first question.

What tools, libraries, - whatever - exist to allow me to configure and access peripherals on the cpu? In particlular, I2C? Where are they located (files, paths, relevant sections)?

Mh is written in Perl. I assume that a module that provides a language interface for that purpose would be the simplest but that likely doesn't exist. Will I need address each discrete I/O bit through the file system?

Thanks for your time,

Peter

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[CF Support]

Peter:

Thank you for your post.

I'll get an image built up with perl and see if MisterHouse will run, or what it might take to give you good guidance on this.

All of the I/O is exposed through the sysfs interface (/sys/class/gpio -- etc.) -- at least all that isn't spoken for by the devicetree. This is done on a per-pin basis, so I don't think you'll run into any difficulties there. In theory, depending on what you want to do, you just need to export the pin as gpio, then set the value of the pin, etc. Once exported, the pin is off-limits to everything else but GPIO from userspace.

There are good examples/tutorials for I2C etc, but I'm sure that we could point you in the right direction once you get your bearings.

 

[CF Support]

My Perl-fu is weak. There are a ton of perl modules that Misterhouse wants to use that I haven't the foggiest idea how to track down. If I had at my disposal all the pieces, I'm sure that it'd be no trouble.

 

[pwhalley]

Admin,

Thanks for the responses, I really appreciate the time you spent. I will dig into the sysfs interface a little as well as "the devicetree". Where can I find info that will indicate what is already spoken for in this platform?

At this stage I would restrict GPIO use to control of relays and reading switch states. I would try to stay clear of pins needed for I2c as this might be useful for 1-wire interface connection. At first, I plan on using USB for 1- wire as well as for other serial connected devices - primarily power line modem for lighting control and RS232 converter for weather station.

As far a the perl modules go, I think, CPAN came into play for me. Do you have a log file that enumerates the needed modules? Perhaps I could compare with my install on ISA platform. also, what version of perl? This raises another question. I will be able to add 'stuff' to the image once installed and running using apt-get or some similar mechanism correct?

I know there are also going to be some USB to RS232 serial drivers that will be needed as well. If my understanding is correct, as long as the architecture has 'main line support' add on devices needing drivers such as the rs232 converters 1-wire and PLM (same one actually) will be available using apt-get.

Thanks again for your time.

Peter