GC finalization should be enabled for modlwip, or it may lead to GC
problems with socket objects. This decreases usable heap size from
36288 to 35968 (-320) bytes.
It belongs with the other pin config functions in machine_pin.c. Also,
esp_mphal.c is put in iRAM so this change saves about 300 bytes of iRAM
(and mp_hal_pin_open_drain is not a time critical function so doesn't
need to be in iRAM).
These drivers can now be used by any port (so long as that port has the
_onewire driver from extmod/modonewire.c).
These drivers replace the existing 1-wire and DS18X20 drivers in the
drivers/onewire directory. The existing ones were pyboard-specific and
not very efficient nor minimal (although the 1-wire driver was written in
pure Python it only worked at large enough CPU frequency).
This commit brings backwards incompatible API changes to the existing
1-wire drivers. User code should be converted to use the new drivers, or
check out the old version of the code and keep a local copy (it should
continue to work unchanged).
The 1-wire bus is defined with fixed timings so there should be no need to
change them dynamically at runtime. Making the timings fixed saves about
270 bytes of code and 20 bytes of RAM.
The reason it was separated is so that the low-level code could be put in
iRAM, for timing reasons. But:
1. Tests show that it's not necessary to have this code in iRAM for it to
function correctly, and taking it out of iRAM reclaims some of that precious
resource. Furthermore, even though these functions were in iRAM there were
some functions that it called (eg pin get/set functions) which were not in
iRAM, so partially defeated the purpose of putting the 1-wire code in iRAM.
2. It's easier to reuse this 1-wire code in other ports if it's in a single
file.
3. If it turns out that certain code does need to be in iRAM then one can
use the MP_FASTCODE macro to do that.
The latest fashion is pushing certificate sub-chains, instead of a single
certificate, during TLS handshake. These are pushed via single TLS record
and effectively put minimum size limit on TLS record buffer. Recently,
these commonly grew over 4K, so we have little choice but to adjust.
For consistent Pin/Signal class hierarchy. With it, Signal is a proper
(while still ducktyped) subclass of a Pin, and any (direct) usage of Pin
can be replace with Signal.
As stmhal's class is reused both as machine.Pin and legacy pyb.Pin,
high/low methods actually retained there.
This implements the orginal idea is that Signal is a subclass of Pin, and
thus can accept all the same argument as Pin, and additionally, "inverted"
param. On the practical side, it allows to avoid many enclosed parenses for
a typical declararion, e.g. for Zephyr:
Signal(Pin(("GPIO_0", 1))).
Of course, passing a Pin to Signal constructor is still supported and is the
most generic form (e.g. Unix port will only support such form, as it doesn't
have "builtin" Pins), what's introduces here is just practical readability
optimization.
"value" kwarg is treated as applying to a Signal (i.e. accounts for possible
inversion).
This follows the pattern of how all other headers are now included, and
makes it explicit where the header file comes from. This patch also
removes -I options from Makefile's that specify the mp-readline/timeutils/
netutils directories, which are no longer needed.
The C nearbyint function has exactly the semantics that Python's round()
requires, whereas C's round() requires extra steps to handle rounding of
numbers half way between integers. So using nearbyint reduces code size
and potentially eliminates any source of errors in the handling of half-way
numbers.
Also, bare-metal implementations of nearbyint can be more efficient than
round, so further code size is saved (and efficiency improved).
nearbyint is provided in the C99 standard so it should be available on all
supported platforms.
The -ansi flag is used for C dialect selection and it is equivalent to -std=c90.
Because it goes right before -std=gnu99 it is ignored as for conflicting flags
GCC always uses the last one.
All arguments to pin.irq are converted from keyword-only to positional, and
can still be specified by keyword so it's a backwards compatible change.
The default value for the "trigger" arg is changed from 0 (no trigger)
to rising+falling edge.
