• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 17 subscribers
  • Views 834 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.

Additional/Alternative RF4CE Profiles

Andrew19474
Intellectual 780 points

Other Parts Discussed in Thread: REMOTI, CC2530, CC2531

I am new to RF4CE.  I appologise and hope some one can advise.

I understand, as well the CERC profile and support for vendor specific commands within a profile, that RF4CE supports the implementation of additional/alternative whole profiles, but presumably each profile has the same general form.

My question is, can any one advise whether, at least in principle, the PC RF4CE target simulation or boards provided by RemoTI CC2530 Development Kit might support the design and implementation or at least the simulation of such additional/alternative profiles.

Thank you.

  • 0
    Intellectual 780 points

    Hi,

    Thank you so much for your advice.

    To clarify please see attached RF4CE layered diagaram.  I want to communicate RF4CE between nodes controller and target or target and target acting as controller but using for example a new profile I shall implemented, say Profile 0x02 in the diagram, rather than CERC.

    To experiment with this idea are you suggesting that multiple CC2531 USB dongles would provide sufficient functionality and support?  I was originally considering CC2533DK-RF4CE-BA, but substituting the remote control for a CC2530 chip and loading that with the RemoTI stack, since (though this is a separate discussion to the one here) I have already discussed with some one else the possibility of implementing some kind of multi-stack functionality on CC2530.

    Is CC2531 essentially the same as CC2530 with additional features?  Didn't see the initials RNP before.  Is RNP, RemoTI Network Processor, of which CC2530 and CC2531, once loaded with the RemoTI stack and running software, are just two examples?  What's the difference between this and the HID Dongle project?

    Thank you again for your advice.

    Andrew

  • 0 in reply to Andrew19474
    TI__Mastermind 19350 points

    The CC2530 and CC2531 indeed have different features (the most notable being of course the USB) - please review their datasheet.

    The RemoTI protocol stack for RF4CE contains sample applications to give users a head-start to developing their own solution. Some of these sample applications have both the CC2530 and CC2531 as a target build in the IAR project. HID only has the CC2531 as a target build because it is the only one supporting USB, and HID is a USB-compliant protocol.

    As you learn in the "RemoTI HID Dongle Developer's Guide", the sample application supports 3 HID endpoints:

    3.5        HID Interfaces

    HID dongle interfaces can be found from usb_hid_descriptor.s51 file.

    RemoTI HID dongle defines three interfaces: a keyboard interface, a consumer control device interface and a vendor specific interface. Besides the control end-point (end-point 0), the USB end-point 1 is used as keyboard input, the end-point 2 is used for consumer control device input and the end-point 3 is used for vendor specific commands both as input and output.

    The RNP, RemoTI Network Processor, is a sample application of how to abstract all of the processing related to RF4CE to a separate chip - thus, the RNP would be part of a 2-chip solution. A device would have a master CPU that controls the end user functionality and exercises over-the-air (OTA) command and control via UART, SPI, or USB control of the network processor slave. The USB control is via the CDC and appears as a virtual COM port, so it is essentially like the UART transport.