Otherwise the Python network object continues to report that it is
attempting to connect.
Also make the return error code consistent with wifi scan.
Signed-off-by: Damien George <damien@micropython.org>
This makes sure deinit() can be called on the interface many times without
error, and that the state of the driver is fully reset.
Fixes issue #7493.
Signed-off-by: Damien George <damien@micropython.org>
This makes fill() about 7x faster (PYBV11 and PYBD_SF6) for the cost of +40
bytes of bytecode (or 120 bytes text).
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
The 72x40 OLED requires selecting the internal IREF, as opposed to the
default external IREF. This is an undocumented feature in the SSD1306
datasheet, but is present in the SSD1315 datasheet. It's possible the
72x40 OLED is actually using the newer SSD1315 controller. Sending the
IREF select command to SSD1306 displays has no effect on them, so it's
added to the init_display() instead of wrapping in an "if width = 72".
Also tested on a 128x64 OLED using the SSD1315 controller (smaller ribbon
cable) and the proposed change has no effect on the display, as the module
comes with the correct current limiting resistor. Internal and external
IREF work the same.
Fixes issue #7281.
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.
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.
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
iabdalkader
Jim Mussared
robert-hh
Damien George
Mike Causer
stijn
Andreas Motl
Damien George
Peter Hinch
Andrew Leech
Jeremy Herbert
Peter Hinch
roland
Mateusz Kijowski