DS1822P sensors behave just like the DS18B20 except for the following:
- it has a different family code: 0x22
- it has only the GND and DQ pins connected, it uses parasitic power from
the data line
Contributed by @nebelgrau77.
It seems that some cards do not tolerate releasing the card (by setting CS
high) after issuing CMD17 (and 18) and raising it again before reading
data. Somehow this causes the 0xfe data start marker not being read and
SDCard.readinto() is spinning forever (or until this byte is in the data).
This seems to fix weird behviour of SDCard.readblocks() returning different
data, also solved hanging os.mount() for my case with a 16GB Infineon card.
This stackexchange answer gives more context:
https://electronics.stackexchange.com/questions/307214/sd-card-spi-interface-issue-read-operation-returns-0x3f-0xff-instead-of-0x7f-0#307268
This patch renames the existing SPI flash API functions to reflect the fact
that the go through the cache:
mp_spiflash_flush -> mp_spiflash_cache_flush
mp_spiflash_read -> mp_spiflash_cached_read
mp_spiflash_write -> mp_spiflash_cached_write
This patch removes the global cache variables from the SPI flash driver and
now requires the user to provide the cache memory themselves, via the SPI
flash configuration struct. This allows to either have a shared cache for
multiple SPI flash devices (by sharing a mp_spiflash_cache_t struct), or
have a single cache per device (or a mix of these options).
To configure the cache use:
mp_spiflash_cache_t spi_bdev_cache;
const mp_spiflash_config_t spiflash_config =
// any bus options
.cache = &spi_bdev_cache,
};
mp_spiflash_read had a bug in it where "dest" and "addr" were incremented
twice for a certain special case. This was fixed, which then allowed the
function to be simplified to reduce code size.
mp_spiflash_write had a bug in it where "src" was not incremented correctly
for the case where the data to be written included the caching buffer as
well as some bytes after this buffer. This was fixed and the resulting
code simplified.
This patch alters the SPI-flash memory driver so that it uses the new
low-level C SPI protocol (from drivers/bus/spi.h) instead of the uPy SPI
protocol (from extmod/machine_spi.h). This allows the SPI-flash driver to
be used independently from the uPy runtime.
This patch takes the software SPI implementation from extmod/machine_spi.c
and moves it to a dedicated file in drivers/bus/softspi.c. This allows the
SPI driver to be used independently of the uPy runtime, making it a more
general component.
The spiflash memory driver is reworked to allow the underlying bus to be
either normal SPI or QSPI. In both cases the bus can be implemented in
software or hardware, as long as the spiflash driver is passed the correct
configuration structure.
This commit fixes two things:
1. Do not allocate on the heap in readblocks() - unless the block size
is bigger than 512 bytes.
2. Raise an error instead of returning 1 to indicate an error: the FAT
block device layer does not check the return value. And other
backends (e.g. esp32 blockdev) also raise an error instead of
returning non-zero.
This patch implements the basic SPI read/write functions for the W5500
chip. It also allows _WIZCHIP_ to be configured externally to select the
specific Wiznet chip.
The poweroff() and poweron() methods are used to do soft power control of
the display, and this patch makes these methods work the same for both I2C
and SPI interfaces.
Header files that are considered internal to the py core and should not
normally be included directly are:
py/nlr.h - internal nlr configuration and declarations
py/bc0.h - contains bytecode macro definitions
py/runtime0.h - contains basic runtime enums
Instead, the top-level header files to include are one of:
py/obj.h - includes runtime0.h and defines everything to use the
mp_obj_t type
py/runtime.h - includes mpstate.h and hence nlr.h, obj.h, runtime0.h,
and defines everything to use the general runtime support functions
Additional, specific headers (eg py/objlist.h) can be included if needed.
It removes the need for a wrapper Python function to dispatch to the
framebuf method which makes each function call a bit faster, roughly 2.5x.
This patch also adds the rest of the framebuf methods to the SSD class.
The SPI flash driver now supports using an arbitrary SPI object to
communicate with the flash chip, and in particular can use a hardware SPI
peripheral.
- Changed: ValueError, TypeError, NotImplementedError
- OSError invocations unchanged, because the corresponding utility
function takes ints, not strings like the long form invocation.
- OverflowError, IndexError and RuntimeError etc. not changed for now
until we decide whether to add new utility functions.
The code conventions suggest using header guards, but do not define how
those should look like and instead point to existing files. However, not
all existing files follow the same scheme, sometimes omitting header guards
altogether, sometimes using non-standard names, making it easy to
accidentally pick a "wrong" example.
This commit ensures that all header files of the MicroPython project (that
were not simply copied from somewhere else) follow the same pattern, that
was already present in the majority of files, especially in the py folder.
The rules are as follows.
Naming convention:
* start with the words MICROPY_INCLUDED
* contain the full path to the file
* replace special characters with _
In addition, there are no empty lines before #ifndef, between #ifndef and
one empty line before #endif. #endif is followed by a comment containing
the name of the guard macro.
py/grammar.h cannot use header guards by design, since it has to be
included multiple times in a single C file. Several other files also do not
need header guards as they are only used internally and guaranteed to be
included only once:
* MICROPY_MPHALPORT_H
* mpconfigboard.h
* mpconfigport.h
* mpthreadport.h
* pin_defs_*.h
* qstrdefs*.h
A previous version of the 1-wire driver (which was recently replaced by the
current one) had this behaviour and it allows to create a 1-wire bus
without any external pull-up resistors.
These drivers can now be used by any port (so long as that port has the
_onewire driver from extmod/modonewire.c).
These drivers replace the existing 1-wire and DS18X20 drivers in the
drivers/onewire directory. The existing ones were pyboard-specific and
not very efficient nor minimal (although the 1-wire driver was written in
pure Python it only worked at large enough CPU frequency).
This commit brings backwards incompatible API changes to the existing
1-wire drivers. User code should be converted to use the new drivers, or
check out the old version of the code and keep a local copy (it should
continue to work unchanged).
Damien George