← index #14429Issue #14280
Off-topic · high · value 3.861
QUERY · ISSUE

Incorrect static const data behavior in native module on esp32.

openby BrianPughopened 2024-05-05updated 2024-07-15
bugport-esp32

Checks

  • I agree to follow the MicroPython Code of Conduct to ensure a safe and respectful space for everyone.

  • I've searched for existing issues matching this bug, and didn't find any.

Port, board and/or hardware

esp32

MicroPython version

MicroPython v1.22.2 on 2024-02-22; Generic ESP32 module with ESP32

Reproduction

I have a medium-complex native module that performs lossless data compression/decompression.
My code as a native modules has been tested to work on x64 and armv6m. I'm currently testing on esp32 and my code is not longer working; I have narrowed it down to the following:

I have a few static const variables defined here. If I remove the static, the code works fine. However, I tried adding static to examples/natmod/features1, and that code works fine with a static. So I have no idea what's going on here.

I found this out because write_to_bit_buffer was being invoked with n_bits=32 at one point, and I traced this down to huffman_bits[0] == 32, but obviously the value should be the constant 0x2.

Expected behaviour

If my library is operating correctly, it should have the following behavior:

>>> import tamp
>>> tamp.compress(b"foo")
b'X\xb3\x04\x18'
>>> tamp.decompress(tamp.compress(b"foo"))
bytearray(b'foo')

Observed behaviour

Accessing the RO data results in incorrect values.

Additional Information

No, I've provided everything above.

CANDIDATE · ISSUE

ruff: ptr8 and ptr16 yield error on pre-commit hooks

openby ubidefeoopened 2024-04-11updated 2024-04-11
bug

Checks

  • I agree to follow the MicroPython Code of Conduct to ensure a safe and respectful space for everyone.

  • I've searched for existing issues matching this bug, and didn't find any.

Port, board and/or hardware

esp32 port, esp32s3

MicroPython version

v1.22.0-181-gca696fb65

Reproduction

Since my last check-out, a module I have been freezing for months yields an error.
I have pre-commit hooks enabled to save time on PRs, and this error never happened before with the code I had.

My module has this

@micropython.viper
    @staticmethod
    def _pack16(glyphs, idx: uint, fg_color: uint, bg_color: uint):

and inside this method

buffer = bytearray(256)
bitmap = ptr16(buffer)
glyph = ptr8(glyphs)

Expected behaviour

This check did not fail a couple of weeks ago, hence something must have changed in the checks.
Any pointers to how I should solve this?

If I add # noqa: F821 to the offending lines it passes the ruff check, but that feels wrong.

Observed behaviour

MicroPython codeformat.py for changed C files............................Passed
ruff.....................................................................Failed
- hook id: ruff
- exit code: 1

ports/esp32/boards/LILYGO_T-QT-Pro/modules/st7789py.py:633:18: F821 Undefined name `ptr16`
ports/esp32/boards/LILYGO_T-QT-Pro/modules/st7789py.py:634:17: F821 Undefined name `ptr8`
ports/esp32/boards/LILYGO_T-QT-Pro/modules/st7789py.py:664:18: F821 Undefined name `ptr16`
ports/esp32/boards/LILYGO_T-QT-Pro/modules/st7789py.py:665:17: F821 Undefined name `ptr8`
Found 4 errors.

ruff-format..............................................................Passed
Spellcheck for changed files (codespell).................................Passed

Additional Information

No, I've provided everything above.

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied