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.

CC3100BOOST: Help with setting wireless radio connection between two CC1310 launchpads

Part Number: CC3100BOOST
Other Parts Discussed in Thread: CC1310, CC3100, CC3120, CC3200,

Hello all,

I am working on a project and I am trying to connect my CC1310 launchpad to the internet. I have purchased a CC3100 booster pack that powers on when I connect it to my CC1310 launchpad. I followed the TI tutorial on how to turn the access point, it said to hold the switch 1 button and keep holding then press and release switch 3 then release switch 1. On the tutorial video, a connection appeared in the available WIFI connections that said simple link. In my case, nothing seemed to happen when I did this combination of buttons. This seems to me like a necessary first step in order to try and achieve what I am trying to do. After that what do I need to do to test the WIFI on my device? I would appreciate any help on this thank you.

Neil Mustafa.

  • I also do not have a CC3100 Emulation board , I thought I would not need it since I have a MCU (CC1310 launchpad) am I wrong to think so?
  • Hi Neil,

    You should look into using the CC3220 instead of the CC3100. Using a CC3220 you can use the ti_154_gateway_ibm example from the SimpleLink SDK 15.4 stack plugin:

    http://www.ti.com/tool/simplelink-sdk-ti-15-4-stack-plugin

    CC3220 15.4 IBM Gateway Readme

    This example shows how you can configure a CC3220 to communicate with a CC1310, and then send the 15.4 data to the cloud. Using the CC3220 Wi-Fi device as the host will be much easier than getting the CC1310 sub-1GHz device to be the host. This is due to the memory limitations on the CC1310.

    If you wanted to use a CC1310 as the host for the CC3100, then you will need to port the Wi-Fi host driver to the CC1310. The CC3100 is a network processor (NWP) only device, and acts as a black box. You need to use the host driver to control it and get it to do useful work. You can look at the CC3100 SDK for examples of how the host driver should be ported. However, I highly recommend that you switch to a CC3220 + CC1310 system.

    Let me know if you need more clarifications on my suggestion, or have further questions.

    Regards,

    Michael

  • Thank you very much, Michael, for your reply. Are there any other advantages in using the CC3220 instead of the CC3100 other than the ti 154 gateway IBM example (by the way I am using AWS)?  What makes the CC3100  with CC1310 more challenging than CC3220 and CC3100? I need to be able to convince my team that it is worth making this purchase in order to get them to do and unfortunately my current knowledge about it I am unable to.


    If I use the CC3100 with the CC1310, can the C3100 be the host or does the CC1310 has to be the host? Also, what are the memory limitations on the CC1310 and the CC3100/CC3220? I truly appreciate you putting the time to reply to my questions. Best regards.

    Neil Mustafa.

  • Hi Neil,

    The CC3100 does not have a general-purpose MCU and cannot be a host. In a CC1310/CC3100 system, the CC1310 must be the host. This is problematic since you will run into extreme memory limitations with such a system. The CC1310 only has 28KB RAM and 128KB of flash. With this memory, you will not only need to run the 15.4 code but will also need to run the CC3100 host driver and the AWS networking code. This is most likely impossible. Furthermore, even it was technically feasible to run all of that on the CC1310, you will have to expend a bit of effort to get everything ported onto the CC1310. The CC3220 has much more memory (256KB RAM, 1MB flash) and all of the AWS and general networking examples are built for it.

    In any case, you cannot use the CC3100 standalone. While there is a method to use the CC3100 with your PC through a CC3100 emuboost, this is just a demo that actually relies on your PC being the host. Without a host, and the host driver running on the host, the CC3100 will not do anything. This is why when you are trying to go through the demos in the CC3100 SDK with it only connected to power, nothing happens. The CC3100 demos explained in the guides and readme files explain how you can use another host MCU, such as the MSP430, to use the CC3100 to connect to an AP/ get the weather/ etc..

    If you have no choice but to get the CC3100 working with the CC1310 as a host, then you should look at the latest wifi plugin as a starting point:
    www.ti.com/.../simplelink-wifi-cc3120-sdk-plugin
    While that plugin is designed for use with the CC3120 and the CC26XX, the porting layer that is used in the plugin should map well to the capabilities of the CC1310. This is since it uses the same drivers as the CC26XX and has very similar hardware and low-level software. Of course, the CC3100 has a different host driver than the CC3120. However, the porting layer is what you will need to provide, and following the CC26xx porting layer should be much easier than taking the MSP430 porting files provided in the CC3100 SDK. Once you have taken this porting layer and integrated it into the CC3100 host driver, you should be able to run the networking examples by copying the code from a CC3100 SDK example into a CC1310 project.

    After you have the basic networking functionality of the CC3100 working, you will need to port the AWS code needed. For connecting to AWS IoT, TI offers the TI AWS IoT Plugin:
    processors.wiki.ti.com/.../AWS_IoT_Development

    This is meant to run on the CC3200 or CC3220, and so you will need to port that code onto the CC1310 + CC3100. This is where you'll likely start to encounter memory issues.

    Once you have all of that completely ported and working on the CC3100 + CC1310, you can start adding your own functionality to the basic AWS platform code. If you were to use the CC3220 + CC1310, you will bypass all of the porting steps. Additionally, I will be able to support you much more on the CC3220 + CC1310 setup, since we have the 15.4 plugin developed for your use case. While the 15.4 plugin ships with an IBM example, it is fairly easy to convert to use AWS. The IBM part of the code should be modular enough to the point that you can replace it with AWS (or any other cloud vendor) without much hassle. For reference on how to convert that example to AWS you can see what I did for the CC3220 thermostat TI design:
    www.ti.com/.../TIDM-1020
    At that page, there are two software release bundles. They are both CC3220 thermostat projects, but the only difference is that one uses IBM and the other uses AWS. You can most likely reuse the code I have for the AWS thermostat for your AWS + 15.4 device.

    I hope this gives you a clearer idea of the options you have, and what you will need to do to get the CC1310 working with AWS.

    Regards,
    Michael
  • Thank you very much for your reply. I am trying to convince my team to switch over to the CC3320 but it is not going very well.
    Do you thing the http_client program under the CC3100 SDK examples could possibly work with the CC1310 and the CC3100Boost ?
    I appreciate the time that you have put in to clarify this for me thanks a lot
  • Hello Mike, 

    I believe my team started considering switching the CC3100 with a CC3220. We have a meeting today and we are going to discuss what our next  couple of next course of actions would be, We are, however , still trying to implement the HTTP_Client software with what we have ( CC1310 Launchpad and CC3100Boost)
    Whenever I make a post about something related it gets deleted even though they are not the same questions and they haven't received answers yet. I would like to know If I could implement HTTP_client from the CC3100 SDK v1.3 linkprocessors.wiki.ti.com/.../CC3100_HTTP_Client with what I have (C3100 and C1300 launchpad) Also would it be possible to connect to a webpage hosted by the cloud using the CC1310 launchpad and CC3100. Thanks a lot Michael.

    Best regards.

    Neil Mustafa.

     

  • Hi Neil,

    It might be possible to get the HTTPClient demo working on the CC1310. However, it will require some porting effort, first on the host driver and then on the application itself.

    For porting the CC3100 host driver, the basic steps are listed in the main page of the SimpleLink API guide, which can be found at <cc3100 sdk path>/cc3100-sdk/docs/simplelink_api/html/index.html.
    You will need to implement device-specific functions such as the SPI read/write, the OS sync objects, and such so that the host driver knows how it can exercise the device-specific features that it needs.
    The most straightforward way to do this would probably be to copy over the CC3100 host driver files from one of the existing examples in the CC3100 SDK to your CC1310 project, and then take a look at the porting files provided in the CC3120 plugin. The CC3120 supports the CC26xx devices as a host, which means if you look at <cc3120 sdk dir>\source\ti\drivers\net\wifi\porting\ you will find a very good example of what CC1310 functions you should use for the SPI drivers, OS functionality, etc..

    Now, the reason why you should move to the CC3220 is because while doing the above steps to port the CC3100 host driver to the CC1310 is possible, it is hard and you will likely not be able to run the HTTP/MQTT/AWS code that you need and the 15.4 code at the same time due to the memory constraints. Using the CC3220 will greatly speed up your project since you don't have to worry about porting the host driver, don't need to worry about the memory constraints, and can use the 15.4 to cloud example that I pointed out for the CC3220.
    Of course, you will still have to do some work to swap out IBM with AWS, but that is vastly less work than trying to implement that solution on the CC1310+CC3100.

    As an aside, the reason why I have been telling you to post in this thread instead of making more threads is that it makes the forum much more readable and searchable if you keep all discussion about the same issue or topic on one thread. If you have more information to contribute, then you can make more posts adding new info to this thread.

    Regards,
    Michael
  • Greetings Michael,

    After discussing our issues of porting and memory with our project mentor. He has decided for us to neglect the cc3100boost and now we are going to use the beagle board black instead.

    Just like in this example.

    Do you think that this is a good solution? I also learned that we are supposed to communicate wi th a webpage that is hosted on the cloud instead of the cloud itself. Thank you.

  • HI Neil,

    Using the beaglebone black should work just fine. The main difference between using a CC3220 + CC1310 and that beaglebone black solution is using Wi-Fi vs. Ethernet. Otherwise, both platforms will allow you to quickly get connected to the cloud.

    Communicating to a webpage should be no problem. That would simply be using HTTP to communicate with your webserver, and that can be easily done with your HTTP library of choice.

    Regards,
    Michael
  • Thank you very much for your reply Michael. Looks like we are going with the beaglebone black. It is convenient since we already have cc1310 launchpads and they have a good guide for it. Do you recommend a good model? Looks like some of them come with 8gb sd card and some of them dont. I will have to find out with model is suitable for our application. I will keep you updated after we made some progress
  • Hi Neil,

    For beaglebone black related questions I advise you create a new thread in the appropriate forum. An engineer with the right expertise will be able to better help you if you made a new thread.

    Regards,
    Michael