#circuitpython-dev
1 messages ยท Page 318 of 1
Need to tag Justin on the PR too to make sure I didn't break any HTML.
That was my first thought upon finding it in /contributing ๐
OK I won't merge it right away then
It is a kind of contributing that someone can do even if they're not ready to put themselves forward as a contributor to the core
Oh, I think it's a perfect place for it, it simply needs to be clearer.
@jwcooper Tagged you to verify that I didn't break any HTML in moving things around.
@jepler Please check the content changes and see if you like them. Feedback is welcome and appreciated.
@onyx hinge ^^ https://github.com/adafruit/circuitpython-org/pull/508
Thanks, pewpew_m4 is still failing.
updates de ES translation again
strings keep coming from ulab, so every week that I check there is a couple of new ones to keep up.
@slender iron that F1 PR is probably going to be in the works for a little while, Dahanzimin is definitely trying hard to make things work but they're not super experienced with C. I had him create the PR so I could help cut out some of the RTC stuff that was giving him issues, but flash still needs a full rework.
@silver tapir thank you for keeping on top of it. Many projects find that they have to actually have a step of the development called "string freeze", so that translators have a chance to catch up and make sure all the strings are translated when release time comes. I don't think we're to that point yet (and not all langauges have translators as dedicated as you anyhow), but maybe we should consider how to approach the issue.
Waiting for a freeze is fine. I'm just obsessing about 6.0 in 100% es. :).
thanks for helping them @ionic elk
Is it expected to be possible to update a displayio.Shape by calling set_boundary() with new values inside the while True: main loop?
If the display is auto-update I would have assumed "yes" @lone axle
WIDTH = 100
HEIGHT = 100
display = board.DISPLAY
shape = displayio.Shape(WIDTH, HEIGHT, mirror_x=False, mirror_y=False)
for y in range(HEIGHT):
shape.set_boundary(y, 0, (WIDTH - 1))
# Create a TileGrid to hold the bitmap
palette = displayio.Palette(2)
palette[0] = 0x0000FF
palette[1] = 0x00FFFF
tile_grid = displayio.TileGrid(shape, pixel_shader=palette)
group = displayio.Group()
group.append(tile_grid)
display.show(group)
for y in range(HEIGHT):
shape.set_boundary(y, 0, 30)
while True:
for y in range(HEIGHT):
shape.set_boundary(y, 0, 80)
time.sleep(1)
for y in range(HEIGHT):
shape.set_boundary(y, 0, 30)
time.sleep(1)
If I understand correctly this code should be changing the shape from 80 px wide to 30px wide back and forth every 1 second.
but on the screen I end up with the shape "stuck" at 80px wide.
if I add time.sleep(1) before the while True: loop then I will have the 30px one "stuck" showing on the screen instead of the 80px one.
I'm not sure that I understand it enough to say if it's warranted, I can create an issue if this behavior seems incorrect.
It seems like you gathered good information, so I'd put it on an issue. either it's a bug, or given that we're used to displayio things updating it's a place the documentation would need to be refined. assuming it doesn't address this.
it looks like the "dirty area" handling that is in the core code of TileGrid is not in Shape. If the area is not marked "dirty" it won't be redrawn
I have this script:
import displayio
import board
import time
WIDTH = 100
HEIGHT = 100
display = board.DISPLAY
shape = displayio.Shape(WIDTH, HEIGHT, mirror_x=False, mirror_y=False)
for y in range(HEIGHT):
shape.set_boundary(y, 0, 30)
palette = displayio.Palette(2)
palette[0] = 0x0000FF
palette[1] = 0x00FFFF
tile_grid = displayio.TileGrid(shape, pixel_shader=palette)
group = displayio.Group()
group.append(tile_grid)
display.show(group)
#time.sleep(1)
...
Forcing the show by manually doing
display.show(None)
display.show(group)
after each for loop gets the shapes toggling.
Still dependent on the sleep value... no sleep toggles blockily. 1 or 0.1 seconds are fine. 0.01 seconds freezes again. Interesting behaviors.
Enabling actions on one's forked circuitpython repo on github is fantastic. The current workflow works in other accounts just fine.
This lets you iterate quickly and just push stuff off to your own branch on your own fork and github will email you with your results.
Probably I'm the last one to figure this out but hey. It's really nice to know my next PR will probably pass CI first try.
disallows using await outside of an async def scope
As of today, https://docs.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners
states that hosted runners have a 2-core CPU.
This uses make -j $physical_cores to try and be better about utilizing the time spent on those machines.
When github upgrades runners to have more cores we'll benefit from that too. Today it cuts about 1 minute off each m4 board build set. It might be faster still to run 2 single-core builds in parallel.
It's valid with = ..., but:
- typeshed doesnโt add
= โฆto constants and properties. - sphinx-autoapi renders
= ...as '= Ellipsis' that can be confusing.
<img width="200" alt="= Ellipsis" src="https://user-images.githubusercontent.com/5351911/88449888-a0162700-ce85-11ea-9d49-83e6a4ba8dbc.png">
So I think just removing them is reasonable.
Thank you for spotting this! I run -j4 builds all the time at home, so it shouldn't cause any issues, and this is a welcome speedup.
I also saw at the link you gave that ubuntu-20.04 is available as a preview. I'm not sure it makes much difference, but we could switch at some point. ubuntu-latest is still 18.04, for now
Using this script:
import board
import displayio
from vectorio import Polygon, VectorShape
# Make the display context
splash = displayio.Group(max_size=20)
board.DISPLAY.show(splash)
# Much easier to see white pixels
color_bitmap = displayio.Bitmap(320, 240, 1)
color_palette = displayio.Palette(1)
color_palette[0] = 0xFFFFFF
bg_sprite = displayio.TileGrid(color_bitmap, x=0, y=0, pixel_shader=color_palette)
splash.append(bg_sprite)
##################################...
I'm late to the party, but I believe it's the SECOND invocation of make down at line 56-59 where the bulk of the work happens:
make_result = subprocess.run(
"make -C ../ports/{port} TRANSLATION={language} BOARD={board} BUILD={build}".format(
port = board_info["port"], language=language, board=board, build=build_dir),
shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
It would make sense to put -j there as well.
@onyx hinge Could you leave a review that requests changes for #3203, to ensure it's addressed?
See my comments above about adding -j2 in a second location.
(For some reason I thought the PR had already been merged when I commented earlier, so I did not Request Changes)
Thank you for spotting this! I run -j4 builds all the time at home, so it shouldn't cause any issues, and this is a welcome speedup.
I also saw at the link you gave that ubuntu-20.04 is available as a preview. I'm not sure it makes much difference, but we could switch at some point. ubuntu-latest is still 18.04, for now
I tried a timing test running -j2 vs -j1 with two boards in parallel, but there's something that breaks when the boards are run in parallel: I was getting some errors related to the selected translation.
I'm late to the party, but I believe it's the SECOND invocation of make down at line 56-59 where the bulk of the work happen:
๐คฆ thanks
I tried a timing test running -j2 with two boards in sequence vs -j1 with two boards in parallel, but there's something that breaks when the boards are run in parallel: I was getting some errors related to the selected translation.
Yeah, I expect two -j 1's will require more work. Probably just using -j 2 will get 70% of the value. Thanks fo...
I've been doing some research about the ESP32-S2 camera's capabilities (in gist here: https://gist.github.com/askpatrickw/0179d09e74d5f2a4347d5666ea937c4d ). The camera functionality is accessed via I2S, the FeatherS2 exposes I2S as DAC1 and DAC2 (pin23,pin24) assuming all that is correct, the next question I have is about I2S support in CircuitPython.
The only mentions of that I find are in relation to audio, specifically audiobusio where I2SOut is implemented.
That leads me to think, in order to use the I2S Camera functionality of the ESp32-S2 a new library would be needed.
Does that sound right or am I way off?
Espressif IDF Docs for I2S
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/i2s.html
https://github.com/espressif/esp-idf/blob/625bd5eb1806809ff3cc010ee20d1f750aa778a1/components/soc/soc/esp32s2/include/soc/i2s_struct.h#L347
Requested by a user.
Yeah, that's me, the user that requested GamePad in Commander board.
@WarriorOfWire Do you understand why the wall-clock time is not different even after your latest commit, ebc1373?
https://github.com/adafruit/circuitpython/actions:

I am wondering if the build times are mostly related to the time to do -flto. Each translation is run on top of an existing build, and is not a clean build, so many compilations can be skipped. I thought perhaps LTO was single-threaded, but there's discussion of it being splittable between cores. I tried -flto vs -flto=4 and -flto-auto, and they were all the same for a single build.
@slender iron there were recent changes to bus_device, I think -- would they be casuing this ```Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 6.0.0-alpha.2-24-ga6e048686 on 2020-07-25; Adafruit Metro M4 Airlift Lite with samd51j19
import ahtx0_simpletest
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "ahtx0_simpletest.py", line 6, in <module>
File "adafruit_ahtx0.py", line 68, in init
File "adafruit_ahtx0.py", line 78, in reset
File "adafruit_ahtx0.py", line 78, in reset
File "adafruit_bus_device/i2c_device.py", line 104, in write
TypeError: extra keyword arguments given
just running the ahtx0_simpletest
tried another I2C device -- same error ```Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 6.0.0-alpha.2-24-ga6e048686 on 2020-07-25; Adafruit Metro M4 Airlift Lite with samd51j19
import msa301_simpletest
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "msa301_simpletest.py", line 8, in <module>
File "adafruit_msa301.py", line 221, in init
File "adafruit_register/i2c_bit.py", line 70, in set
File "adafruit_register/i2c_bit.py", line 70, in set
File "adafruit_bus_device/i2c_device.py", line 104, in write
TypeError: extra keyword arguments given
I'll open an issue
Thanks for the changes. I am surprised more boards didn't fail: more than I expected have room for `-O2', which is good.
The pre-commit check is stuck, but it was fine before. Never mind.
I tried some I2C devices on a fresh build of CP 6.0.0-alpha2 and am getting the following errors
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 6.0.0-alpha.2-24-ga6e048686 on 2020-07-25; Adafruit Metro M4 Airlift Lite with samd51j19
>>>
>>> import ahtx0_simpletest
Traceback (most recent call last):
File "", line 1, in
File "ahtx0_simpletest.py", line 6, in
File "adafruit_ahtx0.py", line 68, in __init__
File "adafruit_ahtx0.py", line 7...
This is due to https://github.com/adafruit/Adafruit_CircuitPython_BusDevice/issues/53. We need to update the library not to use the was-deprecated-and-now removed stop= keyword argument.
This is my first time ever posting an issue to a public project on GitHub, so please bear with me if I break any norms. I'm interested in contributing and learning this process as I go.
I am attempting to use the CPX + Crickit 6.0 alpha 2 release so I can take advantage of the new countio module. The countio module in 6.0.0 a2 works great on its own when I test it.
When I use the same 6.0.0 alpha 2 CPX + Crickit version of CircuitPython and attempt initialize the Crickit and motor I get...
Hi and thanks for giving this pre-release version of CircuitPython a try. We appreciate your feedback.
It looks like this may be a problem to be resolved in the adafruit_bus_device library, consider subscribing to this issue to keep up on new developments: https://github.com/adafruit/Adafruit_CircuitPython_BusDevice/issues/53 -- there's also another similar issue filed here, https://github.com/adafruit/circuitpython/issues/3206
I suspect that in the next few days an updated version of ...
I have seen build times be pretty variable; no I do not know in detail where all of the time went or why this latest run was not materially different than the previous one. This was more of a documentation-based optimization that I saw than a Big Win rigorously validated via scientific method (which I'm not planning to do for this change).
could someone help with what I think is a very easy question
I have three trinket m0s which work and run when plugged into my computer, but dont when using an independent power supply supplying 5V.
does circuit python only work when connected to a computer?
CircuitPython should run just on power, unless there is somehow a dependency on the connection. It's possible (but unlikely) there's not enough power. But what does your code do, and how do you know it's not working?
its switching the dot LED to white and toggling a digital pin at 22Hz when connected to the pc, when powered standalown, the dot is purple only and no blinking dout.
I thought power might be the issue, and tried 5V 500mA, USB charging cable, and a PI power supply
What device is is the dout at 22Hz? Code errors are typically flashing LEDs https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting. Might help if you can post your code.
no real load to speak of, 500mA should be more than adequate
yeah, read up the trouble shooting page.
What versions of CircuitPython and libraries? If you post the code, I can try it here.
no flashing as described line errors
purple flashing said to indicated ValueError, but my purple light doesnt flash
ill send main.py, one sec
example
I thought these imports being left in should be fine
ill check versions one sec
wow preloaded read me says 3.1.1 2018-11-02
you'll want to update that https://circuitpython.org/board/trinket_m0/
libraries too https://circuitpython.org/libraries
rookie mistake, installing right away
What's up with chrome marking our uf2 files as dangerous? Has anyone reached out to the Chrome team?
White Led now with exernal power! I will need a little more time to hook up my scope, but as it looks, promising
@ivory yew is it happening again??
@ivory yew or is this about the message shown on circuitpython.org downloads pages? It happened briefly (as far as I knew) and then stopped .. but by that time we had put the warning up and nobody's taken it down yet.
@tranquil sun I suspect there was something in the old (unused) keyboard code that was dependent on the connection
Re #c14: It wasn't a browser update. Chrome contacts Google's Safe Browsing service to verify that a file being downloaded is safe. There was a bug in that service that caused this issue to happen, but it has now been fixed.
Makes sense, just checked the pulses and I get the 22hz ๐
thanks for your help @crimson ferry
@ivory yew so as far as I know, if circuitpython.org is still showing that block warning you of chrome warning (so confuse) it would be great to PR its removal now
Ah yeah. We should take it down. I might have some time to send a PR later but no promises. ๐
I don't see it / think about it due to not using chrome ๐
anyway the other discussion of it seems to have happened internally to adafruit so you wouldn't have seen it
not intentional, it just happened that way
Reverts adafruit/circuitpython-org#505.
This was a bug in the Google service that Chrome uses: https://bugs.chromium.org/p/chromium/issues/detail?id=1106858&q=component%3AServices>Safebrowsing&can=2, and it was fixed pretty rapidly. Thanks @jepler for the reference.
Images automagically compressed by Calibre's image-actions โจ
Compression reduced images by 44.9%, saving 321.67 KB
| Filename | Before | After | Improvement |
|---|---|---|---|
assets/images/boards/large/unexpectedmaker_feathers2.jpg |
158.21 KB | 40.83 KB | -74.2% |
assets/images/boards/original/unexpectedmaker_feathers2.jpg |
529.34 KB | 346.14 KB | -34.6% |
| `assets/images/boards/small/une... |
I tried running the adafruit_io example adafruit_io_http/adafruit_io_simpletest.py unde the current main for 6.0.0-alpha2 and it fails with this error
This runs normally with CP 5.3.1
Is this a CP issue or does something have to be changed in the adafruit_io libraries?
the esp32spi_simpletest works OK under CP 6.0.0-alpha2
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 6.0.0-alpha.2-43-g7ab5c520e on 2020-07-26; Adafruit Metro M4 Airlift Lite ...
resolved by #54 and redundant with #53
Add aliases for SDI, SDO and EN, so that pin names match the text on the
PCB to avoid confusion.
Also disable all pins from port B, because that package of SAMD21
doesn't have port B.
It turns out this is not necessary, because ports/atmel-samd/asf4/samd21/include/pio/samd21e18a.h does not even #define the PBnn pins. The checks in ports/atmel-samd/peripherals/samd/samd21/pins.c are of the form:
#if defined(PIN_PXnn) && !defined(IGNORE_PIN_PXnn)
so if the ASF4 include files don't even define the pin, you don't need to explicitly ignore them.
I discovered this by coincidence because I'm defining a new board also with SAMD21E18A, and wondered if I had ...
@onyx hinge Thanks for the BusDevice PR's So is PR #54 obsolete now that you filed #55?
@tulip sleet yes if there's consensus to just drop compatibility
Feel free to close it, I'm on mobile right now
np, I'll merge and make a release so it gets into the bundle. Thanks for this, since a lot of people were going to hit it.
I think I scooped @crimson ferry who wanted to give a first timer a chance to work on it. Thanks for your offer to help out! It would have been fine to dive in due to the impact on users of this problem while it was broken. That said, I have read that there is huge benefit to actually reserving "good first issues" for new contributors and I should be mindful of that in the future.
"Good first issue" was certainly appropriate, but it also needed to be fixed quickly since so many things were broken otherwise. So I think it's fine. The two libraries that need fixing could be "good first issue" also.
OK I looked a little more cloesly at the other issues I filed, refined the initial comment, and marked them "good first issue". https://github.com/adafruit/Adafruit_CircuitPython_MLX90393/issues/18 is the one that seems to have the highest odds of just being broken with 6.x. I don't think I have an MLX90393 for testing.
Remove use of stop=False. This option is not supported in CircuitPython 6.x. https://github.com/adafruit/Adafruit_CircuitPython_MLX90393/blob/master/adafruit_mlx90393.py#L165 It looks like this wil...
@onyx hinge Thanks for digging in and fixing it. It was marked "good first issue" and I didn't know the protocol / priorities, but it was affecting a wide swath of devices, so it's nice to have everyone back on track.
Hi guys, what is the cheapest circuitpython capable board with BLE?
@timber mango looks like among adafruit boards it'd be https://www.adafruit.com/product/4481
among other manufacturers https://www.nordicsemi.com/About-us/BuyOnline?search_token=nRF52840DONGLE and https://makerdiary.com/collections/frontpage/products/nrf52840-mdk-usb-dongle may come in a little lower, but I think they lack the (Q)SPI flash which means the CIRCUITPY drive is smaller
Buy Nordic Semiconductor product samples online. Distributor inventory lookup below.
Thanks, Jeff. I know Adafruit so I'll go with that ๐
What is circuitpython
CircuitPython is an open source derivative of the MicroPython programming language targeted towards the student and beginner. Development of CircuitPython is supported by Adafruit Industries.
@mental nexus can i start with CircuitPython if I have low notebook? ๐
CPU celeron
GPU Intel graphic card
RAM 4gb
@woeful siren you don't need a particularly powerful computer to use Circuit Python but you would need to get a Circuit Python microcontroller device, or a Raspberry Pi.
@jepler - what was the host system you were talking to? I was unable to reproduce using a Windows 10 system, but running Ubuntu on the same box I saw the issue. Using Wireshark showed that on Linux the characters were coming in from the USB much faster - 5-6x faster, to be exact. Nearly all the time I measured between calls to readline_process_char() was being used to run background tasks, so I think perhaps with a fast USB and slower clock speeds we must be missing an occasional interrupt.
@woeful siren do you have any programming experience at all or is this your first time? Also do you have a specific project in mind or just wanting to learn?
I think the Circuit Playground Bluefruit: https://www.adafruit.com/product/4333 is a really good 1st device to learn with. It has plenty of features built in to the board to play with while you learn. And when you're ready you can start connecting things to it with alligator clips.
It has BLE connection if that is of interest to you, but you can also ignore the BLE if you don't want to use it for anything.
Interesting thx
- Better description
- Warning about updating beyond 6.x
- Purchase links
^^ <@&327289013561982976>
thanks anecdata
I didn't see this in alpha-1: pystack exhausted doing a Request with 6.0.0-alpha.2. It's a big app... pushing limits of 256k on PyPortal (still have >60KB free mem before the error)
But this is right after setup, during first HTTP transaction, before any displayio shows
"Let us know if you hit a RuntimeError from an exhausted pystack." ๐
Is there a way to programmatically (code.py) capture the output of help("modules")? It seems to just do its thing and return None.
also in CPython -- nothing is returned x = help("modules") does not return anything to x
@crimson ferry FYI re:pystack https://github.com/adafruit/circuitpython/issues/3208
@crimson ferry @solar whale https://stackoverflow.com/questions/11265603/how-do-i-export-the-output-of-pythons-built-in-help-function none of which would work on CircuitPython. help() just prints to stdout. it's not based on pydoc, as in CPython
I was hoping to iterate over the installed modules on any board, it seems to be more definitive than the list in the matrix or circuitpython.org.
Thanks for the references
@solar whale the new network stack may help, bus I suspect we need more pystack in any case
with heap growing from one end and stack growing for the other, where is pystack?
Would it be difficult or undesirable to expose some coarse memory controls to user code? Users have good control of flash, but not memory. It would be useful if user code (maybe boot.py or precursor) could tweak heap vs stack vs pystack.
@crimson ferry you can set the stack size: https://circuitpython.readthedocs.io/en/latest/shared-bindings/supervisor/index.html?highlight=stack#supervisor.set_next_stack_limit
the size of pystack was set experimentally in the alpha, and we can grow it
@tulip sleet Does set_next_stack_limit set the C stack or pystack size though?
it sets the C stack. Using pystack at all is brand new. previously the python stack was on the c stack
Thanks, confirming what I thought. So it's not a knob that anecdata can turn now to fix this problem..
Here's a nice new feather esp32-s2, this time from Electronics Cats from Mexico.
https://electroniccats.com/store/bast-wifi/
you can do a new build and modify the pystack size experimentally
Request to add two books of projects for Circuit Playground Express. Each book includes project instructions, Circuit Python code and detailed walk-throughs.โฆress
@crimson ferry CPython has sys.builtin_module_names, which we don't implement, but it might be handy. help("modules") builds a nice list internally, but then it just prints it and doesn't make it available programmatically.
you could suggest this in an issue
Thanks. I may put in an issue. Part of it is the inconsistency between the textual sources of what modules are on a board. help("modules") is where the rubber meets the road. Fairly regular questions in #help-with-circuitpython on what modules are available.
in the meantime, you can try stuff like:
possible_modules = ('analogio', ...)
have_modules = []
for m in possible_modules:
try:
__import__(m)
have_modules.append(m)
except ImportError:
pass
ah, from a master list... that could work
e.g., I thought I remembered gc being in readthedocs, but I don't see it (and other standard CPython modules) now, and gc.mem_alloc() seems to be upython-specific http://docs.micropython.org/en/latest/library/gc.html#module-gc
(but it is in our builds)
I guess it's not important to replicate CPython docs where we are a strict subset, More useful where CircuitPython has extensions, often inherited from MicroPython.
@tulip sleet are there plans to increase pystack soon? we can discuss at meeting today.
where is pystack set?
Would it be correct to say that memory allocated to pystack isn't available to [c]stack or heap, like it's a segregated chunk of memory?
That's right, to my understanding
@onyx hinge Do you know where pystack is configured? I was going to try changing it, but I can't find it?
I was just looking for that -- I'd search around for MICROPY_ENABLE_PYSTACK, see commit 1160635608ebeaf3868a327803c0ca248f549123
+#define CIRCUITPY_PYSTACK_SIZE 1024
+#endif
+static size_t PLACE_IN_DTCM_BSS(_pystack)[CIRCUITPY_PYSTACK_SIZE / sizeof(size_t)];
+#endif
``` the way it is coded currently, it is set at compile time.
Thanks -- I can play with that.
Backgrounder: https://github.com/adafruit/circuitpython/pull/3160
ah -- thats the ticket!!
py/circuitpy_mpconfig.h
I love how intuitive this all is ๐
i get so lost in the layers of abstraction in the circuitpython core, hard (for me) to find the code that actually does the work. Maybe the abstraction is the work ๐
same here
doubling PYSTACK to 2048 works on the metro_m4_airlift -- my requests to adafruit_io work now
I was afraid pystack was fragmenting memory in some big way, but 2KB is nothing on M4 or better boards
If I double the size of the pystack it works
diff --git a/py/circuitpy_mpconfig.h b/py/circuitpy_mpconfig.h
index a1a7ec238..768e05af1 100644
--- a/py/circuitpy_mpconfig.h
+++ b/py/circuitpy_mpconfig.h
@@ -799,7 +799,7 @@ void supervisor_run_background_tasks_if_tick(void);
#endif
#ifndef CIRCUITPY_PYSTACK_SIZE
-#define CIRCUITPY_PYSTACK_SIZE 1024
+#define CIRCUITPY_PYSTACK_SIZE 2048
#endif
#define CIRCUITPY_BOOT_OUTPUT_FILE "/boot_out.txt"
Nice to be "back in business"
I guess it's not important to replicate CPython docs where we are a strict subset, More useful where CircuitPython has extensions, often inherited from MicroPython.
@crimson ferry I'd like to have docs for subset modules but we inherit most of them from micropython and we haven't restructured them into shared-bindings
Would it be correct to say that memory allocated to pystack isn't available to [c]stack or heap, like it's a segregated chunk of memory?
@crimson ferry Correct. We probably want to reduce the default C stack size as we increase the pystack too. otherwise we'll shrink the heap
though strinking a bit is ok because some allocations that hit the heap now are done on the pystack
thanks @slender iron , I realize these are tricky engineering trade-offs that may manifest differently in different use cases. Maybe the bottom line for users is to get to know the main constraints so they can make their own trade-offs or optimizations in their application
I've not measured it yet but voice 0 appears to be louder than the rest for an audiomixer. Is this by design? Did @onyx hinge create this originally?
No, I'm at least the third person to work on it. You can be the fourth ๐ ๐
I'm just using 1-13 ๐
the first voice that is mixed in does go through different code than the others, because it does not have to sum with a voice whose sample value has already been calculated. It's an optimization and it could well have a bug.
Someone else found it too: https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/Lucio_Blaster_2020/lucio_blaster_2020.py#L112-L113
@ciscorn Let us know when you're ready for review. Thanks!
This is all set for review, right? Thanks.
@simple pulsar in shared-module/audiomixer/Mixer.c, function mix_down_one_voice there are the two blocks of code depending on a bool ... ``` // First active voice gets copied over verbatim.
if (!voices_active) {
@jepler has mentioned voice 0 is processed differently to rest.
I'm about to file a bug ticket for voice 0 being noticeably louder than the rest and was looking to see if that was already covered by an existing issue ticket.
I wrote some quick code recently for playing different notes in an octave using audiomixer and I noticed the my first note in voice 0 was louder than the rest in voices 1 to 12. This is on a CLUE running 5.3.0. I just made an extra voice and am now using 1 to 13 as a workaround.
I was rummaging around for examples of audiomixer and found this two voice one in Learn Guides: https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/Lucio_Blaster_2020/lucio_blaster_2020.py#L...
@dhalbert @tannewt It's ready for another look. Thanks.
This is all set for review, right? Thanks.
Yep, should be.
<@&356864093652516868> The weekly meeting is in about 1 hour (2PM ET). Please add your notes to the document, and if you're going to be lurking note it there (2 places) -- it's super helpful! https://docs.google.com/document/d/1K-himsiOHsJozTNUktOK8SEmiBcRhlDkBW363jlQ2DQ/edit?usp=sharing See you in the CircuitPython audio channel at 2PM ET
@slender iron how would you feel about me implementing the flash module on the F1 once ESP32-S2 Pulseio is done? I think everything else in the F1 port I can guide Dahanzimin though, but flash is tricky. I'm concerned it'll stall out the port.
Good afternoon all you wonderful folks! I'll be text-only/lurking today, and I've updated the notes doc to reflect as such. 
yes
Thank you
lurking
lurking
brb but you can start without me
Any Python/CircuitPython news, send soon to anneb@river quest.com to make this week's issue
lurking
2 4K monitors rocks
I'm on a 4K monitor and my 15" MacBook screen
lurking
Currently using a MBP 16" + 2x 1920x1080 + 2560x1080 --- that's my remote setup. All second-hand panels.
Primary setup at home is a MBP 16" + 2x 1920x1200 + 2560x1600 + iPad 12.9 via sidecar.
Would you believe I want/need more? ๐
Wake up little ALICE!
...
ALICE is a #Kinect controlled #FPV mini-mech
Powered by #CircuitPython on #adafruitfeather.
Skeleton #3dprinting on #mpminidelta
#robots #inventor #makersgonnamake #arduino #puppeteer #animatronics #arduino #adafruit https://t.co/xsVQSqNGEU
back
Wow -- if you turn your volume off -- you can't hear anything!
Lurking. Unhappy about my contribution to the doc... I could not remember what I CP did this week!
I am back if you want to kick to me
lurking
๐
Same.
๐
wat
I banned.
fastest ban clicking on discord
Thank you @idle owl.
was that just some drop-in rando?
Yes, random crashers
ok, if anyone is not a circuitpythonista, then you won't be able to speak
let me know and I'll add you
Can you add me? Thanks!
Sorry mic issues..
. Will try again at weekly reports.
I do not think I am, you can add me though i'm not likely to talk anytime soon ๐
Is there a particular reason we're getting targeted more recently? Seems like it's been a big uptick
we suspect it's the server directory which publicly lists us
Ahh that'd do it, if we're ranking highly
I think we're on the education page...
I see us as number 8 on public servers home, but that might just be me
definitely seems like something Discord itself should be tackling
yup. I'll check in with the python discord folks too
them and home assistant are probably having the same issue
the Travis/git actions was confusing as someone new. I was able to see/work around it, but as someone still new if you want someone to test updated instructions let me know
Github in general is a heck of a learning curve for beginners so anything in this vein is great
Sometimes I'll stare at the GitHub screen for a couple of minutes trying to figure out where they hid stuff.
Usually it's closer to 30 seconds though.
oooo, +1 for the fpga board
I love the cat cam, but maybe a good CP project for @slender iron would be a "cat epilepsy detector" (or at least record on SD card normal cat vibration and abnormal cat vibration to feed an AI for detection).
I've thought about that. it could be a hiss detector
though that would include false positives
I think someone on Twitter awhile back was working on a microcontroller pet epilepsy detector
we should figure out some tech that would need a library called eieio ๐๐
what's the new top secret board? I have youtube blocked on my devices
@tulip sleet Do we need to acquire something to test HCI? Or just migrate a AirLift into a BluefruitLift by changing the firmware? I want to be ready to play with this.
@thorny jay There will be updated ESP32 firmware. It will still do wifi also: the changes are just pin changes
I am using a regular Metro M4 AIrlift Lite, which needed ne firmware, but the breakout may not need new firmware
@ionic elk BLM badge
I think this is the device from top secret:
@ionic elk neopixel with the RMT on esp would be cool
@slender iron interesting
@tulip sleet I have a PyBoard with AirLift build in, and the AirLift Feather. I might acquire a breakout of some kind.
@slender iron I'd probably want a shared RMT mediator in /peripherals then?
so the two modules don't conflict?
ya if it's needed for other things
@thorny jay either one you have now would be fine
@ionic elk mute please?
I think we want to keep the bar low for entry, but could we add some friction like needing an avatar or some other profile richness?
@onyx hinge shoot I'm sorry
server discovery
Unfortunately, plenty of the terrible people have an avatar or even an existing phone-verified account. We enabled 10-minute waiting before posting after joining, but people with phone-verified accounts apparently can bypass that.
from "explore public servers" on the left hand side
I never see SPAM... but maybe because we have good moderator. So it is hard (except for what I have ear today) to figure out what it is. Does it take place in this "room"?
It tends to only last for a few seconds before getting removed.
I have only recently actually seen it occur, because the mods are so on top of it that it's typically gone before anyone has a chance to see it. In the case I saw it was a spammed link of a photo.
PyDis' channel permissions, and the 'acceptance' prob blocks a lot of the spam. (as Scott just mentioned)
When other servers have a "introductions" channel, I wonder how much that can curb spam content?
Force all messages in one place until they get approved, or something like that?
A friend's server has an intro channel and you cannot do anything else until you use a reaction to the intro message. So you have to at least read one message to know to do that
How about bannig UNICODE.
Is it possible to pause discovery while there is a response from discord?
@inland tusk what does banning unicode do?
And also, it seem like help is needed during this change. I'll be happy to moderate.
Prevent "weird" characters from being used to get around automated bad-word filters.
ah
Okay I forgot about that.
And to put this in perspective -- it's roughly 1% causing trouble, out of 23k members. It truly is a small amount, but unfortunately its a vocal minority.
@silver tapir I will DM you later to discuss it.
Thanks.
I mean clearly some of this isn't just bots
Like these people screaming in the meeting, etc
Might want some human hurdles too
I'm suspicious about that though because so many came at the same time
Sadly there are discord servers dedicated to disrupting other servers
I feel like escalation of permissions is a good fit for human bad actors
@slender iron is the correct way to set the pystack up and default stack down? ```
diff --git a/ports/atmel-samd/mpconfigport.h b/ports/atmel-samd/mpconfigport.h
index 540a2f77c..e25568164 100644
--- a/ports/atmel-samd/mpconfigport.h
+++ b/ports/atmel-samd/mpconfigport.h
@@ -109,7 +109,7 @@
#endif
#ifndef CIRCUITPY_DEFAULT_STACK_SIZE
-#define CIRCUITPY_DEFAULT_STACK_SIZE 4096
+#define CIRCUITPY_DEFAULT_STACK_SIZE 3072
#endif
#ifndef SAMD21_BOD33_LEVEL
@@ -134,7 +134,7 @@
#endif
#ifndef CIRCUITPY_DEFAULT_STACK_SIZE
-#define CIRCUITPY_DEFAULT_STACK_SIZE (241024)
+#define CIRCUITPY_DEFAULT_STACK_SIZE (231024)
#endif
#ifndef SAMD5x_E5x_BOD33_LEVEL
diff --git a/py/circuitpy_mpconfig.h b/py/circuitpy_mpconfig.h
index a1a7ec238..768e05af1 100644
--- a/py/circuitpy_mpconfig.h
+++ b/py/circuitpy_mpconfig.h
@@ -799,7 +799,7 @@ void supervisor_run_background_tasks_if_tick(void);
#endif
#ifndef CIRCUITPY_PYSTACK_SIZE
-#define CIRCUITPY_PYSTACK_SIZE 1024
+#define CIRCUITPY_PYSTACK_SIZE 2048
#endif
#define CIRCUITPY_BOOT_OUTPUT_FILE "/boot_out.txt"
ya, I believe so
And to everyone here -- thank you for being awesome. You're upstanding members of the community -- a direct opposite of this issue we're facing. It's refreshing and a pleasure to have y'all here.
OK -- works on M4 airlift -- will test CPX and then do other ports as well
There was a link posted on the weekend and before I could type (at) mod it was gone. Great job Mods!
I need to remain muted beginning at 15:30. I'll stick around, but can't respond.
I've got to log off now. Good bye, everyone!
Thanks everyone!
Thanks everyone! Thanks for running the meeting @onyx hinge!
Thanks all.
I had ๐
so meta
Excellent job indeed ๐
Thank you @onyx hinge . If someone can prepare the next doc, that permit to update it during the week.
@tulip sleet Is there a specific test you want me to do on the CPX with the stack changes?
just importing the module blew out the stack before we grew it
it was refactored to use a superclass, and that and a fairly deep sensor initialization got too deep on the stack
ok -- jsut the standad CPX or should I test the crikit and displayio versions as well
i think they all have the same stack size, let me check
all SAMD21 are the same
circuitplayground_express_displayio/mpconfigboard.h
31:#define CIRCUITPY_DEFAULT_STACK_SIZE (4760) // divisible by 8
circuitplayground_express/mpconfigboard.h
31:#define CIRCUITPY_DEFAULT_STACK_SIZE (4760) //divisible by 8
circuitplayground_express_crickit/mpconfigboard.h
33:#define CIRCUITPY_DEFAULT_STACK_SIZE (4760) // divisible by 8
in ports/atmel-samd/boards/
ugh -- they all need to be changed -- I only looked at the mpconfigport.h in atmel-samd
I forgot to check the individual boards.
will do that
those are the only boards with a custom value, though
whew!
(grep told me)
so they had bigger stacks to start... I'll experiment
Dropping off
In, 6.0.0 alias it in. Once that is done, we'll remove it from pulseio in 7.0.0.
@solar whale try something less, like 256 or 512. We didn't increase the stack a lot to begin with
ok -- will try other values.
@lone axle re: https://github.com/adafruit/circuitpython/issues/3204
The issue here is that the winding number algorithm is kind of "handed." It will miss certain pixels in certain cases, and the rectangle is kind of the worst-case shape for it.
I spent a lot of time over the weekend looking for a solution and haven't landed on one I'm happy with yet.
The code on your issue should produce a 51x51 square, not 50x50. I'd welcome you (or someone else) to take a look and see about an improvement to account for line edges a little better.
winding rules: https://en.wikipedia.org/wiki/Evenโodd_rule
@tulip sleet ok -- reducing by 512 seems to work on CPX -- I'll do some more testing and probalby put in a PR tomorrow
thank you!
Belated reminder, we'd love your submissions to the newsletter! You can make pull requests, and the "development" of the newsletter is done in the open: https://github.com/adafruit/circuitpython-weekly-newsletter/blob/gh-pages/_drafts/2020-07-28-draft.md
@low sentinel whoops, you are right it should be 51x51. So it's not that it is shifted by one, but rather that it didn't fill in the first column of pixels. Neat, thank you, I was unfamiliar with this algorithm. If it were possible to change the size of a vectorio.Rectangle I would probably opt to use that instead of vectorio.Polygon for most of the use cases that I have looked at so far. Perhaps it's worth revisiting that idea if the rectangle is particularly tricky for this algorithm. I can try to look into a bit, but C is mostly outside of my skillset.
@tulip sleet nice! the metro_m4_airlift still can use requests and access adafruit_io with only a 512 byte pystack increase
ok! the 1024 was picked because one micropython port had picked that value for pystack: we didn't have a lot of data to go on
m4 was set for a STACK of 24*1024 so I am also reducing it by 512 bytes (to 24064)
@lapis hemlock You're still in one of the voice channels. I recommend disconnecting as someone could drop in and start talking (or screaming) unexpectedly.
Here is the notes document for next Mondayโs CircuitPython Weekly meeting, August 3 2020. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youโll be attending the meeting - itโs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weโll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1i_l-w0lmHZg7vSoNgAvNWDoVwK1jU5dojDuJvzQgvMQ/edit?usp=sharing
Cheers, @onyx hinge Again, great job today!
You're welcome.
We'll need to revise the opening to advise that you now MUST be a circuitpythonista to speak in the meeting.
Accurate. I'll make a note to update the guide.
This meeting typically happens on Mondays at 2PM Eastern Time, but the date occasionally varies for US holidays. We have an online calendar. If you would like to speak in the meetings,, let us know and we will add you to the โCircuitpythonistasโ role. This will also get you a small number of notifications from Discord during the week, mostly reminders about the meeting. The length of the meeting varies, but itโs often from 60 to 90 minutes long.
Here's what I wrote in my meeting intro script, does that make sense?
Looks good to me fwiw
Mostly makes sense. I might make it more explicitly clear that it's required to speak. I'll let you know when I update the guide, and you can adapt whatever I end up adding to fit your wording.
@lapis hemlock I disconnected you from the voice chat
@idle owl @tulip sleet Thanks, I logged off in a hurry. ๐ณ
@lapis hemlock No worries! Simply looking out for you.
Looks great! Thank you!
We'll need to add dirty tracking to Shape to make this work. Similar to this: https://github.com/adafruit/circuitpython/blob/main/shared-module/displayio/Bitmap.c#L153-L164
just checking - the UF2 bootloader updaters (from cp.org) will set the write protection bits after updating?
@tidal kiln, yes that's right, it's an easy to way to make sure the BOOTPROT fuses are set properly. You can update to the same version
oh. hey! a wild danh appears. excellent.
thanks. would you mind responding here:
https://forums.adafruit.com/viewtopic.php?f=57&t=167795
sure
I've been doing some research about the ESP32-S2 camera's capabilities (in gist here: https://gist.github.com/askpatrickw/0179d09e74d5f2a4347d5666ea937c4d ). The camera functionality is accessed via I2S, the FeatherS2 exposes I2S as DAC1 and DAC2 (pin23,pin24) assuming all that is correct, the next question I have is about I2S support in CircuitPython.
The only mentions of that I find are in relation to audio, specifically audiobusio where I2SOut is implemented.
That leads me to think, in order to use the I2S Camera functionality of the ESp32-S2 a new library would be needed.
Does that sound right or am I way off?Espressif IDF Docs for I2S
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/i2s.html
https://github.com/espressif/esp-idf/blob/625bd5eb1806809ff3cc010ee20d1f750aa778a1/components/soc/soc/esp32s2/include/soc/i2s_struct.h#L347
I probably should have waited to post this on a weekday. I was curious what the team thinks about the ESP32-S2 Camera support... (and if I'm understanding it correctly)
@tannewt What do you think about adding a new name aliased to the old name for 6.0.0, and then drop in 7.0.0? I'm not sure what a better name is, maybe ConnError or BluetoothConnectionError or BTConnectionError.
@idle wharf I think it's on @onyx hinge's radar
I don't know anything specific about it but adafruit may ask me to work on it at some point in the future
๐ got it
@RealAbsurdity Thank you for the issue! It should be fixed in the latest bundle with Bus Device version 5.0.1.
Why is this being deleted? Maybe you need to merge adafruit/main into your branch?
Nevermind. This was my mistake in my PR. This was an error I added but deleted before merging. :roll_eyes:
Looks good! Thank you!
Looks great! Thank you! Don't forget to add it to the circuitpython.org website as well: https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website
@slender iron do you want the adjustment for the increased pystack to be made for the CIRCUITPY_DEFAULT_STACK_SIZE for all ports or just for the atmel-samd (SAMD21/51). in particular for the cxd56,stm,esp32s2,litex ?
ok -- should I just do it there an leave the others alone
either way ๐
ok -- I'll put an a PR with only the SAMD21 and we can discuss it there.
k, thanks!
@slender iron I am working with the the tip of main and now the frozen bus_device module is out of date and the CPX library fails.. how to I update the frozen module in my repo.
@solar whale find the module in the frozen folder and update it like you would in git normally
actually, I think there is a make target to do it
at the top level
Note, this hits a sphinx autoapi issue: https://github.com/readthedocs/sphinx-autoapi/issues/234
- Actually, the issue exists now so it shouldn't block this PR.
increase pystack by 512 bytes
decrease SAMD21 stack by 512 bytes
fixes #3208
also update frozen module Adafruit_CircuitPython_BusDevice
Tested on CircuitPlayGround Express -- able to import express library
This is to resolve the bug when inserting an element at the end of an existing group. See issue: https://github.com/adafruit/circuitpython/issues/3129#issuecomment-656252519
In this PR, per your suggestions I check if the requested insert index is equal to the length of the group. If so, then call append, else call insert.
I hunted around the code for the proper type conversions, but I am unsure if I am doing the type conversion correctly.
** Please double-check since I am not famili...
winding rules: https://en.wikipedia.org/wiki/Evenโodd_rule
@onyx hinge yeah, vectorio.Polygon uses the non-zero winding idea like standard SVG (not even-odd). It has a fixed ray direction though, and per w3.org:
The above descriptions do not specify what to do if a path segment coincides with or is tangent to the ray. Since any ray will do, one may simply choose a different ray that does not have such problem intersections.
I suspect that if I were to choose a different ray direction, I could fix it for rectangles - but any fixed ray angle will be susceptible to ill-defined behavior rising from a colinear ray and segment path.
Might help to do the calculation in floating point and have some heuristic for nudging values by an epsilon in the case of coincidence - but ideas there I think would tend to produce a different artifact along segments (like shape -> 1 empty pixel -> 1 ghost pixel from epsilon) at certain angles and that would slow the calculation tremendously on uc's without fpu's.
or, if you prefer meme form, one does not simply choose a different ray :-p
I tested this out on a PyGamer. Prior to these changes I get IndexError from this line group1.insert(0,group2). With these changes it is working successfully.
Thank you @kmatch98 for working on this! It will be great to unwind this bit of complexity in display_text
@tannewt Thanks for fixing it. I've also added black in the merged commit 54a342a7f5b74f32c7a53ea483d9046e688b9830.
Please append black together with isort.
Added the display QSTR for Wio Terminal so board.DISPLAY can be used.
I have been trying to run the irremote_simpletest on the current master and it is hanging in read_pulses(pulsein)
Not sure if this is an issue for the irremote library or CP
I tried it on both a CPX and a pirkey_m0
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 6.0.0-alpha.2-58-gdebbf1028 on 2020-07-28; Adafruit CircuitPlayground Express with samd21g18
>>> import irremote_simpletest
it works with 5.3.1
Press any key to enter the ...
@low sentinel using the top-left rule https://docs.microsoft.com/en-us/windows/win32/direct3d11/d3d10-graphics-programming-guide-rasterizer-stage-rules will give consistent results, but that assumes you reduce your polygon to triangles. When rasterizing arbitrary shapes, you can apply a top-left-inspired rule. Say that you approach rasterization by thinking "across" rows. You just need to know the segments of the shape that cross that row (a fully horizontal line NEVER crosses a row), the X-coordinates of their intersections, and then you can apply your fill rule.
sweep line algorithm will let you efficiently know what segments cross the row you are dealing with, and you also have to sort the intersections within a row.
https://github.com/jepler/dashing/blob/master/dashing.hh#L130 is code I wrote in the fairly distant past that is vaguely related to this, though I notice it works on doubles and not integers
the top-left rule or variants are nice because when you put shapes next to each other that share endpoints, you know the rasterization will be without gaps and without double-covering pixels
(say you wanted a spinning beach ball animation using shapes...)
FYI -- the irremote_simpletest works normally on a feather_nrf52840 (bluefruit_sense) using an eternal IR sensor.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 6.0.0-alpha.2-60-g945736e9b on 2020-07-28; Adafruit Feather Bluefruit Sense with nRF52840
>>> import irtest
Heard 67 Pulses: [9064, 4422, 618, 534, 622, 531, 624, 528, 617, 536, 620, 533, 622, 531, 615, 537, 618, 1604, 618, 1603, 618, 1604, 617, 1604, 618, 1604, 617, 1605, 616, 1606, 616, 1607...
The basic problem is that:
from _bleio import ConnectionError
will trigger a pylint complaint, because it's shadowing the system exception.
Another alternative I thought of is simply to drop _bleio.ConnectionError, and use the system-provided ConnectionError for that particular error. We don't provide _bleio.IOError, etc., so using the system ConnectionError may be clear enough.
Looks good; thanks for testing!
There's a stuck check but we can merge anyway.
Add blm_badge board. This board has PDM mic, but doesn't have pins available for I2SOut, so add a new compilation macro to allow I2SOut to be disabled. audiobusio.I2SOut() exists but will raise NotImplementedError.
Awaiting final board testing by @ladyada.
@tannewt Thanks for looking into this!
@onyx hinge Thanks, I hadn't seen the top-left rule. In effect, vectorio.Polygon does a bottom-right currently. I think these rules produce shocking results, but I'm not an expert in rasterization
this 3x3 shape produces a 2x2 rectangle
It's true, DirectX and OpenGL is probably not designed so that beginning users get the results they want, but so that advanced users can get the results they want with care
If [1:3] is a slice of 2 items in Python, then a rectangle where low_x = 1 and high_x = 3 being 2 pixels wide is in some sense just as defensible
sure but what is your shape going to be like when you have something more interesting than a rectangle
weirdly shifted by 1 pixel it seems
in python am array starts with index 0, and ends at index len()-1. That behavior seems most natural to expect
I'm happy to leave the actual decisions with you ๐ but this info about how people thought about rasterization in the 80s and 90s is getting harder to find and I wanted to pass it on in case it was missing knowledge for you.
in CP the goal I think should absolutely be helping beginners get a shape that makes intuitive sense, I just wish it wasn't in tension with other things
80's and 90's tech is what I've been rediscovering on my last 3 projects. Thanks ๐
consistently applied, bottom-left and top-right (and the other combinations) are all equally valid, but the one which is most natural seems to depend where you put your (0,0) pixel.
a mode where you draw all the edges too (using the diamond rule ๐ if we're lucky) would probably help with the expectations of a beginning user, but that may complicate the rasterization too much
I think that if you followed the rasterization of those two triangles (or equivalently the square) with drawing the 4 outside lines, you'd get 8 pixels from the border + 1 pixel of interior. 3 of those border pixels would also have been filled by the solid rasterization step.
hmmm circa 1996 there was a software opengl (1.1) rasterizer much smaller than mesa (even circa 1996 mesa). I wonder what happened to it. It would probably fit on micros now.
I'd really like to see an adafruit EVE2 display. I've done some good things with those chips.
if there isn't already one, it wouldn't be too difficult to add a circuitpython library. I already wrote one for the particle photon
@tulip sleet do we have mpy-cross builds for 5 and 6?
@low sentinel there is a _eve module already
added by the gameduino dev iirc
no, there is .zip of a bunch of 4.x or 3.x builds
we need to add a windows CI build of mpy-cross and then actually upload them
there is a
_evemodule already
@slender iron oh yeah!
okay, i'm ready to give adafruit more money
@tannewt now compiles on msys!
Thank you! Always good to be explicit.
Done! Thanks @ciscorn
Using the native one is fine with me. You could have the BLE version inherit from ConnectionError to start.
Looks good.
Maybe we should split audiobusio into pdmio and i2sio.
Please delete the mpy-cross file. The easiest way is to edit the existing commit to remove the file.
This fix looks good otherwise! Just a style comment. Thanks!
Since the if returns, you can omit the else.
size_t index = mp_get_index(&displayio_group_type, common_hal_displayio_group_get_len(self), index_obj, false);
common_hal_displayio_group_insert(self, index, layer);
return mp_const_none;
Further investigation reveals that this issue is related to the terminal emulator being used. Some emulators will send in the entire pasted string in one packet, which always succeeds. Others send in one character at a time, which is prone to the error. Emulators tested so far that work are putty (windows & Linux), TeraTerm(Windows), and screen (Linux). The failures were seen using minicom on Linux. Given the high usb rate (115200 baud) and relatively slow CPU speeds on nrf, I'm not sure that...
@gilded cradle you'll know the answer to: https://forums.adafruit.com/viewtopic.php?f=60&t=167826
@slender iron I'll take a look
thanks!
Thanks @tannewt, I made these changes, verified them again and committed. Also I deleted the unnecessary mpy-cross file.
At what lower (tx) baud rate from the Windows/Linux end does this work (more) reliably?
@slender iron just came across this old post in another forum and moved it to circuitpython:
https://forums.adafruit.com/viewtopic.php?f=47&t=164569
might make for a good FAQ somewhere?
The baud rate actually does not matter ( at least not on the
Circuitplayground Bluefruit I was testing with)
For USB the baud rate only is used if the USB is going through a
USB->serial converter. If it is 'pure'
USB then baud does not matter. I did test with baud rates from 115200 to
9600 just to make sure what I
thought I knew was true; and the results did not vary.
The only reliable fix I found was to use a terminal emulator that sends the
entire pasted string at once.
On Tue, Jul 28, 20...
We did test the fix for issue #3049 on a CPX with irremote - I will re-test and investigate further.
@DavePutz Interesting, I've always wondered if baud rate has any meaning on USB but never looked into it. I'm from the 300 era but I just connected using 110 from PuTTY and it doesn't feel at all like 110 :)
@tidal kiln that's the first time I've seen it. they'll have to make their own terminal
the built in one with blinka is fixed
ok. thanks.
oh look another day where I basically didn't read this channel or check my github pulls & issues. ๐ฅ
@tulip sleet there is a build artifact called mpy-cross.static-x64-windows made by current builds. However, it is cross built from Linux using mingw. I have tried it, but only on wine, so that's maybe not the greatestest test
usage: Z:\tmp\mpy-cross.static.exe [<opts>] [-X <implopt>] <input filename>
Options:
...```
oh, I'll try it on windows. I have many windows machines ๐
there's also one for macos catalina, raspbian, and amd64-linux
they aren't uploaded to S3 right now, so that's the last step. We could create a separate mpy-cross directory, like the language subdirs, I guess
yeah I didn't know how to do the s3 things but it would be a great addition. finding things in actions artifacts is not great.
@onyx hinge OK, ran that .exe on Windows, worked fine, and the compiled .mpy (Hello World) works
i can look at the upload. It should be similar to the .uf2 etc. uploads
thanks for finding that; i had no idea
sure thing (I implemented it)
Looks like this was broken by commit 9cdf5e1. Connie determined that the
previous build
(commit 72f6d7e ) works but 9cdf5e1 ( Jeff's linked list of background
tasks ) does not.
I will investigate to see exactly what the change affected.
On Tue, Jul 28, 2020 at 1:54 PM Scott Shawcroft notifications@github.com
wrote:
@DavePutz https://github.com/DavePutz any thoughts?
โ
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<http...
@onyx hinge I'm working on a PR for mpy-cross upload. not hard
thanks, that'll make it much more useful to people. will you cover all of the binaries we generate?
yes, and the filenames will be tagged with the version
aha I think this is the small opengl implementation I remember from all those years ago https://bellard.org/TinyGL/
Fabrice Bellard is a certain kind of genius
I use tio on debian linux. At least from how it looked on the receiving side, it does transmit one byte at a time. I'll investigate possible alternatives to tio.
Why do SAMD51 CircuitPython devices have a USB path like /dev/tty.usbmodem14701 that is consistent with the physical USB port it's plugged into, whereas ESP32-S2 CircuitPython devices have a USB path like usbmodem1337DEADBEEF1 with the MAC address + "1"(macOS)?
Maybe the better question is, why don't SAMD51 (or other non-ESP32-S2 CircuitPython) devices present some unique-to-the-device USB path?
mpy-cross executables are uploaded to s3://adafruit-circuit-python/bin/mpy-cross/mpy-cross*, with version tags. The version tags make the executables long but make the completely identifiable.
I use this alias:
alias repl='picocom -q -b 115200 /dev/ttyACM0'
Even with tio, 6.0.0.alpha.2 is much better than 5.1.0, the two uf2s I had handy. Now USB tasks are not delayed until the next 1ms tick, making them less likely to get "backed up", I guess.
Modifying tio to do multiple bytes of I/O at once makes the problem go away and also makes it feel faster when pasting lots of code. Interesting. I may PR this with the tio maintainers though it looks like the version I modified (debian stable) is pretty out of date--the changes don't apply directly,...
I set this to long term since the impact is low and there are workarounds
@fiery silo hoping to give you a poke about setting up the Open Book with Circuitpython. I'm not seeing anything appear on the screen and I'm wondering if there's a trick I'm missing. Also ImportError: cannot import name FlashBabel with your example code, not sure what's up wth that
But I might just be being dumb and missing something
@ionic elk No worries, I think I refactored that class to just be called โBabelโ at some point, but would have to duck back into the code to check it out (Iโve been mostly in Arduinoland lately)
Would be happy to regroup with you tomorrow about it either here or in DM, whichever works best
Sure I'll send you a ping in DM
Any ideas why the display might not be working? Libraries, maybe?
Youโre using the latest CircuitPython build for the open book board? https://circuitpython.org/board/openbook_m4/
that's the one
Or rather I've tried both, the 5.3 and the 6
I tested the board with Arduino so I know it isn't the hardware
At least in the case where you just print things to the console and let the code finish executing, the screen should just refresh to show the console output. If youโre drawing to the screen with displayio though you will need to call display.refresh() to make it update
I'm not even getting that.
hmmm maybe I should load up arduino one more time and just make 100% sure it isn't hardware
Also just to be sure is this the Open Book board or the e-book featherwing?
Yea for that one it is more manual, youโll need to use the Feather M4 UF2, youโll also need the appropriate EPD libraries and then youโll have to instantiate the display in your code
Yep that'd do it, I should have thought of that
Do you have the display instantiation code so I don't have to port it from C?
All good, I need to improve the documentation on this point
Itโs just the IL0398 driver
I just meant the pins but it's cool shouldn't take a minute
Ah right, CS is 9, DC is 10, reset is A4 and busy is A3
And SPI is just the main board.SPI
nice, TY!
And what did you say the proper inclusion for the Babel library is? from babel.babel import Babel?
that'll work with the flash chip?
Let me double check on that right quick, itโs been a minute since I looked at that code
Sorry to bug you so late at night I can ping you tomorrow
Screen is updating, though, so that's fun!
Itโs all good! Easy for me to look at now (and Iโm most productive late too)
Here's what I've got:
https://gist.github.com/hierophect/5082f9527efa68718a42942928a46659
I see updates on reloading, but no text, it's just white
Ha ok so I definitely shuffled some things around in a confusing way (left it in kind of a work in progress state)
Itโs from babel.babelflash import FlashBabel
Lemme gist this
demo of babel multi-language support in CircuitPython - code.py
Has dependencies adafruit_bus_device, adafruit_bitmap_font and adafruit_display_text
oh also
hmmm I've got all of those but I see AttributeError: 'FlashBabel' object has no attribute 'info_for_replacement_character'
Huh. Whatโs the stack trace for that?
Traceback (most recent call last):
File "code.py", line 11, in <module>
File "/lib/babel/babelflash.py", line 36, in __init__
File "/lib/babel/babel.py", line 71, in __init__
File "/lib/babel/babel.py", line 101, in _fetch_glyph_basic_info
AttributeError: 'FlashBabel' object has no attribute 'info_for_replacement_character'
OH
Did you hit the step in the setup guide where you burn the Babel.bin file to the chip using an Arduino sketch?
yeah it should be on there
I had it displaying chinese and japanese with arduino
But I did that a while ago, maybe it's out of date?
Nah, the Babel.bin file hasnโt changed in ages...
In the short term though I'm more concerned that I can't get a terminalIO font up and running. Does my setup look ok to you?
Ah, try adding display.show(None) after you instantiate the display
I think I see a very very faint blinka up in one corner?
but it's just like a smudge of pixels? maybe a contrast issue?
But the contrast looks fine on Arduino?
yeah, had no problems there
This whole thing works on your featherwing?
oh what
uhhh
on a whim I changed the terminalIO text color from 0xFFFFFF to color=0xFF0000 and now it works
lol
I was actually about to type something about the highlight color
highlight is still 0x000000
But color was part of the solution at least!
indeed, thank you!
I appreciate your help
just this info_for_replacement_character thing now
I will look into it tomorrow, itโs weird, it looks like itโs crashing when itโs trying to set that attribute which doesnโt make a lot of sense
Though, if itโs a very old babel.bin file, maybe
would have been from mid spring
Yeah the big change happened back in feb, so, hmm.
well thanks for your assistance, it's almost there! Appreciate you staying up late to help out
Anyway Iโm glad we got halfway there, happy to have helped! Yea Iโll loop back with you in DM tomorrow
Coolbeans. I'm using Babel to make a japanese flashcard app and it'd be neat to show it on Show and Tell tomorrow
Rad! ๐
it is you who are rad, fitting all of these glyphs on a humble nor flash ๐
i can't wait for my segger j-link to get here
anyone set this up yet? https://wiki.segger.com/J-Link_Visual_Studio_Code
๏ผ joey for when you get on tomorrow: I'm not grepping any instances of info_for_replacement_character outside babel.py - did you maybe accidentally cut them from the class?
this flips the bottom-right style to top-left which is at least
kind of normal. A 2x2 square at (0,0) would be defined like
(0,0), (3,0), (3,3), (0,3)
Which seems kind of surprising but at least less bonkers than
that square being defined at (1,1), which is the current behavior.
[
(0,0),
(5,0),
(5,10),
(0,10)
]
points as above create the interior pixels below
 version of PEP492 (CPython 3.5), where aiter was
an async-def function. But that changed in the final version of PEP492 (in
CPython 3.5.2) where the function was changed to a normal one. See
https://www.python.org/dev/peps/pep-0492/#why-aiter-does-not-return-an-awaitable
See also the note at the end of this subsection in the docs:
https://docs.python.org/3...
Morning @ionic elk! FYI, I was able to replicate your issue in the end. It has to do with the babel.bin on the chip being outdated; if you erase it and burn the latest version, it should work. https://github.com/joeycastillo/babel/raw/master/babelconvert/babel.bin
basically i made some changes to the babel.bin header in feb to accommodate more Unicode planes, and the CircuitPython library isn't seeing the new values for first and last glyph.
the reason the Arduino library still works is that it still has some of that hard-coded; I hadn't gotten around to making it load those values from the Babel image instead ๐
@fiery silo can I load babel.bin from circuitpython? Or do I need to swap over to arduino again to do that?
You would need to run the BurnBabelBurn Arduino sketch with the new bin file on an SD card, yea
But, yโknow, easy to switch back with a CircuitPython uf2. The Arduino sketch wonโt touch the files on your featherโs flash so it should just go right back to working (though backing up never hurts!)
Love the name of the sketch
I feel like an idiot because I did this before, but is arduino just supposed to work after the board has been programmed with circuitpython, or do I need to run burn bootloader, or put it in UF2 mode, or what?
Youโre all good, the bootloader is the same so you should be able to just run a sketch
tho it never hurts to double tap reset
@fiery silo no luck with latest babel.bin
assuming that is the latest, up on the website?
I get the same error
So weird. You erased, wrote and verified it?
erased, written, verified
here's my babel
(I renamed it before flashing)
maybe it's different than what you have?
HUH. Lemme take a look.
babelconvert/babel.bin does say it was last updated 6 months ago
last change was add first_codepoint field
could you send me the babel.bin that's working on your end?
Just checked with diff, theyโre identical
wat
Yeah, you have the right bin file. And youโre using the latest library files I take it?
This is so confusing. But maybe we should move to DM so as not to monopolize the channel
yeah sounds good this is getting esoteric
Indeed
hmmmm does bitbangio actually work with adafuit_sdcard? I should check ..
no it doesn't. scratch that off the list
This prevents bitbangio.SPI from being used with adafruit_sdcard.
I thought I could test this by forcing the upload to happen all the time, but I can't because a fork PR doesn't have access to the secrets. However, in the process of failing to test I did some strawman testing and did fix some problems, so I think it should work when merged.
Calling storage.erase_filesystem() can cause an intermittent but frequent Linux crash. I considered this a Linux bug but have been informed that Linux doesn't see the need to guard against USB MSC devices acting badly.
This change disconnects from USB before reformatting the filesystem and then waits for 1 second before resetting. This appears to prevent the Linux crashes: I tested multiple times.
My original Ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/187...
@slender iron does Label support text wrapping?
ยฏ_(ใ)_/ยฏ
@ionic elk not last I checked, but you can insert \n
@ionic elk @crimson ferry is correct as of now no automatic wrapping in Label. There is a rudimentary wrap_nicely() function in the PyPortal library though that can be modified to suit other purposes if you do want to have a Label that wraps without having to "manually" insert the newlines . https://github.com/adafruit/Adafruit_CircuitPython_PyPortal/blob/f53287de5b0c406e05badcedb802c3871383c136/adafruit_pyportal.py#L1101
It's probably fine, the font I'm using is monospace
So it's easy to calculate line lengths
I don't think there's an artifact named mpy-cross.static-mingw
There are two major components of the build that are time consuming and can't use make's parallelism:
- lto linking
- qstr preprocessing
Despite not being a measurable "win" in time spent waiting for CI, the changes ARE correct and an improvement. If we ever are able to improve the above two items, it may put us into the "win" column.
I'm anticipating the new bitbangio features will over-fill some M0 builds, in which case we'll have to decide what to do about it.
we can remove bitbangio from M0, its very very rarely used - there's tons of SERCOMs on M0?
I'm going to close this up in order to keep the PRs section tidy, but the work will remain in the related branch.
we can remove bitbangio from M0, its very very rarely used - there's tons of SERCOMs on M0?
We use bitbangio.OneWire internally for busio.OneWire. The base implementation is in shared-module/bitbangio/OneWire.c, and shared-module/busio/OneWire.c just calls the routines in bitbangio.
We could swap that around so that the base implementation is in busio.
:+1: We discussed this on Discord. Assuming I understand what I'm seeing in the attached image, it's the result I was looking for. This is the usual definition used in 90s pixel graphics pipelines like OpenGL, so while no choice is 100% intuitive to a new user, this rule is backed up by practice.
- fix #3011
- update TinyUSB for better highspeed support
- for Highspeed all bulk endpoint (cdc, midi, msc etc ...) must be exactly 512
- add
--highspeedoption to replace --msc_max_packet_size - make sure all CFG BUFSIZE for usb is at least 512 for highspeed port ( iMXRT & cxd56 )
- Should also improve esp32s2 usb speed thanks to https://github.com/hathach/tinyusb/pull/468
- Also remove obsolete tinyusb config macros
@jerryneedell I submitted an PR to fix this #3225 , when you have time, please check it out.
Sorry, yes, there are about three different names being used for the Windows build, and I had an extra line in there.
Sorry it's a mess, but thanks.
There's still a part of this that can't truly be tested until it's merged to main. Feel free to merge when THIS CI turns green, but keep an eye on the result of main's CI next.
Looks like the only failure was spresense, so this didn't run anything out of space. WHEE
Does anyone know how to change time_to_refresh on an e-paper screen? Right now it reads as a ridiculous value of 180 seconds, but if I try to change it I get AttributeError: 'IL0398' object cannot assign attribute 'time_to_refresh'
I think a higher time to refresh can damage the screen; that's why the value was picked
Makes sense but three minutes seems a tad high
I rewrote it to be about 5 seconds, as per @fiery silo 's recommendation
The primary issue seems to be that the value cannot be changed from the python script itself
I know the tri-color displays want three minutes between refreshes, but the black and white ones seem to be fine refreshing more quickly in my experience
@ionic elk @fiery silo https://learn.adafruit.com/adafruit-eink-display-breakouts/usage-expectations
The bookereader displays are very different than the small ones we sell
@tulip sleet Dan, I am thinking of compiling ulab into a native module. Does that make sense at all? What should I watch out for? Are there performance issues?
i'm not sure what you mean; it's already a native module, because it's in C.
do you mean shared-* vs extmod? There would be no performance difference
No, what I meant is an .mpy file that you can copy to the hardware, without having to re-compile and flash the firmware: http://docs.micropython.org/en/latest/develop/natmod.html
@tulip sleet interesting I didn't know that tri-colors needed that degree of caution
unfortunately, we don't support that yet -- it was added after our last merge from micropython (which was a long time ago)
But you do have .mpy files to distribute, don't you? Or are those simply the outputs of mp-cross, and come from .py sources?
right, the latter
OK, then I will have to dig somewhere else. Thanks!
it's a very good idea, it would save a lot of juggling of what goes in what port, but we're not there yet ๐
Right, I was about to ask, whether that could simplify your whole build process.
You could probably just release the major versions, like 6.1, and the modifications/improvements would come from the .mpy files.
Is it somewhere in the pipeline, or you haven't yet seriously considered it?
@onyx hinge - Do you have a couple minutes to chat sometime?
@ionic elk I think the expectation is that you would init with seconds_per_frame= and not need to change it in user code, but you can check time remaining
@crimson ferry I missed that seconds_per_frame would dictate time_to_refresh, you're probably right
fwiw, I was running my 2c & 3c ePaper FeatherWings at much faster refreshes for several weeks or months with no ill effects, longer term YMMV
Might be a manufacturer warning that's just super duper cautious
@lapis hemlock after 6.0.0 comes out, we'll probably wait for micropython 1.13 to come out, and then we'll do a merge. But the last merge took me 2 or 3 weeks to do, and this may be more
@lapis hemlock But the last merge took me 2 or 3 weeks to do, and this may be more
@tulip sleet Yeah, I can imagine.
What version of ulab does this update us to? (For release notes.)
What version of ulab does this update us to? (For release notes.)
0.54.0.
@WarriorOfWire This fixed by #3221 ?
@onyx hinge where is mount_sd? is it something not yet merged?
@solar whale it is a file that the user creates according to instructions in the accompanying guide.
mount_sd.py in CIRCUITPY
๐ณ oops -- I need to read the whole thing.... I was just looking at the example
FWIW, in my ninja branch I was working on parallelizing the qstr preprocessing.
I don't know that I explained it in the PR
Yes, that's the answer. ๐
@Jeff E. - Do you have a couple minutes to chat sometime?
@uncut nexus probably -- what's the topic?
issue 3216 - pulseio is broken after your background task commit
OK
I know what the issue is - just want to discuss the best way to fix it
great. do you want to stay with text or switch to voice?
voice is better, I think
either way I hope you'll add a brief summary to the issue once we're through.
OK
let me find my headphones
Awesome! Thank you for doing this! I've been meaning to update TinyUSB.
@uncut nexus sorry if I started out being a little defensive, every point you made was right on.
@slender iron do you want to review https://github.com/adafruit/circuitpython/pull/3220? If not I will merge and make sure the uploads really happen. Right now it's stuck in Actions, but it ran the non-board jobs fine.
@tulip sleet nope, all good
@ionic elk if you are using monospace then I suggest using a tilegrid instead of label. it'll use less memory
there's a huge backlog of actions, i'll need to wait
and epaper refresh time is seconds_per_frame here: https://circuitpython.readthedocs.io/en/5.3.x/shared-bindings/displayio/EPaperDisplay.html#displayio.EPaperDisplay
@slender iron thanks! I've swapped back to Circuitpython work for the day but I'll check that out for the future.
I hope to ask this in the next meeting, but in the meantime, does anyone object if I try to translate the .org site to spanish?
(want to have this ready for 9-9
)
@silver tapir I think we would want to have a single site still and have a language tab/setting. Does that make sense to you?
@tulip sleet Yes. If I do things right, only if you have your browser configured for "ES" content, you won't see I did anything.
sounds good!
though an explicit tab might be good also
I don't know how various sites do this: some are automatic but you can still switch languages at will
Yes, wikipedia for example has both. I tries to detect my lang, but I can still choose on the left side what translation do I want.
And yes, it sounds better this way.
This is just a couple of minor improvements to the Open Book. The main change is that it sets the screen's orientation to portrait to match the way users hold the device.
It also adds descriptive pin names per comments in #2520; I tried to use nomenclature that matches other Adafruit boards (MICIN and MICOUT from the NeoTrellis, BATTERY from Feather boards). USB is a voltage divider on VBUS for determining if the device is plugged in to external power.
is this just some actions weirdness? must be. https://github.com/adafruit/circuitpython/runs/924407804?check_suite_focus=true
I looked at the raw log, and saw this weirdness: it can't find a machine to use:
2020-07-29T17:59:31.9783608Z ##[section]Starting: Request a runner to run this job
2020-07-29T17:59:34.9155502Z Can't find any online and idle self-hosted runner in current repository that matches the required labels: 'ubuntu-18.04'
2020-07-29T17:59:34.9155612Z Can't find any online and idle self-hosted runner in current repository's account/organization that matches the required labels: 'ubuntu-18.04'
2020-07-29T17:59:34.9155689Z Can't find any online and idle hosted runner in current repository's account/organization that matches the required labels: 'ubuntu-18.04'
2020-07-29T17:59:34.9155846Z Found online and busy hosted runners in current repository's account/organization that matches the required labels: 'ubuntu-18.04'. Waiting for one of them to get assigned for this job.
2020-07-29T17:59:36.1963698Z ##[section]Finishing: Request a runner to run this job
we seem to have overwhelmed the actions system somehow
also I saw messages on other jobs about DBCPU limit being reached
ah I didn't think to look at the raw log. There was no "opening triangle" for the failed step.
Upload worked (test.txt is left over from some manual testing):

Yah, the triangles aren't working right either.
nice (mpy-cross uploads)
there's now a central location, which is the best thing; we should also put links in circuitpython.org somewhere.
I don't know how many people are going to use a commandline program to make mpy files but I think at least a few would.
on anything that's "express" it seems like just copying the py file is fine
but I haven't been pushing the limits in terms of complex programs, some people do
@onyx hinge buuuut if there were a drag+drop frontend for making .mpy files ๐
(at least I'd use it...)
dang!
@slender iron I added memoryio to microcontroller to match nvm. It builds for fomu, but unfortunately I don't have one to test with and the orange crab isn't added to main. https://github.com/ryang14/circuitpython/tree/raw-memory
Actual result:
>>> import displayio
>>> b = displayio.Bitmap(8, 8, 2**28)
>>> b[0, 0] = 1
Traceback (most recent call last):
File "", line 1, in
ValueError: pixel value requires too many bits
>>> b.fill(1)
Traceback (most recent call last):
File "", line 1, in
ValueError: pixel value requires too many bits
(2**28 is used because the PewPew M4 I am testing on doesnโt have long ints enabled โ the bit depth is rounded up to multiples of 8 so this results ...
@kind river nice! it should be doable on non-fpga ports too
Yeah, I'm going to try testing on an m4 tomorrow. Is there a section of memory that I can be fairly sure won't be used by something else?
Or I could just use an array for testing
on the samd51 you could poke backup ram
Okay, I'll try that. Thanks
np, neat! I was reworking the lamdasoc stuff here: https://github.com/tannewt/systemonachip
set up sphinx on the repo last night
Cool, I'll check it out
I'm hoping to output a ninja build file instead of calling everything from python
Neat, would a proper build system let it do stuff like only resynthesize if the generated HDL was actually different?
ya, that's my hope
I don't know how parallel the work is though
@kind river memoryio.ByteArray doesn't need to be a singleton. I'd add a constructor that takes in the start address and length
each port can then block some addresses that we don't want to support
yeah, I still need to rip out some nvm remains
it might also make sense to make it a separate module to allow for porting between accessing the bus locally or through usb/uart/etc from linux
yup! That's what I was thinking. You can pass in anything that acts like a bytearray
we may want to lock it down a bit for access alignment
@kind river memoryio is nice! is the idea only for RAM? I had a use for flash access (readonly would be ok,) as well: I wanted people to be able to read the fuse flags to help for support issues. So I would have a use for a memoryio array based at 0x0.
@tulip sleet we came up with the idea for fpga actually
so we can write a python class that both defines a peripheral's gates and also be the driver for it
I think it makes sense to store start addresses/sizes in microcontroller like pins so you could do something like sram_data = memoryio(microcontroller.memory.sram)
๐ all i want to do is fetch 8 bytes starting at 0x804000
other values I might want to fetch are scattered in various places, and are chip-dependent.
I mean I think that should be available as a shortcut if that makes sense
seemed like a low-level peek/poke interface might be helpful. I was not expecting to use this for regular use, but for debugging/support: "Please check this address and tell me what you see", etc.
otherwise I've had to write a small Arduino program and tell the user to load it, which is a lot of work and requires some extra skills
i did start working on it and cloning nvm, but i didn't finish it, due to the kind of refactoring that you are doing now
having defined regions would be potentially useful for my intended use of accessing memory mapped custom peripherals
however, this may be taken care of by the higher level drivers in that case anyway
I'm fine having predefined regions on boards where we have the memory
you could use a memoryview on a slice of the virtual bytearray representing the entire address space
and I'd like the constructor to have some guard rails so it's hard to actually hose yourself
periph = memoryview(microcontroller.address_space[0x444000:0x4444100]
yes, a constructor might be safer; i'm just thinking idly
a constructor can then have an iknowwhatimdoing kwarg
microcontroller.dangerous_raw_memory
the constructor could take either a predefined or custom region
and maybe treat custom as read only unless explicitly told otherwise or something
maybe we shouldn't call it ByteArray because it's usually always writeable (bytes objects aren't)
microcontroller.dangerous_raw_memory
@tulip sleet
Sorry for intruding, but i just wanted to say that if you do something like this, you might want to make it read-only or somehow.
Or make it a function that returns an internal variable you shouldn't touch?
I should go to sleep
@wooden nest thanks, yes, we want to make it obvious it's dangerous, by default, read-only, etc.
as someone in college once told me, "sleep is where it's at"
Service objects contain a field mp_obj_list_t *characteristic_list, which is meant to be a Python list of Characteristic objects.
Characteristic objects contain bleio_descriptor_obj_t *descriptor_list, which is meant to be a linked list of Descriptor objects
Descriptor objects contain struct _bleio_descriptor_obj* next, which is used for the linked list.
But, there's this code:
https://github.com/adafruit/circuitpython/blob/c754e0171157bdad5341da29bd7e083d81ebc817/ports/...
@slender iron I have a request for adding a Hindi translation of CircuitPython. It looks like a "complex" script with combining characters, but it has a romanization. I assume I should add the romanization? fwiw the requesting user is weblate @spring juniper2604 who I can't directly relate to being active in CircuitPython to date .. there's not a github user with the same exact name and the weblate account is new and doesn't have activity. I'm also not sure how this person would be informed that I added a different translation (hi_Latn) instead of the one they requested (hi). Or even if they are informed that I added a requested translation.
oh good!
we could do the complex version if we disable terminal right?
Yeah it's a question if whether to prioritize showing up in a proper unicode context looking like a native reader would expect (but I hear mu is not great for utf-8 support), or able to work with displayio and the on-display terminal..
same tradeoffs as zh_Latn
I think it'd be good to get it in and then we can disable the terminal
the prints to terminals besides mu should be ok
OK so go ahead and add hi, not the romanization? I can do that.
I think so
we'll rope Joey into getting us a full unicode terminal someday soon right? Anyway it's ready for @spring juniper ! https://hosted.weblate.org/projects/circuitpython/main/hi/
And thanks in advance for your contributions
heh, ya. that's my hope
light cursing the stm sdio PR is taking longer than I thought to get to the state of "actually building". Oh well.
thanks Dan for tagging, that is good read. Disconnect and reconnect is a common way to go around this. Note on some MCUs the tud_disconnect() is not supported in the usb controller (may need external GPIO) but those are pretty old mcu design.
@tulip sleet this lib may interest you https://github.com/WarriorOfWire/tasko
Looks good.
Maybe we should split audiobusio into pdmio and i2sio.
I resolved the conflict by merging and updating circuitpython.pot
Translations update from Weblate for CircuitPython/main.
?serverinfo
do we have a graphic for 23456 members?
No but feel free to pat the person on the back
Does the bot pull those numbers from a public API?
Integrate your service with Discord โ whether it's a bot or a game or whatever your wildest imagination can come up with.
Thank you
gemma and trinket de_DE translations are not fitting in this PR.
this also includes weblate's commit from #3229 that put it over the edge.
The build failures all look spurious to me.
I first noticed this on the weblate PR but it's affecting the main branch already as well.
Is it really necessary to only make the change for these translations? Why not just do it for all?
@solar whale because that's how we've done it in the past, I guess?
Seems overly complicated to me.
Is it really necessary to only make the change for these translations? Why not just do it for all languages?
The inline limit change makes the code slower, so if we can avoid this some of the time, it's probably better.
Is it really necessary to only make the change for these translations? Why not just do it for all languages?
The inline limit change makes the code slower, so if we can avoid this some of the time, it's probably better.
Thanks. That's what i figured. I just hope we never run into issues that only occur in these translations!
We could switch to GCC10 instead. I think we have everything in-place to do it.
I've uploaded the preview gcc10 toolchain from arm here:
aws s3 ls s3://adafruit-circuit-python
PRE adabot/
PRE bin/
2019-04-16 19:02:28 103853 CircuitPython_Repo_header_logo.png
2017-11-15 23:05:07 65011116 gcc-arm-embedded_6-2017q2-2~trusty1_amd64.deb
2018-01-05 00:32:54 65541900 gcc-arm-embedded_7-2017q4-1~trusty3_amd64.deb
2018-07-25 17:40:07 63038916 gcc-arm-embedded_7-2018q2-1~trusty1_amd64.deb
2018-11-26 13:3...
Let's see how this goes.
Closes: #3179
@tulip sleet are patches to gcc10 still needed or can it be used "out of the box"
@solar whale Do you mean "to gcc10" or "for gcc10"? Scott patched the CPy code so it would compile, and that has been merged. He has been testing gcc10 with the arch Linux package; I don't know how that compares with the ARM preview download.
ah -- OK -- I was under the impression a patch was being made to the gcc10 distribution. Glad to hear it is not....
@jepler Did you see the discussion on dropping bitbangio on tiny M0 builds to make space and some mild refactoring it would need?
as with the 8->9 switch, some boards seem to grow while others shrink. For example, trinket_m0 de_DE wasn't fitting at the ref of main where I based this PR, but started to fit. However, bast_pro_mini_m0 overflowed.
There are also some build errors that are NOT just over-full flash, perhaps they weren't encountered while working on #3194 . arduino_nano_33_ble fails with linker messages about multiply defined symbols:
/usr/bin/../lib/gcc/arm-none-eabi/10.1.1/../../../../arm-none-ea...
Looks like the nrf and i.MX builds need to add a bunch of externs. Also de_DE still does not fit for bast_pro_mini, at least.
@tulip sleet @onyx hinge think it's worth me externing things?
Right this second? Maybe not.
it shouldn't take too long to go through them all
if you do, feel free to push it to that branch
I'm listening to the Circuit Python weekly. Do you still need reviewers?
@fringe trench we are always happy to have new reviewers ๐
I need to grind rust off my code reviewing skills, so if you don't mind, I'd like to help.
This page is a great place to get started: https://circuitpython.org/contributing it will list all of the open pull requests for the Libraries
If do take a look at some and/or do some testing of anything please feel free to post your thoughts and/or test results on those PRs in Github.
Will do. I'm pcurry on github, my icon is my Gravatar.
It's also a guitar I own. ๐
Nice! Thank you for helping out. Please feel free to ask for help if you start looking into something and wind up having questions about the Circuit Python, or Github PR Reviewing etc..
@dhalbert bitbangio is already disabled on those ports, it's only in FULL_BUILD.
Looks like trinket_m0 still didn't fit with these changes. Weird, it passed locally. Did I fail to build with the language I intended?
There were also some spurious-or-preexisting failures of xtensa:
FileExistsError: [Errno 17] File exists: '/opt/hostedtoolcache/Python/3.8.5/x64/bin/python' -> '/home/runner/work/circuitpython/circuitpython/.idf_tools/python_env/idf4.2_py3.8_env/bin/python'
@lone axle honestly, my first pass is just going to be formatting, whether the tests run, etc.
I present to you, Quetzalblinka, the mascot for CircuitPython Day Centralamerica.
adorbs
I wonder whether python3's _pydecimal.py can be hacked down into something that'll fit on circuitpython. I'd like to do non-integer arithmetic with more precision than our floats
the mpy file of it is 82kB
?serverinfo
@onyx hinge Is a fixed point approach using existing CP "big" integer viable for what you're doing? Might work if you only need certain math ops
I think it will have to build on big integers. Goal is a 16+ digit RPN calculator with keypad and display
maybe more like a non-graphing hp48?
A 2inch-ish display https://www.adafruit.com/product/1770 and about 40 "12mm" buttons, it would be physically bigger than the HP48. Maybe comically big.
@tulip sleet FYI -- tried gcc 10 on linux (Ubuntu 20.04) -- seems OK for atmel-samd. As noted, nrf fails. have not tried others yet. I am also trying to build a toolchain for the RPi. Takes about 8 hours to build -- sorry --initially posted to wrong channel
Heatsink and fan are holding the RPi4 at a comfortable 55C...
@solar whale did you try many of the created uf2s? sometimes they have had interesting things newly busted ๐
no -- I haven't -- I'll try some -- what issues have you seen?
but that is why I want the RPi build -- still skittish about my Linux box and resetting boards...
@solar whale You could speed up the rpi build by using tools like distcc, that allow you to use the compiler from another (o several) boxes.
(the only recommendation is to have the same compiler version in all distcc systems)
@silver tapir Thanks -- I'll look into that
Let me know if you need some help. I sometimes use a +160 xeon cores to compile slackware-riscv64 packages.
(Quite a rush vs a 4-core riscv64 box, or emulating riscv64 in qemu)
@onyx hinge @tulip sleet When I do my usual git pull and submodule updates, the frozen/Adafruit_CircuitPython_BusDevice submodule is not getting updated. Should it? I was not sore if the PR I did for the CPX updated it or not. Or is there plan to update al the frozen submodules at some point.
Do I have to do something special to update it? For now I just did a git pull origin master in the BusDevice subdirectory and it works for me. Just tried CPX built with gcc10 -- seems to be happy.
Somebody needs to pull-request the update of the submodule. Is that something you'd be comfortable doing @solar whale ? You use git commands in the submodule to update it to the latest release tag, build & test until you're happy, then "git add" and "git commit" the change in circuitpython (or the graphical equivalent) and then create a pull request in circuitpython.
it would be good to do that, it should probably be considered as milestone 6.0.0 as well if there's not an issue already
hmm -- so PR #3213 https://github.com/adafruit/circuitpython/pull/3213/files ddi not accomplish that?
how do I update the release tag?
Several other submodules have had updates as well. Probalbly should all be updated before 6.0 release
I have to go AFK for a few hours -- I'll look into this more when I can
@solar whale I have a simple shell script to update a frozen module to the latest release (not the latest commit): circuitpython/tools/git-checkout-latest-tag.sh I run this over all the frozen module dirs with a bash for loop.
The redo of how background tasks are handled changed the accuracy of supervisor_background_tasks_ok() in the Pulsein interrupt handler. This resulted in the handler pausing the collecting of the pulsein stream, which effectively hangs the application. I will address 2 issues in a PR: 1) Correcting supervisor_background_tasks_ok() so that is is again accurate 2) Proper handling of an actual case of pulsein taking too long, returning an error to the application instead of hanging.
someone want to help bundle this: https://github.com/adafruit/Adafruit_CircuitPython_TC74 ?
@ionic elk from your status update Espressif has a funny habit of naming their peripherals in a way that makes them sound kind of limited, when the truth is just the opposite ๐ฏ
@slender iron do you know if I can document a "protocol" (interface) in our pyi stubs?
@slender iron Since neopixel_write doesn't really have a "construct", do you think it would be good if I put in a flag to detect whether a neopixel write request is the first one for a reset cycle, and then reserve an RMT channel indefinitely for it?
Or should I reserve and free an RMT channel for every neopixel write request?
@onyx hinge I imagine you can but ciscorn is probably the best person to ask
@ionic elk I'd reserve and free every request unless it's very slow
Ok, I haven't done any timing analysis yet but I don't expect it is
Other quick question @slender iron I notice that functions like rmt_wait_tx_done are calling stuff from FreeRTOS for timeout functions, like xSemaphoreTake. Is that all good?
or do I need to reconfigure the timing to avoid it or something
I also can't seem to get it out of GRB mode...
freertos stuff should be ok
I thing the GRB thing is a library problem? If my understanding is correct, when I put in:
pixels = neopixel.NeoPixel(board.IO18, 1, pixel_order=neopixel.RGBW)
pixels[0] = (10, 0, 0, 0)
It should be moving that 10 value to the R slot, since Neopixels use GRB order. But it's still first when I receive it in Neopixel write, and I don't see that the W does anything at all. Should I open an issue or is this something that needs fixing on my end?
@silver tapir Quetzalblinka is amazing! I love it!
def __init_(self, width=64, height=32, bpp=16):
๐คฆ
This PR adds Neopixel support to the ESP32_S2, and adds the onboard WS2812B as a status LED neopixel to the board profile of the Saola1-wrover.
This module utilizes the RMT (Remote Control) peripheral on the ESP32, which will also be used for PulseIn/PulseOut and possibly other purposes - thus, a simple channel reservation system has been added to peripherals, which these other modules will share. Neopixels reserve their channel every time they are written and automatically free it afte...
nice @ionic elk ! will review on my stream
@slender iron are there 1-bit displayio displays? or just epaper?
ah Adafruit_CircuitPython_DisplayIO_SSD1306 maybe
I had only found the "old" one at first
Ya oleds are a few bits too.
@slender iron For memoryio, should the contructor go in init or ByteArray? Assuming we even want to keep the ByteArray behavior.
bytearray
init is for module level stuff
(had a good conversation with whitequark on the #nmigen channel on freenode)
I don't think my 1 bit display is right yet (should be a 64x32 console with blinka)
closer!
where can I find out more about memoryio goals/features? Github search on circuitpython repo yields zero results
@slender iron We should probably open a github issue for memoryio to organize conversation about it. Do you want me to do that?
The main goal is to allow for pure python drivers for custom memory mapped peripherals when running on a FPGA SoC
The secondary goal is to make it also usable for debugging or accessing stuff like RTC ram on other boards
@kind river yes please
This comes in several parts. Everything but the hypothetical adafruit_displayio_sharpmemory is in this PR:
Shim framebuffer protocol
Allows pure Python objects to implement the framebuffer protocol. However, because these displays are Python objects, they do not survive soft-reset.
A do-nothing implementation might read as follows:
class UFrame:
def __init__(self, *, width=64, height=32, color_depth=8):
if color_depth not in (1, 8, 16):
raise Val...
The main goal of memoryio is to allow for pure python drivers for custom memory mapped peripherals when running CircuitPython on a FPGA SoC.
It should also be usable for reading raw memory on microcontrollers to assist debugging and allow access to memory regions not otherwise used by CircuitPython.
The API concept is currently memory = memoryio.bytearray(, ). memory can then be accessed as a byte array.
Displays that may not have displayio equivalents yet:
- pcd8544
- is31fl3731
- ht16k33
- max7219
- multiple adafruit_epd devices
I'm a bit interested in the is31fl3731 except that I have a 2x2 array of them so that won't exactly use standard code.
Alternately, adafruit_framebuf.FrameBuffer could be changed so that it provides those required methods for all the old drivers :thinking:
Code looks good but the CI isn't happy.
Are these mpy-cross build links available publicly?
I've recently built a port of the Qwiic Scale lib in CircuitPython, what's the recommended way to propose a new CircuitPython device driver?
@ionic elk I was trying your esp32-neopixel branch, and I'm getting a compile error. I don't see it in github's ci, but I'll ask anyway.
I'm getting:
$ make BOARD=espressif_saola_1_wrover
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
common-hal/neopixel_write/init.c: In function 'common_hal_neopixel_write':
common-hal/neopixel_write/init.c:105:9: error: implicit declaration of function 'mp_raise_ValueError' [-Werror=implicit-function-declaration]
mp_raise_ValueError(translate("Could not retrieve clock"));
^~~~~~~~~~~~~~~~~~~
common-hal/neopixel_write/init.c:105:9: error: nested extern declaration of 'mp_raise_ValueError' [-Werror=nested-externs]
cc1: all warnings being treated as errors
make: *** [../../py/mkrules.mk:55: build-espressif_saola_1_wrover/common-hal/neopixel_write/init.o] Error 1
I'm using xtensa-esp32s2-elf/esp-2020r2-8.2.0 which I think is ok. On ubuntu 20.04.
i made a mistake and now i need a segger-port-to-idc cable
@hidden geyser Check out this guide: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library. We have a community bundle of contributed libraries.
@tulip sleet nice, everything I need
This is weird, I use cookiecutter, gives me a git clone error. I clone the repo it's trying to clone manually and... indeed it fails, is it just me?
Actually I know what that issue is, it's an invalid folder name on the Windows filesystem
yes, it works fine here on Linux
you may want to use WSL. WSL2 is preferred: much faster disk I/O
I just upgraded WSL 2 days ago, time to check out my shiny new ubuntu โจ
This page might need a warning for Windows users: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/creating-a-library
hmm, cookiecutter is supposed to work on Windows, according to the doc. we might need to change something to make that happen
The templates on that repo I tried to clone uses special characters that aren't valid for folder names on Windows
Perhaps cookiecutter has an alternative syntax that could be used
It's the pipes in the filenames in the adafruit cookiecutter, I think it's an easy fix
I think windows does not like the {{ ... }} template directory name. I was not able to successfully clone and update the repo on windows 7. But I could from Debian VM.
{{ }}i s fine as of latest win 10, but | is not
I am able to create filenames with curly braces and pipes on Windows in the git bash shell
Ah, I see
No, it has a silent error
The names look like jinja2 template strings to me
I'm doing the modifications and I'll have a pull up soon
@tulip sleet git clone nonetheless still fails in that shell
yep, I did see that. But this private variables thing seems like a much more readable way of doing this than using horrible pathnames; thanks for finding that
i have to sleep, but thanks, looking forward to your PR or at least an issue. I did a lot of googling on this, and didn't find any similar mentions of such a problem
Kinda weird, I can't be the only person to be cookiecutting on windows ๐ค
Good night!
{% if cookiecutter.library_prefix %}{{ cookiecutter.library_prefix | lower }}_{% endif %}{{ cookiecutter.library_name | lower }}.py also this file ๐
@tulip sleet looks like it's more complicated in 1.7 than just using private vars, created an issue here
https://github.com/adafruit/cookiecutter-adafruit-circuitpython/issues/82
FYI -- I tried using gcc 10 to buil the grandcentral_m4_express -- it builds OK, but when I put the build on the board, it does not boot properly -- Staus neopixel starts off green then goes to yellow (possibly safe mode?) I can connect to the REPL briefly, but it eventually drops the connection -- no CIRCUITPY drive is mounted
some output from dmesg ```[483299.662154] sd 7:0:0:0: [sdc] No Caching mode page found
[483299.662169] sd 7:0:0:0: [sdc] Assuming drive cache: write through
[483...
I tried to build with this PR but it fails ```-- Build files have been written to: /home/pi/projects/circuitpython/ports/esp32s2/build-espressif_saola_1_wrover/esp-idf
QSTR updated
common-hal/neopixel_write/init.c: In function 'common_hal_neopixel_write':
common-hal/neopixel_write/init.c:105:9: error: implicit declaration of function 'mp_raise_ValueError' [-Werror=implicit-function-declaration]
mp_raise_ValueError(translate("Could not retrieve clock"));
^~~~~~~~...
@silver tapir @ionic elk I had the same error trying to build the neopixel PR (3232) for esp32s2 -- commented in the PR
@tulip sleet @onyx hinge FYI -- I ran into a significant issue with my GCC10 build for grandcentral_m4 -- USB is not working -- REPL or CIRCUITPY ... I have not tried other M4 boards yet. will do so later today. CPX (M0) seems to work OK.
I wonder why this didn't come up on my local machine? Weird.