Split fw doc and add environment page (#94)

* wip

* small fixes

* remove link to empty applications list

* remove unused flipper libraries page

* mark some sections, add link to examples

* add environment page

wiki/_Sidebar.md

@@ -9,12 +9,12 @@ _Do not edit this Wiki in web-interface. Read [How to edit Wiki](Contributing#ho
 # [Contributing](Contributing)
 * [Communication](Communication)
 
-# [Firmware](Firmware)
+# Firmware
 
+* [Architecture](Firmware)
+* [Environment](Environment)
 * [Flipper-applications](Flipper-applications)
 * [FURI](FURI)
-* [Flipper applications](Flipper-applications)
-* [FURI records list](FURI-records-list)
 * [Timers](Timers)
 * [UI](UI)
 

wiki/fw/Environment.md

@@ -0,0 +1,60 @@
+# Building/debugging/emulating
+
+## Preparing for build
+
+1. Install [docker compose](https://docs.docker.com/compose/install/)
+2. After startup you should run `docker-compose up -d` to run the container.
+3. Then you can run `docker-compose exec dev make -C <target_dir>` to build application.
+
+If Dockerfile is changed you should run `docker-compose down` and `docker-compose build` for rebuild the image.
+
+## Local build
+
+For simple case as unit tests or integration test that no require hardware we mock HW and replace RTOS syscalls to POSIX syscalls. We get simple linux app that easy to debug and get flexible control on hardware stubs.
+
+You can run firmware locally (with HAL stub).
+
+* `docker-compose exec dev make -C target_lo` for build
+* `docker-compose exec dev target_lo/build/target_lo` for run
+* `docker-compose exec dev make -C target_lo test` for running tests
+
+For UI we do "UI emulator" (not implemented)
+
+1. Web page with display and other UI elements, controls
+2. Local (linux) version of firmware. All calls, writing data to UI like display or LED, redirects to unix socket writes, and messages from unix socket redirect to firmware (emulates button press, change batt level, insert/remove USB, etc.)
+3. Webserver that run linux version fw, pass events from webpage to unixsocket and vice versa.
+
+## Firmware emulation (not implemented)
+
+For more HW- and RTOS- specific checks we run real FW in [Renode](https://interrupt.memfault.com/blog/intro-to-renode)
+
+## Running on remote Debug/test bench
+
+Eventually we run real FW on remote debug/test bench (#26): flipper board + RPi + some stuff to control and check real hardware.
+
+# Debug/test bench (not implemented)
+
+* 24×7 connected target Flipper device and accessible via Internet. Raspberry PI or some Linux single-board PC can be used as basic high-level control board.
+* Tool can push/click each user buttons by hardware by "control board" (low level). Usage of optocouples/reed-switch relays is fine for that.
+* Connect other Flipper peripherals to target:
+	* 433 door bell/barrier controller, to read it status and it's remote control (to sniff it signal by flipper).
+	* Some iButtons and it's reader can be also connected to target.
+	* RFID reader under the target, to paste readed keys from it to out UART.
+	* RFID cards with different IDs. Can changed by servo or carousel from CD-changer
+	* IR-transmitter/receiver.
+	* ...all the peripherals, that we'll can realize...
+* "Hardware" USB peripherals (SWD programmer tool, etc?) reconnection and control of PWR, RST, BOOTx internal service lines, etc also need. This can be made by some software hacks or by relays.
+* Image from target display will be translated by webcam to web page.
+* WEB page, accessed to all developers (or maybe for everyone to view is better?) with these things:
+	* Target status area, Flipper control buttons, "connected" to real target. Power and service line switches.
+	* Ability to upload custom firmware binary to target. Take firmware build from CI/CD. Button to flash.
+	* Test tool UART with Flipper peripherals status and target device UART log also should be here.
+* OpenOCD connection from target (can be accessed from developers around the world by VPN or just port forwarding with IP access lists). So this feature allows deep remote debug.
+* List can be expanded with other good ideas...
+
+## Usage
+
+1. Developers connect to target directly by shedule.
+2. Run CI tests:
+	* For test automation we can use RobotDemo or simple expect tool/python scripts/etc.
+	* Apply test cases and submit its results.

wiki/fw/FURI-records-list.md

@@ -1,3 +1,5 @@
+_ (not implemented)_
+
 List of [FURI](FURI) records for exchange data between applications.
 
 # Interrupts

wiki/fw/Firmware.md

@@ -52,14 +52,14 @@ Files location: `/app/app_hal.[ch]`
 
 We use FreeRTOS 10.0.1 for sheduling. Documentation available on [freertos.org](https://www.freertos.org/a00106.html).
 
-Files location for L476 version: `/target_prod/Middlewares/Third_Party/FreeRTOS`
+Files location for L476 version: `/target_f1/Middlewares/Third_Party/FreeRTOS`
 
 **[Timers map](Timers)**
 
 # Platform code
 
 CMSIS, Freertos and HAL files are generated by CubeMX.
-You can find platform code for L476 version in `target_prod` folder:
+You can find platform code for L476 version in `target_f1` folder:
 
 * `Drivers/STM32L4xx_HAL_Driver` – hardware abstraction layer  
 * `Drivers/CMSIS` — ARM specific code
@@ -80,12 +80,6 @@ You can regenerate platform code:
 
 There are some arduino-style defines (digitalWrite, delay, etc.). Include `Arduino.h` from `/app/Arduino.h`
 
-## Debug print
-
-You can use `pintf` to write any message to debug UART. UART specify in `Makefile` as `-DDEBUG_UART=<>`.
-
-Implementation of write method located at `/app/write.c`
-
 # Flipper Universal Registry Implementation (FURI)
 
 FURI is used to:
@@ -96,7 +90,7 @@ FURI is used to:
 
 Read more at [FURI page](FURI)
 
-# FS
+# FS (not implemented)
 
 File system is used to volaile storage some files (config, application data, etc.). There are some folders mounted to different volumes:
 
@@ -110,19 +104,13 @@ File system is used to volaile storage some files (config, application data, etc
 
 Each flipper functionality except OS/HAL/FURI doing by Flipper application. Some application are called at startup, the rest are called by the user (for example, from menu).
 
-**[List of Flipper applications](Flipper-applications)**
+(you can see some [examples](Application-examples))
 
 For exchange data between application each app expose own record in FURI. You can subscribe on/read record to get data from application and write to record to send data to application.
 
 **[List of FURI records](FURI-records-list)**
 
-# Flipper libraries
-
-Unlike applications that run after startup, libraries are a collection of constants, types, or functions that the user can call from within the application.
-
-**[List of Flipper libraries](Flipper-libraries)**
-
-# Bootloader
+# Bootloader (not implemented)
 
 After start, bootloader run first. It can:
 
@@ -130,26 +118,3 @@ After start, bootloader run first. It can:
 2. Reflashes firmware from temporary area after updating from usb/bluetooth
 3. Restores factory default firmware for protected flash area
 4. Restores application settings to default by clearing `/etc` volume
-
-# Building
-
-## Build in docker container (main way)
-
-1. Install [docker compose](https://docs.docker.com/compose/install/)
-2. After startup you should run `docker-compose up -d` to run the container.
-3. Then you can run `docker-compose exec dev make -C <target_dir>` to build application.
-
-If Dockerfile is changed you should run `docker-compose down` and `docker-compose build` for rebuild the image.
-
-### Local build and run
-
-You can run firmware locally (with HAL stub).
-
-* `docker-compose exec dev make -C target_lo` for build
-* `docker-compose exec dev target_lo/build/target_lo` for run
-* `docker-compose exec dev make -C target_lo test` for running tests
-
-## Build in IDE
-
-* Arduino IDE (in progress)
-* PlatformIO (in progress)