chore: fix a large number of spelling issues

components/assets/gen_assets.py

@@ -67,7 +67,7 @@ def write_output_file(assets, filename):
     # Must be passed input json file (eg. downloaded from https://assets.blockstream.info/)
     # and the output header/include file to create, for inclusion in assets.c
     if len(sys.argv) != 3:
-        print('Usage: python', sys.argv[0], '<input json> <ouput file>')
+        print('Usage: python', sys.argv[0], '<input json> <output file>')
         sys.exit(1)
 
     input_file = sys.argv[1]

diy/README.md

@@ -171,7 +171,7 @@ _Warning: Doing this cannot be un-done, nor can the signing key that the device
     CONFIG_SECURE_FLASH_ENCRYPTION_MODE_RELEASE=y
     CONFIG_ESP32_REV_MIN_3=y
 
-_Depending on the hardare you have selected, you may need to remove the last line that requires a minimum of Rev3 hardware..._
+_Depending on the hardware you have selected, you may need to remove the last line that requires a minimum of Rev3 hardware..._
 
 **Remove**
 

diy/esp32-cam/README.md

@@ -2,7 +2,7 @@
 
 **Note on Programmers and USB/Serial Bridges for ESP32-CAM**
 
-The ESP32-Cam doesn't have an onboard USB/Serial converter, but is commonly shipped with an ESP32-CAM-MB interface that can simplify programming. Unfortunatly the ESP32-CAM-MB also makes it very difficult to access IO pins, so it's possible to us a different USB/Serial interface. (A CP2104 is a good option as it's low cost, provides both 5v and 3.3v and also allows gives the best compatibility with wallet software)
+The ESP32-Cam doesn't have an onboard USB/Serial converter, but is commonly shipped with an ESP32-CAM-MB interface that can simplify programming. Unfortunately the ESP32-CAM-MB also makes it very difficult to access IO pins, so it's possible to us a different USB/Serial interface. (A CP2104 is a good option as it's low cost, provides both 5v and 3.3v and also allows gives the best compatibility with wallet software)
 
 Once you have flashed the firmware, it's also possible to run the device without any USB/Serial bridge and supplying 5v directly to the ESP32-Cam. (This obviously prevents it being used via USB)
 

diy/esp32-wrover-cam/README.md

@@ -4,7 +4,7 @@
 
 In addition to the 'official' ESP32-WROVER-CAM boards from Freenove, there are also a number of readily available, low cost 'clones'.
 
-Some of these clones have will have different ports (Freenove with USB-C and cloes with MicroUSB), the camera position is slightly different (Hence why the example 3d printed cases have a rather large camera hole) and they also sometimes have slightly different startup behavior.
+Some of these clones have will have different ports (Freenove with USB-C and close with MicroUSB), the camera position is slightly different (Hence why the example 3d printed cases have a rather large camera hole) and they also sometimes have slightly different startup behavior.
 
 Some clone boards won't boot properly until you press the EN/RST pin after powering up the device. If your board behaves in this way, the simplest solution is to connect the EN/RST pin on your ESP32-WROVER-CAM board to a spare button on your LCD hat. (Pressing this button will then allow you to boot/reset the device at any time)
 

docs/index.rst

@@ -12,7 +12,7 @@ Welcome to Jade's RPC documentation!
 
 * All Jade RPC messages are CBOR, roughly based on the format of json-rpc messges.
 * The order of named fields inside the messages is unimportant.  The order of items in array elements usually is important.
-* In most cases the flow is message-reply-message-reply... the exception is the legacy sign-tx flow where n messages are sent before n replies are recieved.
+* In most cases the flow is message-reply-message-reply... the exception is the legacy sign-tx flow where n messages are sent before n replies are received.
 * In some cases there may be a delay between sending a message and a reply being sent, where some physical interaction with the Jade unit is required.
 * In general, the types used are string, boolean, uint32/64, and raw byte-strings for binary data.
 * Every message contains an `id` field - an arbitrary string up to 16 characters - which is included in the reply.
@@ -63,7 +63,7 @@ get_extended_data request
 * 'orig' should be the 'method' of the original request message
 * 'seqlen' should be the 'seqlen' in the replies - indicating the total number of message replies which will be required
 * 'seqnum' should indicate the next fragment required - it should always be less-than or equal-to the 'seqlen'
-* NOTE: atm 'seqnum' *MUST* indicate the next fragement.  ie. ie must be the last received seqnum + 1.
+* NOTE: atm 'seqnum' *MUST* indicate the next fragment.  ie. ie must be the last received seqnum + 1.
 * NOTE: at the moment these messages are only used for 'sign_psbt' replies, where the full psbt binary may be sufficiently large that it needs to be split over multiple messages.  See sign_psbt_request_.
 * Use of these messages may increase in future firmware releases.
 

jadepy/jade.py

@@ -505,7 +505,7 @@ def ota_update(self, fwcmp, fwlen, chunksize, fwhash=None, patchlen=None, cb=Non
             ack'd by the hw, to notify of upload progress.
             Defaults to None, and nothing is called to report upload progress.
         extended_replies: bool, optional
-            If set Jade may return addtional progress data with each data chunk uploaded, which is
+            If set Jade may return additional progress data with each data chunk uploaded, which is
             then passed to any progress callback as above.  If not no additional data is returned
             or passed.
 

jadepy/jade_ble.py

@@ -122,11 +122,11 @@ async def _input_stream():
                                     f'Serial number: {self.serial_number or "<any>"}')
 
         # Peruse services and characteristics
-        # Get the 'handle' of the receiving charactersitic
+        # Get the 'handle' of the receiving characteristic
         for service in client.services:
             for char in service.characteristics:
                 if char.uuid == JadeBleImpl.IO_RX_CHAR_UUID:
-                    logger.debug(f'Found RX characterisitic - handle: {char.handle}')
+                    logger.debug(f'Found RX characteristic - handle: {char.handle}')
                     self.rx_char_handle = char.handle
 
                 if 'read' in char.properties:

logo/README.md

@@ -4,7 +4,7 @@
 python -c "from zopfli import zlib; import sys; open(sys.argv[2], 'wb').write(zlib.compress(open(sys.argv[1], 'rb').read()))" uncompressed_file.bin compressed_file.bin.gz
 ```
 
-# The input file used is the output of GIMP RGB C-Source image dump (file.c) which contains a stucture Picture.
+# The input file used is the output of GIMP RGB C-Source image dump (file.c) which contains a structure Picture.
 # Picture contains the following uint32_t width, height, bytes_per_pixel (always set to 2) and then the binary data in a pointer to a uint16_t
 
 # We extracted the binary data into uncompressed_file prepended with a single byte with the width (since it can at most be 240) and then we compressed it with the python above