Adds support for NeoPixels on GPIO32 and GPIO33 on ESP32. Otherwise,
NeoPixels wired to GPIO32/33 wll silently fail without any hints to the
user.
With thanks to @robert-hh.
Fixes issue #7221.
ATOM is a very small ESP32 development board produced by M5Stack, with a
size of 24mm * 24mm, with peripherals such as WS2812, IR, button, MPU6886
(Only Matrix), and 8 GPIO extensions. It also has a plastic shell.
The random module's getrandbits() method didn't give a proper error message
when calling it with a value that was outside of the range of 1-32, which
can lead to confusion using this function (which under CPython can accept
numbers larger than 32). Now instead of simply giving a ValueError it
gives an error message that states that the number of bits is constrained.
Also, since the random module's functions getrandbits() and randint()
differ from CPython, tests have been added to describe these differences.
For getrandbits the relevant documentation is shown and added to the docs.
The same is given for randint method so that the information is more easily
found.
Finally, since the int object lacks the bit_length() method there is a test
for that method also to include within the docs, showing the difference to
CPython.
asan considers that memcmp(p, q, N) is permitted to access N bytes at each
of p and q, even for values of p and q that have a difference earlier.
Accessing additional values is frequently done in practice, reading 4 or
more bytes from each input at a time for efficiency, so when completing
"non_exist<TAB>" in the repl, this causes a diagnostic:
==16938==ERROR: AddressSanitizer: global-buffer-overflow on
address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff
READ of size 9 at 0x555555cd8dc8 thread T0
#0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
#1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301
#2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re
#3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513
#4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni
#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/
#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m
#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308
#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni
0x555555cd8dc8 is located 0 bytes to the right of global variable
'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of
size 8
'import_str' is ascii string 'import '
Signed-off-by: Jeff Epler <jepler@gmail.com>
This configuration is used by @ladyada and more often than it should
we've discovered late that a change introduced problems building
there.
By adding this to regular CI, hopefully we learn about and fix these
issues sooner rather than later.
Before, when an OnDiskBitmap was a paletted bitmap type, the palette
was internal to the OnDiskBitmap, and it internally performed the palette
conversion itself. When using with a tilegrid, a ColorConverter() object
always had to be passed.
Now, an OnDiskBitmap has a "pixel_shader" property. If the bitmap is
a paletted bitmap type, it is a (modifiable) Palette object. Otherwise,
it is a ColorConverter() object as before. This allows palette effects
to be applied to paletted OnDiskBitmaps.
Code that used to say:
```python
face = displayio.TileGrid(odb, pixel_shader=displayio.ColorConverter())
```
must be updated to say:
```python
face = displayio.TileGrid(odb, pixel_shader=odb.pixel_shader)
```
Compatible code for 6.x and 7.x can say
```python
face = displayio.TileGrid(odb, pixel_shader=getattr(odb, 'pixel_shader', ColorConverter())
```
With GCC 11 there is now a warning about array bounds of OTP-mac, due to
the OTP being a literal address.
Signed-off-by: Damien George <damien@micropython.org>
