X-Git-Url: http://git.scottworley.com/tattlekey/blobdiff_plain/a36c278f05a806c9ced1a96b04eae0e6b9d8a5d5..HEAD:/client/config.h?ds=sidebyside diff --git a/client/config.h b/client/config.h index 23f04d5..3a61793 100644 --- a/client/config.h +++ b/client/config.h @@ -1,32 +1,66 @@ +/* tattlekey: A one-key UDP keyboard + * Copyright (C) 2023 Scott Worley + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + */ + #ifndef CONFIG_H #define CONFIG_H #include "lwip/arch.h" /* Wi-Fi credentials */ -extern char config_wifi_ssid[]; -extern char config_wifi_pass[]; +extern const char config_wifi_ssid[]; +extern const char config_wifi_pass[]; /* Network address of the server to contact */ -extern char config_tattle_server_ip_address[]; -extern u16_t config_tattle_port; +extern const char config_tattle_server_ip_address[]; +extern const u16_t config_tattle_port; /* For distinguishing reports from multiple tattlekey devices. */ -extern u16_t config_this_tattler_identity; +extern const u16_t config_this_tattler_identity; /* 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. */ -extern uint config_button_pin; +extern const uint config_button_pin; /* Don't bother reporting each separate button press when it is pressed many * times in short succession. (We also use this to de-bounce. :) */ -extern u32_t config_minimum_seconds_between_button_presses; +extern const u32_t config_minimum_seconds_between_button_presses; -/* Send each report multiple times. */ -extern uint config_resend_count; +/* Send each report multiple times. Re-sends are sent with exponential delay: + * #1 sent immediately + * #2 after 1 seconds + * #3 after 2 seconds + * #4 after 4 seconds + * #5 after 8 seconds + * ... + * #11 after 8 minutes + * #12 after 17 minutes + * #13 after 34 minutes + * #14 after 68 minutes + * #15 after 2 hours + * #16 after 4 hours + * #17 after 9 hours + * etc. + * This provides some robustness against network outages, automatically + * replaying the log periodically to be collected after connectivity + * is restored. */ +extern const uint config_resend_count; /* These control the size of the per-send-count press queues. When the button is pressed more than config_maximum_queue_size times @@ -36,11 +70,11 @@ the old, longest-delyed, 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 interals are so short. */ -extern uint config_maximum_queue_size; +extern const uint config_maximum_queue_size; /* This is paranoia about unanticipated delays. Setting this to zero would pobably be fine, but imposing a minimum queue size is an easy safety measure. */ -extern uint config_minimum_queue_size; +extern const uint config_minimum_queue_size; #endif