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

[pythoncoder]

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)

[WhiteHare]

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?

[WhiteHare]

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.

[dhylands]

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

[pythoncoder]

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

[WhiteHare]

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.

[dhylands]

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.

[pythoncoder]

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