element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Single-Board Computers
  • Products
  • Dev Tools
  • Single-Board Computers
  • More
  • Cancel
Single-Board Computers
Forum I2C Slave?
  • Blog
  • Forum
  • Documents
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Single-Board Computers to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Not Answered
  • Replies 14 replies
  • Subscribers 59 subscribers
  • Views 3336 views
  • Users 0 members are here
Related

I2C Slave?

Former Member
Former Member over 10 years ago

Hi

I need to communicate with a I2C master with a BeagleBone black rev3 (Debian) as a slave.

I have search over the internet but not find anything. I'm new with BeagleBone.

I find a lot of example for master but not for the slave.

Can somebody please help me?

 

Regards Stefan

  • Sign in to reply
  • Cancel

Top Replies

  • Former Member
    Former Member over 10 years ago in reply to shabaz +1
    Thanks for the responses, Gary and shabaz! I had already done some surface level searches for Linux I2C drivers that also do slave-mode but didn't come up with anything conclusive. And I had almost forgot…
  • gdstew
    gdstew over 10 years ago in reply to clem57 +1
    "if you let the master "broadcast" a welcome message to see who responds with an address" The address used for this in the I2C specification is the general call address. I think your are correct that this…
  • Former Member
    Former Member over 10 years ago +1
    @ benett Linux 3.19 provides I2C slave mode kernel driver.
  • clem57
    0 clem57 over 10 years ago

    @benett

    May I ask what would the master be? Will there be any other I2C in the design on the same interface? How will the BBB respond to the clock from the master? One way could be to have a forever running service. Another would be to sense interrupt and respond(a bit more difficult). How much coding do you want to do or are you looking for already done code? A hardware hookup picture can help me to suggest some coding...

     

    Clem

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Former Member
    0 Former Member over 10 years ago in reply to clem57

    Hi

    There will only be one master and one slave. I have no control over the master, it sends a "ping" and listen to a answer from the slave with right address.

    After that normal I2C operation.

    I found this code for the Arduino and that is what I need for BeagleBone, a library. http://arduino.cc/en/Tutorial/MasterWriter

    If someone know what I can find it, I will be happy. image

    // Wire Slave Receiver
    // by Nicholas Zambetti <http://www.zambetti.com>
    
    // Demonstrates use of the Wire library
    // Receives data as an I2C/TWI slave device
    // Refer to the "Wire Master Writer" example for use with this
    
    // Created 29 March 2006
    
    // This example code is in the public domain.
    
    
    #include <Wire.h>
    
    void setup()
    {
      Wire.begin(4); // join i2c bus with address #4
      Wire.onReceive(receiveEvent); // register event
      Serial.begin(9600); // start serial for output
    }
    
    void loop()
    {
      delay(100);
    }
    
    // function that executes whenever data is received from master
    // this function is registered as an event, see setup()
    void receiveEvent(int howMany)
    {
      while(1 < Wire.available()) // loop through all but the last
      {
      char c = Wire.read(); // receive byte as a character
      Serial.print(c); // print the character
      }
      int x = Wire.read(); // receive byte as an integer
      Serial.println(x); // print the integer
    }

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • clem57
    0 clem57 over 10 years ago in reply to Former Member

    I am getting a BeagleBone Black any day now. When I have it, I can explore some choices like I2C.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Former Member
    0 Former Member over 10 years ago

    I'd also like to know this!

     

    For my project, I'd like to have the BBB rev C receive I2C (TWI) messages from up to about 25 different AVR microcontrollers on the bus. I just assumed that the BBB was capable of I2C slave mode because it said it "supports I2C" but now I'm not sure -- I can't find any examples or documentation.

     

    For my application, they could all be masters in a multi-master layout, or they could switch modes -- BBB(slave) listen to all others (multi-master) then switch to the traditional I2C BBB(master) speak to all others (slaves).

     

    Let me know what you find!

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • gdstew
    0 gdstew over 10 years ago

    The I2C hardware on the AM3358/59 SoC  on the BeagleBone Black is perfectly capable of operating in slave mode. The real question is do any of the Linux I2C drivers support it ?

    If they do all you need to do is figure out how to open the I2C interface in slave mode. If they do not the only recourse is to either write your own I2C driver or find someone that will

    do it for you.

     

    I would be surprised if there were no support for a slave mode in the drivers. While it is fairly unusual for I2C to be used this way on a SBC, it is not unheard of. There is another

    forum member, shabaz, that has done a lot of experimenting with the BeagleBone Black so you might try to contact him to see if he knows anything about this.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • shabaz
    0 shabaz over 10 years ago in reply to gdstew

    I must admit I've never used a microcontroller/processor in slave mode, this is quite unusual. Multi-master mode is supported, but this is something I'm not familiar with either.

    The details are in the AM3359 tech docs of course, but as you say I don't know if the standard I2C drivers support it. It may need some custom driver. An easier option would be to use

    a different interface, i.e. change the AVR code.

    Or you could bit-bang (easier than writing a driver but will still take you some effort if you're new to it. If you want to try this, search for PRU examples).

    I once wrote a single-wire interface which allowed chaining of multiple devices in/out (much like the WS2811 or 'neopixel' style LEDs do) for PIC devices, but I don't have the code for that

    any more.

    So sorry Greg, but this is unusual enough that I don't have an answer. What exactly are you trying to do? (End use-case). Are these 25 devices over some distance?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Former Member
    0 Former Member over 10 years ago in reply to shabaz

    Thanks for the responses, Gary and shabaz! I had already done some surface level searches for Linux I2C drivers that also do slave-mode but didn't come up with anything conclusive. And I had almost forgot about the PRU since purchasing the BBB, but my project isn't necessarily time-sensitive enough to justify the extra effort. Both are good to keep in mind for later optimizations.

     

    My project: I'm trying to have the BBB act as the main intelligence to a connected grid of 2-3 inch "blocks" controlled by AVRs. The blocks could be ordered in different ways, say, 5x5 or 3x8 or even mixed-length rows, but the likely max distance should be less than 3 feet or so which shouldn't be too long (I hope). The idea was I could hard-code an I2C address for the BBB into each AVR block. Once connected, the microcontroller could then take control (become master) of the shared I2C bus and address the BBB (as slave) to pass along its own I2C address, effectively allowing the BBB to collect the addresses of all the blocks present. Once the BBB (now as master) has all the block addresses, it can address each AVR (now switched to slave) individually over the shared I2C to send commands, read other values, etc.

     

    Not all blocks are required and they will be disconnected and reconnected while the full system is running. Also, order matters - so I wanted each AVR address to dynamically reflect its "location" so I didn't want to just assign unique IDs to each AVR manually. (I've worked out dynamic location separately from the I2C stuff). Nor did I want to try to keep track of the IDs of 25+ nearly-identical blocks. I really liked the idea of each block "introducing" itself once connected and I thought the 2-way multi-master I2C common bus was a good and easy solution.

     

    What I might do for now, at least to get a first working prototype started, is fairly regularly poll all 127 or so possible I2C addresses from the BBB and see who responds. This means the protocol is the more traditional 1-master, several-slaves I2C and should at least get me started. It's not as cleanly interrupt-driven like the "introductions" would have been, but it'll get me to the next development stage quicker.

     

    Thanks again for the responses! I really appreciate the feedback.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • clem57
    0 clem57 over 10 years ago in reply to Former Member

    Now it is clear! The switching of master slave in the relationship is not necessary if you let the master "broadcast" a welcome message to see who responds with an address. The broadcast would happen at say 5 second intervals. Reserve address 127 as special for only this purpose. Then a slave needs two address to know: itself and the special 127 address. This is how routing occurs.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • gdstew
    0 gdstew over 10 years ago in reply to clem57

    "if you let the master "broadcast" a welcome message to see who responds with an address"

     

    The address used for this in the I2C specification is the general call address. I think your are correct that this is what Greg is looking for and will simplify

    what he is trying to do.

     

    Greg, if you haven't already I suggest you Google UM10204 which is the document number for the NXP Semiconductors pdf of the official I2C specification.

    The current version is revision 6, earlier versions are also available. NXP Semiconductor used to to be Phillips and they were the originators of the I2C bus.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • clem57
    0 clem57 over 10 years ago in reply to gdstew

    UM10204 I2C -bus specification and user manual

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube