wiki:cc135x

Version 2 (modified by Tim Harvey, 8 days ago) (diff)

added details for cc1352 products

Ti CC135x Sub-1GHz Internet of Things Radio

This page describes the family of Texas Instruments CC135x Sub-1GHz radio modules that are used on several Gateworks products, including the GW16122/GW5910.

Hardware

Hardware with the CC135x:

  • GW16122-B - CC1352P
    • connected to FTDI UART
      • CBUS0: JTAG_RST/CC_RST# output (has strong pull-up)
      • CBUS1: BOOT_BCKDR output (has strong pull-down)
      • CBUS2: CC_TMSC output (cJTAG)
      • CBUS3: CC_TCKC output (cJTAG)
  • GW16122-A - CC1350
    • CC1350 connected to a TI Tiva MCU for programming
  • GW5910-C - CC1352P
    • connected on the JTAG chain with the CPU and GSC
    • connected to IMX UART and SPI bus for bootloader access
  • TI Launchpad
    • these have an XDS110 JTAG Debugger on-board (implemented via the Tiva MCU chip). The XDS110 debugger exposes two USB ACM serial devices where the first one is tied directly to the CC13xx UART (pinout matching the 'serial downloader' pins specified in the TRM) and the second serial device is for JTAG programming. These boards can be programmed via the TI 'Uniflash' tool (GUI or stand-alone command-line) or the CCS IDE.

References:

Software

The TI SimpleLink products have drivers built into ROM for low-level programming capability. TI also offers several API's and stacks that sit on top of these drivers depending on your needs and programming capability.

TI also offers a real time operating system (RTOS) layer if desired and there also exist third party RTOS providers as well such as Contiki-ng and Zephyr.

Here we will focus on the TI set of tools and options as that is your best option for on-line support via the TI Community forums.

To create your own firmware for the CC1352P you use the TI SimpleLink CC13x2 SDK which contains a toolchain for compiling code as well as a set of documentation and examples.

For code development you must use TI's Code Composer Studio (CCS) (you use their compiler, but you don't have to use their IDE unless trying to import examples from the SDK).

Note that the RF core and driver core are built into the chip's ROM but they can be patched via rf_patch_cpe_*.h files which define structures that can be set to the 'cpuPatchFxn, 'mcePatchFxn', and 'rfePatchFxn' fields of the FR_Mode struct passed to RF_open.

  • the patch files can be found in $SIMPLELINK_SDK/source/ti/devices/cc13x2_cc26x2_v1/rf_patches
  • rf_patch_cpu_prop.h - RF core patch for proprietary radio support ("PROP" API command set) in CC13x2
  • rf_patch_cpu_multi_protocol.h - RF core patch for multi-protocol support (all available API command sets) in CC13x2
  • rf_patch_{mce,rfe}_genfsk.h - RF core patch for Generic FSK support

TI has excellent documentation for their SDK:

  • offline: In the SDK install directory under docs
  • SimpleLink CC13x2 26x2 SDK - 3.20.00.68
    • Note that this link is pinned tot he 3.20.00.68 version of the SDK which is what was used when writing this documentation. You can hover over the menu item on the right and select a different version via the '...' menu button

TI Code Composer Studio (CCS)

TI Code Composer Studio is an integrated development environment (IDE) maintained by TI with pre-installed tools and libraries for software development across TI MCU's including an optimized C/C++ compiler, source code editor, project build environment, debugger, and profiler using the Eclipse software framework. CCS supports Windows, Mac OS and Linux 64bit hosts.

While it is not required that you use the CCS IDE you will need the compiler toolchain that is installed with it.

Installation (CCS9 installed on Ubuntu 18.04 bionic host):

  1. Download the 'offline installer' from TI (this is a compressed tarball):
  2. Untar into desired destination directory
  3. Install the following pre-requisites of the installer
    sudo apt install libc6:i386 libusb-0.1-4 libgconf-2-4 build-essential
    
  4. Run the installation GUI app (ccs_setup_*.bin) which allows you to choose your installation directory and what components you wish to install (default $HOME/ti)
    • for CC1352P development choose 'SimpleLink CC13xx and CC26xx Wireless MCUs'
  5. Once installed you can run CCS via the desktop icon.
  6. first install you will be asked to install xdctools then restart

TI GCC toolchain

The TI GCC toolchain is installed with Code Composer Studio and can be found where it installs in the tools/compiler/gcc-arm-none-eabi* directory.

The compiler produces .out files which are regular ELF files that can only be flashed to the device with JTAG programming tools. This file format can be converted to a binary image or an Intel Hex file using objcopy if using the serial downloader.

Examples:

  • convert ELF (.out) to .bin:
    $(GCC_ARMCOMPILER)/bin/arm-none-eabi-objcopy -S --gap-fill 0xff -O binary $(FILE).out $(FILE).bin
    
  • convert ELF (.out) to Intel Hex (.hex):
    $(GCC_ARMCOMPILER)/bin/arm-none-eabi-objcopy -S -O ihex $(FILE).out $(FILE).hex
    

TI SimpleLink SDK

The TI SimpleLink SDK contains libraries, documentation and examples for the TI CC13xx parts.

If using revision control, the following project files should be checked into source control:

  • .ccsproject - project info specific to CCS
  • .cproject - Eclipse CDT project file
  • .project - Eclipse CDT project file
  • .settings folder - Eclipse folder
  • makefile.defs (if using SYS/BIOS) - additional make rules
  • do not check in \Debug or \Release\<config name>, .xdchelp, .config folder, .launches folder

Some of the examples in the SimpleLink directory have makefiles for the TI GCC compiler while others only support being built with TI's Code Composer Studio, IAR compiler, or their newer syscfg tool. Look for 'gcc' directories if you want to use the stand-alone GCC compiler. These examples require that you define the GCC_ARMCOMPILER env variable as specified above.

The SimpleLink SDK provides examples and documentation for driver API's for the low-level drivers built into the chip ROM as well as higher-level abstraction API's such as the 'EasyLink' abstraction layer.

The TI SimpleLink SDK option allows you to jump in and code at various levels depending on your needs and comfort zone:

Other necessary TI tools and details:

  • SmartRF Studio is a Windows app that allows you to obtain configuration code for the various RF registers that control frequency, tx-power, bandwidth, and other low-level protocol details.
  • CCFG registers control details such as MAC address and how the CC135x powers up (ie if it skips past its serial bootloader and how).

Low Level RF driver API

The RF driver offers very low-level API's to run radio operation commands on the TI RF core and send and receive raw packets. For driver documentation see:

References:

TI Real Time Operating System (TI RTOS)

TI-RTOS accelerates development schedules by eliminating the need to create basic system software functions from scratch. TI-RTOS scales from a real-time multitasking kernel - TI-RTOS Kernel - to a complete RTOS solution including additional middleware components, device drivers and power management. TI-RTOS and TI's ultra low-power MCUs combine to enable developers to design applications with much longer battery life. By providing essential system software components pre-tested and pre-integrated, TI-RTOS enables developers to focus on differentiating their application.

The TI RTOS is integrated within the SimpleLink SDK and you can find details and examples for Threads, Semaphors, and Timers. For various examples you can choose to use the TI RTOS or choose the non-RTOS examples which have less complexity but less features.

Documentation:

The RF core has a dedicated driver called the TI-RTOS RF driver which is used for all interaction with the RF core. EasyLink is a simple abstraction layer on top of the RF driver intended as a start point for customers creating a proprietary Sub-1GHz protocol or application.

The EasyLink API is documented both online and offline:

In the EasyLink Network Processor project, the EasyLink API is also exposed via an AT Command Interface such that it can be exercised over serial transport by a host software (running on an PC, MPU or MCU) or manually by using a serial terminal emulator.

Examples can be found in the SimpleLink SDK under Software -> SimpleLink cc13x2 SDK -> Examples -> Development Tools -> CC1352 LaunchPad -> EasyLink.

For instructions on using the TI-RTOS examples refer to docs/proprietary-rf/proprietary-rf-users-guide.html

If you do not wish to use the EasyLink abstraction layer, there is also the option to do simple packet RX/TX using the TI-RTOS RF driver directly (see above).

On the other hand, if you wish to create a full stack-based network solution, consider using the TI 15.4-Stack (see below), available as part of the CC13x0 SDK.

TI 15.4 Stack

TI has an SDK that implements 15.4 Stack if you wish to implement the 15.4 stack on the host CPU vs the CC13xx CPU. See the Sensor and Collector applications for examples of this.

Documentation:

Examples:

  • rfEasyLinkNp:
    export GCC_ARMCOMPILER=~/ti/ccs910/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major/
    cd ~/ti/simplelink_cc13x2_sdk_2_30_00_45
    make -C kernel/tirtos/builds/CC1352P_4_LAUNCHXL/release/gcc # rfEasyLinkNp requires the TIRTOS kernel
    make -C examples/rtos/CC1352P_4_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc
    cd examples/rtos/CC1352P_2_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc
    $GCC_ARMCOMPILER/arm-none-eabi-objcopy -S --gap-fill 0xff -O binary rfEasyLinkNp.out rfEasyLinkNp.bin
    $GCC_ARMCOMPILER/arm-none-eabi-objcopy -S -O ihex rfEasyLinkNp.out rfEasyLinkNp.hex
    

RF Settings / SmartRF Studio

RF commands are used to set various RF properties via the RF Core API. These commands are passed via an RF_RadioSetup structure when calling RF_Open.

While SmartRF Studio can interactively configure SimpleLink chips over JTAG this requires one of TI's Launchpad development boards.

The RF commands and properties can be obtained using the Windows based TI RFStudio application which allows selecting RF details (frequency, tx-power, channel bandwidth, etc) and exporting these to code snippets which define the structures that are passed to RF_Open.

References:

TI Dynamic Multi-protocol Manager (DMM)

The Dynamic Multi-protocol Manager (DMM) allows multiple wireless stacks (ie BLE5-Stack, TI 15.4, Zibgee or EasyLink) to coexist and operate concurrently acting as an arbiter between the stacks and the shared RF core resource.

TI has several examples in the dmm subdirectory of the SimpleLink? SDK.

For more information see the Latest TI DMM Users's Guide

CCFG registers

The TI SimpleLink chips have a CCFG register section defined in the Technical Reference Manual. These registers configure things such as MAC address, bootloader config, JTAG TAP/DAP configuration and some RF gain details. Many of the TI examples contain a ccfg.c file which includes source/ti/devices/cc13x2_cc26x2_v1/startup_files/ccfg.c

Software Examples

The following software examples all assume:

  • CCS9.1.0.00010_linux-x64.tar.gz - CCS9.1.0.0010 installed in home directory (see above for install instructions)
  • SimpleLink cc13x2-26x2-sdk-3.20.00.68 - SimpleLink SDK 3.20.00.68 installed in home directory (see above for install instructions)
  • Environment setup for GCC:
    export COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR=~/ti/simplelink_cc13x2_26x2_sdk_3_20_00_68
    export GCC_ARMCOMPILER=~/ti/ccs910/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major
    export XDC_INSTALL_DIR=~/ti/xdctools_3_51_03_28_core
    

Pre-built firmware for these examples is available at:

Once you have a *.out binary file you can program the CC1352P via JTAG programming.

TI SimpleLink SDK examples

The TI SimpleLink examples fall into the following categories:

  • nortos - TI Drivers without an underlying operating system (OS) (there can be only one main thread which interrupts can preempt - typical 'multithreading' is not available).
  • rtos - TI-RTOS Kernel - a scalable real-time kernel designed to be used by applications that require real-time scheduling and synchronization or real-time instrumentation. It provides preemptive multi-threading, hardware abstraction, real-time analysis, and configuration tools. Note that the TI-RTOS Kennel used to be called SYS/BIOS and you can read more about it in the TI-RTOS Kernel User's Guide.
  • syscfg - The SysConfig tool makes it easy to configure components like TI Drivers and device-specific components (such as the networking stack, EasyLink, and WiFi).

Examples (for more examples see SimpleLink SDK):

  • Drivers (Simple Applications use the low level TI RF Driver API's):
    • rfPacketTx (nortos): Illustrates how to do simple packet transmission using the RF driver. This example is meant to be used with the rfPacketRx example. For every packet transmitted the GRN LED (Board_PIN_LED1) is 'toggled'. The frequency and other RF settings are in smartrf_settings.c defaulted to 868MHz 20dBm tx-power and can be modified using SmartFR Studio.
      cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR
      make -C examples/nortos/CC1352P1_LAUNCHXL/drivers/rfPacketTx/gcc
      ls examples/nortos/CC1352P1_LAUNCHXL/drivers/rfPacketTx/gcc/*.out
      
    • rfPacketRx (nortos): Illustrates how to do simple packet transmission using the RF driver. This example is meant to be used with the rfPacketTx example. For every packet received the RED LED (Board_PIN_LED2) is 'toggled'. The frequency and other RF settings are in smartrf_settings.c defaulted to 868MHz and can be modified using SmartFR Studio.
      cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR/examples/nortos/CC1352P1_LAUNCHXL/drivers/rfPacketTx/gcc
      make
      ls *.out
      
  • EasyLink (Higher Level API for RF applications):
    • rfEasyLinkTx (No RTOS): Illustrates how to do simple packet transmission using the EasyLink API. This example is meant to be used with the rfEasyLinkxRx example. It toggles GRN LED every 100ms indicating a packet has been transmitted. After the 10th packet is transmitted the 11th transmission will be aborted toggling the RED LED then the cycle will continue. The frequency and other RF settings are in smartrf_settings.c defaulted to 868MHz 20dBm tx-power and can be modified using SmartFR Studio.
      cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR
      make -C examples/nortos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkTx/gcc
      ls examples/nortos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkTx/gcc/*.out
      
    • rfEasyLinkRx (No RTOS): Illustrates how to do simple packet reception using the EasyLink API. This example is meant to be used with the rfEasyLinkxTx example. It toggles RED LED to indicate a packet has been received. The GRN LED will toggle indicating an abort which is expected to happen if a packet is not received within 300ms of the RX being scheduled (which should occur every 11th packet as dictated by rfEasyLinkTx above). Both GRN and RED LED's together indicates an error (which is not expected to happen under normal conditions). The frequency and other RF settings are in smartrf_settings.c defaulted to 868MHz 20dBm tx-power and can be modified using SmartFR Studio.
      cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR
      make -C examples/nortos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkRx/gcc
      ls examples/nortos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkRx/gcc/*.out
      
    • rfEasyLinkNP (TI Kernel RTOS): Exposes the EasyLink API over an AT command interface such that it can be excercised by Host SW. Note that this requires the TI Kernel RTOS.
      • Building:
        cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR
        make -C kernel/tirtos/builds/CC1352P1_LAUNCHXL/release/gcc
        make -C examples/rtos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc
        ls examples/rtos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc/*.out
        
      • Once flashed on two different boards (Board_TX and Board_RX) you can connect to the tty of the CC1352P UART at 115200bd 8N1 and use the EasyLink API AT commands to send and receive packets. For example:
        • BoardRX: Initialize the radio and receive data
          AT+I
          AT+RX
          
        • BoardTX: Initialize the radio and transmit 'hello'
          AT+I
          AT+TX Hello World
          
  • BLE5-Stack (These lack Makefiles so must be built via Code Composer Studio):
    • multi_role - demonstrates functioning in multiple simultaneous connection roles, master and slave simultaneously. A UART based API supports operations: Advertise, Discover, Connect. GATT Read, GATT Write, Connection Update, Disconnect. A UART API at 115200baud 8N1 will provide a simple menu (S2/DIO14 moves to the next menu item and S1/DIO15 selects the current menu item).
    • simple_broadcaster: Demonstrates non-connectable beacon applications (ie Apple iBeacon and Google Eddystone). This application uses the UART peripheral to display messages and is configured to broadcast sample advertising data out of the box via non-connectable advertisements. See Bluetooth low energy Beacons Application Note (SWRA475) for more information about Bluetooth low energy beacons. You can use a BLE Scanner such as the 'BLE Scanner' Android application to see the beacon which will be named 'SimpleBLEBroadcaster'.
    • simple_peripheral: Implements a simple Bluetooth low energy peripheral device with GATT services and demonstrates the TI Simple Profile. This example can be a framework for developing many different peripheral-role applications and is used as a baseline for explaining the stack in the BLE5-Stack Users's Guide. A UART API at 115200baud 8N1 will provide a simple menu (S2/DIO14 moves to the next menu item and S1/DIO15 selects the current menu item).
    • simple_central: Implements a simple Bluetooth low energy central device with GATT client functionality. By default the app is configured to filter and connect to peripheral devices with the TI Simple Profile UUID such as the simple_peripheral example. A UART API at 115200baud 8N1 will provide a simple menu (S2/DIO14 moves to the next menu item and S1/DIO15 selects the current menu item).
    • simple_peripheral_oad: Demonstrates on-chip OAD functionality combined with the simple_peripheral example application. This app is configured to be managed and launched by the Boot Image Manager (BIM) example app meaning this project does not include aCCFG section to configure the device at boot and therefore requires that the BIM project is programmed into the device first. See OAD for more info.
    • project_zero: Implements a simple Bluetooth low energy peripheral devices with GATT services also demonstrating how to integrate Over the Air (OAD) Download and three custom services. This app is configured to be managed and launched by the Boot Image Manager (BIM) example app meaning this project does not include a CCFG section to configure the device at boot and therefore requires that the BIM project is programmed into the device first. See OAD for more info.

Programming

Via JTAG

The CC135x by default comes up in 2-wire cJTAG mode but does support 4-wire JTAG. There is a sequence that needs to be done in order to get it to 4-wire mode.

JTAG programming is supported with OpenOCD software on the following:

  • GW16122-B via the Gateworks GW11033 JTAG dongle attached to the 10-pin JTAG header J6 (make sure the board is powered via the miniPCIe connector; ie in a board powered on or via a USB to miniPCIe adapter plugged into a powered USB port)
  • GW5910-C via IMX6 GPIO

Note that the OpenOCD package from Ubuntu lacks the necessary cc26xx flash driver so we must either build OpenOCD from source manually or use the Gateworks Ubuntu PPA:

  • Installing from Gateworks Ubuntu PPA:
    sudo add-apt-repository ppa:gateworks-software/packages
    sudo apt update
    sudo apt install openocd
    
  • Building from source:
    apt install build-essential libusb-1.0-0-dev libftdi-dev autoconf libtool pkg-config git
    git clone https://github.com/Gateworks/openocd.git
    cd openocd
    ./bootstrap
    ./configure --enable-imx_gpio --enable-ftdi --enable-sysfsgpio
    make install
    
    • The Gateworks OpenOCD git repo also has some additional patches we found necessary to make it reliably program the CC135x.

You will also need OpenOCD interface / board config files:

  • If using a GW16122-B+ and a GW16042 JTAG dongle plugged into J6:

    Config file

    cat << EOF > gw16122.cfg
    #
    # Gateworks GW16122 CC1352P JTAG interface
    #
    # Layout: FTDI FT2232H
    #   ADBUS0 TCK
    #   ADBUS1 TDI
    #   ADBUS2 TDO (input)
    #   ADBUS3 TMS
    #   ADBUS4 nTRST
    #   ADBUS5 nSRST
    #   ADBUS6 OE (active high) for TRST, TDI, TMS, TCK
    #   ADBUS7 NC
    #   ACBUS0-7 NC
    #   BDBUS0 RXD
    #   BDBUS1 TXD (input)
    #
    interface ftdi
    ftdi_device_desc "USB-JTAG"
    ftdi_vid_pid 0x0403 0x6010
    ftdi_layout_init 0x0058 0x007b
    ftdi_layout_signal nSRST -oe 0x0020
    
    adapter_khz 10000
    transport select jtag
    source [find target/ti_cc13x2.cfg]
    reset_config none
    EOF
    

Via Serial bootloader

The TI SimpleLink products have a ROM bootloader that supports 2-pin UART or 4-pin SPI via a serial protocol defined in the Techical Reference Manuals (TRM):

A .bin file or .hex file is required when using the bootloader. These can be created with the gcc compiler:

This can be used to program application firmware as long as the CCFG registers define the configuration to keep the bootloader enabled:

There are a number of software resources available for programming in this fashion however if you program firmware that does not have the above CCFG configuration you will no longer be able to access the bootloader and will have to use JTAG. Therefore using JTAG programming is likely recommended recommended.

Once such application you can use out-of-the-box for updating firmware via serial bootloader is cc2538-bsl.py.

Examples:

As the GW5910-C can be programmed via OpenOCD via imx-gpio JTAG there really isn't any reason to want to use the Serial bootloader.

Over the Air Download (OAD) / Over The Air (OTA)

For generic OTA, the idea is to transmit FW over the air to the CC13xx. After finishing FW transmitting, the OTA application will check FW integrity and if the downloaded FW Is correct, the application should notify bootloader and reboot for bootloader to move FW to CC13xx to restart.

TI provides OTA examples in the BLE Stack, TI 15.4 Stack, and EasyLink example projects. This works by having a Boot Image Manager (BIM) which resides on the OAD target and is responsible for loading new images after a download has completed. The BIM executes on a device reset and determines if a firmware update needs to be applied. If no update is being applied then the BIM will transfer program execution to the main application image. Note that TI's BLE-Stack OAD Profile does not implement or perform any security or authentication mechanisms as part of the firmware update process - if this is something you need you will need to implement this yourself or look for another OAD process. TI recommends applications use Bluetooth LE Secure Connections (LESC) with Man-in-the-Middle (MITM) protection with peer devices when performing wireless firmware updates although the use of the LESC feature does not itself guarantee image authenticity.

BIM is a fully executable application that is independent of any high level protocol stack or user application and is guaranteed to run on boot. BIM enables power loss fault tolerance during OAD... if the device power is lost during OAD the BIM will still be able to run from reset and revert to a working image if one is available. The BIM is intended to reside permanently on the chip and cannot be updated via the OAD process. BIM executes before kernel initialization takes place so the design is single threaded and bare metal. Hardware access is accomplished through driverlib. As a separate application, BIMI requires its own interrupt vector table and linker file and will produce a fully executable image that must be merged with the user application image in order to create a functional OAD enabled firmware system.

The TI BIM comes in two forms: 'on-chip' for Storing the firmware update in the internal flash and 'off-chip' for storing the firmware image in an external FLASH chip. Note that the Gateworks CC135x products do not have external flash devices connected to the CC135x however one could implement their own OAD process that uses the baseboard's mechanisms for storage and firmware update (ie JTAG).

To create an OAD image you use the TI OAD Image Tool which is distributed in both source and binary form (Linux, Windows, Mac) and is run as a post build step to an OAD application. The tool located in <SDK_DIR>/tools/common/aod/oad_image_tool.py will generate an output binary file named <app_name>_oad.bin.

For more info on this process please consult the BLE5-Stack Users's Guide

References:

Identifying TTYs

The FTDI USB UART chips are supported by a the 'ftdi-sio' kernel driver/module that registers /dev/ttyUSB<n> devices.

Because this is a commonly used chip including the one used in the Gateworks JTAG dongles it can be helpful to have some commands to help you identify which tty is which device:

Serial UART Access

The GW5910 has the IMX6 UART3 connected as full-duplex to the CC1352P thus you can access it via /dev/ttymxc2

The GW16122 has an FTDI FT231X USB Full Speed UART connected to it via the following pinout:

Hardware flow control (RTS/CTS) is only necessary if you load code onto the CC1352P that uses it.

There are several Linux terminal programs that can aid you in communicating with the UART such as screen, picocom, minicom.

Examples:

# Find the tty associated with the GW16122 device in your system
TTY=/dev/$(for i in $(ls -1d /sys/bus/usb/devices/*); do [ -r $i/interface ] && { [[ "$(cat $i/interface)" =~ "GW16122" ]] && basename $(ls -d $i/ttyUSB*); }; done)
echo $TTY
apt install picocom
picocom --baud 115200 $TTY

Attachments (3)

Download all attachments as: .zip