| Age | Commit message (Collapse) | Author |
|---|
|
- The wrong ACK is returned and checked.
- Send secondary DNS to google.
|
|
|
|
- Fix the BSSID byte order from scan and netinfo.
- Make sure ESSID from netinfo is null terminated.
|
|
Previously the use of `range(start,stop,step)` caused an allocation.
Replace with while loop.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
|
|
- Add WiFi/BT drivers for ublox Nina-W10 (esp32 based) module.
- Add ublox Nina-W10 Python module in extmod.
|
|
The change affects dht.py from the drivers directory as well to include the
logic for the mimxrt port.
|
|
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>
|
|
Saves 71 bytes of bytecode.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
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>
|
|
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
Signed-off-by: Damien George <damien@micropython.org>
|
|
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.
|
|
And clean up (make more efficient) display set-up commands.
|
|
|
|
|
|
This removes any references to a specific SDMMC instance, making the driver
more generic/portable.
|
|
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
|
