Fix some spelling mistakes
This commit is contained in:
parent
133013083a
commit
eedcc98cc5
@ -421,7 +421,7 @@ SPI Example
|
|||||||
"""Widget's one register."""
|
"""Widget's one register."""
|
||||||
with self.spi_device as spi:
|
with self.spi_device as spi:
|
||||||
spi.write(b'0x00')
|
spi.write(b'0x00')
|
||||||
i2c.readinto(self.buf)
|
spi.readinto(self.buf)
|
||||||
return self.buf[0]
|
return self.buf[0]
|
||||||
|
|
||||||
Use composition
|
Use composition
|
||||||
@ -462,7 +462,7 @@ like properties for state even if it sacrifices a bit of speed.
|
|||||||
Avoid allocations in drivers
|
Avoid allocations in drivers
|
||||||
--------------------------------------------------------------------------------
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
Although Python doesn't require managing memory, its still a good practice for
|
Although Python doesn't require managing memory, it's still a good practice for
|
||||||
library writers to think about memory allocations. Avoid them in drivers if
|
library writers to think about memory allocations. Avoid them in drivers if
|
||||||
you can because you never know how much something will be called. Fewer
|
you can because you never know how much something will be called. Fewer
|
||||||
allocations means less time spent cleaning up. So, where you can, prefer
|
allocations means less time spent cleaning up. So, where you can, prefer
|
||||||
@ -471,7 +471,7 @@ object with methods that read or write into the buffer instead of creating new
|
|||||||
objects. Unified hardware API classes such as `busio.SPI` are design to read and
|
objects. Unified hardware API classes such as `busio.SPI` are design to read and
|
||||||
write to subsections of buffers.
|
write to subsections of buffers.
|
||||||
|
|
||||||
Its ok to allocate an object to return to the user. Just beware of causing more
|
It's ok to allocate an object to return to the user. Just beware of causing more
|
||||||
than one allocation per call due to internal logic.
|
than one allocation per call due to internal logic.
|
||||||
|
|
||||||
**However**, this is a memory tradeoff so do not do it for large or rarely used
|
**However**, this is a memory tradeoff so do not do it for large or rarely used
|
||||||
@ -580,4 +580,4 @@ MicroPython compatibility
|
|||||||
--------------------------------------------------------------------------------
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
Keeping compatibility with MicroPython isn't a high priority. It should be done
|
Keeping compatibility with MicroPython isn't a high priority. It should be done
|
||||||
when its not in conflict with any of the above goals.
|
when it's not in conflict with any of the above goals.
|
||||||
|
@ -12,7 +12,7 @@ Adafruit CircuitPython Library Bundle
|
|||||||
We provide a bundle of all our libraries to ease installation of drivers and
|
We provide a bundle of all our libraries to ease installation of drivers and
|
||||||
their dependencies. The bundle is primarily geared to the Adafruit Express line
|
their dependencies. The bundle is primarily geared to the Adafruit Express line
|
||||||
of boards which feature a relatively large external flash. With Express boards,
|
of boards which feature a relatively large external flash. With Express boards,
|
||||||
its easy to copy them all onto the filesystem. However, if you don't have
|
it's easy to copy them all onto the filesystem. However, if you don't have
|
||||||
enough space simply copy things over as they are needed.
|
enough space simply copy things over as they are needed.
|
||||||
|
|
||||||
- The Adafruit bundles are available on GitHub: <https://github.com/adafruit/Adafruit_CircuitPython_Bundle/releases>.
|
- The Adafruit bundles are available on GitHub: <https://github.com/adafruit/Adafruit_CircuitPython_Bundle/releases>.
|
||||||
|
@ -20,10 +20,10 @@ be implemented:
|
|||||||
* SHA1 - A previous generation algorithm. Not recommended for new usages,
|
* SHA1 - A previous generation algorithm. Not recommended for new usages,
|
||||||
but SHA1 is a part of number of Internet standards and existing
|
but SHA1 is a part of number of Internet standards and existing
|
||||||
applications, so boards targeting network connectivity and
|
applications, so boards targeting network connectivity and
|
||||||
interoperatiability will try to provide this.
|
interoperability will try to provide this.
|
||||||
|
|
||||||
* MD5 - A legacy algorithm, not considered cryptographically secure. Only
|
* MD5 - A legacy algorithm, not considered cryptographically secure. Only
|
||||||
selected boards, targeting interoperatibility with legacy applications,
|
selected boards, targeting interoperability with legacy applications,
|
||||||
will offer this.
|
will offer this.
|
||||||
|
|
||||||
Constructors
|
Constructors
|
||||||
|
@ -21,7 +21,7 @@ standard Python library.
|
|||||||
You may need to change your code later if you rely
|
You may need to change your code later if you rely
|
||||||
on any non-standard functionality they currently provide.
|
on any non-standard functionality they currently provide.
|
||||||
|
|
||||||
CircuitPython's goal long-term goalis that code written in CircuitPython
|
CircuitPython's long-term goal is that code written in CircuitPython
|
||||||
using Python standard libraries will be runnable on CPython without changes.
|
using Python standard libraries will be runnable on CPython without changes.
|
||||||
|
|
||||||
Some libraries below are not enabled on CircuitPython builds with
|
Some libraries below are not enabled on CircuitPython builds with
|
||||||
@ -69,7 +69,7 @@ CircuitPython/MicroPython-specific libraries
|
|||||||
--------------------------------------------
|
--------------------------------------------
|
||||||
|
|
||||||
Functionality specific to the CircuitPython/MicroPython implementation is available in
|
Functionality specific to the CircuitPython/MicroPython implementation is available in
|
||||||
the following libraries. These libraries may change signficantly or be removed in future
|
the following libraries. These libraries may change significantly or be removed in future
|
||||||
versions of CircuitPython.
|
versions of CircuitPython.
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
|
@ -71,7 +71,7 @@ parameter should be `id`.
|
|||||||
(password) required to access said service. There can be further
|
(password) required to access said service. There can be further
|
||||||
arbitrary keyword-only parameters, depending on the networking medium
|
arbitrary keyword-only parameters, depending on the networking medium
|
||||||
type and/or particular device. Parameters can be used to: a)
|
type and/or particular device. Parameters can be used to: a)
|
||||||
specify alternative service identifer types; b) provide additional
|
specify alternative service identifier types; b) provide additional
|
||||||
connection parameters. For various medium types, there are different
|
connection parameters. For various medium types, there are different
|
||||||
sets of predefined/recommended parameters, among them:
|
sets of predefined/recommended parameters, among them:
|
||||||
|
|
||||||
|
@ -106,7 +106,7 @@ request a safe mode state which prevents the supervisor from running user code
|
|||||||
while still allowing access to the REPL and other resources.
|
while still allowing access to the REPL and other resources.
|
||||||
|
|
||||||
The core port initialization and reset methods are defined in
|
The core port initialization and reset methods are defined in
|
||||||
``supervisor/port.c`` and should be the first to be implemented. Its required
|
``supervisor/port.c`` and should be the first to be implemented. It's required
|
||||||
that they be implemented in the ``supervisor`` directory within the port
|
that they be implemented in the ``supervisor`` directory within the port
|
||||||
directory. That way, they are always in the expected place.
|
directory. That way, they are always in the expected place.
|
||||||
|
|
||||||
|
@ -13,7 +13,7 @@ When CircuitPython restarts it will create a fresh empty ``CIRCUITPY`` filesyste
|
|||||||
|
|
||||||
This often happens on Windows when the ``CIRCUITPY`` disk is not safely ejected
|
This often happens on Windows when the ``CIRCUITPY`` disk is not safely ejected
|
||||||
before being reset by the button or being disconnected from USB. This can also
|
before being reset by the button or being disconnected from USB. This can also
|
||||||
happen on Linux and Mac OSX but its less likely.
|
happen on Linux and Mac OSX but it's less likely.
|
||||||
|
|
||||||
.. caution:: To erase and re-create ``CIRCUITPY`` (for example, to correct a corrupted filesystem),
|
.. caution:: To erase and re-create ``CIRCUITPY`` (for example, to correct a corrupted filesystem),
|
||||||
follow one of the procedures below. It's important to note that **any files stored on the**
|
follow one of the procedures below. It's important to note that **any files stored on the**
|
||||||
@ -43,7 +43,7 @@ ValueError: Incompatible ``.mpy`` file.
|
|||||||
|
|
||||||
This error occurs when importing a module that is stored as a ``mpy`` binary file
|
This error occurs when importing a module that is stored as a ``mpy`` binary file
|
||||||
(rather than a ``py`` text file) that was generated by a different version of
|
(rather than a ``py`` text file) that was generated by a different version of
|
||||||
CircuitPython than the one its being loaded into. Most versions are compatible
|
CircuitPython than the one it's being loaded into. Most versions are compatible
|
||||||
but, rarely they aren't. In particular, the ``mpy`` binary format changed between
|
but, rarely they aren't. In particular, the ``mpy`` binary format changed between
|
||||||
CircuitPython versions 1.x and 2.x, and will change again between 2.x and 3.x.
|
CircuitPython versions 1.x and 2.x, and will change again between 2.x and 3.x.
|
||||||
|
|
||||||
|
2
main.c
2
main.c
@ -215,7 +215,7 @@ STATIC bool maybe_run_list(const char * const * filenames, pyexec_result_t* exec
|
|||||||
STATIC void cleanup_after_vm(supervisor_allocation* heap) {
|
STATIC void cleanup_after_vm(supervisor_allocation* heap) {
|
||||||
// Reset port-independent devices, like CIRCUITPY_BLEIO_HCI.
|
// Reset port-independent devices, like CIRCUITPY_BLEIO_HCI.
|
||||||
reset_devices();
|
reset_devices();
|
||||||
// Turn off the display and flush the fileystem before the heap disappears.
|
// Turn off the display and flush the filesystem before the heap disappears.
|
||||||
#if CIRCUITPY_DISPLAYIO
|
#if CIRCUITPY_DISPLAYIO
|
||||||
reset_displays();
|
reset_displays();
|
||||||
#endif
|
#endif
|
||||||
|
@ -160,7 +160,7 @@ mp_obj_t os_stat(mp_obj_t path_in) {
|
|||||||
MP_DEFINE_CONST_FUN_OBJ_1(os_stat_obj, os_stat);
|
MP_DEFINE_CONST_FUN_OBJ_1(os_stat_obj, os_stat);
|
||||||
|
|
||||||
//| def statvfs(path: str) -> Tuple[int, int, int, int, int, int, int, int, int, int]:
|
//| def statvfs(path: str) -> Tuple[int, int, int, int, int, int, int, int, int, int]:
|
||||||
//| """Get the status of a fileystem.
|
//| """Get the status of a filesystem.
|
||||||
//|
|
//|
|
||||||
//| Returns a tuple with the filesystem information in the following order:
|
//| Returns a tuple with the filesystem information in the following order:
|
||||||
//|
|
//|
|
||||||
@ -168,10 +168,10 @@ MP_DEFINE_CONST_FUN_OBJ_1(os_stat_obj, os_stat);
|
|||||||
//| * ``f_frsize`` -- fragment size
|
//| * ``f_frsize`` -- fragment size
|
||||||
//| * ``f_blocks`` -- size of fs in f_frsize units
|
//| * ``f_blocks`` -- size of fs in f_frsize units
|
||||||
//| * ``f_bfree`` -- number of free blocks
|
//| * ``f_bfree`` -- number of free blocks
|
||||||
//| * ``f_bavail`` -- number of free blocks for unpriviliged users
|
//| * ``f_bavail`` -- number of free blocks for unprivileged users
|
||||||
//| * ``f_files`` -- number of inodes
|
//| * ``f_files`` -- number of inodes
|
||||||
//| * ``f_ffree`` -- number of free inodes
|
//| * ``f_ffree`` -- number of free inodes
|
||||||
//| * ``f_favail`` -- number of free inodes for unpriviliged users
|
//| * ``f_favail`` -- number of free inodes for unprivileged users
|
||||||
//| * ``f_flag`` -- mount flags
|
//| * ``f_flag`` -- mount flags
|
||||||
//| * ``f_namemax`` -- maximum filename length
|
//| * ``f_namemax`` -- maximum filename length
|
||||||
//|
|
//|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user