From 157f461488a4bf235c58a9bbe7e5f549496851ef Mon Sep 17 00:00:00 2001 From: fengyuchuanshen Date: Tue, 4 Nov 2025 21:20:37 +0800 Subject: [PATCH] chore: fix a large number of spelling issues Signed-off-by: fengyuchuanshen --- components/assets/gen_assets.py | 2 +- diy/README.md | 2 +- diy/esp32-cam/README.md | 2 +- diy/esp32-wrover-cam/README.md | 2 +- docs/index.rst | 4 ++-- jadepy/jade.py | 2 +- jadepy/jade_ble.py | 4 ++-- logo/README.md | 2 +- 8 files changed, 10 insertions(+), 10 deletions(-) diff --git a/components/assets/gen_assets.py b/components/assets/gen_assets.py index 97b8bf93..0028fab4 100644 --- a/components/assets/gen_assets.py +++ b/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], ' ') + print('Usage: python', sys.argv[0], ' ') sys.exit(1) input_file = sys.argv[1] diff --git a/diy/README.md b/diy/README.md index 3849f1d4..783b1ecc 100644 --- a/diy/README.md +++ b/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** diff --git a/diy/esp32-cam/README.md b/diy/esp32-cam/README.md index 9b8f1e4d..701cf9d2 100644 --- a/diy/esp32-cam/README.md +++ b/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) diff --git a/diy/esp32-wrover-cam/README.md b/diy/esp32-wrover-cam/README.md index 0c385342..f2b2465a 100644 --- a/diy/esp32-wrover-cam/README.md +++ b/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) diff --git a/docs/index.rst b/docs/index.rst index 879ea2d2..1df8c6f4 100644 --- a/docs/index.rst +++ b/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. diff --git a/jadepy/jade.py b/jadepy/jade.py index 5d8a8a73..9ac08274 100644 --- a/jadepy/jade.py +++ b/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. diff --git a/jadepy/jade_ble.py b/jadepy/jade_ble.py index 275ed610..c8aee7c1 100644 --- a/jadepy/jade_ble.py +++ b/jadepy/jade_ble.py @@ -122,11 +122,11 @@ async def _input_stream(): f'Serial number: {self.serial_number or ""}') # 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: diff --git a/logo/README.md b/logo/README.md index c1e7452d..459de24e 100644 --- a/logo/README.md +++ b/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