client: Make the queue size bounds configurable

[tattlekey] / client / config.c

#include "config.h"

/* Wi-Fi credentials */
char config_wifi_ssid[] = "THEWIFISSID";
char config_wifi_pass[] = "THEWIFIPASSWORD";

/* Network address of the server to contact */
char config_tattle_server_ip_address[] = "192.168.10.10";
u16_t config_tattle_port = 29803; // 'tk'

/* For distinguishing reports from multiple tattlekey devices. */
u16_t config_this_tattler_identity = 1;

/* Which GPIO pin is the button connected to?
 * The button should span this pin and ground, connecting this pin to ground
 * when pressed.
 * https://projects.raspberrypi.org/en/projects/introduction-to-the-pico/10
 * recommends pins 18, 22, or 28. */
uint config_button_pin = 18;

/* Don't bother reporting each separate button press when it is pressed many
 * times in short succession.  (We also use this to de-bounce. :) */
u32_t config_minimum_seconds_between_button_presses = 1;

/* Send each report multiple times. */
uint config_resend_count = 5;

/* These control the size of the per-send-count press queues.
When the button is pressed more than config_maximum_queue_size times
within the resend interval, some presses will be reported fewer
than config_resend_count times. This is usually fine because it's
the old, longest-delayed, most-redundant reports that get dropped;
fresh, timely reports of new button presses will not get anywhere near
config_resend_count in a resend interval because the early resend internals
are so short.  */
uint config_maximum_queue_size = 512;

/* This is paranoia about unanticipated delays.  Setting this to zero
would probably be fine, but imposing a minimum queue size is an easy
safety measure. */
uint config_minimum_queue_size = 32;