• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 34 subscribers
  • Views 5758 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

1-Wire Communication with Tiva (TM4C1294NCPDT)

Zvi Vered
Expert 2000 points
Other Parts Discussed in Thread: TM4C1294NCPDT, TM4C129XNCZAD, TM4C129XKCZAD

Hello,

I want to connect MAXIM's DS2502-E48 to a GPIO for getting MAC address from external device.

The  DS2502-E48  with one wire protocol described in: http://www.maximintegrated.com/app-notes/index.mvp/id/126

Is it possible to use implement "one wire protocol" with TI's TM4C1294NCPDT?

Can you provide a sample code ?

Thanks,

Zvika  

  • 0
    TI__Guru 58650 points

    Hi Zvika,

    There is an application note that should help you get going in the right direction: http://www.ti.com/lit/an/spma057a/spma057a.pdf

    Regards,

    Sue

  • 0 in reply to Sue Cozart
    Guru 117855 points

    @ Sue,

    Once again - Ms Cozart has gone substantially, "above & beyond."  That is one amazingly focused - superbly detailed - and Nov '13 updated, Ap Note.   Requester should be more than pleased.  (if he's not - our group sure is...)

    Saw this request - you/I have surely used several such, "1-Wire" devices in the past - and I was about to post our, "Timer-cobbled" 1-Wire solution.

    Let the record show that cb1 trash now includes, "Timer-cobbled 1-Wire" - replaced by your suggestion... Thank you, Sue.

  • 0 in reply to cb1_mobile
    TI__Guru 58650 points

    cb1 - you are too kind.  I merely a posted a link.  The hard work was done by the engineer on our team who wrote the document.  I appreciate that you were preparing to help Zvika - you are always ready to help!  

    Sue

  • 0 in reply to Sue Cozart
    Guru 117855 points

    Thank you, Sue.  Would that such "readiness" better include skill/precision...  (a la S.C.)

    Kudos to the engineer/writer - we were impressed by the number & depth of 1-Wire functions included...

  • 0 in reply to Sue Cozart
    Prodigy 20 points

    The application note talks about the 1-wire module, but as far as I can tell the TM4C1294NCPDT does not have one.  Am I right in thinking that the Tivaware library would not work on this MCU?

  • 0 in reply to Adrian Chan1
    TI__Guru**** 244400 points

    Hello Adrian,

    Yes, that is correct. the 1-wire is supported only on the TM4C129XNCZAD and TM4C129XKCZAD devices.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Guru 47900 points

    For completeness the, "One Wire" mode has long been used by far simpler MCUs - most (likely all) of which had no, "built-in/formal" one-wire peripheral module.

    As this "one-wire" accommodates multiple devices, "on the bus" the gpio pin selected must be placed in, "Open Drain" mode when transmission is attempted.  (this so that bus contention is avoided - and is a practice followed by the - far more popular - I2C bus)

    Suggest the referenced APP Note's code be reviewed to see, "how, when and where" any such one-wire, "module" is in use.  Your challenge then is to replace those code segments with straight-forward, gpio code which enables your selected, one-wire gpio pin, to properly transition from input to, "open-drain output."   A standard MCU timer can provide the required bit timing/spacing if such is not included w/in the APP Note.

    Again - "module-free" one-wire usage has long been the most popular (and often the only) means to, "1-wire connect."

  • 0 in reply to Amit Ashara
    Intellectual 390 points
    As mentioned in this discussion, the TM4C1294NCPDT device does not support the 1-wire module. So, I am trying to code the 1-wire protocol on the TM4C1294NCPDT using a timer to generate the necessary time slots for both reading and writing.

    When I try, for instance, to get the 64-bit ROM code, I write the 0x33 Read ROM command. Then, for each of the 64 bits to be read, I pull down the bus by setting the GPIO pin as output and writing a 0. Then the bus is released in order for the device to issue the requested data by setting the GPIO pin as input. I think the device (MAX31820 ambient temperature sensor) understands the Read ROM command and acknowledges the read time slots because I see in my oscillator the different values of the 64 bits.

    The problem is that what I see in the oscillator does not match with the bit values I read. For reading after releasing the bus master, I set a timer to one shot mode and 5 µs period and I sample the bus 10 times so that I read for 50 µs (approximately). The problem is that sometimes I see unexpected behavior such as reading values, as 0110101101 or 1001000110, that make no sense to me. FYI, for the first sequence I see a clear 0 in my oscillator for 30µs, and the second sequence corresponds to a 1 as the bus is pulled down only 10 µs.

    I know that it is recommended to give the code so as to analyze if there are mistakes, but I rather prefer to ask if it is really possible to implement the 1-wire protocol on the TM4C1294NCPDT by smartly configuring a GPIO as input and output alternatively. Can a GPIO pin pass from output mode to input mode within 5µs?

    I'm using the GPIO pin L3 and the bus is read as:
    uint32_t ui32Val= ROM_GPIOPinRead (GPIO_PORTL_BASE, GPIO_PIN_3);
    uint8_t ui8Val= ui32Val & 0xFF; // keeping only the last 8 bits
    ui8Val= ui8Val >> 3; // shifting bit 3 of the byte that represents GPIO port pin 3
    uint8_t ui8Res= ui8Val & 0x01;

    Thank you.
  • 0 in reply to Gello
    TI__Guru**** 244400 points
    Hello Gello,

    Yes, a GPIO Pin can pass from output to input mode in 5us. However I would suggest something better. Instead of using the GPIO Pin Output mode use it in Open Drain mode relying on the external Pull Up resistor. This way the only action that needs to be performed is to drive the pin 0 and 1 and on a read the status from the slave device can be received.

    Regards
    Amit
  • 0 in reply to Gello
    Expert 2415 points

    As a diversion, I suggest taking a look at the following document, which details the use of a UART module with some additional components to create a 1-wire interface. I have to admit this is (still) on my todo list, so I can only recommend it as a solution that seems simple enough on paper. Combine DMA operation for the TM4C UART and you could be able to get away with very little CPU overhead... (though DMA effort should not be present on the first tries, KISS)

    www.maximintegrated.com/.../214

  • 0 in reply to Veikko Immonen
    Guru 47900 points

    Veikko Immonen said:
    DMA effort should not be present on the first tries,..... KISS)

    Thank you Veikko for this.   (long live KISS!)

    I can report that on both (departed) LM3S & LX4F clients of ours have reported success - using the link which Veikko has kindly provided.  IIRC - there was one minor addition - which raised throughput - yet KISS dictates that be "held" until initial success is at hand...

  • 0 in reply to Veikko Immonen
    Intellectual 390 points

    Thank you, Amit and Veikko, for your answers. I really appreciate them.

    The problem is that I am quite new to this MCU world and I do not always understand the answers. That's why I do not see, Amit, the difference between what I do and what I propose, except for configuring the GPIO pin as open drain when working in the output mode with the following line (if I am not wrong):

    HWREG (GPIO_PORTL_BASE + 0x50C)= GPIO_PIN_3; // GPIOOD: 0x50C

    What I do to generate the reading time slots is to switch from output mode (necessary to pull down the bus) to input mode (to sample the bus). Amit, could you please confirm that this switch is also needed for your solution? 

    Veikko, I cannot implement your solution because the pin I reserve for the 1-wire protocol cannot be configured as UART and unfortunately I cannot change it. But it can certainly help other readers interested in this topic.

    What I really find astonishing is that I always read the same values even if I found them senseless. These unexpected sequences, such as 0110101101 or 1001000110, are not random samples. That's why I may be doing something wrong. For instance, (maybe simple question for an expert), if I just enable one pin of port L (L3), why do I read values such as 0xf8 or 0x60? I should only read either 0x08 or 0x00, shouldn't I? If I get 0xf8, does it mean that the MCU read 1 in port pins 4 to 7?

    uint32_t ui32Val= ROM_GPIOPinRead (GPIO_PORTL_BASE, GPIO_PIN_3);

    Regards.

    PS: for those who may be interested in open drain mode and tri-state, I found the following two posts that may help:

    e2e.ti.com/.../1297016
    e2e.ti.com/.../240220

  • 0 in reply to Gello
    TI__Guru**** 244400 points
    Hello Gello,

    Open Drain allows for the bus to be driven by both sides without facing a bus contention, while when switching modes there could be a contention if one side terminated with driving a 1 and other side started driving 0.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 390 points
    Hello Amit,

    Thanks again for your clarifying answer.
    Now it works fine, there was just a mistake in the way I was saving the sampled data.
    Regards
  • 0 in reply to Gello
    TI__Guru**** 244400 points
    Hello Gello

    Can you please elaborate on the fact that it was a mistake in the way the data was being saved?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 390 points

    I'm using a buffer to save data:

    int8_t pi8Val[64*5];

    That is, I get 5 samples of the same bit with a period of 4µs after releasing the bus, and I do so for the 64 bits of the ROM code.

    Two rocky mistakes:

    1) I didn't initialize the buffer (pi8Val) to known value, f.i. 0

    2) data was saved according to the following line:

    pi8Val[idx + ui8NoS*bdx]= ROM_GPIOPinRead (GPIO_PORTL_BASE, GPIO_PIN_3);

    where ui8NoS is the number of samples per bit, that is 5; idx is the iterator for the ui8NoS samples, and bdx is the iterator for the 64 samples. The error was that idx was never reset after reading a bit. That's why the first bit was right, but the others had no sense.

    Regards