nrf: Enable binascii, hashlib modules

[jepler]

These modules would be very handy to have in order to implement a
more robust replacement for ampy. It costs 2192 bytes of text and
no data or bss.

'ubinascii' has base64 encoding, which can be used to create a fully
8-bit-clean transport above the slightly cooked serial connection of
these boards.

'uhashlib' is a bit less critical, but I have found it handy to
be able to robustly checksum remote files.

I see this as only being useful on ports which don't have USB block
device support, so atmel-samd doesn't need it. These modules are
already on esp8266 so I think nrf52832 seems like the only one that
needs it.

[dhalbert]

Adding @microbuilder as a reviewer, because he is best aware of the storage budget on nrf.

[arturo182]

@jepler can you verify that you can still build the feather with SD 5.0.0 (make clean && make ... SOFTDEV_VERSION=5.0.0)

Because looking at https://travis-ci.org/adafruit/circuitpython/jobs/366250196#L1146 and https://github.com/adafruit/circuitpython/blob/master/ports/nrf/boards/feather52/custom_nrf52832_dfu_app_5.0.0.ld#L26, I'm not sure if it will fit.

[jepler]

Yes, it succeeds locally. But note that I am building with a different (older) arm-none-eabi toolchain than is recommended. (My bins are actually somewhat bigger)

I'm also sitting on a patch to enable lto for nrf52 (didn't actually test the resulting binary yet, and anyway I have the same toolchain concerns when it comes to local testing); it saves nearly 6kB of text so if I let you have that can I use up 2kB of the savings right away?

[sommersoft]

Also, remember there are still a few shared modules left on the list to try and get in #526. Not trying to shoot this down, just a reminder of the juggling act. 😄

[tannewt]

I'd like to see these renamed to binascii and hashlib to match CPython too. Please verify they are strict subsets of the CPython versions too.

[jepler]

@tannewt how strict are we about strict subsets? For instance, within ubinascii the function names are a strict subset

>>> import ubinascii
>>> dir(ubinascii)
['__name__', 'hexlify', 'unhexlify', 'a2b_base64', 'b2a_base64']

but I quickly found that CP is more loose with type requirements than CPython3. CP:

>>> ubinascii.hexlify('12345')
b'3132333435'

Python 3.5.3:

>>> binascii.hexlify('12345')
TypeError: a bytes-like object is required, not 'str'

Similarly for hashlib:

>>> uhashlib.sha1("hi").digest()
b'\xc2+_\x91x4&\tB\x8doQ\xb2\xc5\xafL\x0b\xdejB'

vs

>>> hashlib.sha1("hi").digest()
TypeError: Unicode-objects must be encoded before hashing

[tannewt]

Ideally we'd throw the same error. The goal would be that CircuitPython code will run in CPython just fine.

[jepler]

Okay, let's consider this to be in hold until I can work on making the module more cpython3 compatible. It'll be 2 weeks minimum.

[jepler]

The pull requests for python3 compatibility of binascii are in, the hashlib pull request has just been created.

[tannewt]

@jepler Both PRs are in so please update this PR and we'll get it merged in. Thanks!

[jepler]

@tannewt updated. However, gentle reminder to consider that I'm competing with #526 on flash space. For @arturo182 I did verify that the compile still completes successfully when building using SOFTDEV_VERSION=5.0.0.

[tannewt]

If we end up needing the space later we can disable. I don't think we need to lock down the available APIs until 4.0. nRF52 support will be beta/preliminary in 3.0.