> -----Original Message----- > From: Charles Steinkuehler [mailto:[email protected]] > Sent: Sunday, December 01, 2013 6:10 AM > > On 11/30/2013 10:58 PM, Steve Stallings wrote: > >> -----Original Message----- > >> From: Charles Steinkuehler [mailto:[email protected]] > >> Sent: Saturday, November 30, 2013 10:34 PM > >> > >> LinuxCNC doesn't really seem to have decent support for > >> sub-buses, like > >> I2C or even EPP, unless it's wrapped and hidden by the driver. In > >> particular, it would be very cumbersome to write a generic I2C bus > >> driver that could be used by various HAL components to talk > >> to multiple > >> different I2C target devices. Not that I'm volunteering to > >> write this, > >> but don't get mad at me if I implement something less than a fully > >> generic I2C bus transport mechanism for HAL. :) > >> > >> ...although whatever I do will probably be at least somewhat fancier > >> than the bit-banged I2C bus master I used for my initial LinuxCNC > >> control tests of my 3D printer (run on an x86 system, using > >> the software > >> step generation thread to bit-bang I2C via 3 parallel port pins). > >> > >> -- > >> Charles Steinkuehler > >> [email protected] > > > > This is disappointing news. I have been working on a > > follow-on to the K9 Smorgasboard and had assumed that > > I2C devices would be easy to support. Both the original > > Smorgasboard and the new board that I am working on use > > the Beaglebone Black I2C2 bus to interface multiple > > devices. Leave it to a hardware guy to assume that > > the software would be simple. 8-( > > Interfacing to I2C on the Linux side _is_ simple. It's doing it from > the real-time side that's harder. HAL doesn't really have a good > concept for a "shared bus" that lets you make one generic I2C > driver and > then use it to talk to multiple targets (insuring things like one > transaction completes before another one begins), and it's kind of > cumbersome to make one when you can't pass around anything more than > simple signals. > > So it depends a bit on what you're trying to talk to. If it's not > critical real-time, a userland HAL component can leverage the > Linux I2C > support and probably be written in a few lines of Python. The I2C > module I'm referring to above is an accelerometer for a self-balancing > robot, so minimal latency between it and the HAL control loop is > important which means I'll be coding a real-time driver to talk to it. > > -- > Charles Steinkuehler > [email protected] > > Perhaps this is a good case for expanding the available HAL signal types to include a type that can contain a complete I2C transfer. Technically there is no limit to the length of an I2C transfer, but if we constrain it to not more than, lets say 64 bits, then it would handle most devices that I am aware of and data passed by the signal would still be larger than the FLOAT type.
A HAL component could be created to manage the I2C port and present a fixed number of access portals to other HAL components. While not optimal, it might just be enough to be workable. It would need to have handshake and error signals for each portal. Steve Stallings PMDX ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
