profile
viewpoint
Daniel Mizyrycki mzdaniel San Francisco

mzdaniel/loadconfig 5

loadconfig is a tool to simplify configuration management

mzdaniel/alpinewheels 2

Temporary support for Alpine wheels based on musl libc

mzdaniel/django-selenium-test-runner 2

Incorporate functional testing into Django's manage.py test subcommand using Selenium web testing tools.

mzdaniel/micropython-iot 1

Micropython IoT libraries and tools

daguz019/docker 0

Docker - the open-source application container engine

mzdaniel/archlinux 0

Arch install test

mzdaniel/buildbot 0

Python-based continuous integration testing framework; send pull requests for your patches!

mzdaniel/code.pinaxproject.com 0

the site behind code.pinaxproject.com

mzdaniel/cookiecutter-django 0

Cookiecutter Django is a framework for jumpstarting production-ready Django projects quickly.

pull request commentmicropython/micropython

WIP: nrf: Add flash block device for VFS filesystems.

Fantastic @glennrub! According to a very quick test, with this PR, littlefs works natively on xenon's flash and rshell with it. I'll do more extensive tests, including migrating a production device to littlefs.

Re splitting mpconfigport.h: +1. This should make the code cleaner and improve reliability.

Regarding VFS block size, 4K for a tiny FS of 256K seems really big. I didn't read littlefs specs (yet), but if a file takes a full block, this means the fs cannot host many files.

glennrub

comment created time in 7 days

pull request commentmicropython/micropython

WIP: nrf: Add flash block device for VFS filesystems.

I don't understand. I thought your repo was in this state https://github.com/micropython/micropython/pull/5472#issuecomment-573267269

From there make BOARD=pca10056 MICROPY_VFS_FAT=1 does compile and glennrub said its working there.

glennrub

comment created time in 16 days

pull request commentmicropython/micropython

WIP: nrf: Add flash block device for VFS filesystems.

Not sure what is the issue. The tests I mentioned above were done introducing the exact same changes you did in mpconfigboard.h into pca10059 and simply make BOARD=pca10059 MICROPY_VFS_FAT=1 as mention in https://github.com/micropython/micropython/tree/master/ports/nrf#enable-micropy_vfs_fat

Hope it helps

glennrub

comment created time in 17 days

issue commentmicropython/micropython

NRF - Frozen Modules not Available in REPL

NRF is in the process of gain VFS functionality. AFAICT, rshell works after applying https://github.com/micropython/micropython/pull/5472

pacmac

comment created time in 19 days

pull request commentmicropython/micropython

drivers: add general neopixel driver for all ports to use

Congratulations for Micropython's v1.12! It's certainly an awesome release.

Now that we have 1.12 out and in 2020, here are my findings. According with some visual test and oscilloscope measures, the C loop code seems too slow for the nrf52840 that runs at 64MHz. There might be optimizations and/or compile options to still make it work in C, or maybe am I missing something else?

neopixel_short_timing

The test shown in the picture uses the same drivers/neopixel/neopixel.c, an identity function for mp_hal_delay_ns_calc_neopixel to simplify logic, and this code::

from machine import neopixel_write, Pin
neopixel_write(Pin(4, Pin.OUT),(1,2,4,1), bytes([17,0,0]))

With this setup we get 820ns for T0H which is too slow, getting mistaken for a T1H and driving the neopixel to full white (255, 255, 255).

Some trials in assembly are much more promising but much harder to code and port.

neopixel_short_timing_asm

The picture shows the following code in action, getting a much more workable 160ns for a T0H::

GPIO = const(0x50000000)
OUTCLR = const(GPIO + 0x50c)
OUTSET = const(GPIO + 0x508)
T0H = const(1)
T0L = const(1)

# Dummy function showing timing signal
@micropython.asm_thumb
def tx_byte(r0):          # r0 (gpio bit position)
    mov(r3, 8)            # loop for a 0 byte
    label(main_loop)
    mov(r1, T0H)
    mov(r2, T0L)
    movwt(r7, OUTSET)     # turn pin on for bit
    str(r0, [r7, 0])
    label(delay_low_on)   # keep pin on for TH cycles
    sub(r1, 1)
    bgt(delay_low_on)
    movwt(r7, OUTCLR)     # set pin off for 0-bit
    str(r0, [r7, 0])
    label(delay_low_off)  # keep pin off for (at least) T0L cycles
    sub(r2, 1)
    bgt(delay_low_off)
    sub(r3, 1)
    bgt(main_loop)

from machine import Pin
pin = 4                   # Use gpio 4
Pin(pin, Pin.OUT)
tx_byte(1 << pin)         # Translate gpio number to gpio bit position

And finally many boards have high resolution timers (or even hardware PWM) we could use. My concern here is how to create code that is easy to port.

Happy New Year!

dpgeorge

comment created time in a month

pull request commentmicropython/micropython

WIP: nrf: Add flash block device for VFS filesystems.

Thank you glennrub for this PR.

When adding MP_QSTR_ilistdir and MICROPY_PY_UERRNO (and of course MICROPY_VFS_VFAT, MICROPY_VFS_LFS1, MICROPY_VFS_LFS2 plus minor changes on moduos.c) all Fat and LittleFS tests are passing (with vfs_fat_ramdisklarge.py (way too large for Particle Xenon boards) and vfs_userfs (uio not available) skipping), which is fantastic.

Using vfat seems to work pretty well, formatting and using the fs

>>> import nrf, os
>>> os.umount('/flash')
>>> os.VfsFat.mkfs(nrf.flashbdev)
>>> os.mount(nrf.flashbdev, '/')
>>> os.mkdir('/lib')
>>> with open('/lib/test.py', 'w') as f:
...     f.write("print('Hello world\\n')")
...
22
>>> print(open('/lib/test.py').read())
print('Hello world\n')

Shouldnt modules under /lib be able to import?

>>> import test
Traceback (most recent call last):
  File "<stdin>", in <module>
ImportError: no module named 'test'

Writing on /test.py will import correctly

>>> os.rename('/lib/test.py', '/test.py')
>>> import test
Hello world

The extended interface needed for littlefs seems to be missing so far, but maybe can be worked out in a future PR? I am happy to help.

>>> os.VfsLfs2.mkfs(nrf.flashbdev)
Traceback (most recent call last):
  File "<stdin>", in <module>
TypeError: function takes 3 positional arguments but 4 were given

In any case thank you again for this great addition (including the ability to use rshell ;) and happy New Year!

glennrub

comment created time in a month

issue commentmicropython/micropython

open() implementation differs from CPython and is creating a file with different name than specified

It is important to realize micropython cannot possible replicate cpython behavior one by one, especially on edge cases like this where there is an intentional invalid argument. On a desktop machine, python3.8 takes at least of 10 megabytes of ram just to launch (and this does not include the OS). ESP8266 has 64 kilobytes of total ram for doing everything (quite a limited space for today's standards), almost 3 order of magnitude smaller. Don't you rather use the resources available to do something more productive than printing a pretty error message?

panekk

comment created time in 2 months

pull request commentmicropython/micropython

RFC: docs: Replace "umodule" with "module" everywhere.

For learnability and aesthetics perspective, simplifying namespaces is a big +1. As Jimmo mention and as instructor myself, using "module" everywhere instead of "umodule" is important while teaching Python. For example, a bicycle is not expected to acelerate as much as an airplane, but the aceleration concept is the same regardless of the name.

Compatibility wise, it isn't a particularly pleasant experience to have to wrap code in try/except blocks for obvious namespaces just to 'teach' the computer where to find the functionality people need, making code much harder to read, write, and reason about.

jimmo

comment created time in 2 months

issue commentmicropython/micropython

ESP8266 has no littlefs support?

This table explains your findings too.

jedie

comment created time in 2 months

issue commentmicropython/micropython

ESP8266 has no littlefs support?

Although work in LittleFS spans for some time, general availability on Micropython ports is pretty recent. I think the docs refer to the new to be released Micropython v1.12.

jedie

comment created time in 2 months

PR opened micropython/micropython

Fix typo in block device code example

After this PR, the following code in the Custom block devices docs will print 'Hello world'.

BTW, it might be a good idea to include the last 3 lines of my test there as a full example to reasure users on their understanding of the ram block device with extended interface

import os

bdev = RAMBlockDev(512, 50) os.VfsLfs2.mkfs(bdev) os.mount(bdev, '/ramdisk')

with open('/ramdisk/hello.txt', 'w') as f: f.write('Hello world') print(open('/ramdisk/hello.txt').read())

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchmzdaniel/micropython

branch : docs_block_device

created branch time in 2 months

pull request commentmicropython/micropython

drivers: add general neopixel driver for all ports to use

Sure. I think I figured out the namespacing part. I'll wait for v1.12 to report findings on the Xenon. Thank you again Damien.

dpgeorge

comment created time in 2 months

pull request commentmicropython/micropython

Enable USB port on Particle Xenon board

Happy to give back to our community

mzdaniel

comment created time in 2 months

pull request commentmicropython/micropython

[WIP] nrf: Change Xenon board to use built-in bootloader.

Ah, it completely escaped me to test if UART was live on the boards.

And thank you again for the outstanding Micropython.

dpgeorge

comment created time in 2 months

issue commentmicropython/micropython

[nRF port] Unable to Activate the FAT File System

Seems that this issue is also preventing little fs to be used on nrf. When adding vfs_lfs (and verifying it properly works on ramdisk [https://github.com/micropython/micropython/blob/master/docs/reference/filesystem.rst#custom-block-devices]), flash access stops working properly:

pyboard -f cp README.md : cp README.md :README.md Traceback (most recent call last): File "<stdin>", in <module> OSError: 1

As far as I can tell, enabling VFS breaks flash on nrf

sebi5361

comment created time in 2 months

PR opened micropython/micropython

Enable USB port on Particle Xenon board

As mention in https://github.com/micropython/micropython/pull/5158#issuecomment-559931181, it will be great to run Micropython in Xenon boards. After applying the PR, the xenon board USB port becomes active and pyboard.py can be used.

Tests performed:

Test results are the exact same as with master pca10059::

(cd tests; ./run-tests --target nrf)

509 tests performed (14330 individual testcases) 506 tests passed 192 tests skipped: builtin_next_arg2 builtin_pow3 builtin_pow3_intbig builtin_range_binop builtin_round_int builtin_round_intbig bytearray_slice_assign bytes_partition class_delattr_setattr class_descriptor class_notimpl class_reverse_op deque1 deque2 dict_fixed errno1 exception_chain io_buffered_writer io_bytesio_cow io_bytesio_ext io_bytesio_ext2 io_iobase io_stringio1 io_stringio_with io_write_ext memoryview1 memoryview_itemsize namedtuple_asdict ordereddict1 ordereddict_eq slice_attrs special_methods2 string_center string_partition string_rpartition string_splitlines subclass_native_call sys_getsizeof btree1 framebuf1 framebuf16 framebuf2 framebuf4 framebuf8 framebuf_subclass machine1 machine_pinbase machine_pulse machine_signal ticks_diff time_ms_us ubinascii_a2b_base64 ubinascii_b2a_base64 ubinascii_crc32 ubinascii_hexlify ubinascii_micropython ubinascii_unhexlify ucryptolib_aes128_cbc ucryptolib_aes128_ctr ucryptolib_aes128_ecb ucryptolib_aes128_ecb_enc ucryptolib_aes128_ecb_inpl ucryptolib_aes128_ecb_into ucryptolib_aes256_cbc ucryptolib_aes256_ecb uctypes_32bit_intbig uctypes_array_assign_le uctypes_array_assign_native_le uctypes_array_assign_native_le_intbig uctypes_bytearray uctypes_byteat uctypes_error uctypes_le uctypes_le_float uctypes_native_float uctypes_native_le uctypes_print uctypes_ptr_le uctypes_ptr_native_le uctypes_sizeof uctypes_sizeof_float uctypes_sizeof_layout uctypes_sizeof_native uctypes_sizeof_od uhashlib_md5 uhashlib_sha1 uhashlib_sha256 uheapq1 ujson_dump ujson_dump_iobase ujson_dumps ujson_dumps_extra ujson_dumps_float ujson_dumps_ordereddict ujson_load ujson_loads ujson_loads_bytes ujson_loads_float urandom_basic ure1 ure_debug ure_error ure_group ure_groups ure_namedclass ure_span ure_split ure_split_empty ure_split_notimpl ure_stack_overflow ure_sub ure_sub_unmatched uselect_poll_basic ussl_basic ussl_keycert utimeq1 utimeq_stable uzlib_decompio uzlib_decompio_gz uzlib_decompress vfs_basic vfs_blockdev vfs_fat_fileio1 vfs_fat_fileio2 vfs_fat_more vfs_fat_oldproto vfs_fat_ramdisk vfs_fat_ramdisklarge vfs_lfs vfs_lfs_corrupt vfs_lfs_error vfs_lfs_file vfs_lfs_mount vfs_userfs websocket_basic cmath_fun cmath_fun_special float2int_doubleprec_intbig float_divmod float_parse_doubleprec math_domain_special math_factorial_intbig math_fun_special math_isclose emg_exc heapalloc_bytesio heapalloc_bytesio2 heapalloc_traceback meminfo memstats native_closure native_const native_const_intbig native_gen native_misc native_try native_try_deep native_with opt_level schedule viper_addr viper_args viper_binop_arith viper_binop_comp viper_binop_comp_imm viper_binop_divmod viper_binop_multi_comp viper_cond viper_const viper_const_intbig viper_error viper_globals viper_import viper_misc viper_misc_intbig viper_ptr16_load viper_ptr16_store viper_ptr32_load viper_ptr32_store viper_ptr8_load viper_ptr8_store viper_subscr viper_try viper_types viper_with non_compliant print_exception sys_atexit sys_exc_info sys_settrace_features sys_settrace_generator sys_settrace_loop 3 tests failed: parser heapalloc_fail_bytearray opt_level_lineno

+2 -0

0 comment

1 changed file

pr created time in 2 months

create barnchmzdaniel/micropython

branch : particle-xenon

created branch time in 2 months

pull request commentmicropython/micropython

drivers: add general neopixel driver for all ports to use

I'd like to try and help with testing this neopixel driver in the Xenon board too, and struggling how to include it in the namespace of the nrf port. Any tips would be appreciated.

dpgeorge

comment created time in 2 months

pull request commentmicropython/micropython

[WIP] nrf: Change Xenon board to use built-in bootloader.

Made an interesting and validating discovery. After successfully flashing a pca10059 with pyocd, I tried to flash the xenon with "pyocd flash -e chip -t nrf52840 pca10059.hex". For the first time, I am able to run micropython on the Xenon, which makes sense as both boards are based on underlying nrf52840

dpgeorge

comment created time in 2 months

pull request commentmicropython/micropython

[WIP] nrf: Change Xenon board to use built-in bootloader.

Thank you glennrub and dpgeorge for working on this.

As https://github.com/micropython/micropython/pull/5041 was merged and Micropython can be compiled, flashed (in my case with Particle's debugger and OpenOCD) and run in a pca10059, I assumed the xenon board would work. It is not clear what else is missing...

I tried compiling with "make BOARD=particle_xenon" (generating a firmware.hex of 467176 bytes) and "make BOARD=particle_xenon SD=s140" (generating a firmware.hex of 499917) and after flashing none of these firmwares made the xenon show as /dev/ttyACMx (no even messages on dmesg)

Will be great to run micropython in Xenons even with no bluetooth, SD or Particle's built-in bootloader, at least to start experimenting with them. I can help with testing.

dpgeorge

comment created time in 2 months

more