Please could you try this code on nRF* hardware [SOLVED]

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
Post Reply
User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Please could you try this code on nRF* hardware [SOLVED]

Post by pythoncoder » Fri Nov 02, 2018 8:12 am

There is a report here that the following piece of code throws an exception on nRF52840. It runs on CPython. It also runs on MicroPython on the targets I have to hand: Unix, Pyboard and ESP8266.

The exception is "TypeError: 'memoryview' object doesn't support item assignment". Is this a consequence of a build option? It would be good if people with nRF* boards could paste it and report findings (good and bad).

Code: Select all

radioBuffer = bytearray(256)
mv = memoryview(radioBuffer)

def copyStringToRadioBuffer(s):
    l = len(s)
    mv[: l] = s.encode('utf8')[: l]
    mv[l] = 0

copyStringToRadioBuffer('The quick brown fox\n')
print(radioBuffer)
Peter Hinch
Index to my micropython libraries.

User avatar
WhiteHare
Posts: 129
Joined: Thu Oct 04, 2018 4:00 am

Re: Please could you try this code on nRF* hardware

Post by WhiteHare » Fri Nov 02, 2018 1:08 pm

Not sure if this helps or not, but here's the result on a BBC micro:bit (which is an nRF51822):

Code: Select all


>>> radioBuffer = bytearray(256)
>>> mv = memoryview(radioBuffer)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'memoryview' is not defined
>>>

Is memoryview a part of some particular module that I need to import first?

User avatar
WhiteHare
Posts: 129
Joined: Thu Oct 04, 2018 4:00 am

Re: Please could you try this code on nRF* hardware

Post by WhiteHare » Fri Nov 02, 2018 3:59 pm

Here's the results on an nRF52832-DK:

Code: Select all

>>> MicroPython v1.9.4-651-g0f6f86ca4-dirty on 2018-10-24; PCA10040 with NRF52832
Type "help()" for more information.
>>> radioBuffer=bytearray(256)
>>> mv = memoryview(radioBuffer)
>>> def copyStringToRadioBuffer(s):
...     l = len(s)
...     mv[: l] = s.encode('utf8')[: l]
...     mv[l] = 0
...
>>> copyStringToRadioBuffer('The quick brown fox\n')
Traceback (most recent call last):
  File "<stdin>", in <module>
  File "<stdin>", in copyStringToRadioBuffer
TypeError: 'memoryview' object doesn't support item assignment
>>>
It would be nice if someone else could confirm this as well, in case perhaps I made some kind of build error.

Interesting that it seems to recognize the memoryview object but yet also claims that it doesn't support assignment. Strange.

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Please could you try this code on nRF* hardware

Post by dhylands » Fri Nov 02, 2018 4:45 pm

Check to see if MICROPY_PY_ARRAY_SLICE_ASSIGN is set to 1 in the mpconfigport/baord.h file

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Please could you try this code on nRF* hardware

Post by pythoncoder » Fri Nov 02, 2018 5:10 pm

@dhylands That sounds promising. There seems no reason to disable it on a target with 256K of RAM.

Re BBC micro:bit I too tried that, with the same outcome. The different error message suggests that memoryview objects are disabled entirely. This is understandable given the very limited resources and the intended beginner audience.
Peter Hinch
Index to my micropython libraries.

User avatar
WhiteHare
Posts: 129
Joined: Thu Oct 04, 2018 4:00 am

Re: Please could you try this code on nRF* hardware

Post by WhiteHare » Fri Nov 02, 2018 7:39 pm

dhylands wrote:
Fri Nov 02, 2018 4:45 pm
Check to see if MICROPY_PY_ARRAY_SLICE_ASSIGN is set to 1 in the mpconfigport/baord.h file
Good news: that worked. However, for the benefit of other readers, I think you probably meant the mpconfigport.h file.

:D

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Please could you try this code on nRF* hardware

Post by dhylands » Fri Nov 02, 2018 8:29 pm

I was trying to say mpconfigport.h or mpconfigboard.h

MICROPY_PY_ARRAY_SLICE_ASSIGN is set to 0 in py/mpconfig.h and the other 2 places that you can override this are either on a port level (mpconfigport.h) or on a board level (mpconfigboard.h).

Which place to set it will depend on the boards being used. For example, setting it to 1 in mpconfigport.h probably means that you may need to set it to 0 in the boards/microbit/mpconfigboard.h file.

It kind of becomes a tradeoff of how many boards want it set to 0 and how many want it set to 1.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Please could you try this code on nRF* hardware

Post by pythoncoder » Sat Nov 03, 2018 10:11 am

@WhiteHare Arguably your solution is best as it will work with the standard configuration. Quite why this config option is the default on a target with so much RAM is puzzling.

@dhylands I think the build options have become confusing. It would be good if the defaults could be combined in consistent ways and documented, but I've no idea how feasible this is. I'm thinking of something on the lines of "small", "medium" and "full" builds depending on the capability of the target.

At the moment users find entirely orthodox code fails; they need a detailed understanding of the build options to figure out the reason why. This strikes me as unsatisfactory.
Peter Hinch
Index to my micropython libraries.

Post Reply