0 Replies Latest reply on Jun 26, 2014 10:59 AM by ndutton

    Machine friendly or human friendly - the programmers debate

    ndutton

      How to approach a serial interface have been one of those programmer debates for years...

       

      If you optimize a serial interface such that a microcontroller spends little time parsing; then the whole communication interface lends itself to battery powered operations a lot better, micros can spend more time sleeping, but as a caveat the 'coded' serial communication makes it tougher to quickly setup demos to evaluate a peripherals features and capability.

       

      But wouldn't it be nice to to have to compromise?

       

      WiConnect builds upon Broadcom's WICED to offer, amongst other features, a best of both worlds API. WiConnect offers 2 modes of operation, a machine friendly optimized interface and a more verbose human friendly interface.

       

      Human Friendly Command Mode
      By default, the serial interface is configured to be human friendly with the following settings.
      Detailed information about these settings is available here.

      set system.print_level all -> Turn on all debug & informational prints

      set system.cmd.header_enabled 0 -> Disable a response header

      set system.cmd.prompt_enabled 1 -> Turn on the user prompt

      set system.cmd.echo on -> Turn on echo to see what you're typing

      Machine Friendly Command Mode
      To configure the serial interface for machine friendly operation, use the following settings.
      Detailed information about these settings is available here.

      set system.print_level 0 -> Turn off all debug & informational prints

      set system.cmd.header_enabled 1 -> Enable a response header (described below)

      set system.cmd.prompt_enabled 0 -> Turn off the user prompt

      set system.cmd.echo off -> Turn off character echo

      Command Format

      Commands sent to WiConnect are formatted as shown in the following table. The <command name> is a WiConnect command issued by the host, and [variable name <argument>]\r\n is an (optional) WiConnect variable name and accompanying argument terminated by a carriage return and newline character.

      <command name> [variable name <argument>]\r\n 

      Response Format

      Responses from WiConnect follow the format shown in the text below.

      RXYYYYY\r\n <response data>

      where …

      • R denotes a Response header.
        NOTE! If the module is operating in Safe Mode, R is replaced with S.
      • X is the error code (response error codes are listed below).
      • YYYYY is the response data length in bytes including a trailing \r\n.
        The response data length is zero if no data is available, or >2 (including \r\n) if data is available.
      • <response data>. If the response data length is >0, the <response data> is the data returned from WiConnect in response to the command.


      Response Error Codes

      0 = Success

      1 = Command failed

      2 = Parse error

      3 = Unknown command

      4 = Too few args

      5 = Too many args

      6 = Unknown variable or option

      7 = Invalid argument 

      Log Format

      If system.print_level is greater than 0, a log header together with one or more informational debug logs may be returned in addition to a response header and response data when a command is issued. Log headers follow the format shown in the table below.

      LXYYYYY\r\n <log message>

      where …

      • L denotes a Log header.
      • X is the log level.
      • YYYYY is the log message length in bytes including a trailing \r\n.
        Log messages are always >2 bytes in length and including terminating \r\n characters.
      • <log message>. The log message returned by WiConnect in response to the command.

       

       

      Make sure to visit the WiConnect Reference manual to see all the latest and greatest features here:   http://wiconnect.ack.me

       

       

      WICED Wi-Fi

      WICED Wi-Fi Forums

      Zentri

      Macnica