src/main.h

#pragma once

#include "screen.h"

extern bool axp192_found;
extern bool ssd1306_found;
extern bool isCharging;
extern bool isUSBPowered;

// Global Screen singleton.
extern meshtastic::Screen screen;

// Return a human readable string of the form "Meshtastic_ab13"
const char *getDeviceName();

void getMacAddr(uint8_t *dmac);

void nrf52Setup(), esp32Setup(), nrf52Loop(), esp32Loop();
begin cleanup of sleep code for new state machine 2020-02-21 17:01:26 -08:00			`#pragma once`

Screen cleanups and refactoring Work towards separating out how Screen interacts with other stuff. * `Screen` should now be thread-safe. All commands to it are put in a queue and handled in `doTask` from the `loop()` task. * Break dependency from `BluetoothUtil` to `Screen` by changing the pairing request into a callback. * All accesses to screen now happen through the class. * Fix `drawRows` so that the text scrolls along with frame animations. * Remove example code that wasn't used. 2020-03-15 16:47:38 -07:00			`#include "screen.h"`

begin cleanup of sleep code for new state machine 2020-02-21 17:01:26 -08:00			`extern bool axp192_found;`
until my TBEAM is fixed, leave GPS power on in sleep sometimes 2020-02-24 11:21:08 -08:00			`extern bool ssd1306_found;`
			`extern bool isCharging;`
Screen cleanups and refactoring Work towards separating out how Screen interacts with other stuff. * `Screen` should now be thread-safe. All commands to it are put in a queue and handled in `doTask` from the `loop()` task. * Break dependency from `BluetoothUtil` to `Screen` by changing the pairing request into a callback. * All accesses to screen now happen through the class. * Fix `drawRows` so that the text scrolls along with frame animations. * Remove example code that wasn't used. 2020-03-15 16:47:38 -07:00			`extern bool isUSBPowered;`

			`// Global Screen singleton.`
			`extern meshtastic::Screen screen;`
move bluetooth code into something that is architecture specific... because the ESP32 implementation will be different from NRF52 to make this possible I needed to decouple knowlege about bluetooth from our mesh service. Instead mesh service now uses the Obserable pattern to let any interested consumer get notified of important mesh changes (currently that is only bluetooth, but really we should do the same thing for decoupling the GUI 'app' from the mesh service) @girtsf would you mind reviewing my Observer changes? I haven't written C++ code in a long time ;-) 2020-04-10 12:18:48 -07:00
			`// Return a human readable string of the form "Meshtastic_ab13"`
			`const char *getDeviceName();`
use a real macaddr on the nrf52 2020-04-23 16:55:25 -07:00
placeholder guess at PMU code until I have HW 2020-04-24 09:33:45 -07:00			`void getMacAddr(uint8_t *dmac);`

			`void nrf52Setup(), esp32Setup(), nrf52Loop(), esp32Loop();`