• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 142 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1352R: Customizing CUI for I2C use

SmartEnrg
Expert 1145 points
Part Number: CC1352R

Hi,

Would it be possible to use alternate serial interface (e.g. I2C, SPI) - instead of UART to realize CUI (Common User Interface)?

Here I'm looking at cui.c/.h - is it as simple as substituting serial bus interface logic - upstream (Tx) and downstream (Rx) from 
gUartRxBuffer, gUartTxBuffer. Essentially replacing UartReadCallback, UartWriteCallback and CUI_writeString - would that do 
the trick or there's more to it?

Please advise. Thanks.

  • 0
    TI__Guru 58425 points

    Hi,

    Possible, sure, question is how easy it would me. You would likely have to re-write the logic to fit your need as UART and I2C does not really behave in the same manner here. 

    May I ask why you would like to integrate I2C into CUI in the first place? Is is mostly a convenient layer for DMM examples. What feature are you trying to leverage?

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1145 points

    Thanks M-W,

    "May I ask why you would like to integrate I2C into CUI in the first place?"
    I have two host processors communicating with this DMM node, so UART interface won't be as practical.

    "Is is mostly a convenient layer for DMM examples. What feature are you trying to leverage?"
    If I understand CUI documentation correctly - it mimics LCD interface; I am hoping to use CUI API for 
    access to collector functionality (n/w provisioning, sensor config, data access etc.)

    New, related question - does the (DMM collector) BLE interface (provisioning etc) use same CUI API?

    Best,
    SE

  • 0 in reply to SmartEnrg
    TI__Guru 58425 points

    Hi SE,

    Does the processors both interact with all stacks at the same time? The reason I ask this is because I suspect that trying to leverage the CUI here will end up being more effort then simply implementing the communication your self.

    While CUI might mimic the LCD interface, this is more in the sense of simplifying writing out data in a visually simple way (the two applications does not need to mind row offsets etc). By the brief explanation you left above, this does not seem to be what you are actually after.

    To clarify, you could for sure try to modify CUI to suit your need but most likely you are better of implementing just what you need, both from a RAM/FLASH footprint and development time. In the end, CUI could be considered an abstraction to mask away thread-to-thread interaction in the examples. 

    In your application, assuming you have a Collector and a BLE side, how do you intend to interface to this from the two external processors (who talks to who etc.).

    With CUI API, do you mean "input options"? It should in that case be similar but it could also differ depending on the stack in question (you never specified the other side).