1 files changed, 27 insertions(+), 8 deletions(-)

M README.md

@@ 10,7 10,7 @@ Because the focus of this work has been mostly on the USB OTG device, I used htt
 some parts may even be 'direct translation'.
 when writing SDRAM interfacing and DSI controller. It was very challenging to find information about the interface and display otherwise.
 Luckily this hal library has even examples for the STM32H747-DISCO board, so the individual display configuration and commands required
-to bring up the display, are present as well.
+to bring up the display are present as well.
 
 ## Project Structure
 


@@ 20,12 20,14 @@ with typical structure for Rust crates, and `firmware`,
 where the STM32 firmware is located.
 
 As for `firmware` structure:
+
 - `devices` - Folder with support for various devices. It contains linker scripts, isr definitions,
 as well as a startup file that ensures bss is nulled, .data contains initialized code in ram, and calls main.
 - `include` - headers
 - `libs` - Third-party libraries. Specifically CMSIS for register definitions for both Cortex-M and STM32H7
 - `src` - C source code
 - `tests` - Tests runnable on Linux. Initially the author wanted to make more tests, where parts of the device
+
 would be simulated. But afterall there was no need for this, and only one test was made. Specifically,
 a test for seeing contents of device descriptor. The test utilizes that functions for sending data are used,
 and they are replaced by code that just prints to a file instead of changing chip memory.


@@ 41,6 43,9 @@ like sending or receiving specific data. `usb_device.h` contains functions speci
 for initializing the device, for handling interrupts, and setup.
 `usb_device_cdc.h` contains implementation of CDC ACM.
 
+`usb_device.c` contains all the code for setup. Most of the setup, and communication
+with the host generally, is performed in interrupt handler.
+
 Care has been taken to properly abstract the usb send, reception, from
 setup and that from application layer. This means that it should be trivial
 to add support for other application layers besides USB CDC.


@@ 55,7 60,7 @@ where if the function would have to spin loop, it will just return
 WOULD_BLOCK. This ensures that no functions block, and it can be decided
 from upper layers what to do about that, like when to retry this operation.
 
-cdc acm implementation leverages queue for reception of data. It saves
+CDC ACM implementation leverages queue for reception of data. It saves
 the data to queue, and then the application can receive the data from
 the queue. This is quite handy as the application doesn't need to implement
 some kind of a callback, but rather can just spin loop with `cdc_data_receive`.


@@ 99,6 104,13 @@ mode, it has never been tried on hardware.
 
 ## Usage
 
+The application is using USB OTG for communication,
+so it needs to be connected via that usb port.
+Since standard application layers is used - CDC ACM,
+most operating systems should support it out of the box.
+It is possible to open the serial port, write
+characters to it, and receive characters from it.
+
 ## Building and flashing
 
 For building, makefile is available.


@@ 110,14 122,21 @@ to flash the program.
 ### Communication protocol on top of CDC ACM
 
 There is a simple ASCII based protocol supporting a few simple commands.
-
-r - turn screen to all red
-g - turn screen to all green
-b - turn screen to all blue
-l - toggle led
-i<IMG> - Upload an image and show it on the display. The IMG is expected to be in RGB888 format, ie. first three bytes show what's on the first pixel,
+The device will not reply to these commands unless otherwise specified.
+
+* p - ping. Will reply pong
+* e - Echo everything back (not accepting commands), E to quit this mode
+* r - turn screen to all red
+* g - turn screen to all green
+* b - turn screen to all blue
+* B - turn screen to all black
+* l - toggle led
+* i\<IMG\> - Upload an image and show it on the display. The IMG is expected to be in RGB888 format, ie. first three bytes show what's on the first pixel,
 first byte is intensity of R, second G, third B. The image is written row by row.
 
+On Linux, it's possible to use picocom on the ACM device created
+by Linux drivers. On Windows, something like PuTTY can be used.
+
 ### Application
 
 The computer application has been made in Rust.