Back

Comments 8

  • Arduino I2C Multi-Master Approach - Why and How 6 months ago

    Pedro,

    Thank you. I am glad you found this useful.

    Thanks, Chip

  • Arduino I2C Multi-Master Approach - Why and How over 1 year ago

    Tego, You are correct that using a rising or falling edge would be more precise and would eliminate contention. You had suggested an interrupt to do this but, I am not sure how to implement this given that the clock is running at about 32kHz. That interrupt would beed to be serviced and would eat a lot of clock cycles. I would be open to any suggestions you might have on making this work.

    I have build a deployed about a dozen of these sensors and they are running continuously. Collectively, they have years of operation and they have proven to be very reliable. I will say, however, that most of the issues that do require a watchdog timer reset are caused by the i2c bus. It may be contention or a hung request but, each device hangs only about once every 60 days so I have chosen to focus my efforts elsewhere and let the watchdog do its work. This may not be acceptable in some applications but it works for me.

    I would be interested in any suggestions you might have on a edge triggered approach.

    Thanks,

    Chip

  • Arduino I2C Multi-Master Approach - Why and How over 1 year ago

    Tego,

    Thanks for taking a look. The issue you raise came up when I was working on this. The solution is to make a simple rule - each master is required to take the clock only on their assigned clock logic level. One is assigned to Clock LOW and the other to Clock HIGH.

    In this example, the SImblee can only take the bus on Clock LOW:
    //Serial.println("Simblee has the Bus");
    while(digitalRead(SQWPin)) {} // The Simblee will wait until the SQW pin goes low

    While the Arduino can only take the bus when Clock is HIGH.

    Does this address the issue you raised?

    Thanks,

    Chip

  • Arduino I2C Multi-Master Approach - Why and How about 2 years ago

    Anton,
    Yes, you could use one line for both clock and busy. But, I am concerned about the edge case of two "masters" both taking control at the same time. I also wanted to make the code as simple as possible.

    To that end, one change I made from the example code in this article was to use the digitalWriteFast library to speed all the reads and writes.

    Thanks, Chip

  • Arduino I2C Multi-Master Approach - Why and How about 2 years ago

    PaJaSoft,
    Thanks for the question. I guess I can think of two ways to make this happen.

    First, let me recap for those who are reading from here. This project shows how you can arbitrate between two masters on an i2c bus running the Wire.h library. I have been using this approach with great success in my projects. The model has two shared lines - a 32k square wave "clock" line, and an open-drain "talk" line. The question is how this could be extended beyond two masters.

    As you alluded to in your question, older networking technologies like Token Ring were connected to a common wire and had to take turns talking on the network. The way they did this was with a "token" which was passed from one computer to the next and you can think of this simply as a rule like - "you can't hold the token for longer than xxx" AND "you can't talk unless you are holding the token".

    As you suspected, you could use this model to connect more masters to the i2c bus as long as you wrote code on each master that ensured they would not hold the token for more than some reasonable amount of time. The issue with this approach would be to make sure that two or more devices would not grab the bus at the same time. You could solve this by implementing this approach:
    1) Test the bus to see if the token is taken (ie "talk" is HIGH)
    2) Wait until you see the "clock" line go HIGH
    3) Delay a fixed - unique time assigned to each Master
    4) Test the "talk" line again and, if it is still low, take the token by setting it "HIGH".
    I believe this approach would work as long as your application can tolerate the i2c latency that this approach would introduce.

    This approach would not require you to change the wiring of this circuit but it would require a more complex "take the bus" function. Still quite doable. If you implement this, please share.

    Thanks for reading my article,

    Chip

  • Garage Parking Sensor about 2 years ago

    Michael,
    Thank you for your comments, I am glad you liked the project. I have added a link to the RGB LEDs - thank you for catching that.

    I do think this approach would work when ceiling mounted just as you described. Here are a few thoughts.

    1) Cars reflect ultrasonic signals so using the more expensive Maxbotix sensors will be even more important as they can be "chained" to prevent cross-talk.
    2) You will need to "tune" the signal so it tells you when the car is pulled in the right distance. If you hood or car top is near horizontal, you may need to adjust this carefully. You may also try detecting where the hood meets the front window but, experimentation will be required as the return signal will be weak.

    3) You can place the sensors on the roof of your garage, but for the tuning above and for the indicator lights, you will need to place the Arduino somewhere where you can get to it.
    4) You could use sound instead of LEDs to signal with a sound beeping more quickly and going steady when the car is properly parked. It could then turn off after 10 seconds of no movement.

    Have fun, and if you build this, I would love to see what you came up with.

    Chip

  • Arduino Control Center over 3 years ago

    Drew, Wow, you have good eyes. I had to create a custom footprint for the N and P MOSFETs and I made a mistake in this v3 rev. What you see is a wire across the four pins (since they are all connected anyway) to make up for my mistake. It works fine but I fixed the footprint in the v3a board files and OSHPark shared project.

  • IoT Garage Door Monitor/Opener with Finger Print Scanner over 3 years ago

    Very cool and ambitious project. I think I may repurpose one of my CC3000 WiFi Data Loggers for this purpose. One issue I found which could be causing some of your CC3000 lock-ups is the momentary power demands of that board when transmitting may be more than your power supply can meet causing a short dip in voltage.

Add projectSign up / Login