Hi -
I’m reading chapter 8 of Dr. Molloy’s book, which discusses bus access. The example I’m working on right now uses the file system to access devices on the I2C bus. I recognize that this is a typical way to access that bus, but I’m wondering whether it’s feasible to bypass the file system and just bit-bang the lines directly.
The purpose of this question is mostly educational, but also for some troubleshooting purposes, as I’m getting a lot of errors when I run the ADXL345.cppexample. In his loop of 60 read iterations, about 15 fail on a usual run for me. I also imagine that real time applications would benefit from bypassing the overhead of the file system, so it seems like a good thing to learn about.
Thanks…
It would be good if you shared the actual errors with us so we knew what
you were talking about. But bit banging an I2C bus in Linux ? No not really
much point to that.
Hi William -
Yeah, sorry about that…I was being lazy. The output of perror says “Connection timed out” though the first time the write is called, errno is 22. In the next write attempts, errno is 110 (agreeing with perror). I’m trying to write an 8 to register 45 (POWER_CTL).
But, before we worry too much about this error, let me ask this: if bit banging isn’t a good idea, can you point me to a reference that describes the workings of the file I/O to the I2C? I’m new to embedded Linux (used to an RTOS) so bit-banging is more natural to me. I need to learn a little about what’s “under the hood” of the Linux technique for this kind of I/O.
I think looking at the source code for the various tools included in the
i2c-tool debian package would be a good place to start. Also seeing if
there is a driver for your hardware in the Linux kernel might be a good
place to just gloss over ( at least ) to see how they're doing things.
I've done some lower level Linux dev I2C as well, and have probably run
into similar issues you're facing here. I'm not an expert. But what I did
realize in my own case that communicating with the hardware I am using( a
real time clock ) that using a different approach was much better. In my
case. I have some I2C code I've written in C, but at this very moment I'm
busy with my own things, and not quite sure where that code is. At some
point however, I could look into my code and refresh my memory, and give
you an idea of what I did for a different situation.
So bit banging I2C would be a terrible idea in my opinion, because you
would using a lot of processor time. After that, there is very little
chance you'd be better at doing this than is what already is done in
drivers already. It could be worth a look, but I think you'd be spinning
your wheels. However, if performance, and a lower processor load was a
definite must. You could probably use an external MCU that used hardware
assisted I2C, and design something like an I2C to UART bridge . . .which
could be useful, I guess.
Now as far as direct memory access to the I2C hardware. Well, it’s not impossible, and is probably already being done in the driver module for the beaglebone’s hardware. In kernel space. So, if you’re dead set on learning that, you’d need to look into the am335x I2C kernel driver source for that. Not sure exactly where to start with that. But you could start by looking into the mainboard source file to see which kernel module is being loaded for the I2C hardware, then track your way back into the source file.
Or you could just start exploring the kernel source, and perhaps run into the I2C driver source that way too.
"mainboard source file" meaning the device tree overlay file for the
beaglebone.
Thanks for the words of wisdom, William. I don’t want to swim upstream with this, so I guess I’d better learn about creating and installing device drivers in Linux. I found a book on Amazon that looks good, and I think I’ll start there.
Thanks again.
Derrek Molly has a semi recent 3 piece set of article on his exploring beagelbone web site. For creating Linux device drivers.