network_config.json Structure

Root-Level Fields

These keys are mainly for documentation and traceability. The generator’s required input is networkStack; other root keys do not change code generation today but help teams know which file and revision they are editing.

Each networkStack[] Object

Think of each array element as a complete “network personality”: middleware path, optional Cyclone/lwIP config header path, stack init include, DHCP/DNS toggles, and the interface list. When you switch products, you often flip use flags so the same file can describe multiple targets while only one is compiled in.

How Interfaces Are Filtered

The generator does not merge stacks: inactive stacks are skipped entirely. Inside the active stack, each interface row must opt in with use: true. Rows with use: false (or missing use treated as false by convention—always set it explicitly) are omitted from NET_INTERFACE_COUNT and from networkServiceStartInterfaces().

flowchart TB
  S["networkStack[i]"]
  S --> U{"use == true?"}
  U -->|first match| I["interfaces"]
  U -->|false| Skip["ignored"]
  I --> E["ethInterfaces[]"]
  I --> G["gsmInterfaces[]"]
  E --> E1{"per item use?"}
  G --> G1{"per item use?"}
  E1 -->|true| EH["Ethernet macros + order"]
  G1 -->|true| GH["PPP macros + order"]
              

Global interface indices increment from zero: all active Ethernet entries first (in array order), then all active PPP entries. NET_INTERFACE_COUNT is the sum of those two counts.

Ethernet — ethInterfaces

Each active entry describes one logical Ethernet link: Linux interface name, static IP fields or DHCP behaviour (depending on stack), hostname, MAC, and for embedded Cyclone builds, nicDriver with driverConfig for SPI and external interrupt lines. The generator maps ethAppManagerPath (or legacy appManager) to an #include, and the ethAppManager*Function strings to *_APP_MANAGER_*_FUNCTION macros.

If there is only one active Ethernet interface, macros use the ETH_ prefix. If there are several, the generator uses ETH0_, ETH1_, … so each link has a unique macro set and networkServiceStartInterfaces() calls each start function in the same order as the JSON array.

GSM / PPP — gsmInterfaces

PPP entries reference an application manager header via ppAppManagerPath (or appManager), and function name fields for start/close/reconnect/ready. Modem parameters live under gsmModemConfig (PIN, APN, dial string, timeout). The physical link is described in driverConfig (for example UART line and driver header path). Multiple PPP links use PPP0_, PPP1_, … prefixes parallel to Ethernet numbering.

Stacks You Can Wire In JSON

The repository provides implementation folders under Services/Network/Interfaces/. You may list several stacks in JSON to document alternatives, but the build only uses the first use: true block.

Snippet — Linux Profile (Illustrative)

Below, two stacks are disabled and the Linux stack is enabled. Only the Linux stack’s interfaces block is expanded; Cyclone and lwIP entries are ignored even if they contain data.

"networkStack": [
  { "use": false, "name": "CycloneTcp", ... },
  { "use": false, "name": "lwIP", ... },
  {
    "use": true,
    "name": "Linux",
    "stackInitSourcePath": "Services/Network/Interfaces/Linux/AppLinuxTcpIpStack.h",
    "stackInitFunction": "appLinuxTcpIpStackInit",
    "interfaces": {
      "ethInterfaces": [
        {
          "use": true,
          "ifname": "eth0",
          "ethAppManagerPath": "Services/Network/Interfaces/Linux/AppLinuxEthMng.h",
          "ethAppManagerStartFunction": "appLinuxEthMngStart",
          ...
        }
      ]
    }
  }
]