Skip to content

need TWI library! #1

Description

@bombasticbob

write hardware TWI library compatible with existing library

Activity

  1. self-assigned this
    on Oct 6, 2014
  2. bombasticbob commented on Oct 12, 2014

    @bombasticbob
    ContributorAuthor

    there is sample TWI code in the ATMel Studio collection. There is also another implementation of the entire arduino IDE out there, perhaps with a TWI library, and some earlier code that I was working on almost a year ago (that didn't work for TWIE, but that may be broken on the 64d4). need to implement a way of testing it reliably, both as a client AND as a master, possibly using an Arduin Uno.

  3. bombasticbob commented on Oct 13, 2014

    @bombasticbob
    ContributorAuthor

    There is a good soft TWI implementation. this can be adapted as well for 'universal' TWI on ANY pair of pins. Link to github resource HERE.

  4. bombasticbob commented on Mar 13, 2015

    @bombasticbob
    ContributorAuthor

    "work in progress" TWI, basically a status update.

  5. bombasticbob commented on Dec 23, 2016

    @bombasticbob
    ContributorAuthor

    additional "work in progress", low level TWI support working for master mode only, via apis in the XWire/utility directory. Note that TWIC and TWIE both work.

    The new TWI implementation requires that you pass the address of the TWI port base as a 'TWI_t *' to all of the 'twi_' API functions. A modification to this (for compatibility with earlier Arduino libs for ATMega) might be to use the 'TWI_DEFAULT' for the 'twi_' APIs and then add new ones that let you support multiple TWI ports.

    In the current (work in progress) you would cal 'twi_init(&(TWIC))' for example.

    Additionally, twi_readFrom() re-defines the last parameter as a timeout, so that you can read for a period of time and then return [this avoids blocking forever on error]. Normal TWI read takes about a millisecond for up to a handful of bytes. If you specify a timeout of 10 milliseconds, a failed read operation [i.e. device not responding] will return back with "fewer than requested" bytes, indicating the timeout.

    Again, it's a work in progress, but appears to be working 'as-is' for master mode. It uses ISRs and multiple "context buffers" for the different TWI ports. This may use up too much memory when only one port is needed but 4 are available [for example], and so modifications to this method should be done to deal with that problem.

  6. bombasticbob commented on Dec 27, 2016

    @bombasticbob
    ContributorAuthor

    status: currently "working" with minor caveats

    1. The MASTER works with a MAX31725, sending an 'index' byte and reading registers.

    2. When connecting TWIC and TWIE both to the MAX31725 at the same time, the low-level utilities in twi.c are able to read/write both to the slave TWIE and to the MAX31725, by address, from TWIC as the master.

    3. When reading from TWIE, however, if the slave does not end the transaction, it does not recognize STOP nor a re-START [it gets 'data' interrupts instead]. But if you read ALL of the available data via the master, and the slave sends the 'transaction completed' command, it works fine.

    So, even though the protocol appears to work perfectly with the actual 2-wire slave device (the MAX31725) as controlled by the master, the TWI slave on the XMega doesn't handle the stop/re-start sequence correctly when it's in "read mode". Still, it's "working" for the most part and can just be fixed later on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions