aditihilbert closed pull request #863: Move tutorials/other to mynewt-documentation URL: https://github.com/apache/mynewt-core/pull/863
This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/docs/os/tutorials/codesize.rst b/docs/os/tutorials/codesize.rst deleted file mode 100644 index 163c18aba..000000000 --- a/docs/os/tutorials/codesize.rst +++ /dev/null @@ -1,38 +0,0 @@ -How to Reduce Application Code Size ------------------------------------ - -Gettng your application to fit in an image slot can be challenging, -particularly on flash constrained hardware such as the nRF51. Below are -some suggested system configuration settings that reduce the code size -of your Mynewt image. - -+------------------------+---------------------------------------------+ -| Setting | Description | -+========================+=============================================+ -| LOG\_LEVEL: 255 | Disable all logging. | -+------------------------+---------------------------------------------+ -| LOG\_CLI: 0 | Disable log shell commands. | -+------------------------+---------------------------------------------+ -| STATS\_CLI: 0 | Disable stats shell commands. | -+------------------------+---------------------------------------------+ -| SHELL\_TASK: 0 | Disable the interactive shell. | -+------------------------+---------------------------------------------+ -| SHELL\_OS\_MODULE: 0 | Disable memory management shell commands. | -+------------------------+---------------------------------------------+ -| SHELL\_CMD\_HELP: 0 | Disable help for shell commands. | -+------------------------+---------------------------------------------+ - -You can use the ``newt target set`` command to set the syscfg settings -in the ``syscfg.yml`` file for the target. See the `Newt Tool Command -Guide </newt/command_list/newt_target>`__ for the command syntax. - -**Note:** The ``newt target set`` command deletes all the current syscfg -settings in the target ``syscfg.yml`` file and only sets the syscfg -settings specified in the command. If you are experimenting with -different settings to see how they affect the code size and do not want -to reenter all the setting values in the ``newt target set`` command, -you can use the ``newt target amend`` command. This command adds or -updates only the settings specified in the command and does not -overwrite other setting values. While you can also edit the target -``syscfg.yml`` file directly, we recommend that you use the -``newt target`` commands. diff --git a/docs/os/tutorials/unit_test.rst b/docs/os/tutorials/unit_test.rst deleted file mode 100644 index 21c8e0b8e..000000000 --- a/docs/os/tutorials/unit_test.rst +++ /dev/null @@ -1,359 +0,0 @@ -Write a Test Suite for a Package -================================ - -This document guides the reader through creating a test suite for a -Mynewt package. - -Introduction ------------- - -Writing a test suite involves using the -```test/testutil`` <../modules/testutil/testutil.html>`__ package. The -testutil library provides the functionality needed to define test suites -and test cases. - -Choose Your Package Under Test ------------------------------- - -Choose the package you want to write a test suite for. In this tutorial, -we will use the ``time/datetime`` in the apache-mynewt-core repo. -Throughout this tutorial, we will be inside the apache-mynewt-core repo -directory, unlike most tutorials which operate from the top-level -project directory. - -Create A Test Package ---------------------- - -Typically, a library has only one test package. The convention is name -the test package by appending ``/test`` to the host library name. For -example, the test package for ``encoding/json`` is -``encoding/json/test``. The directory structure of the json package is -shown below: - -.. code:: c - - encoding/json - ??? include - ??? ??? json - ??? ??? json.h - ??? pkg.yml - ??? src - ??? ??? json_decode.c - ??? ??? json_encode.c - ??? test - ??? pkg.yml - ??? src - ??? test_json.c - ??? test_json.h - ??? test_json_utils.c - ??? testcases - ??? json_simple_decode.c - ??? json_simple_encode.c - -The top-level ``test`` directory contains the json test package. To -create a test package for the datetime package, we need to create a -similar package called ``time/datetime/test``. - -:: - - $ newt pkg new time/datetime/test -t unittest - Download package template for package type pkg. - Package successfuly installed into /home/me/mynewt-core/time/datetime/test. - -We now have a test package inside ``time/datetime``: - -:: - - time/datetime - ??? include - ??? ??? datetime - ??? ??? datetime.h - ??? pkg.yml - ??? src - ??? ??? datetime.c - ??? test - ??? README.md - ??? pkg.yml - ??? src - ??? ??? main.c - ??? syscfg.yml - -There is one modification we need to make to the new package before we -can start writing unit test code. A test package needs access to the -code it will be testing, so we need to add a dependency on -``@apache-mynewt-core/time/datetime`` to our ``pkg.yml`` file: - -.. code:: hl_lines="10" - - pkg.name: "time/datetime/test" - pkg.type: unittest - pkg.description: "Description of your package" - pkg.author: "You <y...@you.org>" - pkg.homepage: "http://your-url.org/"; - pkg.keywords: - - pkg.deps: - - '@apache-mynewt-core/test/testutil' - - '@apache-mynewt-core/time/datetime' - - pkg.deps.SELFTEST: - - '@apache-mynewt-core/sys/console/stub' - -While we have the ``pkg.yml`` file open, let's take a look at what newt -filled in automatically: - -- ``pkg.type: unittest`` designates this as a test package. A *test - package* is special in that it can be built and executed using the - ``newt test`` command. -- A test package always depends on - ``@apache-mynewt-core/test/testutil``. The testutil library provides - the tools necessary for verifying package behavior, -- The ``SELFTEST`` suffix indicates that a setting should only be - applied when the ``newt test`` command is used. - -Regarding the conditional dependency on ``sys/console/stub``, the -datetime package requires some form of console to function. In a regular -application, the console dependency would be supplied by a higher order -package. Because ``newt test`` runs the test package without an -application present, the test package needs to supply all unresolved -dependencies itself when run in self-test mode. - -Create Your Test Suite Code ---------------------------- - -We will be adding a *test suite* to the ``main.c`` file. The test suite -will be empty for now. We also need to invoke the test suite from -``main()``. - -Our ``main.c`` file now looks like this: - -.. code:: c - - #include "sysinit/sysinit.h" - #include "testutil/testutil.h" - - TEST_SUITE(test_datetime_suite) { - /* Empty for now; add test cases later. */ - } - - #if MYNEWT_VAL(SELFTEST) - int - main(int argc, char **argv) - { - /* Initialize all packages. */ - sysinit(); - - test_datetime_suite(); - - /* Indicate whether all test cases passed. */ - return tu_any_failed; - } - #endif - -Try It Out ----------- - -We now have a working test suite with no tests. Let's make sure we get a -passing result when we run ``newt test``: - -:: - - $ newt test time/datetime - <build output> - Executing test: /home/me/mynewt-core/bin/targets/unittest/time_datetime_test/app/time/datetime/test/time_datetime_test.elf - Passed tests: [time/datetime/test] - All tests passed - -Create a Test -------------- - -To create a test within your test suite, there are two things to do. - -1. Implement the test case function using the ``testutil`` macros. -2. Call the test case function from within the test suite. - -For this tutorial we will create a test case to verify the -``datetime_parse()`` function. The ``datetime_parse()`` function is -declared as follows: - -.. code:: c - - /** - * Parses an RFC 3339 datetime string. Some examples of valid datetime strings - * are: - * 2016-03-02T22:44:00 UTC time (implicit) - * 2016-03-02T22:44:00Z UTC time (explicit) - * 2016-03-02T22:44:00-08:00 PST timezone - * 2016-03-02T22:44:00.1 fractional seconds - * 2016-03-02T22:44:00.101+05:30 fractional seconds with timezone - * - * On success, the two output parameters are filled in (tv and tz). - * - * @return 0 on success; - * nonzero on parse error. - */ - int - datetime_parse(const char *input, struct os_timeval *tv, struct os_timezone *tz) - -Our test case should make sure this function rejects invalid input, and -that it parses valid input correctly. The updated ``main.c`` file looks -like this: - -.. code:: c - - #include "sysinit/sysinit.h" - #include "testutil/testutil.h" - #include "os/os_time.h" - #include "datetime/datetime.h" - - TEST_SUITE(test_datetime_suite) - { - test_datetime_parse_simple(); - } - - TEST_CASE(test_datetime_parse_simple) - { - struct os_timezone tz; - struct os_timeval tv; - int rc; - - /*** Valid input. */ - - /* No timezone; UTC implied. */ - rc = datetime_parse("2017-06-28T22:37:59", &tv, &tz); - TEST_ASSERT_FATAL(rc == 0); - TEST_ASSERT(tv.tv_sec == 1498689479); - TEST_ASSERT(tv.tv_usec == 0); - TEST_ASSERT(tz.tz_minuteswest == 0); - TEST_ASSERT(tz.tz_dsttime == 0); - - /* PDT timezone. */ - rc = datetime_parse("2013-12-05T02:43:07-07:00", &tv, &tz); - TEST_ASSERT_FATAL(rc == 0); - TEST_ASSERT(tv.tv_sec == 1386236587); - TEST_ASSERT(tv.tv_usec == 0); - TEST_ASSERT(tz.tz_minuteswest == 420); - TEST_ASSERT(tz.tz_dsttime == 0); - - /*** Invalid input. */ - - /* Nonsense. */ - rc = datetime_parse("abc", &tv, &tz); - TEST_ASSERT(rc != 0); - - /* Date-only. */ - rc = datetime_parse("2017-01-02", &tv, &tz); - TEST_ASSERT(rc != 0); - - /* Zero month. */ - rc = datetime_parse("2017-00-28T22:37:59", &tv, &tz); - TEST_ASSERT(rc != 0); - - /* 13 month. */ - rc = datetime_parse("2017-13-28T22:37:59", &tv, &tz); - TEST_ASSERT(rc != 0); - } - - #if MYNEWT_VAL(SELFTEST) - int - main(int argc, char **argv) - { - /* Initialize all packages. */ - sysinit(); - - test_datetime_suite(); - - /* Indicate whether all test cases passed. */ - return tu_any_failed; - } - #endif - -Take a few minutes to review the above code. Then keep reading for some -specifics. - -Asserting -~~~~~~~~~ - -The ``test/testutil`` package provides two tools for verifying the -correctness of a package: - -- ``TEST_ASSERT`` -- ``TEST_ASSERT_FATAL`` - -Both of these macros check if the supplied condition is true. They -differ in how they behave when the condition is not true. On failure, -``TEST_ASSERT`` reports the error and proceeds with the remainder of the -test case. ``TEST_ASSERT_FATAL``, on the other hand, aborts the test -case on failure. - -The general rule is to only use ``TEST_ASSERT_FATAL`` when subsequent -assertions depend on the condition being checked. For example, when -``datetime_parse()`` is expected to succeed, the return code is checked -with ``TEST_ASSERT_FATAL``. If ``datetime_parse()`` unexpectedly failed, -the contents of the ``tv`` and ``tz`` objects would be indeterminate, so -it is desirable to abort the test instead of checking them and reporting -spurious failures. - -Scaling Up -~~~~~~~~~~ - -The above example is small and self contained, so it is reasonable to -put everything in a single C file. A typical package will need a lot -more test code, and it helps to follow some conventions to maintain -organization. Let's take a look at a more realistic example. Here is the -directory structure of the ``fs/nffs/test`` package: - -:: - - fs/nffs/test - ??? pkg.yml - ??? src - ??? nffs_test.c - ??? nffs_test.h - ??? nffs_test_debug.c - ??? nffs_test_priv.h - ??? nffs_test_system_01.c - ??? nffs_test_utils.c - ??? nffs_test_utils.h - ??? testcases - ??? append_test.c - ??? cache_large_file_test.c - ??? corrupt_block_test.c - ??? corrupt_scratch_test.c - ??? gc_on_oom_test.c - ??? gc_test.c - ??? incomplete_block_test.c - ??? large_system_test.c - ??? large_unlink_test.c - ??? large_write_test.c - ??? long_filename_test.c - ??? lost_found_test.c - ??? many_children_test.c - ??? mkdir_test.c - ??? open_test.c - ??? overwrite_many_test.c - ??? overwrite_one_test.c - ??? overwrite_three_test.c - ??? overwrite_two_test.c - ??? read_test.c - ??? readdir_test.c - ??? rename_test.c - ??? split_file_test.c - ??? truncate_test.c - ??? unlink_test.c - ??? wear_level_test.c - -The ``fs/nffs/test`` package follows these conventions: - -1. A maximum of one test case per C file. -2. Each test case file goes in the ``testcases`` subdirectory. -3. Test suites and utility functions go directly in the ``src`` - directory. - -Test packages contributed to the Mynewt project should follow these -conventions. - -Congratulations ---------------- - -Now you can begin the work of validating your packages. diff --git a/docs/os/tutorials/wi-fi_on_arduino.rst b/docs/os/tutorials/wi-fi_on_arduino.rst deleted file mode 100644 index 3a381d7e7..000000000 --- a/docs/os/tutorials/wi-fi_on_arduino.rst +++ /dev/null @@ -1,368 +0,0 @@ -Enable Wi-Fi on Arduino MKR1000 -------------------------------- - -This tutorial shows you how to enable Wi-Fi on an Arduino MKR1000 board -and connect to a Wi-Fi network. - -Prerequisites -~~~~~~~~~~~~~ - -Ensure that you have met the following prerequisites before continuing -with this tutorial: - -- Have an Arduino MKR1000 board. -- Have Internet connectivity to fetch remote Mynewt components. -- Have a computer to build a Mynewt application and connect to the - board over USB. -- Have a Micro-USB cable to connect the board and the computer. -- Have local Wi-Fi network that the computer is connected to and that - the MKR1000 board can join. -- Have a `Serial Port Setup </os/get_started/serial_access.html>`__. -- Have a `Segger J-Link Debug - Probe <https://www.segger.com/jlink-debug-probes.html>`__. -- Have a `J-Link 9 pin Cortex-M - Adapter <https://www.segger.com/jlink-adapters.html#CM_9pin>`__ that - allows JTAG, SWD and SWO connections between J-Link and Cortex M - based target hardware systems -- Install the `Segger JLINK Software and documentation - pack <https://www.segger.com/jlink-software.html>`__. -- Install the Newt tool and toolchains (See `Basic - Setup </os/get_started/get_started.html>`__). -- Create a project space (directory structure) and populated it with - the core code repository (apache-mynewt-core) or know how to as - explained in `Creating Your First - Project </os/get_started/project_create>`__. -- Read the Mynewt OS `Concepts </os/get_started/vocabulary.html>`__ - section. - -Create a Project -~~~~~~~~~~~~~~~~ - -Create a new project if you do not have an existing one. You can skip -this step and proceed to `fetch external packages <#%20fetchexternal>`__ -if you already created a project. - -Run the following commands to create a new project: - -.. code-block:: console - - $ mkdir ~/dev - $ cd ~/dev - $ newt new arduinowifi - Downloading project skeleton from apache/mynewt-blinky... - Installing skeleton in arduinowifi... - Project arduinowifi successfully created. - $ cd arduinowifi - $ newt install - apache-mynewt-core - $ - -Fetch External Packages -~~~~~~~~~~~~~~~~~~~~~~~~ - -Mynewt uses source code provided directly from the chip manufacturer for -low level operations. Sometimes this code is licensed only for the -specific manufacturer of the chipset and cannot live in the Apache -Mynewt repository. That happens to be the case for the Arduino Zero -board which uses Atmel SAMD21. Runtime's git hub repository hosts such -external third-party packages and the Newt tool can fetch them. - -To fetch the package with MCU support for Atmel SAMD21 for Arduino Zero -from the Runtime git repository, you need to add the repository to the -``project.yml`` file in your base project directory. - -Mynewt uses source code provided directly from the chip manufacturer for -low level operations. Sometimes this code is licensed only for the -specific manufacturer of the chipset and cannot live in the Apache -Mynewt repository. That happens to be the case for the Arduino Zero -board which uses Atmel SAMD21. Runtime's github repository hosts such -external third-party packages and the Newt tool can fetch them. - -To fetch the package with MCU support for Atmel SAMD21 for Arduino Zero -from the Runtime git repository, you need to add the repository to the -``project.yml`` file in your base project directory (``arduinowifi``). - -Here is an example ``project.yml`` file with the Arduino Zero repository -added. The sections with ``mynewt_arduino_zero`` that need to be added -to your project file are highlighted. - -**Note:** On Windows platforms: You need to set ``vers`` to ``0-dev`` -and use the latest master branch for both repositories. - -\`\`\`hl\_lines="6 14 15 16 17 18" $ more project.yml project.name: -"my\_project" - -project.repositories: - apache-mynewt-core - mynewt\_arduino\_zero - -repository.apache-mynewt-core: type: github vers: 1-latest user: apache -repo: mynewt-core - -repository.mynewt\_arduino\_zero: type: github vers: 1-latest user: -runtimeco repo: mynewt\_arduino\_zero $ \`\`\` - -Install the project dependencies using the ``newt install`` command -(you can specify ``-v`` for verbose output): - -.. code-block:: console - - $ newt install - apache-mynewt-core - mynewt_arduino_zero - $ - -**NOTE:** If there has been a new release of a repo used in your project -since you last installed it, the ``1-latest`` version for the repo in -the ``project.yml`` file will refer to the new release and will not -match the installed files. In that case you will get an error message -saying so and you will need to run ``newt upgrade`` to overwrite the -existing files with the latest codebase. - -Create a Target for the Bootloader -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You need to create two targets for the MKR1000 board, one for the -bootloader and one for the ``winc1500_wifi`` application. Run the -following ``newt target`` commands, from your project directory, to -create a bootloader target. We name the target ``mkr1000_boot``. - -.. code-block:: console - - $ newt target create mkr1000_boot - $ newt target set mkr1000_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_mkr1000 - $ newt target set mkr1000_boot app=@apache-mynewt-core/apps/boot - $ newt target set mkr1000_boot build_profile=optimized - $ newt target set mkr1000_boot syscfg=BSP_ARDUINO_ZERO_PRO=1 - -Create a Target for the Wi-Fi Application -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Run the following ``newt target`` commands to create a target for the -``winc1500_wifi`` application in the arduino repository. We name the -application target ``mkr1000_wifi``. - -:: - - $ newt target create mkr1000_wifi - $ newt target set mkr1000_wifi app=@mynewt_arduino_zero/apps/winc1500_wifi - $ newt target set mkr1000_wifi bsp=@mynewt_arduino_zero/hw/bsp/arduino_mkr1000 - $ newt target set mkr1000_wifi build_profile=debug - $ newt target set mkr1000_boot syscfg=BSP_ARDUINO_ZERO_PRO=1 - -Build the Bootloader -~~~~~~~~~~~~~~~ - - -Run the ``newt build mkr1000_boot`` command to build the bootloader: - -.. code-block:: console - - $ newt build mkr1000_boot - Building target targets/mkr1000_boot - Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c - Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c - Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c - Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c - Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c - Compiling repos/apache-mynewt-core/apps/boot/src/boot.c - - ... - - Archiving util_mem.a - Linking ~/dev/arduinowifi/bin/targets/mkr1000_boot/app/apps/boot/boot.elf - Target successfully built: targets/mkr1000_boot - $ - -Build the Wi-Fi Application -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Run the ``newt build mkr1000_wifi`` command to build the wi-fi -application image: - -.. code-block:: console - - $newt build mkr1000_wifi - Building target targets/mkr1000_wifi - Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c - Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c - Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c - Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c - Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c - ... - - Archiving util_mem.a - Linking ~/dev/arduinowifi/bin/targets/mkr1000_wifi/app/apps/winc1500_wifi/winc1500_wifi.elf - Target successfully built: targets/mkr1000_wifi - $ - -Sign and Create the Wi-Fi Application Image -~~~~~~~~~~~~~~~ - - -Run the ``newt create-image mkr1000_wifi 1.0.0`` command to sign and -create an image file for the Wi-Fi application. You may assign an -arbitrary version (e.g. 1.0.0) number. - -.. code-block:: console - - $newt create-image mkr1000_wifi 1.0.0 - Compiling bin/targets/mkr1000_wifi/generated/src/mkr1000_wifi-sysinit-app.c - Archiving mkr1000_wifi-sysinit-app.a - Linking ~/dev/arduinowifi/bin/targets/mkr1000_wifi/app/apps/winc1500_wifi/winc1500_wifi.elf - App image succesfully generated: ~/dev/arduinowifi/bin/targets/mkr1000_wifi/app/apps/winc1500_wifi/winc1500_wifi.img - $ - -Connect to the Board -~~~~~~~~~~~~~~~~~~~~ - -- Connect your computer to the MKR1000 board with the Micro-USB cable. -- Connect the debug probe to the JTAG port on the board using the Jlink - 9-pin adapter and cable. - - |J-Link debug probe to MKR1000| - -.. raw:: html - - <p> - -Mynewt will download and debug the target through this port. You should -see a green LED come on and indicates the board has power. - -Load the Bootloader onto the Board -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Run the ``newt load mkr1000_boot`` command to load the bootloader onto -the board: - -.. code-block:: console - - $ newt load mkr1000_boot - Loading bootloader - $ - -Load the Wi-Fi Application Image onto the Board -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Run the ``newt load mkr1000_wifi`` command to load the wifi application -onto the board: - -.. code-block:: console - - $ newt load mkr1000_wifi - Loading app image into slot 1 - $ - -Setup a Serial Connection Between Your Computer and the Board -~~~~~~~~~~~~~~~ - - -Set up a serial connection from your computer to the MKR1000 board (See -`Serial Port Setup </os/get_started/serial_access.html>`__). On the -MKR1000 board, the TX pin is PIN 14 and the RX pin in PIN 13. |Serial -Connection to MKR1000| - -.. raw:: html - - <p> - -Locate the port, in the /dev directory on your computer, that the -serial connection uses. The format of the port name is platform -dependent: - -- Mac OS uses the format ``tty.usbserial-<some identifier>``. -- Linux uses the format ``TTYUSB<N>``, where ``N`` is a number. For - example, TTYUSB2. -- MinGW on Windows uses the format ``ttyS<N>``, where ``N`` is a - number. You must map the port name to a Windows COM port: - ``/dev/ttyS<N>`` maps to ``COM<N+1>``. For example, ``/dev/ttyS2`` - maps to ``COM3``. - - You can also use the Windows Device Manager to find the COM port - number. - -.. code-block:: console - - $ ls /dev/tty*usbserial* - /dev/tty.usbserial-1d13 - $ - -Start Wi-Fi via console -~~~~~~~~~~~~~~~~~~~~~~~ - -Use a terminal emulation program to communicate with the board over the -serial port. This tutorial shows a Minicom set up. Run the minicom -command with the serial port you located on your computer: - -**Note:** On Windows, you can use the PuTTY application. - -.. code-block:: console - - $ minicom -D /dev/tty.usbserial-1d13 -b 115200 - -Type ``wifi start`` to start Wi-Fi. - -.. code:: hl_lines="11" - - - Welcome to minicom 2.7.1 - - OPTIONS: - Compiled on May 17 2017, 15:29:14. - Port /dev/tty.usbserial, 15:12:10 - - Press Meta-Z for help on special keys - - - 138465 compat> wifi start - 144570 compat> (APP)(INFO)Chip ID 1503a0 - (APP)(INFO)Firmware ver : 19.4.4 - (APP)(INFO)Min driver ver : 19.3.0 - (APP)(INFO)Curr driver ver: 19.3.0 - wifi_init : 0 - -Connect to the local Wi-Fi network. Note that the MKR1000 board only -supports 2.4 GHz Wi-Fi networks. - -Run the ``wifi connect`` command and specify your network and . After -you are connected to your wi-fi network, run the ``net service`` command -to start network services. - -\`\`\`hl\_lines="2 9" - -wifi connect 037624 wifi\_request\_scan : 0 037627 compat> scan\_results -7: 0 038454 wifi\_connect : 0 039451 connect\_done : 0 039958 dhcp done -192.168.0.135 040169 get sys time response 2017.7.12-22.41.33 net -service - -\`\`\` - -The board is connected to the network succesfully and has IP address: -192.168.0.135 - -Establish TCP Connection and Talk! -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -From a terminal on your computer, telnet to ports 7, 9, or 19 using the -IP address your board has been assigned. Type something on this terminal -and see the console output (on minicom). Can you see the difference in -the behaviors? - -.. code-block:: console - - - $telnet 192.168.0.135 7 - Trying 192.168.0.135... - Connected to 192.168.0.135. - Escape character is '^]'. - hello - hello - ^] - telnet> q - $ - -One port echoes whatever is typed, one discards everything it gets, and -the third spews out bits constantly. Type ``wifi stop`` to disable WiFi -on the Arduino board. - -.. |J-Link debug probe to MKR1000| image:: pics/mkr1000-jlink.jpg -.. |Serial Connection to MKR1000| image:: pics/mkr1000-serial.jpg - ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
