`idf.py monitor` connects to the debug UART and shows the messages. In
contrast to a traditional terminal program, it also has the limited
ability to transform hex addresses into file & line number information,
especially for debug builds.
This requires the elf file be copied to a specific place.
.. this board is nearly the same as the "1.2" version originally
released, but makes a few changes to reduce pin conflicts between the 13-pin
camera header and the bootstrapping pins. "1.3" was introduced in summer
2020-- check the bottom of your board silk to find out whether you have a 1.2
or a 1.3, because it's not clear whether there is remaining 1.2 stock.
Another vexing fact about the 1.3 is that its LCD can have one of two
chipets, and the chipset used is not marked anywhere!
This is more or less a complete re-organization of the code.
* Use the actual byte size of the .bin file as the flash size,
as the algorithm for packing sections into the flash is complicated
* Match each section to a data region & find the high water mark in the
region
* Report on all the RAM regions, separately
Note that elftools is a requirement of esp-idf and so does not need to
be listed in our requirements.txt.
This detects an overflowed flash partition, such as
```
1452105 bytes used, -10313 bytes free in flash firmware space out of 1441792 bytes (1408.0kB).
444428 bytes used, 1652724 bytes free in ram for stack and heap out of 2097152 bytes (2048.0kB).
```
on a metro esp32-s2 built with debugging.
This also removes the need to pin share because we don't use the
status LED while user code is running.
The status flashes fallback to the HW_STATUS LED if no RGB LED is
present. Each status has a unique blink pattern as well.
One caveat is the REPL state. In order to not pin share, we set the
RGB color once. PWM and single color will be shutoff immediately but
DotStars and NeoPixels will hold the color until the user overrides
it.
Fixes#4133
As MicroDev1 pointed out the problem is a divide by zero when calculating the duty cycle.
Maybe need to check again in `common_hal_pwmio_pwmout_set_frequency()`.
FeatherS2 crashes if you set the PWMOut frequency to 0.
This change will raise `ValueError: Invalid PWM frequency` if the requested frequency is 0.
(Lifted from the atmel-samd port)
In #4683, tannewt noticed that uncrustify was not running on some
file in common-hal.
I investigated and found that it was not being run on a bunch of paths.
Rather than make incremental changes, I rewrote list_files to work
bsaed on regular expressions; these regular expressions are created from
the same git-style glob patterns.
I spot-checked some specific filenames after this change, and all looks good:
```
$ python3 tools/codeformat.py -v --dry-run tests/basics/int_small.py ports/raspberrypi/common-hal/pulseio/PulseIn.c extmod/virtpin.c tests/thread/thread_exit1.py ports/raspberrypi/background.h extmod/re1.5/recursiveloop.c
tools/codeformat.py -v --dry-run tests/basics/int_small.py ports/raspberrypi/common-hal/pulseio/PulseIn.c extmod/virtpin.c tests/thread/thread_exit1.py ports/raspberrypi/background.h extmod/re1.5/recursiveloop.c
uncrustify -c /home/jepler/src/circuitpython/tools/uncrustify.cfg -lC --no-backup extmod/virtpin.c ports/raspberrypi/background.h ports/raspberrypi/common-hal/pulseio/PulseIn.c
black --fast --line-length=99 -v tests/thread/thread_exit1.py
```
recursiveloop and int_small are excluded, while PulseIn, virtpin,
and background are included.
Testing running from a subdirectory (not _specifically_ supported though):
```
(cd ports && python3 ../tools/codeformat.py -v --dry-run raspberrypi/common-hal/pulseio/PulseIn.c ../extmod/virtpin.c)
../tools/codeformat.py -v --dry-run raspberrypi/common-hal/pulseio/PulseIn.c ../extmod/virtpin.c
uncrustify -c /home/jepler/src/circuitpython/tools/uncrustify.cfg -lC --no-backup ../extmod/virtpin.c raspberrypi/common-hal/pulseio/PulseIn.
```
As a side-effect, a bunch more files are re-formatted now. :-P