Protocol Feature Negotiation

From RepRap
Revision as of 22:00, 7 May 2011 by Triffid hunter (talk | contribs) (describe feature negotiation protocol)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

This page describes a proposed feature negotiation protocol for firmware and hostware.

It works like this:

Host sends M115 to firmware. Firmware replies with FEATURES:0/feature0,1/feature1,2/feature2 Host works out which features it also supports. Assuming it supports feature0 and feature2 but not feature1, it calculates (1<<0) + (1<<2) = 5. Host sends M118 P5 to firmware.

This allows a non-linear feature set, and also allows firmwares and hostwares to negotiate the maximum set of combined features that they both support.

Simple firmwares can simply send a statically stored list, and more complex firmwares can build a list dynamically. The parsing and lookup is left to the host which has plenty of cycles to burn doing work like this, and the firmware receives a simple bitmask as a response which even the simplest of firmwares can easily handle. Host must use a 32 bit integer internally for the bitmask, firmware can choose an appropriate bit width for the number of features it supports.

The Generation N+1 electronics debacle has shown us clearly that linear versioning simply doesn't work in conjunction with reprap's bazaar-style development.

This feature negotiation (or something similar) is a prerequisite for Dual Band data exchange, and a simple launchpad for a large array of binary protocols.

Feature Name List

proposed list of feature names

  • dual-band - see Dual Band
  • accel-ramping - ramping acceleration
  • accel-reprap - reprap acceleration
  • accel-none - no acceleration
  • baud-change - allow baud change
  • sdcard-print - print from an sd card. firmware can either use the sd as a simple buffer, or implement a full filesystem.
  • sdcard-save - write to an sd card. firmware can either use the sd as a simple buffer, or implement a full filesystem.
  • sdcard-fileio - firmware supports multiple files on sd card, rather than a static single file or using sd as a raw block device buffer. Hostware should always provide a filename regardless. This is just a cue that hostware should expect to be able to write a new file and then load an older one, and that hostware can request a file list.