| Age | Commit message (Collapse) | Author |
|---|
|
So this driver works on faster MCUs (that run this loop fast) with older,
slower SD cards.
Fixes issue #7129.
Signed-off-by: Damien George <damien@micropython.org>
|
|
This only needs to be enabled if a board uses FAT FS on external SPI flash.
When disabled (and using external SPI flash) 4k of RAM can be saved.
Signed-off-by: Damien George <damien@micropython.org>
|
|
Previously the interaction between the different layers of the Bluetooth
stack was different on each port and each stack. This commit defines
common interfaces between them and implements them for cyw43, btstack,
nimble, stm32, unix.
|
|
This is consistent with the other 'micro' modules and allows implementing
additional features in Python via e.g. micropython-lib's sys.
Note this is a breaking change (not backwards compatible) for ports which
do not enable weak links, as "import sys" must now be replaced with
"import usys".
|
|
Making it more specific to use 0x02 for display with an aspect ratio > 2
(resolutions 96x16 and 128x32) and 0x12 for all other sizes as recommended
by @mcauser. Tested with a 64x32 display which did not work before.
|
|
|
|
On CPython, and with pylint, the variables MATCH_ROM and SEARCH_ROM are
undefined. This code works in MicroPython because these variables are
constants and the MicroPython parser/compiler optimises them out. But it
is not valid Python because they are technically undefined within the scope
they are used.
This commit makes the code valid Python code. The const part is removed
completely because these constants are part of the public API and so cannot
be moved to the global scope (where they could still use the MicroPython
const optimisation).
|
|
This makes a cleaner separation between the: driver, HCI UART and BT stack.
Also updated the naming to be more consistent (mp_bluetooth_hci_*).
Work done in collaboration with Jim Mussared aka @jimmo.
|
|
This is run with uncrustify 0.70.1, and black 19.10b0.
|
|
These addresses were initially chosen to match the nRF24 Arduino library
examples but they are byte-reversed. So change them to be on-air
compatible with the Arduino library.
Also, the data sheet for the nRF24 says that RX data pipes 1-5 must share
the same top 32-bits, and must differ only in the LSbyte. The addresses
used here (while correct because they are on TX pipe and RX pipe 0) are
misleading in this sense, because it looks like they were chosen to share
the top 32-bits per the datasheet.
|
|
|
|
|
|
With a SPI flash that has more than 16MB, 32-bit addressing is required
rather than the standard 24-bit. This commit adds support for 32-bit
addressing so that the SPI flash commands (read/write/erase) are selected
automatically depending on the size of the address being used at each
operation.
|
|
|
|
Enabling WIZCHIP_USE_MAX_BUFFER will make the TX/RX buffers the maximum
available size, for use with MACRAW mode.
|
|
Otherwise the code can get stuck in an infinite loop if the SD card fails
to respond to a read.
|
|
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.
|
|
|
|
|
|
|
|
Fixes issue #3482.
|
|
|
|
Some ports (eg esp8266) need to have specific behaviour for driving a DHT
reliably.
|
|
|
|
pyb.umount(None, mountpoint) no longer works.
|
|
The intention of oflush() is to flush the "fast SPI" command itself so that
the SPI object is ready to use when the function returns.
|
|
Otherwise it can clash with time_t from the C standard include headers.
|
|
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 was a typo from the very first commit of this file.
|
|
|
|
These new API functions do not use the cache.
|
|
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.
|
|
A new directory drivers/bus/ is introduced, which can hold implementations
of bus drivers. A software QSPI implementation is added.
|
|
|
|
|
|
machine.SPI(0) results in ValueError on ESP8266. SPI(1) is the user
hardware SPI port (or use SPI(-1) for software SPI).
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
