This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SMBus and Address Resolution Protocol (ARP) between two MSP430 boards

Other Parts Discussed in Thread: MSP430F5338, MSP430F5172

Hello, 

I was wondering if there were example codes, solutions, etc. or if the following is even possible.
I am trying to achieve communication from one master board to many slave boards. All slave boards have the same default address, but I would like to be able to dynamically allocate a different address to each slave board so that I can communicate with them individually. I read that there is such a protocol called Address Resolution Protocol (ARP) that can be utilized with the MSP430. 

Is this protocol realizable between a master MSP430 and multiple slave MSP430's? (Specifically my master board is MSP430F5338 and the slave boards are MSP430F5172) 

Thank you,
Jon

  • Hello Jonathan,

    Sadly we do not include any ARP software solutions with our MSP430 SMBus Library. If you would like to dynamically allocate an address for each MSP430 slave device then you will have to create your own search algorithm. You can follow a similar algorithm that Maxim 1-Wire devices use to differentiate between slave devices:

    www.uni-due.de/.../1Wire_Search_App_Note187.pdf
    http://www.ti.com/lit/pdf/spma057
    e2e.ti.com/.../297009

    Basically, each slave device has a unique ROM number that the master identifies by iteratively reading two bits from the slaves and writing the appropriate bit that defines the search path in the enumeration algorithm (thereby setting some slave devices in an idle state while keeping others active) until it is able to uniquely identify a slave device. This process is repeated until all slave devices have been located. You would perform a similar search except you would be requesting TLV die records (Lot/Wafer ID & Die X/Y position) as a unique identifier and then allocating a unique address after a slave has been identified. You will also probably have to use a "reset" GPIO to indicate when the master is ready to re-start the algorithm, in which case all slave devices would need to exit their dormant state and be ready for instructions. This solution will require firmware changes to both the master and slave boards.

    Regards,
    Ryan

  • I see. 

    So, the way I'm understanding this is...
    1. A master requests a "TLV die record" from each slave (which all at this point have the same address) and this "TLV die record" is a unique identifier.
    2. The master can then reprogram a different address to the slave that responds and is left on the bus while all other slaves enter an idle mode.
    3. Then a global "reset" is sent to do this again, while the slave that had responded would no longer respond until all slaves have responded and have been allocated a new address.

    Would you happen to know where I could find example code for something like this?
    And what kind of firmware changes are required?

    Thank you for the response!

  • I think you understand the basics of what would need to be accomplished. TI provides this algorithm for recognizing different 1-wire slave devices in the SPMA057 app report's project files, which uses a DK-TM4C129X. The firmware would have to be ported for the master MSP430 and adapt this algorithm for communicating with I2C slave devices instead of 1-wire protocol. Expecting a TLV die record instead of a ROM number shouldn't be too hard since they can be of similar size. The slave firmware would require additional work to recognize an enumeration request and send the correct requested bits, with the end goal of either going idle or re-assigning its slave address.

    Regards,
    Ryan
  • What does it mean to have the firmware ported for the master MSP430?
    I think I know the processes well, but the practically applying, coding, and implementing the process is limited.

  • Firmware porting refers to taking code developed for one MCU (TM4C129X) and altering it so that it can operate on a different MCU (MSP430). The process can be simple or complex depending on the similarities between microcontroller environments and functionality/operation.

    Regards,
    Ryan
  • Got it. Thank you! I've been learning a lot these past few days.

**Attention** This is a public forum