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.

RTOS/TIDM-TM4C129XWIFI: switching between CC3100 and Wired Ethernet

Prodigy 250 points

Replies: 5

Views: 1033

Part Number: TIDM-TM4C129XWIFI

Tool/software: TI-RTOS

I am aware that the TM4C TI-RTOS NDK HTTP interface is designed to be compiled for either wired or wireless (simplelink CC3100) interfaces. It wont support both simultaneously.

In our product we wont be running wired and wireless together, but would like to switch between them on demand, without reloading full applications.

We have developed separate firmware builds for each. Each works fine in isolation. The issue is in combining them. 

Before I reinvent the wheel, I want to check if this has been done before, and or take recommendations on how best to proceed.

Thanks

For reference we are using the TM4C129XNCZAD, CC3100, CCSv7, TI-RTOS 2_16_1_14, arm compiler 5_2_9, wolf SSL commercial 3_8_0_1

5 Replies

  • Hi William,
    The stack for wireless is running on the CC3100 while the stack for wire (Ethernet) is running on TM4C. The TM4C is more a host controller when paired with the CC3100 network processor so I think the host side firmware shouldn't be very big. How big is each one of the applications? Can both of them fit inside the TM4C flash so you don't need to reload each application on demand?

    regards,

    Charles

     

  • In reply to Charles Tsai:

    Thanks Charles.
    Each full application is under 300K, so there's plenty of room in flash. I just don't want to manage separate builds. And a separate boot app that runs (jumps to) the appropriate one. 90% of the code is shared, so I wish to keep it all in a single build/binary. Much easier to maintain.
    I am planning on building & linking in, separate HTTP libraries, which then get selected at run time.
    I am just checking to see if this has been done before to save time & avoid dead ends.
  • In reply to William James10:

    Hi William,

    People have gotten both the WiFi and Ethernet to work at the same time. Basically you have to use the lower level WiFi calls (e.g. the sl ones) to avoid repeated functions. You'll potentially need to have the code that is using the WiFi and Ethernet in different files to avoid duplicate macros also.

    Todd

  • In reply to ToddMullanix:

    Thanks Todd,

    It appears I should be able to leave the Ethernet as is, & make a stand alone WiFi HTTPS module/driver. It may require more than a header and make file, but should be straight forward. I repost how it went when done.

    Thanks

  • In reply to William James10:

    It wasn't terrible. Took about 4 days to implement. Still much testing to do though.

    Since all I had to worry about was https, I copied out & modified (renamed a few function groups) for WiFi:

    /ti/tirtos_tivac_2_16_01_14/products/ns_1_11_00_10/packages/ti/net/http/httpcli.c : HTTPCli_ & Ssock_calls
    /ti/tirtos_tivac_2_16_01_14/products/ns_1_11_00_10/packages/ti/net/sntp/sntp.c   : SNTP_ calls
    /ti/tirtos_tivac_2_16_01_14/products/ns_1_11_00_10/packages/ti/net/ssock.c        : Ssock_ calls
    /ti/tirtos_tivac_2_16_01_14/products/ns_1_11_00_10/packages/ti/net/ssock_sl.c    : Ssock_ calls
    /ti/tirtos_tivac_2_16_01_14/products/ns_1_11_00_10/packages/ti/net/tls_sl.c         : TLS_ calls

    Then had lots of fun with their headers.

    To use it, I set up some function pointers

    typedef void (*fpHTTPCli_Params_init)(HTTPCli_Params *params);

    ...

    typedef struct {
        fpHTTPCli_Params_init           pHTTPCli_Params_init;

    ...

    HTTPCLI_FXNS httpcli_NDK_fxns = {
        HTTPCli_Params_init,

    ...

    HTTPCLI_FXNS httpcli_SL_fxns = {
        HTTPCli_SL_Params_init,

    Then tweaked existing code to pick one:

     PHTTPCLI_FXNS phttpcli_fxns;    = &httpcli_NDK_fxns;

    and use it:

    phttpcli_fxns->pHTTPCli_Params_init(&params);

    EZ-PZ. except for the fun with the includes.

    The build still uses all the NDK EMAC Wolf cfg settings along with NET_NDK global set. With only the HTTPS for the CC3100 routed directly to the chip.

    Now I can boot up both interfaces, and post/reply out either. Could probably do both simultaneously but that's not a requirement. So I'm not gonna try.

    Thanks for the pointers.

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.