#circuitpython-dev
1 messages · Page 345 of 1
I thought I had made a lot of progress when I figured out that my 'Unknown failures' are of type OSError, not ConnectionError. Except "No network with that ssid" is also an OSError. I'll post my test code later.
ah you are using pyportal matrix protal, now I have a version that works on the ESP32S2, but I have to modify it to use with a wifi coprocessor. I want to do it because I'm interested in it, but I gotta solder headers on my airlift featherwing first 
if you are interested, I think I have a version that should work for you. I put it there:
https://github.com/Neradoc/websockets-circuitpython-test/tree/airlift
CircuitPython update is implemented and User Code update can be done by a FTP server implementation in python layer as a library instead of implementing it in the core.
Move Build-CI actions on the basis of :- (closes issue #3877)
- Frequency of failing.
- Speed of completion.
its works thank you
nice ! it still needs work though, it might be a little rocky
hey, would y'all accept PRs on circuitpython libraries adding PEP-484 type hints?
The esp32s2 port currently does not have audio support.
only way to do this is with i2s, which there's a PR for
Ask again on Monday US time when the Adafruit crew are working.
You could always ask by opening a Github issue. If no, they it's answered and closed, in a public, and helpful, forum. If yes, then you already have an issue from which you can create the PRs
Reports 0.0.0 which is probably a little low.
➜ ~ cat /media/blake/MAGTAGBOOT/INFO_UF2.TXT
UF2 Bootloader 0.0.0
Model: Adafruit Metro MagTag 2.9 Grayscale
Board-ID: MagTag-29gray-revC
My ConnectionError crashes were due to me not catching the errors properly. So on that basis you might want to close out this issue. On the other hand, I am still getting unknown error and I think you were trying to fix those. I still get the errors, but I'm not crashing any more. I created this script to count connection errors and log them on Adafruit IO. See the README for more details.
https://io.adafruit.com/endico/feeds/failures
I have a close neighbor who is a gamer and I th...
@alpine nimbus so the crash happened in the requests code and not the Wi-Fi?
Running these commands in REPL my device is rebooting into standard mode coming up as a CIRCUITPY drive.
import microcontroller
microcontroller.on_next_reset(microcontroller.RunMode.BOOTLOADER)
microcontroller.reset()
Tested on:
Adafruit CircuitPython 6.1.0-beta.2-182-g1b7fbaf31 on 2020-12-26; Adafruit MagTag with ESP32S2
I don't see why not, but there could be compatibility or tooling problems I don't know about. Why not start with just one, and we can look at whether it's working with mpy-cross, the documentation and so forth. Some type hints seem to work (def f(x: Optional[int]=None) -> int: ...) and generate a .mpy file of the same size as without the type hint. However, you can't import typing so Arbitrary generic types as base classes don't work, or any other technique that requires import typing. That's what I know.
Also, hi and welcome!
ooh, that's interesting. i generated a stubs file for a few the libraries that had no types, and i was going through and adding types for the bits i was using. but then i thought, i'd need to do this after every update of the libs and it would be cool if the original stubs generation would be able to take the types from the file.
okay, is there somewhere i can learn how the libraries (like adafruit_midi etc) are built into the bundle and mpy files, so that i can try one and see if everything continues to work?
hi and thankyou!
generally speaking, each lib in the adafruit bundle is its own git repo, so you'd want to fork that one and make a pull request there. Once the pull request is accepted, the next steps are that adafruit peeps make a release of the lib, then the bundle picks up the new tagged release, and it'll go out in a dated bundle zip
so for instance the magtag lib is at https://github.com/adafruit/Adafruit_CircuitPython_MagTag/ and improvements can be PR'd there
microcontroller.RunMode.BOOTLOADER isn't implemented on the esp32s2.
I don't think it is possible to enter DFU (first-stage) bootloader on esp32s2 from software.
I tried to get reset to UF2 bootloader working but I am facing a strange issue #3813.
In your Pull Request, github actions will automatically do things like build the mpy files, so you can just create the PR and check the status. Let me see if I can find some relevant guides..
@minor glade If you have not seen this guide, it may help https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github/overview
OK this is a bit out of date... https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/creating-a-library#mpy-2982472-11
ah neat, thank you :)
i have a few of the libraries cloned already, so i'll read their github actions to see the build and test workflow and then make some changes and see what happens
OK, I did a quick update on the Learn page I linked, some of the version numbers it stated were out of date.
@minor glade feel free to ask more questions if you get stuck. I'm stepping away for the moment though
there is some way to enter the DFU bootloader from usercode because arduino does it...
@me-no-dev do you have any hints we could use to implement? :)
@minor glade one gotcha I ran into first contributing to the libraries is the CI runs black and pylint on all the code and won't accept it unless it passes those checks. If you can't figure it out let me know I can probably help you through
ah, i just recently got my editor set up to run Black on save, i'll see if i can teach it about pylint ^_^
I was trying to work out to what degree print() was slowing down some testing I was doing and noticed something else. This is a weird one, it's strangely reproducible. print() normally takes about 1ms but first one from a while loop (REPL only?) takes around 80ms extra:
Adafruit CircuitPython 6.0.0 on 2020-11-16; Adafruit Feather nRF52840 Express with nRF52840
>>>
>>> import time, random
>>> for _ in range(5):
... t1 = time.monotonic_ns()
... print("{:f} {:f} {:f} {:f...
Running 6.1.0-beta.2-182-g1b7fbaf31 on 2020-12-26; FeatherS2 with ESP32S2.
From REPL the following causes restart:
>>> from board import *
>>> import busio
>>> x = busio.UART(TX,RX,baudrate=115200)
>>> x.deinit()
this asm trick for function-specific ABI is horrifying. I'm sure someone motivated could use it to make CircuitPython compile smaller and be less readable. https://justine.lol/cosmopolitan/index.html
(different for arm than x86_64 of course)
I get following error when accessing the SparkFun VR IMU Breakout - BNO080 (Qwiic) using I2C from SparkFun Pro nRF52840
code.py output:
Traceback (most recent call last):
File "code.py", line 8, in
File "adafruit_bno08x/i2c.py", line 27, in __init__
File "adafruit_bno08x/__init__.py", line 506, in __init__
File "adafruit_bno08x/__init__.py", line 512, in initialize
File "adafruit_bno08x/__init__.py", line 1054, in soft_reset
File "adafruit_bno08x/i2c.py", line...
Is there a Board that can run circuitpython and be programmed via Bluetooth? As far as i can see, Circuit Playground Bluetooth etc. Can't, at least out of the Box...
I guess that would need either a custom Software in the Host, or a file-access bt-profile.
Alternatively, is there something like kind of "USB over bt" that could be added externally, transparent to the board?
@ladyada here is the shutdown handler that does the reboot into the proper mode: https://github.com/espressif/arduino-esp32/blob/idf-release/v4.2/cores/esp32/esp32-hal-tinyusb.c#L458-L479
it is registered here: https://github.com/espressif/arduino-esp32/blob/idf-release/v4.2/cores/esp32/esp32-hal-tinyusb.c#L531
Let me know if this does not help :)
In 6.11beta2 I get the following error when trying to initialise the UART
>>> from board import *
>>> import busio
>>> x = busio.UART(TX,RX,baudrate=115200)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: IO44 in use
I can't even get to x.deinit()
@atomic summit is this a DEBUG=1 build?
Thanks! @me-no-dev, this works... the changes are in my update-run-mode branch. :)
I was able to replicate the crash...
Adafruit CircuitPython 6.1.0-beta.2-182-g1b7fbaf31 on 2020-12-26; microS2 with ESP32S2
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x400b5347 PS : 0x00060030 A0 : 0x800b4349 A1 : 0x3ffdccf0
A2 : 0x00000000 A3 : 0x3f02c1e0 A4 : 0x3ffcf564 A5 : 0x3ffcf560
A6 : 0x00000010 A7 : 0x00000000 A8 : 0x800b534c ...
@analog bridge I think that the same pins are not supposed to be used twice, thus the hang.
hi @hearty tapir, I don't think that is the case... I did a fresh start, I am using different pins in order to not get the in use error.
I think I found the issue... common_hal_reset_pin(NULL) causes the crash.
A good change. Could go further and simplify existing cleanup code which DID check pins for being NULL, but not necessary in this PR.
excellent, thank you.
A good change. Could go further and simplify existing cleanup code which DID check pins for being NULL, but not necessary in this PR.
@jepler I removed the redundant NULL checks.
@slender iron I had to push to your PR via the web. I am curious, if you mouse over question mark on this permission checkbox (right sidebar on the PR), does it mention adafruit/circuitpython or micropython/micropython? (This screenshot is from an old draft PR of mine.)
I wonder if it's different because you forked from micropython
Thanks for the last bit. I was doing my pushes via the web. I'll let you merge if you're satisfied.
?serverinfo
Hi all and particularly <@&356864093652516868>, here's your reminder that due to the holidays there's no meeting today. I do want to take a quick moment to thank the past week's authors and reviewers, though!
- 27 pull requests merged
- 17 authors - siddacious, digixx, microDev1, bettse, ladyada, jamesrusso, slootsky, makermelissa, mshannon78660, d-c-d, ktdreyer, TwoTenPvP, dhalbert, jay0lee, jepler, twa127, jerryneedell
- 9 reviewers - siddacious, jerryneedell, ladyada, tannewt, brentru, makermelissa, dhalbert, FoamyGuy, jepler
- 16 closed issues by 11 people, 19 opened by 18 people
There are lot of people here, and a bunch of names I'm not familiar with: digixx, bettse, slootsky, jamesrusso, d-c-d, ktdreyer, TwoTenPvp, jay0lee, and twa127. We appreciate all your contributions!
We have one new library, https://github.com/adafruit/Adafruit_CircuitPython_LTR390
Thank you all for a great 2020 and we'll talk to you in 2021! This community has been truly important to me in this difficult year, so treat yourselves to a bug hug report from me.
I'm going to post some hug reports for the week here:
- jepler: Thank you for working on a fix for Acenders / Decenders and fonts without the M Glyph in display_text
- makermelissa: Thank you for the Web ESPTool. It's very convenient to use this instead of the python tool with drivers and extra setup steps.
- Group Hug: wishing everyone a happy new year!
I want to give myself a big hug for the swedish translation (Not sure anyone else uses it to be honest). 😎
Also; a big distanced group hug to everyone!
🎉 💯
Do I need the ARM toolchain for building esp32-s2?
no, when you run esp-idf/install.sh, it will download its own toolchain copy.
I'm looking at the Building CircuitPython guide, but sounds like I should start with Espressif's getting started guide
@crimson ferry take a look at ports/esp32s2/README.md, which will then point you elsewhere as well. Basically, you do esp-idf/install.sh once, and then after that, whenever you want to set up for building, do esp-idf/export.sh in a fresh terminal.
@crimson ferry I set up up building esp32-s2 not too long ago so if you get stuck or run into some weird problem let me know I may remember. It didn't end up being that hard to do
OK, thanks, I've never built any software before, so I'm trying to get my arms around what all's needed. I'll start there.
they've made it a lot easier than it was for the 3.x esp-idf versions. Setting up to build nina-fw was a lot more painful
@tannewt should we merge this into 6.0.x?
Not yet, but it's something I'd really like to enable for all of our nrf products
It says adafruit/circuitpython for me
is it normal to get esp32-s2 install.sh errors like ... ERROR: No matching distribution found for bidict>=0.21.0 (from python-socketio>=1.6.1->Flask-SocketIO<3.0,>=2.9->gdbgui==0.13.2.0->-r ...
maybe related to Python version, some warnings eearlier about Python 2.7
@onyx hinge the ESP32-S2 I2S PR https://github.com/adafruit/circuitpython/pull/3733 has some unresolved comments. I can pass it to someone to test, but I though there were some loose ends to wrap up.
@crimson ferry python should be python3
wow, even on Big Sur it's not
i have NOT tried to do ESP32-S2 builds on Mac. Only Linux
I think I did S2 builds on mac
there are apparently a lot of wrong ways to make macOS use python3
ideally ESP-IDF should refer to it as python3, not python, but it doesn't...
I use docker and ubuntu to build on mac
would I be better off having a dedicated Raspberry Pi for this?
it would be really slow
I wouldn't. the pi builds slowly
alias python => python3... I've used latest IDF on macOS. No need to build anything just clone, checkout s2 branch, recursively pull in submodules, run the ./install.sh and . ./export.sh commands and ya should be set.
Is there a good learning guide on using busio register for CP?
I am trying to verify an issue of always getting back 255 from register reads on arduino and I want to test on CP, but I haven't built the CP library yet
this is for a breakout board I am working on
@last flame the git stuff is still a foreign language to me, but don't I want to work on main?
@crimson ferry ya, you want to start with main
but if you are making changes, create a branch off of main to keep your changes separate. Don't commit to main.
I did make a branch of my clone of my fork
we renamed master to main
oh magic
or more correctly, we made a new branch main and abandoned working on master
main is now the default branch
I've spent a lot of time poking at this area for the work I'm doing so I can try to help
oh cool, you can dm me so we don't clog this up 🙂
please don't
this is a better place to discuss technical things
because then others can lurk and learn
@blissful pollen C code: Serial.print("The device ID is: "); Serial.println(ODT_AT42QT1070().readRegister8(0x00)); // shoule be 0x2E delay(1000); returns 255 rather than 46
Hrm. I don't use REPL regularly but it sounds like a bug. Why are you using the REPL for this?
well i need to verify in CP
so I need to write a quick CP program to fetch the register value
but I think i found it
I don't see any new changes. Did you forget to push them?
Looks good to me! Thank you!
@tannewt should we merge this into 6.0.x?
No, because the Fomu port itself is unstable.
I suspect this is a lower level pin reset problem because I believe the release_displays code itself is port-agnostic.
I don't think we'll have a chance to look at this any time soon. The relevant code is here if you'd like to take a look: https://github.com/adafruit/circuitpython/blob/main/ports/nrf/common-hal/rotaryio/IncrementalEncoder.c
It's not clear to me that this is a CircuitPython core issue.
Please work this through with SparkFun support first. Their support forum is here: https://forum.sparkfun.com/
mostly for prototyping and doing quick tests.
Also, I'm building a "computer for my kids" using CircuitPython for the API, and I want them to try things using REPL. Things like:
>>> set_pixel([0,1], RED)
>>> play_music("CDEFGAB")
>>> move_sprite(sprite, (x,y))
...and that will give them immediate feedback of what's happening.
Okay, so it works on the circuitpython side by I'm not understanding why the arduino side isn't... hmmm
Thanks @microDev1 👍
Any idea what the:
ValueError: IO44 in use
error is?
@UnexpectedMaker
This was fixed in #3817. Any non DEBUG=1 build after commit d6ee17c will not have that error when using default uart pins.
@UnexpectedMaker
This was fixed in #3817. Any non DEBUG=1 build after commit d6ee17c will not have that error when using default uart pins.
But is that specific to UART pins? I see this error with other pins as well. This was reported with my LDO2 pin when trying too turn on my second LDO in my shipping code.py. I just re-flashed 300 boards removing that line to stop the error/fail.
`...
When creating SPI on the default pins on the latest 6.1.0 beta 2 I receive a value error ValueError: IO36 in use. This happens both when I create the SPI myself spi = busio.SPI(board.IO36, MOSI=board.MOSI, MISO=board.MISO) I get the same error as well. But when I create this bus by hand in the 6.0.0 release it works fine.
Sample 1:
import board
spi = board.SPI()
Sample 2:
import board, busio
spi = busio.SPI(board.IO36, MOSI=board.MOSI, MISO=board.MISO...
Please try the absolute newest build off of S3. We've had some pin reset fixes recently.
Just to be sure the f9d9c03 build?
@slender iron the 6.0.1 circuitpython-org action failed. I'm looking at it but you changed it in main (maybe to fix a problem). Does this error ring a bell?
Run python3 build_board_info.py
python3 build_board_info.py
shell: /bin/bash -e {0}
env:
pythonLocation: /opt/hostedtoolcache/Python/3.8.6/x64
RELEASE_TAG: 6.0.1
ADABOT_GITHUB_ACCESS_TOKEN: ***
Logged in as adafruit-blinka
Traceback (most recent call last):
File "build_board_info.py", line 310, in <module>
generate_download_info()
File "build_board_info.py", line 257, in generate_download_info
previous_languages.update(version["files"].keys())
KeyError: 'files'
Error: Process completed with exit code 1.
https://github.com/adafruit/circuitpython/runs/1618736022?check_suite_focus=true
@tulip sleet ah, ya. I removed the files part from the json
since it was too big to download
so it's having trouble with the existing json that's there. I can maybe patch up the existing one and add the download counts
not sure it's worth writing some code for upward compatibility
you can run the script locally and do it manually
yes, I can run the main version on the 6.0.x branch
got it, tnx
np, it's an edge case
Had to update version manually, due to change in build_board_info.py and structure of _data/files.json. Tried running new version in old tree, but ran into credential problems.
Also updated download counts, using December 2020 data.
@slender iron could you review ^^? It's set so I can't self-review. Thanks!
looks
@tulip sleet I'll let you merge
Using CircuitPython 6.0.0 on a Circuit Playground Express, after running the irremote-simpletest.py (below), auto-reload doesn't work (i.e. writing to CIRCUITPY doesn't force reload). Normal execution of a simple print loop with time.sleep() also doesn't seem to work properly. It hangs until keyboard input(?). The only recovery seems to be to re-install the bootloader AND CircuitPython (reset, and re-installing CircuitPython alone doesn't seem to fix the problem)
# Circuit Playgroun...
Using the following test code and a SGP40 attached to the CLUEs Stemma QT port,
import board
import busio
import adafruit_bus_device.i2c_device as i2c_device
i2c = busio.I2C(board.SCL, board.SDA)
i2c_device = i2c_device.I2CDevice(i2c, 0x59)
print("i2c_device 'found'")
with 6.0.1 I get:

with 6.1.0 Beta 2 I get:
 • I see a lot of "make ... flash" but that makes no sense to me, the binary should be independent of USB port??
Also, how did you get around the python2 vs python3 thing on macOS? I went down a deep rabbit hole today on pyenv vs venv vs virtualenv vs etc etc, and came out not wanting to do any of that.
Are you going to build all the ports or just esp32s2
You don't need to worry too much about virtualenv because when you build you'll be in a virtulenv supplied by the IDF.
However my $.02. Use pyenv on Mac. SOO much easier IMHO than other methods. 😉
I did nothing in relation to the case-sensitivity of my volume.
Make is just a command that runs scripts which build the binaries, along with the MAKE command you can pass additional parameters like BOARD=name_of_board and you can also pass clean which cleans up crud from a previous build or flash wich will flash your device so you don't have to think about what the 20 parameter esptool command is
But you can just run MAKE BOARD= and do the flash step manually
I thought that might be the case, flashing to me is an entirely separate thing. Still not sure if I can get a UF2 out of this process, or a .bin
when I look at a recent build output, I only see a .bin file
cool, I won't worry about UF2 yet
I've not played around with the UF2 because the build flashes my device for me... so why bother. 😉
But it is the way most other people will install so its good to get to that method at somepoint.
makes sense. So pyenv was how you got install.sh to play with python3?
make BOARD=... outputs a .bin which is automatically converted to .uf2
run python --version in your terminal
Knowledge! I didn't know that!
2.7.16
yes.
".bin which is automatically converted to .uf2" not sure what that means... they operate differently, no?
I had to think about. I use Pyenv to control which Python environment is active. The System one is the default.
* system (set by /Users/askpatrickw/.pyenv/version)
see the makefile... there uf2conv.py (converts to uf2) is run after esptool.py (generates .bin)
ok, thanks, I'll check it out
have you done this step to make python3 default?
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/get-started/macos-setup.html#installing-and-setting-up-python-3-as-default
I infer those sections at the end correspond to make params
Big Sur doesn't allow even sudo to mess with /usr/bin
but looks like that is local, so I'll dig into that more
The setup stuff is annoying and then you don't need to do it again. You'll get it.
Thanks for all the help @idle wharf @analog bridge I'm still at the stage where every little thing requires a bunch of searching and reading, so sanity checks and even small tips are immensely useful
I can create /usr/local/bin/python -> /usr/bin/python3 but I can't create a symlink for /usr/bin/python, even sudo, and install.sh still fails. /usr/local/bin:/usr/bin: is the order in $PATH. Any ideas?
🤷♂️
ok, thanks, i've got a few other avenues to try
I'm curious let us know what you try and what works I've been putting off upgrading because I heard someone had trouble with the IDF on Big Sur. I can remember who it was..
🔍 Searching for "Big Sur" reveals BruceS and Jerryn have it working...
question regarding esp32s2... which adc channel has interference problem when WiFi is on?
interference? no idea... but:
Since the ADC2 is shared with the WIFI module, which has higher priority, reading operation of adc2_get_raw() will fail between esp_wifi_start() and esp_wifi_stop(). Use the return code to see whether the reading is successful.
For a given channel, adc2_config_channel_atten() must be called before the first time this function (i.e. adc2_get_raw) is called. If Wi-Fi is started via esp_wifi_start(), this function will always fail with ESP_ERR_TIMEOUT.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/adc.html
not sure how that fits into the CPY code 😬 would have to go source-diving
Thanks! @last flame
@crimson ferry FYI -- in my experience, you only need a case sensitive file system on your Mac if you need to build the xtensa toolchain. I am able to build CP for the esp32s2 on a a standard file system following the guide for installing the esp-idf.
Running this BLE HID demo on an Adafruit CLUE doesn't work because of a problem with DeviceInfoService. The offending line is:
device_info = DeviceInfoService(software_revision=adafruit_ble.__version__,
manufacturer="Adafruit Industries")
and the stack trace (from running that line in the REPL):
Traceback (most recent call last):
File "", line 2, in
...
This bug has been fixed in CircuitPython 6.0.1, which was released yesterday. The fix will also be in the next 6.1.0 beta release. First reported as #3746, and fixed in #3861 and #3874.
so, I have run into a problem on macOS with circup that is a problem with shutil.rmtree that I actually encountered earlier when doing my own idea of circup. The problem is that rmtree gives a FileNotFoundError when deleting a file that has a matching ._ hidden file. Or more exactly it seems to properly delete the file, but then errors on the hidden file. I originally thought of posting an issue on circup, with possible solution of adding ignore_errors = True (which might still be a valid workaround), but maybe it's a problem with Circuitpython/tinyUSB ? (or yeah with macOS, but...)
>>> import shutil
>>> shutil.rmtree("/Volumes/CIRCUITPY/lib/adafruit_display_text/")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/shutil.py", line 715, in rmtree
_rmtree_safe_fd(fd, path, onerror)
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/shutil.py", line 672, in _rmtree_safe_fd
onerror(os.unlink, fullname, sys.exc_info())
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/shutil.py", line 670, in _rmtree_safe_fd
os.unlink(entry.name, dir_fd=topfd)
FileNotFoundError: [Errno 2] No such file or directory: '.___init__.mpy'
>>>
(the __init__.py file has been deleted)
Hi @UnexpectedMaker, the ValueError you are getting seems to be coming from your python code.
The reason you are getting it now is because the way pins are claimed was changed in 6.1beta2 as it was flawed before.
thanks, @solar whale
just a reminder... issue #3886 needs to be closed manually... the link to link issue and pr isn't appearing for me.
I don't think esp-idf requires that python be python3, I have it as 2.7 on all my machines and circuitpython builds for esp32-s2. I would investigate other theories before continuing with the python-is-python3 theory @crimson ferry
@jaunty juniper Looks like various people have encountered similar problems in other contexts. https://bugs.python.org/issue29699 https://bugzilla.redhat.com/show_bug.cgi?id=1362667 etc -- I think that macos is manipulating the ._ file for you, and it results in this problem readily. A fix has been offered to Python but not incorporated yet .. https://github.com/python/cpython/pull/14064
https://docs.python.org/3.8/library/shutil.html#shutil.rmtree you might be able to specify ignore_errors=True ?
@onyx hinge thanks. the error I'm getting is basically due to requirement bidict>=0.21.0, and bidict docs say "Drop support for Python 2" as of bidict 0.19.0. Espressif instructions also step through making python3 the default python (though I couldn't get this to work on Big Sur) ...working on pyenv now
IDF version 4.2 does not have the python3 instructions, but it's in the latest, but the error occurs invoking install.sh from the current circuitpython main
oh yeah it's possible some upstream lib has ruined things since the last time I installed esp-idf
is there a way to copy circuitpython Actions to a forked repo? i realize local would be faster dev cycles, but I have diminishing confidence that anything I build locally would match what GitHub builds
yes... they can be enabled from the actions tab
I have done that for my repo, it works.
I thought I did that, but my Actions are empty
I'll start over and re-fork
this results in no workflows in the Actions tab
or is that supposed t be empty until I commit or merge something
ok, nevermind, it needed a push
can I make DEBUG=1 this way though?
I have it installed, trying to decide whether to install new python into its directory, or symlink to existing
you use pyenv to install and set which python version is active
I would not try to make it work some other way... seems like more potential for issues
ok, no symlink then, thanks
You could setup the GitHub actions, keep in mind, it will try to build the world and there are Adafruit specific config and secrets so you'll need to modify the github actions to be your own.
ok, so that's likely a dead end (along with the DEBUG issue to see logging on the debug console)
That would be one of the changes you'd need to make 😉
do we have a preferred version of python3 for the build?
So funny thing... you're just fixing this so the install.sh will work. When you start the IDF environment.... it has its own Python version in its own virtualenv
ok, so I don't need to worry about that, proibably any python3 will work
I use 3.8 for system
@crimson ferry I think I used brew for python3
Did you use ln to set /usr/bin/python to python3 ?
He can't make that change on Big Sur
looks
pyenv python3 build failed, and myriad different "here's how I fixed it..." search results o_O
I could just buy a Linux box
yeah, but Big Sur changed some things
ya, I'm trying it now
I've building another port but not esp
I'm trying to get esp going now
(and I'm on big sur)
what do you get from python --version on a new terminal ?
2.7.16
same
Kewl... I was worried maybe you had tweaked your OS and then upgraded. You're both starting from the same state it seems
I have been able to build other ports. I just haven't tried esp on my mac recently
I do have the repo on a case sensitive partition
@jerryneedell Do you know if the REPL will overwrite the display while it's in use?
what do folks think about doing a 6.1.0-rc.0?
I think it'd be good to do a stable release before we change the socket stuff to support tcp server
@onyx hinge do you have any thoughts or plans on a library in the community bundle perhaps that includes your icons.py mapping for fork awesome? Maybe a few other helpers as well like a function to return a single character label or button ready to add to the screen could be nice as well.
@slender iron I am having some trouble because of idf@v4.2.... the latest one is with touch-alarm... I am getting an error deep inside the idf
https://github.com/microDev1/circuitpython/runs/1620571067?check_suite_focus=true#step:12:850
That seems like the BIT macro may be wrong
I'd rather not rush things. we can do 6.2.0 betas
making 6.1.0 stable will mean we can recommend the same version for everyone
I am in favor of 6.1.0-rc.0 would be great to MagTag onto the same stable release as everything.
looks at the 6.1.0 issues
idf@v4.2 is blocking lots of stuff reset-to-bootloader, touch-alarm and ulp-alarm plus some upgrades for dualbank module...
This no longer blocks 6.1.0 because we've disabled native bus device for now.
@analog bridge I don't want us on some random idf version
we can patch our branch if needed or simply not use the idf for things
@idle wharf do you think #3735 should block 6.1.0?
@lone axle It's worth considering!
@onyx hinge how do you feel about us getting 6.1.0 stabilized?
@slender iron I'm in favor of it 🙂 I just may not have been doing my fair share of the actual work.
you could do the release 😛
sure, I can do the steps
@falkenad Please try 6.0.1. We believe this is fixed.
Closing because we never heard of a better number.
I guess these will have to wait then... I'll update the status on github.
No, its an ESP32S2 only issue
we could have an idf 4.3 tracking issue @analog bridge
@slender iron OK, should I pick that up next time I'm ready to switch tasks then?
@idle wharf I'd like 6.1.0 be stable for esp
@onyx hinge when do you think that will be? I can find time to do it today or tomorrow
OK... let me test is again
it looks a bit weird calling connect multiple times
@dhalbert Do you think this was fixed in 6.0.1 as well?
When should one setup Wifi.. inside or outside your While Loop? (Assuming no use of deepsleep)
Then let's close it or convert to a learn guide\doc bug.
what happens if you do it that way? does it crash?
@slender iron looks like I will probably spend the rest of my hours today wrapping up other stuff, so I could pick it up first thing tomorrow.
@onyx hinge ok, that'd be great!
will do
thank you!
a nice way to wrap up the year!
(I will be around but not "working" thursday through sunday)
ya, that's fine. that's why we can do it as an rc
@idle wharf esp32s2 probably could use a check in connect for already connected, otherwise it does seem odd to call it again
@lone axle do you think that python module with the icon "names" is useful, then? I wasn't sure
@slender iron wait, will I make 6.1.0 or 6.1.0-rc.0?
rc.0
Connect inside the loop, it doesn't crash the ping just doesn't work on the second time. It returns None.
Connect outside the loop it works. I agree with @crimson ferry though, connect should be more resilient.
@onyx hinge I do think so for sure. I am used to using them in HTML/CSS by applying classes with their names. I'd love an analogous way in circuitpython that allows us to use them by name easily.
@crimson ferry circuitpython built fine for me
@slender iron are you using virtualenv, pyenv or the like?
Connect inside the While. None on the second ping
Adafruit CircuitPython 6.1.0-beta.2-151-g737828ccb-dirty on 2020-12-21; FeatherS2 PreRelease with ESP32S2
>>> import wifi
>>> from time import sleep
>>> import config
>>> import ipaddress
>>> while True:
... wifi.radio.connect(config.SSID, config.WIFI_PASSWORD)
... print(f"Pring: {wifi.radio.ping(ipaddress.ip_address('8.8.8.8'))}")
... sleep(60)
...
Pring: 0.012
Pring: None
Connect outside the While works...
install.sh is what fails for me, on a library dependency that seems tied to using python2 instead of python3
I'll start from scratch, slightly better informed this time, and see what happens
hrm
I may have installed it myself
let me see what my python3 is
ya, I have python3 from brew
do you have it installed?
k, I have 3.7.8 in /usr/local/bin
I also have 3.8.2 in /usr/bin but am not using it
I have /usr/local/bin/python -> /usr/bin/python3 but it apparently doesn't get used despite $PATH order: /usr/local/bin:/usr/bin:
my python itself is 2.7.16
Does the Qt Py build support bytes and bytearrays?
@slender iron thanks for digging in, I'll start again as clean as I can and see what happens
I'm getting an error for unsupported datatypes
looks like the install script from the idf did use 2.7
>>> import time
>>> import busio
>>> import board
>>> import odt_at42qt1070
>>> i2c = busio.I2C(board.SCL, board.SDA)
>>> qtouch = odt_at42qt1070.AT42QT1070(i2c)
>>> qtouch.touched()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/lib/odt_at42qt1070.py", line 163, in touched
TypeError: unsupported types for : 'bytearray', 'int'```
@ornate breach does it work on M4?import builtins dir(builtins)
guess not on qt py, let me test on m4
@ornate breach what is on line 163?
that looks like the error you get when trying to add two different types
return self._buffer & 0xF
and _buffer is a bytearray
you can't bitwise the bytearray
you need to [] an element of it
bummer, thanks
the error with touch-alarm isn't coming up with current main even though the include paths are the same
@analog bridge you may need to include something before you include it
if its includes are wrong
oh I was attempting to mask the buffer but returning the individual bit is probably far more precise in the long run.
I wasn't sure if I wanted to leave it open to return the whole detect register or not.
qtpy: bytearrays yes, not sure about bytes
it's all good, it works now 🙂
it should have both
just had to return the individual bit element
are the official cirpy 6.0.1 downloads being built w/ the newer gcc-10-2020-q4?
@slender iron bidict is apparently a dependency for something in requirements.txt (I can post the relevant parts of the output if of interest) ...always fails in the same place
@tulip sleet would know
what version of the idf are you on?
no, the 6.0.1 github action is still running with the gcc 9 compiler
the version in main
did you do esp-idf/install.sh?
yes, ebe7784. @tulip sleet yes, that's what's failing. I'll post the relevant bits of the output
thx ... would you expect any issues w/ gcc-10? i had the newer installed for building 6.1.x and threw it at 6.0.1, no errors so far, but not sure what to expect.
nope. I'm using gcc 10 locally without issue
👍
I'm on python-socketio==4.5.1
you could activate the idf virtual environment and install that version directly
I just did some CircuitPython stuff on weblate, and I was wondering if there's a way that I can test the strings? Such as test scripts or routines, and how to get the various languages?
@fossil gorge I recently merged in the pending changes from weblate, 3 hours ago. If that would have included your contributions, you can grab the zip for the board you want to test at https://github.com/adafruit/circuitpython/actions/runs/451062198 and load it as you usually load circuitpython. If you did it since that time, weblate hasn't created a new pull request yet (it delays up to 2 hours)
@fossil gorge .. thank you for working on translating CircuitPython!
I did it in the last 1-1.5 hours, so on par with my general timing!
I'll try it out for now, and keep an eye on the next release
okay. If you go on github and look for the PRs from weblate you can use that to test. of course, if you want you can learn to build circuitpython on your own computer but that is more trouble than it's worth for a lot of folks
Thanks @onyx hinge . I'm good (for now) impatiently waiting for the next build, and figure ways to ensure the right string appears in the right location.
The ones I'm mostly concerned or uncertain about, are the ones that appear to be mid-sentence, or sentence fragments - no starting capital letter and no period.
But also, the consistency of the terms across the codebase and their use
My mom was/is a translator, so I have... opinions on translations! lol
I agree 100% -- there are a number of "best practices" for making software translatable that CircuitPython doesn't do, or doesn't do consistently. Sometimes it's due to technical limitations, and sometimes due to general unawareness. I think there's a big opportunity for someone with the right skillset to look through the core and figure out how we can improve that
Hardcode all the strings!!!
No problem with one branch per language with all the same code, right?
</smart-alec>
To build the SAMD builds now I need the new GCC10 correct? I'm pretty sure I saw that pass by in the last couple weeks
my background is some college-level french, plus at a previous job I converted a HUGE existing codebase to use gettext-style translation. the result was very unsatisfactory. The translation system we have is I think mostly coded by @slender iron but the existing messages and message structure date from before translation was a thing.
To be serious, I don't really have any experience with best practices, setup or anything similar, but I'm always happy to help out with what I do know, and learn + share the rest
so I have some idea of what best practices are supposed to be, but not as much real world experience as I'd like
I've worked mostly in the MS product space, so my experience mostly revolves around resource files
Thanks! Hearing from actual multilingual people is also helpful, when so many people at the center of development are only fluent in American
coughs
hehe
I'm not sure I'm fluent in american and I AM america hehe
So the incorrect AND correct spellings (in that order) of words 😉
I know enough spanish and french to get food and get myself arrested
haha! I can order food in german and I can get myself in pretty good trouble in french still.
I still have my textbook from my college french days
it was a downhill battle, B, C, and a D my final semester 🙂
@fossil gorge ^ there is the pull request right on schedule. In an hour or so I think this page should have links to download: https://github.com/adafruit/circuitpython/pull/3893/checks
Saw that. I think GithubBot is spying on the convo!
um, it was advanced french by the third semester
so mostly just actually putting it together. The instructor played a big part in this. She was of course a middle aged french lady who had fun making fun of english speakers
Ugh, hate those types of teachers
Rather than elevate others, they make themselves feel better by putting them down
I did okay right up until classes switched from grammar & pronounciation to "reading serious literature". I can't read serious literature in English.
Students absolutely THRIVE in those environments
I can read okay in french but speaking, I can barely do that in english
Same here, with the "Serious literature". I need to be interested, regardless of the language. And "a good grade" != "interest"
We are building with gcc10 (it might work with gcc9 but you should use 10 because it's stricter and will catch some things 9 wont'). Versions discussed here: https://learn.adafruit.com/building-circuitpython/linux#install-build-tools-on-ubuntu-2986713-2
I took a number of years of spanish growing up and did pretty well. not enough to contribute to society but yeah
I did about 3.5 years of Spanish in high school, and now live in Texas. Pretty sure I can get away with enough to take a severe beating in the wrong crowds!
Thanks Dan, figured may as well get it all set up
Specially combined with the Spanish I picked up from the movie "Encino Man"
@idle wharf is there some reconciliation process that you did after installing the default Espressif IDF, but then circuitpython requiring what I think is an Adafruit-patched version of the IDF from some branch of Espressif's tree?
You pick which one you're using when you run the export.
alias get_idf
get_idf='. $HOME/esp/esp-idf/export.sh'
or if you run export from the ..ports/esp32s2/esp-idf folder
@idle wharf ok, thanks, that's what I did
I ran export.sh from both and then did where python and they both seem to use the same virtualenv (in ~/.espressif/python_env/idf4.3_py3.8_env/bin/python) though.... so you could think your using one and because the virtualenv was created by the other end up with a mish-mash.
messy dependency mgmt for sure
I was unable to exactly reproduce this using CP 6.0.0 or 6.1.0-beta.2. I do see that while the irremote script is running auto-reload does not seem to work, but I had no issues with time.sleep or needing to reload the bootloader afterwards.
@idle wharf yeah, once this works, I may need to do another OS clean install to make sure it can be replicated... I should get back into VMs
The error I'm getting in install.sh is in Step 3 of Espressif's process. I didn't do step 2, but instead just used the IDF already within the circuitpython repo. Is this a bad assumption?
https://github.com/adafruit/circuitpython/blob/main/ports/esp32s2/README.md is high-level, but seems to support that sequence
I believe you should install.sh from the idf in the CP repo.
That will eliminate the virtualenv not being from the right instance of the idf.
(I prolly need to do that... )
I was planning to rebuild when the new GCC comes down
i always use install.sh (once) and export.sh (in each new shell), and that works out well
gcc10 is not used for the esp32s2 builds - we use the toolchain that esp-idf installs
Hmmm. So, I just duplicated the issue I'm seeing with CP 6.1.0-beta.2.
The exact procedure is:
- Run
irremote_simpletest.pyby copying tomain.pyon the CPX - Make and save any change to
main.pyand note that auto-reload doesn't work - Use
CTRL-Cin serial console to stop the program. - Replace
main.pywith:
import time
while True:
print ("Hello")
time.sleep(.5)
- Notice that auto-reload still doesn't work.
- Use
CTRL-Dfrom the serial console ...
@dhalbert looks the same with the uf2 you linked to:


hmm I didn't read the whole thread but this reminds me of our problems trying to reset wifi https://github.com/espressif/esp-idf/issues/5122
Just wanted to point out that I was seeing this exact error when using the adafruit_jwt library and having a wrongly formatted value set for private_key (string instead of set). That library should probably be doing type checking on the value but the point is, this error may be a bad configuration elsewhere as opposed to the value of CIRCUITPY_PYSTACK_SIZE being to low.
6.1.0-beta.2-171-g8b03951fe on 2020-12-29 🇸 2️⃣ 🎉 I (106604) wifi:connected...
congratulations @crimson ferry
started over... brew installed python 3.9, but it works, I'll take it
does https://learn.adafruit.com/building-circuitpython/linux need updating for gcc version for 6.x?
there's a mention already there: "For CircuitPython 6.1 and later, we are now using 10-2020-q4-major."
oh, I didn't see it, I'm blind, sorry
Better to suggest it and have it there already than to have missed it in the first place.
there are a couple examples (setting path etc, towards the bottom of that page) that still show the eabi-9-2019 version.
the version links probably ought to be listed explicitly on the Manual Setup page for clarity
the version links probably ought to be listed explicitly on the Manual Setup page for clarity
I have clarified the version information on both the Linux page and the manual setup page.
brilliant, tysm
WIFI_REASON_ASSOC_LEAVE = 8 seems to be the magic reason for either calling esp_wifi_stop() while connected but without disconnecting first, or by calling esp_wifi_disconnect() while connected.
There may external causes for WIFI_REASON_ASSOC_LEAVE to arise, but since it does arise after explicit disconnect or stop, we shouldn't automatically reconnect in the handler for this reason.
I've got a Feather S2 and this sparkfun board: https://www.sparkfun.com/products/16294 . The sparkfun board is at address 0x60 vs the 0x67 that adafruit has for their MCP9600 CircuitPython library.
So I wrote this code:
import time
import board
import busio
import adafruit_mcp9600
# frequency must be set for the MCP9600 to function.
# If you experience I/O errors, try changing the frequency.
i2c = busio.I2C(board.SCL, board.SDA, frequency=100000)
mcp = adafruit_mcp9600...
It is possible that the quarter counter can get out of sync with the quadrature pins. By checking the new_state, instead of just the quarter counter, it stays in sync with the rotary encoding.
During testing I was able to recreate the bug and saw that the quarter count would sometimes count (from a settled click position to next encoder position) 2, 3, 4, 1 and back to 2. In this mode it does a position increment mid way through the quadrature cycle and it works fine if it is always i...
Thank you for working on this. Happy to review and test when you're done.
Is there a separate channel for #adabox016? I couldn't find one. I am a Discord noob too so not sure if I am searching correctly. Anyway I have a question about the Matrix Portal. When the 64x32 RGB Matrix is connected to the Matrix Portal if I connect it to my laptop USB, I don't get a very stable connection and my laptop starts behaving weird. Is this a power draw issue? Should I disconnect the Portal from the RGB Matrix when programming it?
@maiden cairn we don't have separate adabox channels. yes, that sounds like a power issue. The matrix should have a power source of its own when you are programming it over usb
Thanks @slender iron . I just got around to trying out some of the other adabox016 examples and wanted to test the halloween countdown, but change the code to countdown to New Years Eve.
good idea!
I guess I will disconnect the RGB Matrix first. Not sure how I can power the matrix and also keep it connected via USB. There is only one USB C port on the Matrix Portal.
@maiden cairn do you have a powered usb hub? You could try using that between your computer and the matrix
@slender iron Aha! Yes! Thanks. Completely forgot that I could use something like that.
BTW, a bit unrelated question, but since the Matrix Portal has ESP32 and is connected by WiFi to my local network, is there an example code to connect to the REPL over-the-air?
nope, we only support usb now
Hmm, that's not what I expected. Could you also try the absolute latest from here: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/clue_nrf52840_express/en_US/
esp32-s2: do we need start_station() in start_scanning_networks? scanning should be independent of wifi mode (e.g., scanning can be done unconnected or connected)?
Does anyone recognize this error?: TypeError: unsupported types for ge: 'AnalogIn', 'int'
The program runs once, and the error stops it the second time through
while True:
psi = mpr.pressure * 0.0145037738
print("psi:", psi)
print(a0.value)
print()
time.sleep(1)
if a0 >= 65000:
relay.value = True
elif a0 < 65000:
relay.value = False
it stops at the if statement
Then it would default to AP_STA mode. https://github.com/espressif/esp-idf/blob/b0150615dff529662772a60dcb57d5b559f480e2/examples/wifi/scan/main/scan.c#L125 it is done like that also in the espressif examples. I think you asked this already, can you tell me the suspected issue you see? It may help me to better understand which issue you try to solve 🙂 Thank you
I haven’t worked on the PR to fix the Wi-Fi mode vs Wi-Fi interface yet, if you want to address this yourself - the issue you found :). I‘m on vacation and would usually be all over this type of stuff, but right now I spend time with family 🙂
all done except that one test failed, humph !?
all done except that one test failed, humph !?
That was a network problem at GitHub; we can ignore that.
question with the cp community bundle
the driver i'm adding has a release for it, but the CI check is saying it's failing because it doesn't appear to have a release yet
says it failed to generate a version file
fatal: run_command returned non-zero status for drivers/at42qt107
9.
10
11 Generating VERSIONS
12Failed to generate versions file. Its likely a library hasn't been released yet.
13WARNING: some failures above```
how would I fix this?
@ornate breach the commit for at42qt107 that you pushed is 49261b9, which is way back on the commit list for that repo. Your release is de255a8. So you need to descend into the submodule repo, check out main to the latest, and then go back up to the bundle repo and commit that change.
ah okay
e.g.
cd at42qt107
git checkout main
cd ..
git commit -a -m "..."
you can verify you're at a tagged commit by doing git log
wait, I think i got it
I fetched and rebased in the submodule so hopefully that should work with a release I just created
yes it worked for that part
thanks @tulip sleet
🙂
@ornate breach a rebase was probably no necessary, just checkout the main branch, because the most recent commit was the release. If that were not true, you can always check out a particular commit: git checkout abc12345
a submodule is a snapshot of a particular repo, at a particular commit
It passed the CI for the community bundle after fetching main so I think it’s okay for now
I appreciate the help in getting it sorted 🙂
Still new to these sub module shenanigans, but I’m slowly getting it down
i have found this book helpful: I read it a number of years ago: https://git-scm.com/book/en/v2
We have been having trouble with I2C on the ESP32-S2. Could you try the "Absolute Newest" build for the Feather S2 from https://circuitpython.org/board/unexpectedmaker_feathers2/ . Third box down on the right side.
I'm just trying to understand the design, and figure out what code is anticipatory of additional modes, and hopefully keep clean concepts of netif [de]init, wifi [de]init, wifi mode (we'll eventually want AP and AP+STA, I hope), wifi start/stop, wifi [dis]connect. Sounds like your PR does some of this.
Sure, I'll PR the start_station issue I found, good small test of the process. 🙂
I have some code that is hard-faulting my board and not entering safe mode. Reflashing CP hasn't worked since it re-runs the offending code immediately. Is there a way to reset a board into the REPL from power up?
@tulip sleet should I create the 6.1.x branch FIRST and then tag the -rc.0 SECOND ?
@prime cove yes but it depends on the device you have. Can we take this over to #help-with-circuitpython ?
So sometime after the New Years I (like a few people here) will be getting one of the ESP32-C3 boards
I’m hoping to contribute to support for that chip for CP since native USB is on it. It’s kind of exciting
I have no idea how much I’ll be able to do, but I’m excited for that
hopefully very similar code will work on both since they're both able to use the esp-idf.
(as I understand it anyway)
Hopefully so
@jepler
SAMD51 based board with build CircuitPython 6.0.0-278-g66fb09506
Uncomment super().write(b'hello') to cause the error.
import board
import busio
import digitalio
import time
import random
class RS485(busio.UART):
def __init__(self, tx: microcontroller.Pin, rx: microcontroller.Pin, de_pin, *, baudrate: int = 9600, bits: int = 8, parity: Optional[Parity] = None, stop: int = 1, timeout: float = 1, receiver_buffer_size: int = 64 , re_pin=None, auto_de_...
I'm closing the issue based on the above comments. Please feel free to re-open or file a fresh bug report if necessary.
If you have items you think should be noted in the Known Issues section of 6.1.0-rc.0 please let me know. I'm drafting the release notes.
Known issues
- ESP32-S2: Crash when repeatedly creating and destroying busio.I2C object on ESP32-S2 (#3846)
- Built-in adafruit_bus_device has been disabled due to issues (#3859, #3856), please install the version from the Bundle
- See https://github.com/adafruit/circuitpython/issues for other issues.
Narrowing focus of this issue.
@onyx hinge are you planning to update the frozen libraries before releasing 6.1.0
I'm not sure I know how to do that.
i can do that -- I have a script
It would make a PR?
@tulip sleet has also reminded me that there are two 6.0.x-tagged bugs https://github.com/adafruit/circuitpython/milestones/6.0.x that we should look at
i make the PR by hand, but I have a script to do the submodule update
Will bus_device be fixed before the release?
no, use the python-coded bus device.
hmmm -- should boards that used to "freeze" bus-device be updated now to put it back in?
I think that might have happened when the PR was reverted, but I will double-check
I did not revert the PR, I just disabled it in one of the .mk files
ah -- ok -- thinking of m0_rfm69 and rfm9x
so, no, if there are boards that froze it before and don't now, that would be a regression
My goal is to start working on it today and try to get it working asap but it won't be today 😐
OK, I will open a 6.1.0 issue for that.
The DAC(s) support DMA, but it's not in the ESP-IDF API yet: https://github.com/espressif/esp-idf/issues/6333. So we would wait for that.
Thanks for raising these issues y'all
Native adafruit_bus_device was turned off for now (#3869) due to regressions, but the boards on which it was frozen (and then removed) need to have it be frozen again.
Can someone point me at a board where this was changed? I am not finding it with git grep like I expect
(this = removing a frozen-in adafruit_bus_device)
feather_m0_rfm9x should be one
OK, found it -- thanks
commit 23ed3ef971f8f38497337874da39273e5ae090d7 Removing frozen libs
This reverts commit 23ed3ef971f8f38497337874da39273e5ae090d7 and closes #3899.
@onyx hinge Thanks!
you're welcome
Oh a finer point might be to refactor this to be ever so more efficient:
- switch the order of the conditional
(new_state == 2 && self->quarter > 0)because thequarterwill be non-zero more often than the state is 2 - I guess to go even further it could be refactored with an outer if clause and an inner case, perhaps like this:
if (new_state == 2 && self->quarter != 0) {
if (self->quarter > 0) { // increment
...
} else if { // decrement
...
}
...
Take a look also at https://github.com/adafruit/circuitpython/blob/48de52c8ab62fae93e1382cb774802828cf92edd/ports/atmel-samd/common-hal/rotaryio/IncrementalEncoder.c, which implements the same thing (the nrf version is a rewrite; I wrote the atmel-samd version and it was reworked for nrf). I tested the atmel-samd version and it may suffer from the same issue. I have a rotary encoder volume control that uses the atmel-samd version .Also see whether you think one version is clearer than...
nice, I am looking and learning vocab (like detent) and will keep looking at them both to compare, fun.
On a SAMD51 CircuitPython build 6.0.0-278-g66fb09506
busio.UART will not initialize if receiver_buffer_size is not a multiple of 4. This is probably a hardware limitation, but I did not find it referenced in the documentation.
import board
import busio
buffer_len = 3 # will fail unless this is a multiple of 4
port1 = busio.UART(board.TX1, board.RX1, baudrate=115200, receiver_buffer_size=buffer_len)
Thanks! Approving in advance of check completion.
@dhalbert Do you think this was fixed in 6.0.1 as well?
I don't know of a specific fix, but @kevinjwalters, could you try it with 6.0.1? Thanks.
Raises an error when a busio UART "receiver_buffer_size" is not a multiple of 4. Behavior referenced in issue #3901 and tested using same setup: SAMD51 and CircuitPython 6.0.0
Example:
import board
import busio
buffer_len = 5 # will fail unless this is a multiple of 4
port1 = busio.UART(board.TX1, board.RX1, baudrate=115200, receiver_buffer_size=buffer_len)
Will raise an error with the message: ValueError: Invalid RX buffer size of 5, must be a multiple of 4
It isn't native USB. It's a built in USB to UART and JTAG
we can support it once we have a BLE workflow
and it'll be BLE-only
because it can't do usb mass storage
makes sense, well if I can be of any help testing or contributing to BLE workflow I'd be happy to take a shot at helping move that forward 🙂
adding ble support for it is the first step
Thanks for noticing this. I think we should explore the causation behind the error: whether SAMD actually requires this or we are doing something wrong somewhere.
We suggest creating a branch in your forked repo, instead of changing your own main. That causes your main to get out of sync with the upstream main. See https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github/always-work-on-a-branch.
See non-review comment as well.
This is a long message, and we need to save space. We don't need to print out the input argument, so I'd suggest this (using the argument name in shared-bindings/busio/UART.c):
mp_raise_ValueErorr( translate("receiver_buffer_size must be a multiple of 4"), receiver_buffer_size);
I'm going to mark this as a dupe of #3268. It is a Linux issue which they don't want to fix. We can try to ameliorate it by perhaps inserting some delays before switching from one filesystem to another, but it also occurs when a filesystem disappears, it seems.
Thanks for noticing this. I think we should explore the causation behind the error: whether SAMD actually requires this or we are doing something wrong somewhere.
It looks like it's based on the requirements of the ATMEL hal ringbuffer: https://github.com/adafruit/asf4/blob/84f56af13292d8f32c40acbd949bde698ddd4507/samd51/hal/utils/src/utils_ringbuffer.c#L53
Looks like my assumptions were wrong anyhow, power of 2 instead of multiples of 4.
@slender iron should I go ahead and do the release we talked about but tag it as beta instead of rc? what would you like me to do?
It looks like it's based on the requirements of the ATMEL hal ringbuffer: https://github.com/adafruit/asf4/blob/84f56af13292d8f32c40acbd949bde698ddd4507/samd51/hal/utils/src/utils_ringbuffer.c#L53
Looks like my assumptions were wrong anyhow, power of 2 instead of multiples of 4.
We might consider rounding up to the nearest power of 2, and changing the documentation to note that the buffer size might be bigger. And/or noting that some platforms might have specific requirements.
yeah there was a lot of stuff to cover when I started the release notes
we have a great community working on this thing!
@onyx hinge thanks for doing the release notes, which can be tedious... I will work on updating the frozen libs right now
init.c:
Add logging to the event handler default event to capture any other wi-fi events that occur, to see what else happens in the field that we may want to handle better.
Radio.c:
This call in start_station():
esp_wifi_set_config(WIFI_MODE_STA, &self->sta_config);
has the wrong parameter (should be ESP_IF_WIFI_STA == 0; WIFI_MODE_STA == 1 and sets the config for AP interface type ), and is also not needed here since it's called in connect() anyway (...
@tulip sleet OK I'll wait for that, do a few release note updates, and tag there. Do we want to hold off with branching 6.1.x, or do it at the same time @slender iron ?
@onyx hinge I forgot this! I had added a circuitpython/Makefile target make update-frozen-libraries, which does all the work.
very nice
so i'm using it
I was thinking that some things should happen by a cron actions -- this could be one of them
"make translate" is the other one I think about
it could be an adabot checking thing. Occasinally there have been reasons to delay an update
re 6.1.x: I wouldn't make a branch if we are still doing betas. An rc is feature freeze, then it's appropriate
gotcha
@slender iron @onyx hinge I would like to make a checklist of what's necessary for a release: there are many steps, and some pitfalls (like make sure you are tagging off the right branch). This could be in an internal Learn Guide, but I was wondering if we could put it in a wiki entry in the circuitpython repo. We have not enabled wikis yet. I started to do this and then wondered if it should be Learn Guide instead.
there are other examples of manual processes we should document. A README is not the best place, maybe
I like the idea of a checklist, and I like the idea that it's in a place where people can contribute.
though wiki entries don't have PR's, I think
anyway, something to think about, and we can always change it
Issues can have checklists...
Markdown.
Wait I misread that
You want a general checklist, not a specific one.
Statement stands anyway.
right, this would not be closed, though, so it's not an issue, but a checklist to refer to every time doing a release.
the wiki is markdown too, i'm sure
We had an eternal library issue before. It's not unheard of. But fair enough.
Probably, yes.
yah, an uncloseable issue is better as something else
we could put the checklist in an issue template, and literally create a release issue with the checklist to check off.
That's what I was picturing, I suppose.
github has "projects" too, not sure how that works. Issue template, that sounds good. I forgot they existed (or that there could be multiple tempaltes)
(however, issue templates are attractive nuisances, anyone could semi-accidentally create one. But then you just delete the unwanted text)
(especially if it's the only one)
submodules are a pain but i finally got the community bundle pr right
my preference would be to leave wikis off. we can add something to the docs folder though
time.sleep should leave anything running alone. So, wifi should stay up. Same for light sleep. Only deep sleep shuts things down.
I agree we should make calling connect a second time work.
great now I mpy cross hehe... hey @slender iron can you look over this and see what might be causing mpy-cross to fail on this file. https://github.com/skerr92/at42qt-acorn-python/blob/main/odt_at42qt1070.py
Why are you subclassing UART? Most native classes don't work with subclasses. We have to add code explicitly to the native class now to support it.
doesn't have to be right now, but whenever you have a chance.
👍
if you try importing in the repl you might get the same error unmangled. this is what i get:
>>> import odt_at42qt1070
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/lib/odt_at42qt1070.py", line 167, in set_lowpower
SyntaxError: 'break' outside loop
vs:
$ mpy-cross odt_at42qt1070.py
dexpresed ing back (most recent call File "odt_at42qt1070.py", line 167stionusEUSyntaxError: amcttsed ' outside l
RS485 doesn't need too much more than some logic and timing around toggling a couple GPIO pins. Subclassing UART felt like the cleanest implementation, though I can avoid it if needed. I was unaware of the limitation of subclassing most native classes; if it is allowed, is that usually denoted in the documentation?
Does the interrupt work during light sleep?
Is there a new recommendation for MagTag and ESP32S2 board to use 6.0.1? https://learn.adafruit.com/adafruit-magtag-project-selector/code-the-magtag-project-selector say: "Make sure you have CircuitPython 6.0.1 or a more recent version (anything released after 12/28/20) installed. Previous versions including 6.1.0 betas will not work." ( cc: @trim elm )
6.0.1 doesn't support magtag, so that needs to be rephrased
Yeah, that sentence was disturbing.
Ya, I think so. You could also add it to UART if you like. You can see the technique here in Group: https://github.com/adafruit/circuitpython/blob/main/shared-bindings/displayio/Group.c#L79
Can you send a signal inside?
@thorny jay thanks for letting me know. I’m currently running an errand but I’ll fix it when I’m back
Will definitely give it a shot today. As another data point - I was able to get things to work using Arduino on that board.
It would be nice if CircuitPython threw an error if you tried to subclass a native class that isn't expecting it. Perhaps we could add a flag bit that it is allowed, with the default being that it is not.
Addresses issues like #3897.
Oh man I missed that bit thanks
@tulip sleet Should I close that PR and remake it so it is on a branch? I'll make the other suggested changes as well.
@mild fog that's fine, sure. You can clean up your main branch by using git reset --hard to back out those commits (after using git cherry-pick or manually getting the changes) and then git push -f.
I checked that these are all updates to newer, tagged commits in the submodules.
okay @slender iron thanks to @strange pike I got it fixed and it passes
(wrong adam 👍 )
sorry!
no worries at all just didn't want the other adam to miss the message
@tulip sleet You mentioned rounding to the next power of 2 for the buffer, looking at the data sizes that could potentially add ~32kB of unneeded RAM. Would just raising an error to let the user make the call be better than that?
alarm.wake_alarm seems to be broken for light sleep... can someone confirm? I am on latest main.
import time
import alarm
print('entering light sleep')
alarm.light_sleep_until_alarms(alarm.time.TimeAlarm(monotonic_time=time.monotonic() + 2))
print(alarm.wake_alarm)
@AdamCummick said in discord:
You mentioned rounding to the next power of 2 for the buffer, looking at the data sizes that could potentially add ~32kB of unneeded RAM. Would just raising an error to let the user make the call be better than that?
I was thinking more of buffer sizes in the tens or hundreds. Either is OK. In practice it seems people have always chosen a power of two, without thinking about it, or we would have heard about this before.
@analog bridge Could you open an issue? I know this was a deep sleep issue which i thought was fixed, but not light sleep.
sure... 🙂
I think this is related to missing function call for setting wake_alarm after a light sleep wake.
I might be able get it fixed with touch_alarm... if not I'll open an issue for it.
@thorny jay I just updated the sentence you were concerned about. Thanks for pointing that out to me. I just assumed that 6.0.1 works with the magtag without actually checking so it's definitely good that was able to be fixed relatively early on.
When using the REPL from a different language than "en", the output of a call to help() for a given object is not localized. It threw me off for a moment while testing other localizations I'd contributed.
I checked weblate to make sure that the string wasn't overlooked or left blank in the target language, and it isn't. The text doesn't appear in weblate at all.
I then checked the CircuitPython codebase, and noticed that the static text for the output isn't wrapped in a call to `trans...
While the fix is most likely "as simple as" (famous lasts words) wrapping the strings in calls to translate(), but before making such a change, I wanted to check and get feedback in case there were other steps or checks that would need to be done beforehand.
@tulip sleet found it... I inserted alarm_save_wakeup_alarm() here :-
https://github.com/adafruit/circuitpython/blob/main/ports/esp32s2/common-hal/alarm/__init__.c#L119
Adding localization values for the output of calls to help() can match the current firmware's language.
This change addresses issue #3907
@analog bridge is your PR almost ready, or should we make that a separate PR? We are trying to do beta.3 very soon?
I am almost done.... organizing commits... will push in a few minutes.
@slender iron note x:39pm above
👍
This won't work because the type of a translate() is not a char *, it's a special compressed string type. You'll need to do more to get this to print. See calls to serial_write_compressed() in main.c, for example.
It would be good to test this in a local build.
Ya, I think so. You could also add it to UART if you like. You can see the technique here in Group: https://github.com/adafruit/circuitpython/blob/main/shared-bindings/displayio/Group.c#L79
I tried adding this, but I'm still seeing the same crash: https://github.com/AdamCummick/circuitpython/commit/4809c9235468914231e9ee1a7e454a9e42166e96
Looking into the origin of this on group and #1881 it l...
@tulip sleet if #3905 finishes please go ahead and merge it. I'll check back about the status of this sleep fix after I get home (on an errand now)
do others see a lot like this in the esp32-s2 debug console when GET-ing:E (19314804) esp-tls-mbedtls: write error :-80: E (19314804) esp-tls-mbedtls: write error :-78:The GET calls are successful, and result in 200 status and full content. maybe it's just normal low-level retries?
Thanks for pointing this out. IDF implementation of TouchWake doesn't work for LightSleep.
I forgot to test this with mechanics of pretend-to-sleep... wake on interrupt from light sleep is working now.
I pushed touch-alarm changes along with light-sleep fix...
Great, I did not test the learn guide. I just quickly started to read and found that. Maybe I should just follow it completely and give it a try.
@crimson ferry Are you around?
yes
Excellent. I wanted to give you a quick few sentence primer on what you can do as a reviewer since we may not have made it clear going in. 🙂
You are welcome to review, request changes on, and merge PRs. It's best to merge once you've tested it, but obviously for some, it's pretty obvious whether it's going to work or not, and at that point you can say "Approved, did not test" or some such so it's clear, and merge the PR. Once merged, please feel free to do a release. There's standard copy in all the releases about installing the bundle from circuitpython.org, and using pip, and regarding RTD. Include that always, and if you want to, you can include a note above that boilerplate saying what changed. That's typically what's in the title of the release though, so it's not always necessary. With releasing, regarding versioning, small bug fixes are x.x.N bumps, larger but not breaking changes are x.N.0 changes, and breaking changes and huge feature adds are N.0.0 changes. (Let me know if that doesn't make sense.)
I usually edit an old release and copy and paste the markdown from it to the new release and make any necessary changes to notes.
Version numbers are free for the most part, so don't fret over what one to bump, pick one and go with it.
@crimson ferry Any other questions I didn't cover?
No, that's perfect, thank you!
You're entirely welcome! Apologies for not making that clear going in. You're not the only one who was unclear. I will make sure that we introduce folks to reviewing much more clearly moving forward.
whew, home again.
Welcome back.
thanks
@slender iron want me to continue with the beta release today without the TouchWake changes in #3850? Or do it tomorrow (I had not planned to work tomorrow but it's no problem to put in a couple of hours and doesn't disrupt any of my plans)
the fix in that PR for light sleep wake alarm is probably a good thing
even by itself
and we could merge touch with only light testing, since it's beta
er that must not be the PR I mean. Let me scroll back
that one failed CI and has requested changes and is not new. I thought I saw something new go by from @analog bridge while I wasn't able to give it full attention.
This is the conversation/problem I was thinking of, which is not a PR yet?
OK, the failed build is a red herring (upload artifacts failed)
let me see if it looks like scott's review items were addressed
Works ok on 6.0.0 on Feather nRF52840 Express.
I think it addresses scott's review notes..
Does the interrupt work during light sleep?
I forgot to test this with mechanics of pretend-to-sleep... wake on interrupt from light sleep is working now.
@tannewt 's requested changes seem to have been addressed. Merging so we can have this in beta3.
Thank you for the PR! Just a couple comments.
I wish my pin alarm PR was already in. I heard you hit the same issue I did. I hope we can figure it out soon.
@onyx hinge do you know about repos/circuitpython/tools/convert_release_notes.py, which converts the release note markdown to HTML and BBCode? Scott keeps the quote delimeters it adds, I remove them.
yes except .. it's not working for me
Requirement already up-to-date: mistune in /home/jepler/.local/lib/python3.7/site-packages (0.8.4)
jepler@babs:~/src/circuitpython$ python3 tools/convert_release_notes.py < 610b3.txt
Traceback (most recent call last):
File "tools/convert_release_notes.py", line 7, in <module>
import mistune.renderers
ModuleNotFoundError: No module named 'mistune.renderers'; 'mistune' is not a package
also you can use the Duplicate Post button in the blog to duplicate a previous beta announcement. I forgot to change the permalink last time, don't repeat my error
i am using mistune 2.0.0a4
ok that worked
maybe I upgraded something else. checking... [no, apparently]
Automated website update for release 6.1.0-beta.3 by Blinka.
New boards:
- stackrduino_m0_pro
- bastble
New languages:
- ja
- en_US
- zh_Latn_pinyin
- el
- fil
- nl
- pl
- it_IT
- hi
- en_x_pirate
- fr
- ID
- ko
- pt_BR
- de_DE
- es
- cs
- sv
"new languages" -- must just be a bug?
I want to merge that PR before doing the forum and blog announces right?
- "downloads": 144,
+ "downloads": 0,``` hm what do I do about download counts !?
I can update the download counts. I have the data from just a couple of days ago.
OK, would you do it by adding to that PR, or as a separate PR?
I update the PR
Would you please?
sure, i am eating, will try to do it during the meeting
Indeed
@onyx hinge ok pushed downloads update
Thank you for the feedback @dhalbert, much appreciated. Working on getting the build to complete locally.
It did yesterday when I got it setup, but while I was asleep, the bits did play and move around it seems.
I was unable to establish what the default or power-on value is, so we should set one.
Hi folks, here's a video of the issue in action. Thanks!
https://user-images.githubusercontent.com/869133/103387130-22a7b000-4ad0-11eb-85f6-538351ac3b31.mov
@ionic elk I asked Noe to post a video of their ESP32-S2 LED sign flickering because I think their might always be white. He'll add a video clip to the GitHub issue. If needed next week, I can set up my project again and get video of it flickering because I swear it wasn't only white, but maybe I'm wrong.
@lone axle I love your suggestion of having the full icon list, but it uses a LOT of ram! ```>>> gc.collect(); gc.mem_free()
219296
import forkawesome
gc.collect(); gc.mem_free()
188224
Adding localization values for the output of calls to help() can match the current firmware's language.
This change addresses issue #3907
n.b.: This is a recreation of PR #3908 since ran into issues with my previous local branch. Apologies for the noise and mess.
Are there any obvious blockers to porting the WSGI web server to Feather M0/M4 plus Ethernet Wing? My end goal is a simple REST api to toggle latching relay feather wings, which will be controlling a hacked Sabrent USB 3.0 switch for automated Yocto Project testing.
closing this PR for now. will be taking another tact on this fix to handle inverted pins etc.
@idle owl Ok I'll plan on spending some time recreating issues this week
@hoary moat I might be oversimplifying, but it may just be a matter of replacing the esp socket with the wiznet5k socket https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/blob/fce466bd2bb70ca86b79e5cb36bbaca00afacfd1/adafruit_esp32spi/adafruit_esp32spi_wsgiserver.py#L35 Note that wiznet5k doesn't have HTTPS currently. Also, I'd be a little surprised if M0 boards have enough RAM for this, M4 should be fine.
Yes. That’s exactly what thought and meant. I couldn’t find the link on my phone lol. SSL/TLS is not required, it’s on a jailed subnet.
Good to know about M0 RAM. I’ll save that for other fun projects and just port the M4 (and contribute the code when it works)
Of course I have to actually order the Ethernet Feather because I only found out it exists a week after receiving the original Feather order. #2020
I realize Arduino support is out there. CircuitPython all the way.
If you need more interfaces, they plug-and-play pretty well 😉 https://twitter.com/anecdat/status/1327472474624323585
@crimson ferry I’m contemplating maybe 4x latching relay wings... should theoretically be scalable to 10 with 20 GPIO pins...
that's a huge feather sandwich 🙂
Now that I said it, of course I have to build the 10x version. Lol
And then write a labgrid driver https://github.com/labgrid-project/labgrid/tree/master/labgrid/driver
I see a future show and tell
Hi all, I'm trying to hook up a sun sensor device over I2C to a custom pull up board. There are intermittently ERRNO 19, ERRNO 5, and "SDA / SCL needs a pull up" errors when trying to use a certain set of pins. This is a long shot, but it looks like the Samd51 chip we're using has internal pull up resistors. Anyone know how to disable these in CP?
For circup: make check runs pyflakes and pycodestyle, CI runs Pylint I'd like to make it consistent so you get the same results locally. What is the preferred set of code checks for CP supporting tools such as circup ?
weirdness: 6.1.0-beta.3 qtpy builds lost about ~40% of the free space that 6.0.1 builds had (w/ gcc10): only 2764b free in beta3 vs 4612b free in 6.0.1.
this makes it more difficult in my use case, but i dunno if it's concerning in general.
I totally missed it, but congrats to all on 6.1 beta3 ! I hope you all have a safe and happy new year!
Seems to be the same issue with STM32F405 Cortex M4 CPU on Adafruit Feather STM32F405 Express.
Find my investigations here: OneWire support STM32F405
Perhaps stm32duino / Arduino_Core_STM32 group is working on something similar (no. 412)?
Like @tannewt estimated something with timing.
Maybe this post is helpful even it is not CircuitPython related: [Support OneWire device (ex: DS1822) #412](htt...
I was encouraged to post this issue here after discussing it on the Adafruit Metro M4 Express forums - here is the thread.
Essentially it seems like time.sleep() provides inaccurate intervals on Windows 7. Below are excerpts from the thread referenced above, but it's also worth noting that the release notes stated there were changes to the sleep functionality in CP 6.0.0 which may have introduced issues. I have also confirmed tha...
Yeah, that would be great
@slender iron
Traceback (most recent call last):
File "code.py", line 42, in <module>
File "adafruit_ble/__init__.py", line 340, in tx_power
NotImplementedError: setting tx_power not yet implemented
Safe to assume there's a bit of scaffolding that'd go into enforcing correct power limits on each platform, and also the register-level code to actually set this on a given chip? Or is it actually kind of trivial and just hasn't been done?
I've been working on a web-based converter for bdf -> pcf conversion. It's ready for someone to kick the tires. It works entirely in the browser and is actually hosted by github pages: http://www.unpythonic.net/web-bdftopcf/ [source code: https://github.com/jepler/web-bdftopcf]
I've learned a lot but still not how to make web pages pretty 🙂
@dhalbert You had suggested that I look at the nrf and the atmel-samd versions. Fun to have read and now understand both, my informal analysis is: They look to be functionally equivalent, but use resources differently. The nrf interrupt handler may use more CPU, where the atmel-samd probably uses less cpu-cycles but could have a slightly larger memory footprint. What would you suspect to be the more precious resources at runtime?
then I have another small quandary : there could be encoder...
I need a bit of advice since I
am new to Circuit Python. I'm trying to use an Adafruit msa301 accelerometer with a Feather M0. From what I've been able to glean so far, I am likely running into a lack of sufficient RAM issue but I want to check before I reinvest in an M4 feather. The program is:
import time
import board
import busio
import adafruit_msa301
i2c = busio.I2C(board.SCL, board.SDA)
msa = adafruit_msa301.MSA301(i2c)
while True:
print("%f %f %f" % msa.acceleration)
time.sleep(0.5)
And upon loading I get the following error message:
Traceback (most recent call last):
File "code.py", line 4, in <module>
File "adafruit_msa301.py", line 207, in <module>
File "adafruit_msa301.py", line 233, in MSA301
File "adafruit_register/i2c_bits.py", line 61, in init
OverflowError: small int overflow
This isn't an explicit out-of-memory message but it seems unlikely that there is a overflow issue built into the accelerometer library either. Can someone help me understand if I'm just low on RAM or low on understanding.
Thanks
That is an odd error. Just to check. Are you loading the .py or .mpy versions of all the libraries? -- you must use the .mpy versions. I'm searching to see if I have one of those sensors handy...
Let me check on the library...
I am, indeed, loading the .mpy version from the adafruit-circuitpython-bundle-6.x-mpy-20201223.zip archive.
OK -- just found mine -- now to find an M0 express and bring it up to date. I'll be back in a few minutes....
Thanks for the help, I'll get another cup of coffee and await your findings.
Line 233: _xyz_raw = ROBits(48, _MSA301_REG_OUT_X_L, 0, 6)
This specifies that the "xyz raw" register has 48 bits, which it will try to treat as a single integer value. This doesn't work in M0 builds, because they don't support "long integers", they only support integers 30 bits long (31 bits? anyway, fewer than 48 and even fewer than the customary 32).
I don't know that there's a simple solution to this problem, but if you file an Issue about it the maintainer will be able to decide whether to fix it or to add a notice that the library is not compatible with M0 boards.
That is too bad -- I'm still setting mine up, but expect to reproduce your results. I'd get the m4....
I don't want to put words in anyone's mouth, but I think there's a reasonable possibility it can be modified to get rid of this particular use of a 48 bit quantity. Instead of using RWBits for this particular data, you would use a 6-byte readinto() followed by a struct.unpack. It's all a conjecture from me though
interesting -- the msa301_simpletest from the bundle works for me ```
Adafruit CircuitPython 6.1.0-beta.3 on 2020-12-31; Adafruit Feather M0 Express with samd21g18
import msa301_simpletest
6.526161 -6.214935 4.036356
6.574041 -6.214935 3.945382
6.540525 -6.243664 3.926230
6.574041 -6.238874 3.907078
oh yeah it's a basic vs express distinction. feather m0 express has long, feather m0 basic doesn't.
as does your code @slow matrix ```Adafruit CircuitPython 6.1.0-beta.3 on 2020-12-31; Adafruit Feather M0 Express with samd21g18
import msa_test
6.454338 -6.229300 4.170422
6.454338 -6.229300 4.074661
6.459127 -6.243664 4.098600
6.473492 -6.224510 4.093813
6.473492 -6.243664 4.089025
6.478279 -6.277180 3.998052
I am admittedly running the latest version of the feather_m0_build ---- What version are you running?
Ah I assumed you had an M0 express -- which board are you using?
I just got the M0 Basic a week or two ago so I suspect the latest version. How do I get the version from the device?
The basic is a different beast than an express.
it's printed at the top of the repl
Yeah, I just saw that. It is: Adafruit CircuitPython 6.0.0 on 2020-11-16; Adafruit Feather M0 Basic with samd21g18
also in the boot_out.txt file on the flash
the version is not the problem, that's very close to the current stable version
much more limited. I'll try it on a basic, but as @onyx hinge noted it will not work....
I'm pretty sure the m0 basic is going to be incompatible with that library as it stands
confirmed -- the adalogger is a "basic" ```
Adafruit CircuitPython 6.1.0-beta.3 on 2020-12-31; Adafruit Feather M0 Adalogger with samd21g18
import msa_test
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "msa_test.py", line 4, in <module>
File "adafruit_msa301.py", line 207, in <module>
File "adafruit_msa301.py", line 233, in MSA301
File "adafruit_register/i2c_bits.py", line 61, in init
OverflowError: small int overflow
In general, the M0 basic will be a frustrating place to work with CircuitPython .... but it it worth opening an issue. Are you comfortable doing that or would you like me to open it?
My application will also require a 14-segment display and the native touch input so I'm pretty sure I'll need more memory than what the Basic can provide. I'm always looking for the lowest cost, leanest implementation but M0 Basic doesn't seem to be the answer here. Thanks for all your help, it is very much appreciated.
I would be happy to learn how to submit an issue as one never knows when the knowledge will come in handy. Just a pointer to where to start would help and I'll stumble around from there.
Thanks again.
go here https://github.com/adafruit/Adafruit_CircuitPython_MSA301/issues and click on "new issue" -- include your code example -- or just reference the msa301_simpletest.py example and include a copy of the error traceback.
Excellent! I'll do that. You all have been very helpful.
Make it clear you are using an M0 Basic.
You're welcome -- glad to try to help. You found a real issue!
Thanks @onyx hinge for the quick "root" cause.
@slow matrix for low cost, you might want to consider the itsy Bitsy M4 express https://www.adafruit.com/product/3800
with the display and a sensor, I would not recommend an M0 based board.
unless you need the battery charger on the feather.
Thanks for the recommendation, I'll definitely look into it. For this application, having the onboard battery charger is much less important than small form factor.
As for the bug report, I have a github account that has been fallow for a very long minute (like a four year long minute) and, as it seems silly to create a second account merely to report the bug, I'm in the process of resurrecting this account. It's been a day of discovery for me.
@siddacious thanks for linking to that issue. After taking a closer look, if you disable the "USB Printing" plugin in CURA the issue appears to go away.
To disable in Cura go to "Marketplace" -> "Installed" tab and uncheck "USB Printing".
I'm messing around with a new stemma device (the best!) and the sample code looks like this:
import board
from adafruit_lc709203f import LC709023F
sensor = LC709023F(board.I2C())
That doesn't work on the MetroS2 or FeatherS2, you need to first create an i2c object and pass it in. Not a big deal for me, but I'm curious, do other boards have a default i2c like in that sample?
I'm wondering if this is something that needs to be updated in the samples or if it is something that needs to be implemented in the esp32-s2 port...
the feather S2 port used to be missing board.I2C but it's there now
is that what you are talking about or ?
I don't expect it to be too much work.
I'll try a newer build, thanks !
I received a response from Github -- it appears the behavior is by design. However, I remain puzzled at the advice about "merging the master branch into the feature branch frequently" as this is exactly what we are doing and it does not resolve the display issue in pull requests. But for now I think we have a choice between doing nothing and accepting the behavior, or switching to rebasing on weblate which we don't want to do.
Hi Jeff,
Thanks for contacting GitHub Support!
...
Hmm... I built a clean build off CP main and I still see the not implemented.
sensor = LC709023F(board.I2C())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NotImplementedError: No default I2C bus
I think the default is the critical word there
the metro ? it definitely works on the feather, I use i2c = board.I2C() (PR3671, 12 november) maybe it needs to be added to the metro too
i'm using a feather s2
I'm using a PRE-RELEASE FeatherS2... (green) that might be it...
oh right it's treated as a different board
bytearray extend of simple list fails. Works in python 3.
Adafruit CircuitPython 6.1.0-beta.2-182-g1b7fbaf31 on 2020-12-26; FeatherS2 with ESP32S2
>>> t=bytearray()
>>> t.extend([0])
Traceback (most recent call last):
File "", line 1, in
TypeError: object with buffer protocol required
Thanks @jaunty juniper... that was it. board.I2C() works now on my build.
I see some other changes in the release vs. pre-release I'll ask UM about on his server. HNY !
This is draft because I'm not sure of the commits from pull cp/main.
The changes though are to being the FeatherS2 files NSync with the only changes being the actual changes between the two boards.
I have tested board.I2C() works on the pre-release.
I've just looked through shared-bindings adapter.c and (nrf)common-hal adapter.c and.... Yeah I don't know what I'm doing 🙂
User Code update can be done by a FTP server implementation @microDev1 Any example available ?
i can reproduce this using a custom build on a QT Py that adds the native _pixelbuf. it does not occur using brightness=0 in the constructor:
import board
import neopixel
np = neopixel.NeoPixel(board.NEOPIXEL, 1, brightness=0)
# no change visible yet
np[0] = (100,0,0)
# now turned off
np.brightness = 0
# back to full on
looking in shared-bindings/_pixelbuf/PixelBuf.c, the [constructor calls mp_obj_get_float()](https://github.com/adafruit/circuitpython/blob/...
I found code in the Learn Guide repo but I did not find the Learn Guide: https://github.com/adafruit/Adafruit_Learning_System_Guides/tree/master/ESP32_S2_WiFi_Tests (did I fail in my search? is there a guide on the FeatherS2 in preparation?) I believe this would have been useful for me as I re-did this based on MagTag example and other guide to test my FeatherS2. It would also be usefull for Metro S2 board: https://learn.adafruit.com/adafruit-metro-esp32-s2 cc: @atomic summit
Curious if you expand Ram on the m0 using i2c SRAM
Probably not directly with circuitpython without some serious reworking I bet
Or maybe not at all
Not sure adding 64k of SRAM would do much but 🤷♂️
I just followed the Welcome to CircuitPython instructions for writing your first program on a Metro M4, using the recommended stable 6.0.1 and Mu editor, and it is now broken because time.sleep hangs.
Having a working new user tutorial is important, but that could mean simply downgrading the recommended stable release if there isn't a simple fix to the sl...
I can confirm that time.sleep hangs with 6.0.1 (on a Mac using Mu editor, in case that is relevant).
I was able to play and get duck typing working. But see two possibilities
- Just use duck typing for all calls (busio, bitbangio or other).
- Use duck typing but for a known type (busio, bitbangio eventually) call the common_hal methods directly.
As I can see it the first option will be a smaller code base, but may be slower with known bus types. The second option will be a larger addition size wise to the core code but may be faster for the known bus types.
@jepler @tannewt any p...
The most recent working M4 Express download that I could find is 3.1.2 from S3 (since the 5.x series .uf2 files are not available on either github or S3).
When I was developing the driver code for my touch sensor, I would occasionally receive the error: OSError: [Errno 5] Input/output error
I could either wait for the filesystem to refresh or resave the code.py file. It isn't consistent and sometimes happened on hard resets via the reset button.
Using Qt Py CP6 build from 11/13/2020.
One other users in the discord help with CircuitPython channel also mentioned the same issue.
I'll be checking this with my CP Sapling M0 and the Fe...
The earlier builds were not grouped by language. Look under the en_US (or other directory) to find newer builds on S3.
@dkirkby Are you trying this in the REPL or in a code.py? In the REPL, it seems to mess up, but try it in a program file.
@hathach Could you take a look at https://github.com/adafruit/circuitpython/issues/3829#issuecomment-750406312 above? This seems very odd, and seems to depend on the host driver, or maybe the terminal program. We may not be servicing USB properly on the CircuitPython side. #3912 is similar, on Windows 7. I haven't yet tried to replicate on Windows 10.
I think it might be related to this i2c bus error from October. #3376
In my code I was using i2c. The user in the discord channel was using audiobusio I2S.
Thanks @dhalbert, I found 5.3.0 on S3 here.
I am following these welcome instructions which have you enter the code in the Mu editor then save.
In my debugging, I later opened the serial connection but that did not change the problem (but did enable me to isolate `time.sleep...
@dkirkby Are you trying the blink example, saved as code.py? Does on-board LED blink?
Nope, sorry. Those chips don't support adding external RAM that is directly visible to the CPU.
I will be walking 25 students through their first CircuitPython program via zoom on Monday, so just looking for a working recipe now :-)
3.1.2 (which is what the board shipped with) seems to work fine.
6.0.1 (the current recommend stable version) hangs in time.sleep.
5.3.0 (mentioned in #3912 as working) hangs (with the RGB led solid blue) when I drag the .uf2 file to the USB drive, and never remounts as CIRCUITPY.
I figured, but was worth asking 🙂
Yes, the blink example, saved as code.py. The code hangs at the first time.sleep, so with the D13 LED on:
import board
import digitalio
import time
led = digitalio.DigitalInOut(board.D13)
led.direction = digitalio.Direction.OUTPUT
while True:
led.value = True
time.sleep(0.5) #### CODE HANGS HERE WITH 6.0.1
led.value = False
time.sleep(0.5)
If I replace time.sleep with a busy loop (for i in range(20000): y = math.sin(0.1)) it works as expected.
What version of MacOS are you using, and are all the students using the same?
I am using OS X 10.15.6 and the students are likely using 25 different platforms :-)
Thank you for following up on this @dhalbert!
(after manually unplugging and inserting the USB cable, my 5.3.0 install seems ok)
I will try to replicate this. Here is 5.3.1 (note it appears above the earliest 6.0.0 releases, due to chronology): https://adafruit-circuit-python.s3.amazonaws.com/bin/metro_m4_express/en_US/adafruit-circuitpython-metro_m4_express-en_US-5.3.1.uf2
are you using an editor that flushes the file completely to disk. try mu
I should have mention that I was using the MU editor
Dropping 5.3.1 onto the bootloader works as expected (i.e. with CIRCUITPY automounted after a short delay), thanks! Was that a known issue with 5.3.0?
I'm up for cleaning up the commit history, but the changes are just what were expected. Ready for Review.
Dropping 5.3.1 onto the bootloader works as expected (i.e. with CIRCUITPY automounted after a short delay), thanks! Was that a known issue with 5.3.0?
I did see that once, but power-cycling the board made it possible to load 5.3.0. There is no change between 5.3.0 and 5.3.1 that would have fixed that. It may be some MacOS idiosyncrasy. I am testing on a Big Sur machine (that's all I've got).
It might be a Qt Py specific issue, I'm trying it out on my CP Sapling (also an samd21e18a) though I'm not seeing it replicated.
I was not able to reproduce the Win 7 issue using either Putty or Mu; time.sleeps of .5 seconds were accurate. I did see that when I tried very small sleep values (i.e. .01) that occasionally the time.monotonic() would jump by .06. I suspect this may be due to running some background task, but it was not a 'near halt' as you reported. Have you tried loading the latest Circuitpython Windows 7 drivers linked from https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting?
Wait, I got it to reproduce. Here's the output:
`Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Traceback (most recent call last):
File "code.py", line 7, in <module>
File "/lib/odt_at42qt1070.py", line 119, in init
File "/lib/odt_at42qt1070.py", line 145, in reset
File "/lib/odt_at42qt1070.py", line 125, in _write_register_byte
File "/lib/odt_at42qt1070.py", line 125, in _write_register_byte
File "adafruit_bus_de...
@solar whale I think the issue might be in the bus_device library
I'll investigate further
it doesn't throw without a call for adafruit_bus_device
Interesting.. Good luck finding something. There has been a lot of work done recently to move bus_device into the core. It was implemented then reverted due to some issues that are being resolved. https://github.com/adafruit/circuitpython/pull/3612
It's related to this specifically
https://github.com/adafruit/Adafruit_CircuitPython_BusDevice/blob/eb4b21e216efd8ec0c4862a938e81b56be961724/adafruit_bus_device/i2c_device.py#L102
@ornate breach are you testing with beta.2? We turned off the native adafruit_bus_device in beta.3 because of a number of issues.
no
current version for my CP Sapling: Adafruit CircuitPython 6.1.0-beta.1-8-g8301dcada-dirty on 2020-11-23; CP Sapling M0 with samd21e18
local build, but the qt py is using CP 6 from 11/13
stable
both throw the same OS Error
I like the idea of having a file that is run even when started in safe mode, @dhalbert . That would let me perform a test of the batteries and make a decision based on my actual situation. I also like that it puts the solution in Python rather than having to choose from 2 or three options written in C.
Just to flesh this out, would there be limitations on the code in safemode.py? For example, would the SD card still be read-only? Would it be run before sensors are active or anything ...
I wonder if maybe the i2c buffer isn't cleared properly on reset
I may add a delay between my write bytes section of reset() to see if that fixes it
nevermind... there is a 1ms delay in the reset write calls.
@ornate breach, I think that i2c no longer has any „deinit“ (uninstall) - which was the way to fix the reload issue
Maybe, but the uninstall was removed from the i2c code
I‘ve spent a lot of time on this and couldn’t figure out how to fix it until Bruce removed the uninstall from the deinit function
right, but the issue seems to still exist at least in some builds
at least for m0
it doesn't seem to just affect i2c either
it was happening with i2s for someone in the CP help channel
I have to admit, that I don’t like the solution to remove the uninstall. It is a workaround, but I hope that we can find a better way go fix it sometimes soon
yeah, I've honestly look over all the i2c related files, and I'm not sure where it might be even hanging up.
in my issue, mine returned for python self._i2c.write(...)
I‘ve read a comment where the esp32 was still waiting for a reply from the i2c device (e.g. during discovery) and that caused some serious issue
I just wonder if the buffer isn't clearing
because it is also hanging on python self._write_then_readinto(...)
though, I probably could just use python self._readinto(...)
but I'm not confident that you could avoid that
I haven’t run into issues again, but I mainly spent time on enhancements
My NYE state machine https://github.com/bwolfram1/NYECountdown/blob/main/main.py
it's mostly random when it throws the OSError
it could throw it right away, or 5 minutes after running just fine.
though... the adafruit_bus_device does say that the OSError it throws is from the device not being present
I could try with other i2c devices, but other people have similar i2c issues so it might not be trivial
@thorny jay I don't think a per board guide is needed. Not for CP functionality, as ESP32-S2 is ESP32-S2 - There is only the 1 MCU right now, just being delivered in various formats. So from a code point of view, all of the non hardware specific stuff like Wifi is the same.
Unless there was something else FeatherS2 specific you though needed to be made clearer?
Well, 10 minute ago I figured there is a light sensor... I dunno if there is a demo code for it.
Also I tested TouchIO (actually I want to test wake on touch) and I took pin 33 at random, but later I looked at the schematic and now I know that I have to choose a pin that is touch compatible.
The point is/was that there is code in the Learn Guide repo, and I don't know what guide link to it.
I had no trouble to make the wifi work, it work I guess like for other board since I succeeded. 🙂
the light sensor could bear better documentation, and a place in the demo file too (light = analogio.AnalogIn(board.AMB))
I have more example code I am preparing that will ship with the featherS2 in the future and I'll also have on my feathers2.io website, that includes a wifi example, LDO2 use and I can also add the lightsensor.
Maybe like on the MagTag that also has alight sensor that is used in this guide: https://learn.adafruit.com/twin-peaks-light-reactive-pyportal-picture-frame
Touch is the same on all boards. it's hardware level which IO it's on, and I have those on the pinout guide.
Yeah, I am on that image too.
How did you create this graphic? I really like it 🙂
I should add the RTCGPIO pins as well. It's on my list of things to do... I'm just have 2 hands, so struggle to cover everything I need to get done 😦 #growingpains
The LDO2 I tried to figure out how to use it... I guess I have to power external device from that pin, and then they will sleep when I sleep the ESP32S2.
I made it by hand in Affinity Designer (like illustrator)
Nice, I even have that on my MBP 🙂
You can turn LDO2 on and off with IO21, but if the ESP32S2 deep sleeps, it auto shuts down for you.
Oh and I want that graphic in higher resolution, just because my eyes are not that good anymore... and did not go to they eye doctor yet.
It is a vector graphic, so I guess @atomic summit could scale it as he wants 🙂
Adafruit has a link in learn guide that contain multiple resolution, I always go to the bigger one.
Is this ok? I can make it any size 🙂
Thanks, saved. Now I can print a poster and put that in my room.... not sure my wife will like that. 🙂
adafruit has pinout graphics, they might have a way to generate them ? ask an engineer 😉
It's not clear how they do. Depend on the guide and who does it. I have catch a conversation here where kattni needed to update one.
I'm happy making my pinout cards the way I do. I mean, it takes a lot of time and effort, but the I'm happy with the results and consistency across all of my products.
they look really nice
@brrzap good catch, wanna submit a PR for that setter change? its ok if it adds some cycles - better to have it right :)
@unexpectedmaker please take a look!
Thanks for doing this @askpatrickw
IO13 is still in pins.c twice for FeatherS2 and Prerelease - lines 93 & 12
Please remove lines 93 in both files
Cheers
Seon
I tested this feature with the ESP32S2.
It seems that my board wakeup twice in a raw when I touch.
Basically it made this code blink the blue LED twice in a raw for 5 seconds (even with a single touch of the pin).
This is tested with 6.1.0-beta3.
sync brightness setter's float cast to that used in constructor for error checking. fixes #3753.
this is neat: https://github.com/johnmcfarlane/unformat
Ok, the double trigger on touch only seems to occur with the USB connected to computer, but not when on a power supply. So that would be on fake sleep path.
Also wake-up speed on touch seems much faster on fake sleep than on real sleep... understandable but should it be better faked?
@UnexpectedMaker This last commit fixes that dupe IO13 and removes some whitespace.
Same person who did the clang format scripts?
¯_(ツ)_/¯
Filename misnamed (?) in MagTag Project Selector ... adafruit_matrixportal lib has network.mpy file ... Call from project selector weather.py is looking for network.py ... I'm just gettin' started with this CPY stuff so I'm not sure how 2 fix the coding ... Using 20210101 libs & uf2 6.1.0-beta3 ... Where do I go next ?
Hola ... Figured it out (Note 2 self - don't work on MatrixPortal Weather B4 workin' on MagTag Weather) ... Copied wrong weather.py 2 MagTag Project ... RTM a couple of times & triple check
what U just did
That looks like unreliable connection on the i2c bus. How long are the cables you are using? Are they soldered or just inserted into a breadboard? Do you have any additional pull-up resistors on the lines?
There's something not quite right on 6.0.1, the value of 0.02001 trips the range checking logic:
Adafruit CircuitPython 6.0.1 on 2020-12-28; Adafruit CLUE nRF52840 Express with nRF52840
>>> from adafruit_ble import BLERadio
>>> from adafruit_ble.advertising.adafruit import AdafruitColor
>>> ca = AdafruitColor()
>>> ca.color = 0x4b4c46
>>> ca
Advertisement(data=b"\x0a\xff\x22\x08\x06\x00\x00\x46\x4c\x4b\x00")
>>> ble = BLERadio ()
>>> ble.start_advertising(ca, interval=0.02...
Bug is still present:
Adafruit CircuitPython 6.0.1 on 2020-12-28; Adafruit CLUE nRF52840 Express with nRF52840
>>> from adafruit_ble import BLERadio
>>> from adafruit_ble.advertising.adafruit import AdafruitColor
>>> ca = AdafruitColor()
>>> ca.color = 0x4b4c46
>>> radio = BLERadio()
>>> radio.start_advertising(ca)
>>> for adv in radio.start_scan(timeout=30.0):
... print(adv)
... radio.stop_advertising()
... radio.start_advertising(ca)
...
...
...
<Advertisem...
The floating-point conversations are apparently different for the C compiler and the CircuitPython/MicroPython converter. So for now, could you just use a larger value? I will try to make this more consistent.
It’s connected over Stemma QT, 10k pull ups on the breakout PCB soldered on. I’d be inclined to agree with you if I was getting “no device detected” but the trace back doesn’t return past the write operation to confirm one way or the other.
I'm not actively using that value in new code but I mentioned 0.02001 as a workaround in this ticket that's been around since last May. That value is also in the code in Adafruit Learn: CLUE Rock, Paper, Scissors Game using Bluetooth but that also doesn't work on 6 so far due to #3731
// TODO: Talk openly, develop openly
@deshipu It might be isolated to the i2c device I'm using currently which only uses Adafruit_Bus_Device, I might try to use Adafruit_register as well to see if that helps any. It was mentioned to me that there was some issue with Adafruit_bus_device (hence the freeze in core builds).
Splitting this issue off from #3829:
from @dkirkby:
I just followed the Welcome to CircuitPython instructions for writing your first program on a Metro M4, using the recommended stable 6.0.1 and Mu editor, and it is now broken because time.sleep hangs.
Having a working new user tutorial is important, but that could mean simply downgrading the recomm...
[Omitting some false starts]
Originally posted by @dkirkby in https://github.com/adafruit/circuitpython/issues/3829#issuecomment-753359516:
Yes, the blink example, saved as code.py. The code hangs at the first time.sleep, so with the D13 LED on:
import board
import digitalio
import time
led = digitalio.DigitalInOut(board.D13)
led.direction = digitalio.Direction.OUTPUT
while True:
led.value = True
time.sleep(0.5) #### CODE HANGS HERE WITH 6.0.1
led.va...
I tried the same blink program above on a Metro M4 Express with 5.3.1, 6.0.1, and 6.1.0-beta.3. They all work and blink as expected, whether plugged into a Linux box or a MacBook running the latest Big Sur.
(btw, getting mu to run on Big Sur is a chore, and I gave up. The old alpha supposedly works for some people. See https://github.com/mu-editor/mu/issues/1147)
Restarting issue #3829, which got off track, and had some false starts:
First reported by @mcauser in https://github.com/adafruit/circuitpython/issues/3829#issuecomment-747804072. Replicated.
I see the problem with 6.0.1 and 6.1.0-beta.3.
On Linux using picocom, and Windows using Tera Term, this works:
Adafruit CircuitPython 6.0.1 on 2020-12-28; Adafruit Metro M0 Express with samd21g18
>>> import time
>>> time.sleep(0.1)
>>>
On MacOS 11.0.1, using screen or ...
Closing in favor of #3918 and #3919.