Thanks to visit codestin.com
Credit goes to github.com

Skip to content

nrf: Enable binascii, hashlib modules #761

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 12, 2018
Merged

Conversation

jepler
Copy link

@jepler jepler commented Apr 13, 2018

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 dhalbert requested a review from microbuilder April 13, 2018 19:00
@dhalbert
Copy link
Collaborator

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

@arturo182
Copy link
Collaborator

@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
Copy link
Author

jepler commented Apr 13, 2018

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
Copy link

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
Copy link
Member

tannewt commented Apr 13, 2018

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
Copy link
Author

jepler commented Apr 13, 2018

@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
Copy link
Member

tannewt commented Apr 13, 2018

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

@jepler
Copy link
Author

jepler commented Apr 13, 2018

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
Copy link
Author

jepler commented May 6, 2018

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

@tannewt
Copy link
Member

tannewt commented May 7, 2018

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

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

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

'hashlib' 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 nrf52 seems like the only one that
needs it.
@jepler
Copy link
Author

jepler commented May 11, 2018

@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.

@jepler jepler changed the title nrf: Enable ubinascii, uhashlib modules nrf: Enable binascii, hashlib modules May 11, 2018
Copy link
Member

@tannewt tannewt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@tannewt tannewt merged commit ce5eae1 into adafruit:master May 12, 2018
@jepler jepler deleted the nrf-modules branch November 3, 2021 21:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants