begin plugin-api tutorial

docs/software/TODO.md

@@ -34,6 +34,8 @@ For app cleanup:
 * move python ping functionality into device, reply with rxsnr info
 * use channels for gpio security https://github.com/meshtastic/Meshtastic-device/issues/104
 * generate autodocs
+* update positions and nodeinfos based on packets we just merely witness on the mesh.  via isPromsciousPort bool.
+* MeshPackets for sending should be reference counted so that API clients would have the option of checking sent status (would allow removing the nasty 30 sec timer in gpio watch sending)
 
 For high speed/lots of devices/short range tasks:
 

docs/software/build-instructions.md

@@ -1,8 +1,11 @@
 # Build instructions
 
-This project uses the simple PlatformIO build system. PlatformIO is an extension to Microsoft VSCode.
+This project uses the simple PlatformIO build system. PlatformIO is an extension to Microsoft VSCode.  Workflows from building from the GUI or from the commandline are listed below.  
+
+If you encounter any problems, please post a question in [our forum](meshtastic.discourse.group).  And when you learn a fix, update these instructions for the next person (i.e. edit this file and send in a [pull-request](https://opensource.com/article/19/7/create-pull-request-github) which we will eagerly merge).
 
 ## GUI
+
 1. Purchase a suitable [radio](https://github.com/meshtastic/Meshtastic-device/wiki/Hardware-Information).
 2. Install [Python](https://www.python.org/downloads/).
 3. Install [Git](https://git-scm.com/downloads).
@@ -19,6 +22,7 @@ This project uses the simple PlatformIO build system. PlatformIO is an extension
 Note - To get a clean build you may have to delete the auto-generated file `./.vscode/c_cpp_properties.json`, close and re-open Visual Studio and WAIT until the file is auto-generated before compiling again.
 
 ## Command Line
+
 1. Purchase a suitable [radio](https://github.com/meshtastic/Meshtastic-device/wiki/Hardware-Information).
 2. Install [PlatformIO](https://platformio.org/platformio-ide)
 3. Download this git repo and cd into it:

docs/software/device-api.md

@@ -1,4 +1,6 @@
-# Device API
+# Bluetooth/serial/TCP protocol API
+
+(This document describes the protocol for external API clients using our devices.  If you are interested in running your own code on the device itself, see the [on-device](plugin-api.md) documentation instead)
 
 The Device API is design to have only a simple stream of ToRadio and FromRadio packets and all polymorphism comes from the flexible set of Google Protocol Buffers which are sent over the wire. We use protocol buffers extensively both for the bluetooth API and for packets inside the mesh or when providing packets to other applications on the phone.
 

docs/software/plugin-api.md

@@ -0,0 +1,66 @@
+# Plugin-API
+
+This is a tutorial on how to write small plugins which run on the device.  Plugins are bits regular 'arduino' code that can send and receive packets to other nodes/apps/PCs using our mesh.
+
+## Key concepts
+
+All plugins should be subclasses of MeshPlugin.  By inheriting from this class and creating an instance of your new plugin your plugin will be automatically registered to receive packets.
+
+Messages are sent to particular port numbers (similar to UDP networking).  Your new plugin should eventually pick its own port number (see below), but at first you can simply use PRIVATE_APP (which is the default).
+
+Packets can be sent/received either as raw binary structures or as [Protobufs](https://developers.google.com/protocol-buffers).
+
+### Class heirarchy
+
+The relevant bits of the class heirarchy are as follows
+
+* MeshPlugin (in src/mesh/MeshPlugin.h) - you probably don't want to use this baseclass directly
+  * SinglePortPlugin (in src/mesh/SinglePortPlugin.h) - for plugins that receive from a single port number (the normal case)
+    * ProtobufPlugin (in src/mesh/ProtobufPlugin.h) - for plugins that are sending/receiving a single particular Protobuf type.  Inherit from this if you are using protocol buffers in your plugin.
+
+You will typically want to inherit from either SinglePortPlugin (if you are just sending raw bytes) or ProtobufPlugin (if you are sending protobufs).  You'll implement your own handleReceived/handleReceivedProtobuf - probably based on the example code.
+
+If your plugin needs to perform any operations at startup you can override and implement the setup() method to run your code.
+
+If you need to send a packet you can call service.sendToMesh with code like this (from the examples):
+
+```
+    MeshPacket *p = allocReply();
+    p->to = dest;
+
+    service.sendToMesh(p);
+```
+
+## Example plugins
+
+A number of [key services](/src/plugins) are implemented using the plugin API, these plugins are as follows:
+
+* [TextMessagePlugin](/src/plugins/TextMessagePlugin.h) - receives text messages and displays them on the LCD screen/stores them in the local DB
+* [NodeInfoPlugin](/src/plugins/NodeInfoPlugin.h) - receives/sends User information to other nodes so that usernames are available in the databases
+* [RemoteHardwarePlugin](/src/plugins/RemoteHardwarePlugin.h) - a plugin that provides easy remote access to device hardware (for things like turning GPIOs on or off).  Intended to be a more extensive example and provide a useful feature of its own.  See [remote-hardware](remote-hardware.md) for details.
+* [ReplyPlugin](/src/plugins/ReplyPlugin.h) - a simple plugin that just replies to any packet it receives (provides a 'ping' service).
+
+## Getting started
+
+The easiest way to get started is to copy [src/plugins/ReplyPlugin.*](/src/plugins/ReplyPlugin.h) into src/plugins/YourPlugin.*.  Then change the port number from REPLY_APP to PRIVATE_APP.
+
+## Picking a port number
+
+For any new 'apps' that run on the device or via sister apps on phones/PCs they should pick and use a unique 'portnum' for their application.
+
+If you are making a new app using meshtastic, please send in a pull request to add your 'portnum' to [the master list](https://github.com/meshtastic/Meshtastic-protobufs/blob/master/portnums.proto).  PortNums should be assigned in the following range:
+
+* 0-63 Core Meshtastic use, do not use for third party apps
+* 64-127 Registered 3rd party apps, send in a pull request that adds a new entry to portnums.proto to register your application
+* 256-511 Use one of these portnums for your private applications that you don't want to register publically
+* 1024-66559 Are reserved for use by IP tunneling (see FIXME for more information)
+
+All other values are reserved.
+
+## How to add custom protocol buffers
+
+If you would like to use protocol buffers to define the structures you send over the mesh (recommended), here's how to do that.
+
+* Create a new .proto file in the protos directory.  You can use the existing [remote_hardware.proto](https://github.com/meshtastic/Meshtastic-protobufs/blob/master/remote_hardware.proto) file as an example.
+* Run "bin/regen-protos.sh" to regenerate the C code for accessing the protocol buffers.  If you don't have the required nanopb tool, follow the instructions printed by the script to get it.
+* Done!  You can now use your new protobuf just like any of the existing protobufs in meshtastic.

docs/software/sw-design.md

@@ -1,9 +1,10 @@
 This is a mini design doc for developing the meshtastic software.
 
 * [Build instructions](build-instructions.md)
+* [On device plugin API](plugin-api.md) - a tutorial on how to write small Plugins which run on the device and can message other nodes.
 * [TODO](TODO.md) - read this if you are looking for things to do (or curious about currently missing features)
 * Our [project board](https://github.com/orgs/meshtastic/projects/1) - shows what things we are currently working on and remaining work items for the current release.
 * [Power Management](power.md)
 * [Mesh algorithm](mesh-alg.md)
-* [Device API](device-api.md) and porting guide for new clients (iOS, python, etc...)
+* [External client API](device-api.md) and porting guide for new clients (iOS, python, etc...)
 * TODO: how to port the device code to a new device.