#circuitpython-dev
1 messages Β· Page 70 of 1
Probably the CircuitPython bundle. We have separate repos for CPython compatible modules.
I'm not sure what we can do about this. We could increase the buffer but there will always be a limit to how much we can buffer. We could dynamically buffer but that'd add code size and complexity.
We should see if MicroPython has the same problem, and if not, what are they doing differently.
You aren't deiniting the display so I suspect we need to have it ensure the display bus hasn't been deinit.
Howdy <@&356864093652516868> ! In about 50 minutes it'll be my pleasure to welcome you to our weekly meeting. please add your notes to the document: https://docs.google.com/document/d/1C4XIYb0tcKxlzNpwMI5pGf2OmRlzvSLOz7nbUt_Jo3s/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for July 15, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you canβt make the meeting and would s...
I was thinking that I could add a little "slip" into the UART write so that when it got backed up, it dropped output. I think that might be a better result than turning off the rx interrupts and dropping input data. I'll see if I can work up the idea in a PR so you can see what I'm thinking. If you don't like that option, marking this as a limitation of boards that don't support UART flow control might be the only option :grin:
@lone axle do you anticipate being able to read the library section of the meeting today?
Yes, I believe I should be able to.
Well I found the Micropython-lib reference and it looks like it adds additional methods to the library for cpython compatibility. I think it would be difficult to use with Circuitpython so unless someone thinks there's a better choice, I'm going to just drop that last sentence.
We should see if MicroPython has the same problem, and if not, what are they doing differently.
Micropython pastes a little more data before dropping input but behaves the same way. MP may use a slightly larger buffer, or perhaps the console output is slightly more efficient (doesn't check Webworkflow, BLE, etc streams).
in "raw repl" on a Adafruit CircuitPython 9.1.0-beta.3-48-g396aaef964-dirty on 2024-06-28; Adafruit Feather ESP32 V2 with ESP32 I can consistently paste a 103 line 7994-byte string via tio 2.6. In "paste mode", even a 100ms "line delay" (-O100) is not enough. A 1ms "char delay" (-o1) is enough.
this is just using a terminal keystroke to paste
The "raw repl" mode doesn't echo characters as you're typing/pasting does it? The echo is what has been causing the problem I think
code.circuitpython.org is being changed to to use Raw Mode instead of Raw Paste mode. Raw Mode does not echo. We talked a bit about this internally, and kind of came to the conclusion that it's not going to work well without delays, and no echo is the way to go if you have to do that.
βΊοΈ
ViperIDE now runs the full @micropython compiler right in the browser, thanks to #WebAssembly! π
Spot errors early with this powerful tool.
π https://t.co/2jk0MGhLYJ
#MicroPython #CircuitPython #WebIDE
Here is an example of the ruff config https://github.com/adafruit/Adafruit_CircuitPython_Requests/pull/173/files#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711R41
justmobilize's:
ignore = ["PLR2004", "UP030"]```
my project (leapseconddata):
select = ["E", "F", "D", "I", "N", "UP", "YTT", "BLE", "B", "FBT", "A", "COM", "C4", "DTZ", "FA", "ISC", "ICN", "PIE", "PYI", "Q", "RET", "SIM", "TID", "TCH", "ARG", "PTH", "C", "R", "W", "FLY", "RUF", "PL"]
ignore = ["D203", "D213", "D400", "D415", "ISC001"]```
i havent used it, but i know the ruff TOMLs support some sort of composition
at the very least i saw you can override "default" library-level settings in some subfolder
could perhaps leave the pyproject's as is, and add an extra toml with the enable/disable rules
$ ruff linter
F Pyflakes
E/W pycodestyle
C90 mccabe
I isort
N pep8-naming
D pydocstyle
UP pyupgrade
YTT flake8-2020
ANN flake8-annotations
ASYNC flake8-async
S flake8-bandit
BLE flake8-blind-except
FBT flake8-boolean-trap
B flake8-bugbear
A flake8-builtins
COM flake8-commas
CPY flake8-copyright
C4 flake8-comprehensions
DTZ flake8-datetimez
T10 flake8-debugger
DJ flake8-django
EM flake8-errmsg
EXE flake8-executable
FA flake8-future-annotations
ISC flake8-implicit-str-concat
ICN flake8-import-conventions
LOG flake8-logging
G flake8-logging-format
INP flake8-no-pep420
PIE flake8-pie
T20 flake8-print
PYI flake8-pyi
PT flake8-pytest-style
Q flake8-quotes
RSE flake8-raise
RET flake8-return
SLF flake8-self
SLOT flake8-slots
SIM flake8-simplify
TID flake8-tidy-imports
TCH flake8-type-checking
INT flake8-gettext
ARG flake8-unused-arguments
PTH flake8-use-pathlib
TD flake8-todos
FIX flake8-fixme
ERA eradicate
PD pandas-vet
PGH pygrep-hooks
PL Pylint
TRY tryceratops
FLY flynt
NPY NumPy-specific rules
AIR Airflow
PERF Perflint
FURB refurb
RUF Ruff-specific rules
Thanks for hosting Jeff π
thanks Jeff!
Thanks for hosting Jeff. Have a great week everyone!
thanks Jeff!
In cases like code.circuitpython.org where you have control of the serial transmitter, you can insure the speed is controlled and gain some transmission confidence by confirming that each character transmitted echos back what you sent, before transmitting the next character. In that mode however, you completely negate any speed advantage from the internal uart/Circuitpython buffers.
The Raw Mode is probably a more speed efficient approach, although it adds the slight annoyance of sometime...
https://gist.github.com/jepler/117ceae99f8c9439f86fcdd4e28d3f9b here's what pylint-to-ruff prints (minus comment lines) when I run it in adafruit_circuitpython_requests
so we could just chuck that in ruff.toml I guess
# 4. Ignore `E402` (import violations) in all `__init__.py` files, and in select subdirectories.
[lint.per-file-ignores]
"__init__.py" = ["E402"]
"**/{tests,docs,tools}/*" = ["E402"]```you can also apply different settings by path so we can invoke ruff once, not twice (right now we lint examples differently)
that's right, I haven't seen anything like that on debian 12
On Mon, Jul 15, 2024 at 8:54β―AM Dan Halbert @.***>
wrote:
@asmagill https://github.com/asmagill Could you post the string of
consecutive relevant log entries from dmesg or /var/log/syslog (latter
might have more or less info) when plugging in the board when it works and
when it does not work, so we can compare the two sets of entries?Do you see this problem even if code.py is not present or very simp...
A handful of the ruff rules that were output by pylint-to-ruff tool end up outputing these warnings when ruff is run:
warning: Selection `PLC2801` has no effect because preview is not enabled.
warning: Selection `PLE0643` has no effect because preview is not enabled.
warning: Selection `PLE0704` has no effect because preview is not enabled.
warning: Selection `PLE1141` has no effect because preview is not enabled.
warning: Selection `PLR0202` has no effect because preview is not enabled.
warning: Selection `PLR0203` has no effect because preview is not enabled.
...
There are about 20 of them. Would we want to run with "preview" enabled in order to use these? Or if not should we remove them from the config file for now if they will have no effect?
ugh my audio was clippy during the recording. oh well.
I have updated the BME680 PR to move the ruff config into it's own file and bring in those rules that were outputed by pylint-to-ruff. https://github.com/adafruit/Adafruit_CircuitPython_BME680/pull/70 for now I've left all the ones that it warns about having no effect. There were a few other tweaks to the code from running the ruff with these rules in place but not too much.
unrelated to ruff, but it looks like perhaps we're going to face this on lots of libraries (I saw it on a different one earlier today):
Error during sphinx build
/home/runner/work/Adafruit_CircuitPython_BME680/Adafruit_CircuitPython_BME680/adafruit_bme680.py:docstring of adafruit_bme680.Adafruit_BME680_I2C:19:'any' reference target not found: board.I2C
The cause as far as I can tell is useage of tick marks surrounding "board.I2C" in a docstring. By changing them to double tick marks it makes it so that the sphinx build can complete successfully.
Here is the notes document for next Mondayβs CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1cvCxFaJT5hIQ4UmzZm6f_betgOKNhtXJrsA4GYdVeQ4/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for July 22, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you canβt make the meeting and would st...
https://docs.circuitpython.org/en/latest/shared-bindings/board/index.html @lone axle the "board" module page is empty in the latest docs. not sure why.
it had correct content in 9.0.x https://docs.circuitpython.org/en/9.0.x/shared-bindings/board/index.html so this is a problem introduced in 9.1.0.
strange, I'll try to look into that.
OK, I can reproduce it locally, doing a bisect
commit 798e38e4470cbbc9316f40a9b161a37d9c8c52d4
Author: foamyguy <foamyguy@gmail.com>
Date: Sun Jun 23 11:14:35 2024 -0500
enforce min py3.9 for setboard. create init.py in board-stubs
Makefile | 1 +
tools/board_stubs/circuitpython_setboard/__init__.py | 4 ++++
2 files changed, 5 insertions(+)
I suspect the empty board/__init__.py created by touch is being used in lieu of the stuff in shared-bindings
Since 798e38e4470cbbc9316f40a9b161a37d9c8c52d4 an empty board/__init__.py is created inside the stubs directory and sphinx uses this in lieu of the autodoc generated file from shared-bindings.
We don't intend to build docs from files in these paths, so just prune them.
@lone axle thanks for bringing the problem up, I think I may have a solution ^
I don't think we have to cut an urgent release to fix this, because the intersphinx is just using the "latest" version, I think
I confirmed in a local build with this branch that the content has returned to the board module docs page.
Thanks for the fix @jepler!
it's nice to be helpful when the rest of my day has consisted of little progress on my own tasks π happy I could help
My goal is a standard socket wrapper for the openthread TCP/UDP APIs (https://openthread.io/reference/group/api-tcp and https://openthread.io/reference/group/api-tcp)
OpenThread
Great! Start with UDP. That's the land I'm in now. (Web workflow will need TCP though.)
That's the plan. UDP is generally preferred for openthread applications and should be easier to implement
Where should I inlude the openthread shared-bindings files?
what should the module be called?
I'm just calling it openthread
It might make sense to have a generic thread module with an openthread implementation but I haven't seen a thread MCU that doesn't support openthread
openthread is good. thread will conflict with the threading execution model
Yeah, many revised google queries have taught me that
especially before matter was a thing
should it live in shared bindings or shared modules? it could run on any port with a UART and an external radio but will have port specific init for ones with an internal radio
the python to c layer is always in shared-bindings
the external uart impl could go in shared-module
I'm not at home at moment, so it'll be a day or so to gather the logs requested.
As to to boot.py/code.py, mostly I've tested without these files (or the defaults as created after storage.erase_filesystem() -- no boot.py and a simple print statement in code.py).
I did have a thought... the system I do most of my work on has externally powered usb hubs, one to a USB3 port, the other to a USB2 port and these are what I plug devices into 90+% of the time... when I gather the reques...
M5Stack Fire v2.6 not working me...
anyone aware of why the circuitpython-build-bundles CI job step might be throwing a wobbly:
https://github.com/adafruit/Adafruit_CircuitPython_AdafruitIO/actions/runs/9958291807/job/27513367239#step:2:767
check out latest changes to the code
probably introduced something that is not supported on CP8
you can install the mpycross locally and test too
I don't believe it's at the mpy-cross bit, it's only failing there due to failing the bundle script I think, or whatevers in the /tmp/randomName with the syntax error
RuntimeError: ('mpy-cross failed on', '/home/runner/work/Adafruit_CircuitPython_AdafruitIO/Adafruit_CircuitPython_AdafruitIO/adafruit_io/adafruit_io.py')
and if you look slightly on top: Checking S3 for https://adafruit-circuit-python.s3.amazonaws.com/bin/mpy-cross/linux-amd64/mpy-cross-linux-amd64-8.2.0.static
my mistake, it's also like 655 of my file not the tmp file
doesn't like this syntax self._post(path, {**metadata, "feeds": feeds_and_data})
move the "feeds" before unpacking the dict, might just work
otherwise. runnin mpy locally will help identify/fix issues
(did for me, at least)
nah tbf it likes the other order fine
Traceback (most recent call last):
File "<stdin>", line 1
SyntaxError: invalid syntax
```this is not accepted by circuitpython, though it's valid in python 3.11.
(and possibly earlier, 3.11 is the version I have handy)
{'feeds': 'whatever'}
```this syntax should work
is the former invalid too if it has a leading normal keyvalue pair, in circuitpython?
you could also some_dict | {"feeds": "value"} (at least on CPython)
** unpacking within {} dict literals is not supported. I don't think it matters if there's a key-value pair before or after it.
yes vertical bar syntax seems to work in circuitpython ```>>> {'a': 1} | {'b': 2}
{'a': 1, 'b': 2}
thanks folks, appreciate the schooling
there's no way to know all these things in advance, but it's good to be aware there are Python language constructs not supported in CircuitPython, and then check by running on a device if it's convenient
FYI, if im not mistaken, | (aka dict.__or__) is just an alias for dict.copy + dict.update
as in... could have used those manually if __or__ didnt work
I assume the dict constructor version is doing similar under the hood. Mainly I didn't like the idea of an unnecessary for loop to update all the present keys. Mental note always try on device even if a PITA
if you dont have to leave metadata untouched, could .update on it
and use it later
yeah, your code above will unpack existing dict, so you end up with {"key": "value", "key2": "value2"} which is (almost?) equivalent to dict(key="value", key2="value2")
I dump an array of dicts into one new field, but yeah similar. I like the metadata.update rather than a copy+update, a good suggestion
beware you can't replace your code with metadata.update
it returns None, not the changed dict
because it edits inplace
thus my "only if you can afford to edit metadata" before
metadata.update({"feeds": feeds_and_data})
self._post(path, metadata)
The crash disappear if I use displayio.release_displays(). I assume this what you called deiniting the display.
I let you close the issue if you think it is enough.
Thanks!
does this look worthy of a PR to the bundle? https://github.com/elpekenin/circuitpython_backports
if so, ideas for anything else that might be a good and not too hard to implement addition?
@spare jacinth Out of all those things, @contextmanager is the one I miss sometimes.
D (31470) lwip: pbuf_alloced_custom(length=150)
D (31475) lwip: pbuf_free(0x3fff3834)
D (31479) lwip: pbuf_free: deallocating 0x3fff3834
D (31484) lwip: dhcp6_information_request: INFOREQUESTING -> -4
D (31490) lwip: DHCPv6 state: 1 -> 2 (dhcp6_information_request)
D (31496) lwip: dhcp6_information_request(): set request timeout 2000 msecs
LWIP_DEBUGF(DHCP6_DEBUG | LWIP_DBG_TRACE, ("dhcp6_information_request: making request\n"));
β¦ err = udp_sendto_if(dhcp6_pcb, p_out, &dhcp6_All_DHCP6_Relay_Agents_and_Servers, DHCP6_SERVER_PORT, netif);
pbuf_free(p_out);
LWIP_DEBUGF(DHCP6_DEBUG | LWIP_DBG_TRACE | LWIP_DBG_STATE, ("dhcp6_information_request: INFOREQUESTING -> %d\n", (int)err));
```It appears `udp_sendto_if` fails with `ERR_RTE = -4,` but of course there is not yet any ipv6 route when you're doing dhcp6!
weird!
('FE80::7EDF:A1FF:FE00:518C', 'FD5F:3F5C:FE50:0:7EDF:A1FF:FE00:518C', (nil), (nil), (nil))
```oh hey we're getting somewhere
π
Ok, yeah, some preliminary tests suggest that the hub is in fact the issue... I remove that and the write-protects almost entirely go away.
While that makes it a much less critical issue, it still leaves open the question of what changed the sensitivity between 8.x and 9.x and is it something that can be addressed or just needs to be documented and worked around?
...before I post logs, should I open this as a new issue?
I can now attempt to connect to a v6 service, but the destination address is incorrect in the transimtted packet.```>>> s = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
s.connect(("fd5f:3f5c:fe50:0:6d9:f5ff:fe1f:ce10", 22))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 119] EINPROGRESS
```D (276442) lwip: IPv6 header:
D (276444) lwip: +-------------------------------+
D (276449) lwip: | 6 | 0 | 0 | (ver, class, flow)
D (276456) lwip: +-------------------------------+
D (276461) lwip: | 24 | 6 | 64 | (plen, nexth, hopl)
D (276468) lwip: +-------------------------------+
D (276473) lwip: | fd5f | 3f5c | fe50 | 0 | (src)
D (276478) lwip: | 7edf | a1ff | fe00 | 518c |
D (276483) lwip: +-------------------------------+
D (276488) lwip: | 3001 | 600 | 5da | 880 | (dest)
D (276494) lwip: | 26 | fe3f | 7085 | 23f |
D (276499) lwip: +-------------------------------+
We can leave it open. It should be easy to guard against this and fixing crashes is always a good idea.
...before I post logs, should I open this as a new issue
It's fine to open a new issue, and then close this as being superceded. That way the new thread will be more on point.
If you have a different hub, you might try that so see if it's that particular hub. I had a cheap USB-C to USB-A hub that disconnected frequently, causing all kinds of problems. Also maybe try the "bad" hub on some non-RPi computer.
Seeing the same thing, I've tried to pull the latest releases of both the adafruit_ble and adafruit_hid too and the same thing occurs. Board is an Unexpected Maker TinyS3.
*** len[0]=28
*** len=28 family=10 port=5632
>>> s.recv_into(buf)
40
>>> bytes(buf)
b'SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3\r\n\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
```OK I actually connected over v6 π really this time
but DNS messes up once I connect to v6... ```>>> wifi.radio.ipv4_dns
10.0.2.76
wifi.radio.ipv6_addresses
wifi.radio.start_dhcp()
wifi.radio.ipv4_dns
253.95.63.92
>>> s.connect(("fd5f:3f5c:fe50::1", 80))
>>> s.send("GET / HTTP/1.0\r\n\r\n")
18
>>> b = bytearray(100)
>>> s.recv_into(b)
100
>>> b
bytearray(b'HTTP/1.0 200 OK\r\nConnection: close\r\nETag: "31e-346-65e90ba6"\r\nLast-Modified: Thu, 07 Mar 2024 00:34:')
>>> s.close()
```you can manually make a request on it, but I think ipv6-address URLS like `http://[fd5f:3f5c:fe50::1]/` are probably not understood by adafruit_requests yet, and it needs to know whether to select `AF_INET` or `AF_INET6`.
CircuitPython version
Adafruit CircuitPython 9.1.0 on 2024-07-10; Adafruit Feather nRF52840 Express with nRF52840
Code/REPL
from adafruit_ble import BLERadio
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement
from adafruit_ble.services.nordic import UARTService
import time
ble = BLERadio()
uart = UARTService()
advertisement = ProvideServicesAdvertisement(uart)
while True:
ble.start_advertising(advertisement)
whil...
@slender iron ipv6 udp socket works, except the host name is not returned for recvfrom_into. raw ntp test: ```>>> ntp_addr = ("fd5f:3f5c:fe50::20e", 123)
PACKET_SIZE = 48
buf = bytearray(PACKET_SIZE)
with socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) as s:
... s.settimeout(1)
... buf[0] = 0b0010_0011
... s.sendto(buf, ntp_addr)
... print(s.recvfrom_into(buf))
... print(buf)
...
48
(48, ('0.0.0.0', 123))
bytearray(b'$\x01\x03\xeb\x00\x00\x00\x00\x00\x00\x00GGPS\x00\xeaA0h\x07s;\xc0\x00\x00\x00\x00\x00\x00\x00\x00\xeaA0n\xeb4\x82-\xeaA0n\xebAU\xb1')
@onyx hinge nice! I think I will need the sender address too
I need to get back to sending packets today. TLV encoding tests are all green atm.
very cool
Fixes #9429
I took this further than I was planning, but these changes do resolve the UART issues when pasting large files into the REPL paste (CTRL-E) mode on ESP32 boards that don't have uart flow control capability.
The first commit simply drops any echo characters when the ESP-IDF indicates the transmit buffer is not available (full?) and does allow the successful paste of large files, howe...
Okay, I'm not sure but I think this CI failure is not my fault :grin:
As I mentioned in #9433, this paste mode feature is not even available in CPython, and I don't think we necessarily have to accommodate boards like this with poor or no flow control. I think the easiest solution for an end user is to rate-limit the paste externally, for example, by using the inter-character or inter-line delays available in tio. If you use paste mode a lot, you can set up your terminal program to include enough delay.
from tio man page:
-o, --output-delay <ms...
Thanks for thinking about this. I would say:
common_hal_busio_uart_write()is used forbusio.UART()in general, so adding specialized features like the negative length hack for this very specific case is not the place to do this. Instead, I would create a specialized path for the console UART when it has no flow control available. It is just an accidental convenience that we have been usingcommon_hal_busio_uart_write()for console writes. It would be better to create a specialized...
I agree completely :grin: I really started just to convince myself there was no HW/SW flow control option and got trapped down the rabbit hole :laughing:
It was really fun getting the pastes to work and echo perfectly though....
One interesting thing that you have anticipated is that upstream, as of MicroPython v1.22, mp_hal_stdout_tx_strn() does return a length rather than being void. I am in the middle of doing that merge and haven't yet looked at why that return value was added.
Yep, I'm good closing this. Thanks for putting up with my visit to Alice's wonderland :grin:
I'm getting a "CIRCUITPY_OPENTHREAD" is not defined error. Where should that be defined?
I added CIRCUITPY_OPENTHREAD = 1 to the Espressif port config which seems to be where the others are defined
probably, from a makefile
makefile != c compiler
so you are likely lacking something similar to: ```mk
C_FLAGS += -DCIRCUITPY_OPENTHREAD=$(CIRCUITPY_OPENTHREAD)
should be easy to find an equivalent configuration and write that correctly, rather than my assumption/guess
possibly, the only define I can find for wifi is in the port config
@RetiredWizard No problem, it's good to think out of the box on this. This issue provoked a discussion internally where we came up with the terminal-program idea.
not sure what you mean by that
but sounds like you were just missing the "glue" from makefile to C (or incorrectly assuming they were implicitly/inherently glued by default - they are not)
I'm trying to figure out where it is
search for $(some_other_config)
found it
but again.. should be quite similar to this
-DVALUE=ERROR being passed to the compiler is equivalent to having #define VALUE ERROR on each and every compilation unit
Whatβs the likelihood that getting an IMX RT1176 to work would be fairly straightforward going off of the current NXP RT implementation for circuitpython?
I think it's mostly a more featureful version of the other RT11xx, so it might be relatively straightforward.
making the second core available in some way is more work
Revised RawSample will not loop unless played with loop=True, otherwise behavior is unchanged. Test code exercises this with an audiomixer with 3 voices. Here's how you run the test for all combinations of single/double buffer and loop/not loop:
>>> mix.play(single_buffer=True, loop=True)
(200, 1, 0)
(400, 0, 1)
(100, 1, 1)
>>> mix.play(single_bu...
I tried ages ago but it was unreliable.
@ornate breach https://github.com/tannewt/circuitpython/commits/imxrt11xx/
I'm thinking of having an openthread.PendingDataset singleton that wraps a dataset and has an openthread.PendingDataset.SetSctive() function that sets the wrapped dataset as active
I could allow creation of multiple dataset instances but that seem overly complex
what was the biggest issue with the port? Is it something that could be managed?
Or do you have a list of things that need to be resolved to make it reliable?
dumb question about class inheritance in CircuitPython -- i've got a 3-deep inheritance that the super-classes own attributes, i get an "AttributeError: 'super' object has no attribute -- is this kind of an expected thing due to the limited memory constraints?
(i don't like posting bugs/issues for things that are "yeah, we don't do that" type items)
@shadow vigil there are some limitations of super() compared to standard python. the one I remember is super() & properties do not work as standard python. and lots of built in classes do not properly support subclassing. e.g., this from micropython docs. we inherit most of the language differences/limitations from micropython, as we don't do a whole lot of work on the core language implementation. https://docs.micropython.org/en/latest/genrst/core_language.html#calling-super-getter-property-in-subclass-will-return-a-property-object-not-the-value
apparently time for plan b -- once i figure out what plan b is π
Property annotations are a 'convenience'. Try without the annotations and use something like .get_prop_name() [or just .prop_name()] instead .prop_name.
and .set_prop_name(value)
For closer to the functionality in the referenced page try this (raw example, not tested in any way):
class A:
def __init__():
self._p = None
def _set_p(self, value):
self._p = value
def _get_p(self):
return self._p
class AA(A):
@property
def p(self):
return self._get_p()
The non-property methods should still inherit, so that structure should work. No super reference needed unless functionality needs to be overridden.
CircuitPython version
adafruit-circuitpython-adafruit_kb2040-en_US-8.2.10.uf2
adafruit-circuitpython-adafruit_kb2040-en_US-9.1.0.uf2
libs:
adafruit-circuitpython-bundle-8.x-mpy-20240716/
adafruit-circuitpython-bundle-9.x-mpy-20240709/
Code/REPL
import board
import usb_hid
import neopixel
import supervisor
from adafruit_hid.keyboard import Keyboard
from adafruit_hid.keyboard_layout_us import KeyboardLayoutUS
US_SAMPLE_TIME = 500
kbd = Keyboa...
thanks, but that's not actually the point -- it's "depth of inheritance": a parent with a child class is fine, a "grand-child" doesn't play nice -- otoh, i'm "only" using single inheritance, so...
CircuitPython version
Adafruit CircuitPython 9.1.0 on 2024-07-10; Adafruit Feather ESP32S3 No PSRAM with ESP32S3
Code/REPL
import time
import adafruit_ble
from adafruit_ble.advertising.standard import SolicitServicesAdvertisement
from adafruit_ble_apple_media import AppleMediaService
# PyLint can't find BLERadio for some reason so special case it here.
radio = adafruit_ble.BLERadio() # pylint: disable=no-member
a = SolicitServicesAdvertisement()
a...
If you power-cycle does that work?
A way to clear the pairing/bonding info so you don't have reinstall is to do:
import _bleio
_bleio.adapter.erase_bonding()
power-cycling does not work. i did not know about erase_bonding() and that did work, thanks!
To compare two ticks_ms values, you should not use <. Instead, when working with ticks values, use ticks_less, ticks_diff and ticks_add. An implementation suitable to cut&paste is show in the documentation, or you can use the adafruit_ticks library.
The starting point of ticks_ms was chosen so that it would "wrap around" soon after boot, so that users would encounter the problem promptly instead of several days after power-on.
There is more information in the documentation...
Its hard to remember. You'll have to try it and see
Okay, itβll be a bit. I actually have to design the hardware first lol.. rt1176 feather π¬
I started a 1060 feather. that's what I'd work on
hello! Looking for help: I have a custom PCB with the STM32H743 on it. Having a hard time getting it to boot into CircuitPy drive.
I can pull BOOT0 High and get it into USB/ DFU but touching the NRST pin to GND does not bring up the drive. I'm on Mac.
Default BOOT0 is low.
π We don't have any adafruit boards with an H7 so it may be broken unfortunately. I'd suggest connecting a debugger and getting a backtrace.
I've read that there might be an issue with the bootloader (I got mine from Nucleo) - so I uploaded v7.0. The latest version is 9.0
which bootloader?
π this bootloader https://circuitpython.org/board/nucleo_h743zi_2/ but then I went here https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/nucleo_h743zi_2/en_US/ and got adafruit-circuitpython-nucleo_h743zi_2-en_US-7.0.0.bin
I have a STMLink, will that work as a debugger?
ah, that isn't a bootloader. that is the circuitpython binary
yes STMLink will work as a debugger
oh! Am I uploading the wrong thing to the board? I'm trying to see a CircuitPy drive
nope, that seems like the right thing
it just isn't a bootloader (a bootloader is separate software that facilitates loading other software)
tinyuf2 is an example of a bootloader
I think your best bet would be to build circuitpython yourself and then use a debugger
so basically build it on mac, upload using STLink, then debug w STLink?
yup. once you build it, then you can add blinks into the early code to see if it gets that far
you'll also have debug symbols
this channel is the best place to get help π
I came immediately to the right place then. Yay!
[adafruit/circuitpython] New review comment on pull request #9421: Add double buffering to RawSample
Need this uncommented? Otherwise, you can remove it.
[adafruit/circuitpython] New review comment on pull request #9421: Add double buffering to RawSample
Do you mean to include this in a later PR? It doesn't seem complete.
[adafruit/circuitpython] New review comment on pull request #9421: Add double buffering to RawSample
nvm. I see you use this as a module
>>> import wifi
>>> wifi.radio.ping("1.1.1.1")
0.021
>>> wifi.radio.start_dhcp()
>>> wifi.radio.addresses
('FE80::7EDF:A1FF:FE00:518C', 'FD5F:3F5C:FE50:0:7EDF:A1FF:FE00:518C', '10.0.3.96')
>>> wifi.radio.dns
'FD5F:3F5C:FE50::1'
>>> wifi.radio.ping(_)
0.014
@slender iron recvfrom & accept, which return different data when v6 packets are in use, kinda break the C API... cpython 3.11: ```>>> s.recvfrom(len(packet))
(b'$\x01\x03\xeb\x00\x00\x00\x00\x00\x00\x00DGPS\x00\xeaB\x8c\xf0\x07y\x93\x15\x00\x00\x00\x00\x00\x00\x00\x00\xeaB\x8c\xf3\xc7"\xf7l\xeaB\x8c\xf3\xc7-\x86\xae', ('fd5f:3f5c:fe50:0:3ca7:8912:9d4:8360', 123, 0, 0))
vs a 2-tuple. ```>>> s.recvfrom(len(packet))
(b'$\x01\x03\xeb\x00\x00\x00\x00\x00\x00\x00DGPS\x00\xeaB\x8d8\x07u\xda\xee\x00\x00\x00\x00\x00\x00\x00\x00\xeaB\x8d;\xe1\xe6\xad]\xeaB\x8d;\xe1\xf5\x1d+', ('10.0.2.74', 123))
I can trample all over it, just letting you know.
np, do what must be done π
What works:
- Getting a v6 address
- Resolving v6 addresses
- Connecting to v6 addresses
- sending to v6 addresses (UDP)
- Pinging a v6 address
presently you have to start_dhcp to get v6 addresses
Addresses & ping:
>>> import wifi, socketpool
>>> wifi.radio.ping("1.1.1.1")
0.021
>>> wifi.radio.start_dhcp()
>>> wifi.radio.addresses
('FE80::7EDF:A1FF:FE00:518C', 'FD5F:3F5C:FE50:0:7EDF:A1FF:FE00:518C', '10.0.3.96')
>>> wifi.radio.dns
'FD5F:3F5C:FE50::1'
...
GAH! I figured it out -- it was a very weird sort of circular reference that was pretty easy to fix by over-riding methods instead of super() calls
the more I've used inheritance, the less I've liked it
it works in languages built for it π
Nothing in the reference document said there were limitations for multiple levels of inheritance. It only showed that @property does not play nice with super(). Can you post sample code with grandchild class that does not do what you expect?
silly names and all π -- but i did realize that i was really not doing this very pythonic, and it was a very poor translation from Kotlin (yep AI strikes again)
Using CPython 3.10.14 and CircuitPython 9.5
Output from your sample code in CPython
Multi-inheritance
static one
middle {'state': 'yah, nope', 'static': 'one'}
upper: {'state': 'yah, nope', 'static': 'one', 'okay': 'cool'}
{'state': 'yah, nope', 'static': 'one', 'okay': 'cool'}
CircuitPython fails with AttributeError.
My Modified code, avoiding use of inherited @property, methods gives the identical result with CPython, and "equivalent" with CircuitPython. Equivalent not identical, because the dictionary elements are being reported in a different order, although the values match. Key reference order is not guaranteed in python for regular dict data type.
Multi-inheritance
static one
middle {'state': 'yah, nope', 'static': 'one'}
upper: {'static': 'one', 'state': 'yah, nope', 'okay': 'cool'}
{'static': 'one', 'state': 'yah, nope', 'okay': 'cool'}
My version of the code. The statical properties of MostbasestClass and MiddleThingie are not needed for this sample, but I left them in, in case instances of those classes want to use them.
class MostbasestClass:
def __init__(self, static_value:str, other_value:str):
self._static_value = static_value
self._state_value = other_value
@property
def state(self):
return self._state_value
@state.setter
def state(self,value:str):
self._state_value = value
def _statical(self)->dict:
print(f"static {self._static_value}")
return {
"state":self._state_value,
"static":self._static_value
}
@property
def statical(self)->dict:
return self._statical()
class MiddleThingie(MostbasestClass):
def __init__(self, static_value:str, other_value:str):
super().__init__(static_value, other_value)
self._yadda = "cool"
def _statical(self)->dict:
v = super()._statical()
print(f"middle {v}")
v["okay"] = self._yadda
return v
@property
def statical(self)->dict:
return self._statical()
class HereItIs(MiddleThingie,MostbasestClass):
def __init__(self, static_value:str, other_value:str):
super().__init__(static_value, other_value)
@property
def statical(self)->dict:
v = self._statical()
print(f"upper: {v}")
return v
print("Multi-inheritance")
h = HereItIs("one","two")
h.state = "yah, nope"
print(h.statical)
HI - I'm building circuitpython and getting an error at make -C mpy-cross, have tried many things.
and error being....?
it works for me running the exact same command from the circuitpython folder... you might need some dependency (perhaps from make fetch-all, perhaps some python lib or somthing, idk)
Right now in rp2040 audio DMA in audiopwmio always proceeds at a rate set by a DMA timer. I've found these to be not precise enough to synchronize with e.g. the ADC pacing timer. It would be helpful to be able to specify a sample rate by reference to another peripheral, i.e. "use whatever sample rate the ADC pacer is set to." One way this could be done is to define some high sample rates as special-purpose codes, e.g. a sample rate of 0xFFFFFF00 would be interpreted as "use the ADC DREQ...
- Verbosity options: any combination of "steps commands rules", as `make V=...` or env var BUILD_VERBOSE
Cannot determine version.
CircuitPython must be built from a git clone with tags.
If you cloned from a fork, fetch the tags from adafruit/circuitpython as follows:
make fetch-tags
make: *** [build/genhdr/mpversion.h] Error 1```
did you do make fetch-tags at the top level of the repo?
by top level, do you mean above the circuitpython folder that I cloned into?
in the circuitpython folder. Looks like you are there now
yes I did
git fetch --tags --recurse-submodules=no --shallow-since="2023-02-01" https://github.com/adafruit/circuitpython HEAD
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
From https://github.com/adafruit/circuitpython
* branch HEAD -> FETCH_HEAD```
yes I still get the error w mpy
I'm following along here https://learn.adafruit.com/building-circuitpython/build-circuitpython
how did you do the clone?
git clone --recurse-submodules https://github.com/adafruit/circuitpython.git
I've re-cloned several times and still get the mpy error. I'm on an M2 mac, but that shouldn't matter right?
you don't need to do --recurse-submodules. We have some make targets for that, that only fetch what you need
what version of macOS are you using?
what does git --version say?
I'm on Ventura, git version 2.45.2
that should be ok
are you using a case-sensitive filesystem, btw?
not sure that's the problem here, but if not, it may be a problem later
have you read https://learn.adafruit.com/building-circuitpython/macos and the rest of that guide?
no, I went straight to building it!
we have pre-built mpy-cross, by the way, here:
https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/mpy-cross/
please do read the guide, there are many prep steps
thanks very much!
web workflow via ipv6
I did read that guide, several hours ago. Anyway, I'm starting over. I have the partition and gmake 4.4.1
i did a fresh clone to check and the right tags are there: git tag will show them. So the problem is the mpy-cross compile.
you may need to say gmake -C mpy-cross instead of make ...
as mentioned in the guide:
If you install the brew version of make, it will be known as gmake.
YES. I forgot to rename it. OK, will try that! thank you thank you!
that worked hurrah!
I would say don't rename, just use gmake as the command name. It will propagate down.
anyway, you are on track!
ok! well, I'm stuck again. I'm trying to build for a chip that Adafruit doesn't use. Its the STM32H743, used on Nucleo
I see the chip in /boards.
make: *** No targets specified and no makefile found. Stop.```
did you cd ports/stm ?
yea
you have to pick a diretory name. the .ld file is not a board name
so I cd ports/stm/boards and tried nucleo_h743zi_2 also
make: *** No targets specified and no makefile found. Stop.
sophikravitz@MacBook-Pro-7 boards % make BOARD=openmv_h7
make: *** No targets specified and no makefile found. Stop.```
do make fetch-port-submodules first, in ports/stm
do gmake not make
rename it back
good looking out, appreciate it
move out of the boards directory
yup
up one, to ports/stm
are you doing your own build to adjust the build?
since there's a build here already: https://circuitpython.org/board/nucleo_h743zi_2/
there is no UF2 bootloader for these boards
you'll have to use the .bin and the ROM bootloader on the board
I have a custom board and the bin from Nucleo isn't showing me CircuitPy drive.
I'm able to connect using STLink and also via USB but the board just wont boot into CircuitPy
we haven't tested these builds for a while, so you could try older ones here: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/nucleo_h743zi_2/
I tried 7.0.0 earlier from this link, I think the latest is 9.0.0
Maybe its my hardware then
Altho, everything else seems to be ok
do you have a nucleo also to test with?
no, but I'll get one. I have an open MV here, but it uses the F version of the H chip
you can add DEBUG=1 to do a debug build with symbols too
unfortunately, the nucleoh743 is obsolete, can't buy it anymore
where do I add that? just after BOARD= ?
yup
i wanted to buy that one too, cos i suspect the builds don't work for the h7
just dropped the 5.1 version from Nucleo and it's not working
so maybe there's an issue with the STM32H743 build. Someone on the STM forum thought that there was
I have never used Circuit Python π€·
I think that build was done by a volunteer. We don't sell a board with that chip, so it's not high priority.
The stm line of chips definitely needs more love in circuitpython π
I'm going to try the H7 on the open MV now
Do you know if it's ok to download it over USB?
you need to use the dfu loader, I assume.
MicroPython has STM32 support, and it was originally for STM chips, so it may have better support. We won't feel bad if you go that direction π
You have the OpenMV Cam H7 ? Could you let me know if the circuitpython image works on it?
That's the only other port using H7, and I'm trying to confirm a theory... but I don't have the board.
9 doesn't work on my Nucleo H743ZI
Does 8? Or other previous versions?
eh, i found a cleaner way of doing what i mostly wanted that wasn't so convoluted -- i realised that the code that was translated by one of the AI generators was messing with me
6 works
I see.... Thank you!
CircuitPython version
Adafruit CircuitPython 8.2.7 on 2023-10-19; Adafruit Hallowing M4 Express with samd51j19
Code/REPL
# SPDX-FileCopyrightText: 2019 Carter Nelson for Adafruit Industries
#
# SPDX-License-Identifier: MIT
import board
import displayio
display = board.DISPLAY
# Setup the file as the bitmap data source
bitmap = displayio.OnDiskBitmap("/purple.bmp")
# Create a TileGrid to hold the bitmap
tile_grid = displayio.TileGrid(bitmap,...
I'm not able to connect to the H7 so I don't think it works
Try CP 6 on your board
The openMV variant that I have doesn't connect to dfu at all / is not recognized by computer - it's OpenMV3 R2 CN-ET-003 OV7725-M7
btw the STM32H743 doesn't connect on Micropython either.
Maybe it's my hardware, I forgot a pullup on DP and soldered it on by hand. If hw is the issue, I'm not sure why it connects on dfu tho.
dfu over usb should indicate usb is ok
although maybe that runs as usb full speed (can it do high speed otherwise?)
I don't know. The only thing I've been able to verify without code is the power and dfu.
I have a stlink π can you point me to docu on this?
and gives you another way to load code besides dfu
yes, but only code in C/C++ right?
ya, some native code
it should help you get circuitpython going though
https://learn.adafruit.com/debugging-the-samd21-with-gdb is my process with jlink
I've not used stlink myself
cool, I'll give it a shot.
Still, if micropython isn't working either...
I'd expect micropython st support to be working
the issue is the hw- I thought that CP communicates over DP and DM. π
@slender iron can you briefly review why IP address objects were useful e.g., with ping? in veesix I did NOT add an IPV6Address object, and I made ping able to take an IPv4/IPv6 string (or actually anything resolvable with getaddrinfo).. I want to make sure this is OK.
Hi, is there maybe someone who owns Adafruit MEMENTO and would be able to help me test some code?
I do not have one myself, and I would like to make sure that the example I want to create for adafruit_httpserver works before creating a PR.
If anyone would be able to help, please DM me. π
This PR contains part of the changes necessary to implement the processing of live sampled audio as described in https://github.com/adafruit/circuitpython/issues/2676. Here analogbufio.BufferedIn is modified to add a loop keyword argument to BufferedIn.readinto(). If called without the keyword or with loop=False, behavior is identical to the current readinto(). If called with loop=True, readinto() sets up chained DMA which continuously writes ADC values into the buffer.
Th...
[adafruit/circuitpython] New comment on issue #9173: Hard fault: memory access or instruction error.
Might be related - Iβm using Xiao ESP32-C3 and using busio.UART to read modbus data from SDM630 energy meterβ¦ after about two days it crashes with hard fault and goes into safe mode. I have the same code (wifi, mqtt, some other logic) except uart running for months on different device without issues. My uart class is very simple - does a write, then waits for 0.1s and does a read. Works for two days, then crashesβ¦ happens very consistently.
Maybe can help you @plucky tulip probably tomorrow night or over weekend. Hopefully someone helps before then
What time zone you on?
Thank you. It is not urgent, also it probably won't take much time, I hope. I am in Europe/Warsaw CEST.
Over weekend would be great.
foamyguy / others: Apologies I've probably asked this before, but is there anything I should be aware of when doing release notes or even releases in general for circuitpython libraries? Just going to push out some changes for Adafruit IO circuitpython library. I'd probably just use auto generate notes and then tweak unless told otherwise.
What time would work for you? I will try to adapt
To be honest no plans yet, most likely I'll be online around when the deep dive stream happens and Tim's Saturday stream at about 4 I'm often around
Great, I will prepare everything before then. Thanks
For libraries, we almost always used the autogenerated notes. The release name should include the version number and a brief summary, e.g. `3.2.1 - Allow busy-wait loop in send to be interrupted"
I dug out my SD card breakout and did some 4-wire testing and it seems to work fine as well. Not surprisingly the 4-wire connections had the same deinit and ctrl-D resetting issue but the deinit is probably pretty easily solved by lifting the changes that Dan referenced. If I have some time, I'll take a look at the board never-reset logic and see if I can make any headway on the ctrl-D not cleaning up the SDIO pins.
There was one additional issue related to the deinit problem that I notice...
Cool, thanks Dan. Sounds similar to my own thoughts. Only tricky bit is squeezing 3 features into one release title. I usually pick one, or cram two occasionally ποΈ or go more generic.
CircuitPython version
Adafruit CircuitPython 9.1.0 on 2024-07-10; Teensy 4.0 with IMXRT1062DVJ6A
Code/REPL
import audiobusio
import audiocore
import board
import array
import time
import math
# Generate one period of sine wave.
length = 8000 // 440
sine_wave = array.array("H", [0] * length)
for i in range(length):
sine_wave[i] = int(math.sin(math.pi * 2 * i / length) * (2 ** 15) + 2 ** 15)
sine_wave = audiocore.RawSample(sine_wave, samp...
I think I was mimicking: https://docs.python.org/3/library/ipaddress.html
OK so an IPv6Address object might be useful as a way for the Python program to interact with the byte-wise data in an ipv6 address...
D21 is GPIO_AD_B1_11 and is muxed to RX_BCLK. Our current I2SOut assume it connects to TX_BCLK. I'm not sure how to use RX_BCLK when transmitting. GPIO_AD_B1_14 is TX_BCLK and D26 on the teensy4.0.
You can cross reference the pin mux info with the board pin mapping:
https://github.com/adafruit/circuitpython/blob/2f626121867efa429b7484fa3ca5a315021cc506/ports/mimxrt10xx/peripherals/mimxrt10xx/MIMXRT1062/periph.c#L219-L265
https://github.com/adafruit/circuitpython/blob/2f626121867efa42...
One super minor doc thing. Looks good otherwise. Thank you!
//| def readinto(self, buffer: WriteableBuffer, loop: bool = False) -> int:
@slender iron should I have start_dhcp_client_v6 and start_dhcp_client_v4? with the existing start_dhcp_client .. starting both? and both starting by default when bringing up the interface?
maybe start_dhcp_client with two kwargs that default to true?
sure
thanks!
Problem found by @Erland in discord, while testing against a commercial device under development.
A simple BLE UART (NUS) service central could not receive notifications from another device.
I was able to reproduce this using an nRF52840 acting as a NUS central and an ESP32-S3 acting as a NUS peripheral. nRF52840 to nRF52840 worked OK.
Test programs:
central
from adafruit_ble import BLERadio
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement
f...
- Fixes #9440.
See #9440 for test programs.
Debugged by looking at packet traces with nRF sniffer and printing out SD BLE events. The symptoms were that the connection and discovery seemed fine, but the notification events, BLE_GATTC_EVT_HVX, never arrived at the event handler in Characteristic.c. After a few seconds the connection was broken.
MTU negotiation seemed fine, but someone reported something slightly similar in Nordic DevZone, and the suggested problem was that some n...
Makes sense, didn't test
I am having issues with ```#
OpenThread
CONFIG_OPENTHREAD_ENABLED=y
end of OpenThread```
not being copied from sdkconfig.defaults to the generated esp-idf config. I"ve tried running make clean and deleting the build directory
make menuconfig has no openthread options despite the openthread component existing in the esp-idf source folder
Great, I will prepare everything before
I wonder if https://github.com/adafruit/circuitpython/pull/9441 has anything to do with @lone axle 's BLE problems trying to do circup file transfers
this was a specific problem with nordic. Were those problems with espressif or nordic?
I guess I don't know. I just recall that some simple operations would work but bigger operations would hang for no clear reason.
I don't know which MCU tim was testing with, either
i have other known problems to debug now too π , so I can look at those
Based on @berkut0's and others' testing I'm going to close this. @aivarannamaa if you still see this we can reopen it.
Any ideas on why esp-idf seems to be ignoring the openthread component?
I tried finding it too, and could not. There is an openthread/Kconfig. I tried "A" ahd "/" in menuconfig, and it couldn't find anything. I looked for a list of components somewhere and couldn't find that either. I did some websearching about this but that was also unusccessful.
Thanks for trying, at least I know it's not just me now. That's pretty much what I tried too. I also tried adding ESP_IDF_COMPONENTS_LINK += openthread to ports/espressif/Makefile with no noticeable change.
@stuck elbow hi, a user wrote to us and noted that http://circuitpython-stage.readthedocs.io/ is broken right now. The builds are failing for some reason. The link from https://learn.adafruit.com/circuitpython-stage-game-library/documentation is how they found that out.
I noticed it a week ago too, but I've been down with covid since. I will look into it as soon as I can. Thank you for the notice.
fixed
CircuitPython version
Adafruit CircuitPython 9.1.0 on 2024-07-10; Adafruit PyPortal Titano with samd51j20
Code/REPL
any
Behavior
none
Description
No response
Additional information
Based on someone having an issue in Discord with their PyBadge board, I also tested on my PyGamer, and PyPortal Titano, and they all have the same behaviour.
The screen is completely black as soon as CP 9.1.0 is installed.
There is no visible splash s...
The fix was tested by @Erlend in discord and fixed their problem.
Thank you! I hope you are feeling better.
π I will try this out on a newer version from after this PR is merged. Thank you!
I'll try to distill it into a smaller reproducer if I can once I get back to it as well. If I manage that I'll submit an issue with it. Though some part of me fears that I'll strip out the layers of Click and the circup "Backend" architecture and then not have the same problem.
I just tested a few of the recent releases and found that 9.1.0-beta.3.uf2 is the most recent beta that allows the display to function properly on the PyPortal Titano at least. beta.4 has the same issue with display remaining dark as 9.1.0 release.
"removed definition of board_display_obj" is a pygamer-specific change after 9.1.0-beta.3
but that removal looks so sensible
I noticed an issue other the weekend for a DisplayIO Driver Library (SSD1322) that wasn't updated for the newer displayio API changes where displayio.Display became busdisplay.BusDisplay
I checked the rest of the bundle and found there are 4 such drivers in need of updates still and a small handful of helper libraries that need docstrings and/or type annotation updated but should function AFAIK.
Looking into that this morning I've found we have 8.x / 9.x compatibility code in a number of the other display driver libraries i.e. https://github.com/adafruit/Adafruit_CircuitPython_SSD1325/blob/main/adafruit_ssd1325.py#L33
Is it okay to go ahead and remove that compatibility fallback and just update to the newer code? If so I can submit PRs today for that change along with the fix for the ones using the old version only.
I think 8.x is still "in the bundle" so probably not yet.
@lone axle thanks for the sleuthing about the pyportal/pygamer display problem. do you want to continue by "bisect"ing or is that as far as you go?
I'd be happy to bisect it further between beta.3 and beta.4 to try to find the one where it changes.
With regard to my issue:
The pico was connected directly to the Dell 490 - I tried both front and rear USB ports.
I have also tried the Pico on a Dell 6400 Inspiron laptop - similar set up to the above Dell 490 (Win 10 Pro 22H2 x64, Raspberry Pi Desktop VM running under VMware 12.5.x Player).
In all cases the Pico mounts (in the Raspberry Pi Debian 11 VM) as ReadOnly.
I've narrowed this down further. On the Pyportal Titano the last build that runs successfully is:
And the first build where the display stays dark is the next one:
[PR9343-cbd5131.uf2](https://adafruit-circuit-python.s3.amazonaws.com/bin/pyportal_titano/en_US/adafruit-circuitpython-pyportal_titano-en_US-202406...
>>> wifi.radio.ping("ipv6.google.com")
0.048
>>> wifi.radio.addresses
('FE80::7EDF:A1FF:FE00:518C', '2001:470:3996:0:7EDF:A1FF:FE00:518C', '2001:470:7C:285:7EDF:A1FF:FE00:518C', '10.0.3.96')
I forget who reminded me of the existence of ipv6 tunnels so that I could test this
but hug report to you
- I didn't find the esp-idf API for v6 netmask & route equivalent, so not adding it at this time
- adding & removing addresses is unclear as well (there's esp_netif_add_ip6_address but it is defined as an event handler) and there's not currently a use case
- though ipv6 AP would need .. something
- v6-only networks also left for future
- need to test raspberrypi & add ping-by-string there
Other modules & libraries may need to be updated. For instance, do adafruit_requests & adafruit_ntp work properly with v6 addresses & names? Since our focus is on v6 for matter support, I did not investigate this or file issues.
@kind river did you add it to the CP CMakeLists file?
This adds CircuitPython missing boards and Blinka missing boards.
<@&356864093652516868> Just under an hour until our meeting. Excited to chat with you all. Notes doc is here: https://docs.google.com/document/d/1cvCxFaJT5hIQ4UmzZm6f_betgOKNhtXJrsA4GYdVeQ4/edit?usp=sharing
The raspberrypi port's socket implementation is largely taken from micropython. micropython recently added v6 support: https://github.com/micropython/micropython/issues/12600 and we can study / incorporate it to get our own v6 support
note this might not actually fit this on the pico w because its firmware space is small and nearly full already. so this is not a big priority right now!
good news! this does seem to set ipv6 mdns records:
$ avahi-resolve -6 -n cpy-00518c.local
cpy-00518c.local fe80::7edf:a1ff:fe00:518c
huh v6 support might only cost around 32kB, possibly actually feasible to add to pico w if it's that small.
@slender iron https://github.com/adafruit/circuitpython/commit/109bcafd072bd94a9eef4e4d06657efa4a112b0e#diff-d695723d1b6e886103267211b0f1867a65f2e83cf0e8fb1ac639c54828550859 -- I don't see a PR with this change
**to all folks making PRs: **I just created branch 9.1.x on adafruit/circuitpython. If you are submitting a bugfix PR, do it against 9.1.x. New features can go against main.
yup, I must have forgotten
we can do this against 9.1.x now. I can make a new PR. I will check the other inky frame too. Don't bother to make a PR.
π thanks!
fan noise seems fine, did hear the sirens though
Full title: Connecting Old to New with CircuitPython: Retrocomputer input devices on modern PCs
Presented by:
Jeff Epler
The input devices of decades past hold nostalgic value for many folks. But they don't need to merely sit on a shelf as museum objectsβthey can be reverse engineered and then adapted to modern computers without modifying the ...
π
I've been playing around with ViperIDE this weekend, it's pretty neat
Just adding this here in case anyone stumbles over this issue like I did:
My SAM E54 Xplained Pro (ordered July 2024, SST26VF064B QSPI flash chip dates to sometime in 2021 so I guess this issue has been around for some time already) has the same issue as @tomiahola described. The issue can be observed for all CircuitPython builds that include the above commit from #8054.
No response from the board, neither CIRCUITPY or USB Drive appears, and no COM port is detected.
Previous builds of C...
Reopening since this sounds like it is still a problem.
Pypi is optional
When you run cookie cutter it will ask you yes or no if you want to deploy to pypi
I was looking to create a library but found someone else beat me to it
https://github.com/iorodeo/iorodeo-as7331
Thanks IORodeo for this. Worked great for UV sensor
Thanks for hosting Scott. Have a great week everyone.
np!
Here is the notes document for next Mondayβs CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1B3UNUMkUamVZ9-aSAbCf8csy48K5ER-eUjna9yU6Arc/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for July 29th, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you canβt make the meeting and would...
Does the board come back up in safe mode? Or is it just USB that is reset?
It does not come back in safe mode. It looks like this:
[15:58:35.446] tio v2.7
[15:58:35.446] Press ctrl-t q to quit
[15:58:35.446] Warning: Could not open tty device (No such file or directory)
[15:58:35.446] Waiting for tty device..
[15:58:43.551] Connected
[***typed ctrl-C***]
Traceback (most recent call last):
File "code.py", line 17, in <module>
KeyboardInterrupt:
Code done running.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPyth...
I tested, and the changes in #9343 are the ones breaking the display.
Specifically, removing the 2 while loops, while (tc->COUNT16.SYNCBUSY.bit.CC1 != 0) { } and while (tcc->SYNCBUSY.reg != 0) { }
Based on the datasheet, these delays seem to be necessary before you can do the other register operations.
@lone axle I think it is too early to switch to the split displayio layout in libraries. Blinka displayio tries to support it but isn't quite right
BusDisplay needs to be updated to import BusDisplay as Display
Hi @timchinowsky: #9343 is your PWM fix. It's breaking backlight control on boards like PyPortal, causing the display to remain unbacklit. Not sure what the PWM change that's causing this is. I will revert this temporarily for a 9.1.1 release unless you think you have a quick fix.
Most of the display drivers have code that is compatible with both BusDisplay and displayio.Display: https://github.com/adafruit/Adafruit_CircuitPython_SSD1325/blob/main/adafruit_ssd1325.py#L33
Do we want to have that same compatible code in the 4 that don't have it currently?
Or just leave it as-is for now, but I think if we don't make a change anywhere then those 4 display drivers are un-usable in some contexts, Blinka_DisplayIO I think, but still work in the core perhaps.
A user reporting not being able to use one of those display drivers here https://github.com/adafruit/Adafruit_CircuitPython_SSD1322/issues/21 which is what led me down this path. I'm happy to do whatever remediation is best at this time.
I think fixing blink_displayio would be my preference. that will make it match CP 9
Thanks for the tip! The component is being included now but openthread/dataset_ftd.h still isn't found.
did that fix menuconfig? to fix headers you will need to edit the Makefile where it has -isystem paths
(we don't use cmake for the CP side of the build)
@onyx hinge do you have avahi working but not .local lookup in your browser?
@slender iron I don't really know what the deal is. Trying to use .local has never worked reliably for me, so I mostly don't even try anymore. /shrug
avahi has a step to connect it to domain lookup on arch: https://wiki.archlinux.org/title/Avahi#Hostname_resolution I use resolved for domain look up so it does the mdns queries
[adafruit/circuitpython-org] Pull request review submitted: #1436 Add latest round of missing boards
One weird filename. Looks good otherwise. Thanks for adding these!
@onyx hinge I think this is waiting your follow up review: https://github.com/adafruit/circuitpython/pull/9427
looking, thanks
I'll review your ipv6 changes next
Menuconfig is working but adding -isystem esp-idf/components/openthread/include doesn't seem to
shared-bindings/openthread/PendingDataset.h
CircuitPython provides this at exception.print_exception(), with improved compatibility with standard Python.
This is an alternative to #9472, which adds documentation for the non-standard function.
One reason NOT to take this change is that the traceback module is not built on samd21s, leaving non-standard sys.print_exception as the only way to print an exception object (besides raising it)
hrm. I'd expect adding the -isystem addition to work. maybe the path isn't exactly right? I use fd to find where a header is in the esp-idf tree
This is fine if it's green (I tweaked the markup so that traceback and traceback.print_exception would become hyperlinks). However, we might also just choose to remove this non-standard python extension: https://github.com/adafruit/circuitpython/pull/9446 and should consider which to do.
@slender iron maybe you can decide whether to delete or document, I created a PR #9446 to duel with #9427 π
k, let me finish your review
A few questions. It all looks pretty good. Thanks for figuring this out!
How would you determine this in CPython? Should it be on Radio or SocketPool (if CPython's socket has a way to detect it.) I'm thinking ahead to having a thread network interface that is ipv6-only (I think.)
Why not use this all of the time?
I looked in the bundle and in the Learn Guide code, and sys.print_exception() is only used in code that runs on larger boards. It is used, so the few places it's used should be fixed to used traceback.
libraries/drivers/mcp2515/examples/mcp2515_canio_test.py
libraries/helpers/debouncer/examples/debouncer_unittest.py
I think I am OK with samd21 not being able to print tracebacks "manually". There are so many other things limited in that port, this is not such a big deal. You can still print info about the exception.
Let's remove in CP10 and add a FutureWarning now because code can be moved to traceback now. (I assume traceback is in 8.x too.)
The actual openthread libs were in openthread/openthread/include. Now I'm getting error: 'mbedtls_ssl_set_hs_ecjpake_password' was not declared in this scope
that may be behind a setting
Does anyone know if it's possible or how to specify requirements for a cookiecutter template?
In one of our cookiecutter hooks we use pkg_resources for parsing semantic versions: https://github.com/adafruit/cookiecutter-adafruit-circuitpython/blob/251be2cfd205b427ae7807d08a40695ef3353b04/hooks/pre_gen_project.py#L6-L12 but in python 3.12 this is deprecated or removed and doesn't work (at least in my environment) so the cookiecutter fails after asking all of it's prompts.
I have found that https://pypi.org/project/packaging/ exists and seems to implement the same functionality so in my local branch I've changed the code to use that and it works if I manually pip install packaging but ideally we'd want cookiecutter to install that whenever the user runs cookiecutter gh:adafruit/cookiecutter-adafruit-circuitpython I tested it with my own branch and it fails if I don't manually install that package. I tried adding a requirements.txt thinking that might do it, but it doesn't seem to have made a difference.
Or as an alternative the code could be simplified to parse "manually" with string split and int() and then compared to the minimum version. As far as I understand it this code looks to just be enforcing a minimum version which does feel like a bit minimal to be requiring an external module for.
yep, menu config option for mbedtls. everything is compiling now
Honestly I don't think that mechanism for enforcing the minimum version is actually effective. I installed cookiecutter 1.7.3 which is lower than 2.1 and when I try to run it I get a stacktrace explosion about a filename being too long and it never prints the error from our hook.
good question. I don't think there's a look-before-you-leap "is there working ipv6" check in CPython.. However, in CPython with no ipv6 global connectivity, a v6 connect() to an internet address will promptly fail:
>>> s.connect(("ipv6.google.com", 80))
OSError: [Errno 101] Network is unreachable
If the OS lacked even support compile-time for V6 sockets at all then the socket module can lack the AF_INET6 definition:
#ifdef AF_INET6
ADD_INT_MACRO(m, AF_INET6); ...
I can drop these properties if they're not useful. I really only added them so that the documentation could show a "correct" default parameter for start_dhcp_server, by showing the constant supports_ipv6 instead of a literal True or False which would be incorrect
To start up code.py with IPv4 only, are these the required steps (with PR#9436?```
import wifi
wifi.radio.stop_dhcp_client()
wifi.radio.start_dhcp_client(ipv4=True, ipv6=False)
I have to admit I did not test this. In principle, just the 2nd call is needed, because it stops whichever one(s) are not requested. ```c
void common_hal_wifi_radio_start_dhcp_client(wifi_radio_obj_t *self, bool ipv4, bool ipv6) {
if (ipv4) {
esp_netif_dhcpc_start(self->netif);
} else {
esp_netif_dhcpc_stop(self->netif);
}
#if LWIP_IPV6_DHCP6
if (ipv6) {
esp_netif_create_ip6_linklocal(self->netif);
dhcp6_enable_stateless(esp_netif_get_netif_impl(self->netif));
} else {
dhcp6_disable(esp_netif_get_netif_impl(self->netif));
}
#endif
}
π the increasingly inaccurately named `start_dhcp_client`
https://github.com/adafruit/circuitpython/pull/9436/files#diff-45099aee9920055cc86eca6488ba14d43010cf831c6083a9da55680ef8dc5fecR696 uhmmm I shoulda finished writing the docs I guess
do we know if the espressif implementation uses the RFC 4941 βprivacy extensions"?
if not, I would suggest not starting IPv6 by default
I do not have a strong opinion about what the default should be. Now is the time to influence that choice. I do not see any signs via full text search of rfc 4941 support, though I also don't know in detail what that is (I know it has to do with not linking global IPv6 address to hardware address, but that's just a very general level of knowledge)
I don't have an in-depth understanding of it either, but I am concerned (and suspect some others would be as well) if their microcontrollers are permanently and globally identifiable
Please raise this on the PR even if it's just a quick comment!
I don't have an in-depth understanding of IPv6, so I could be off-base on this. Do we know if the espressif (and eventually, the raspberrypi) implementation uses the RFC 4941 IPv6 privacy extensions? If not, I'd suggest not starting IPv6 by default. Some users may be concerned if their microcontrollers are globally identifiable.
Almost there, getting undefined references to the coex functions
I'm happy to change this to default v6 off until we understand the ramifications better. @tannewt say the word
- Fixes #9443.
Reverts PWMOut.c code changes from #9443 to restore screen backlight functionality on SAMD51 boartds.
The code changes in #9343 were reverted by #9447, because they broke screen backlighting on SAMD51 boards like PyPortal (and maybe other PWM things as well), as reported in #9443.
The intention of #9343 is good, but it needs to be fixed.
Note that #9343 did not affect backlighting on Hallowing M0, so I'm guessing the #9343 changes were OK for SAMD21 but not SAMD51.
@timchinowsky I hope you are able to take a look at this. Thanks.
Found this:
DHCPv6 in lwIP is very simple and supports only stateless configuration
This is probably the original SLAAC mechanism, and may be a permanent address embedding the hardware MAC address (could be verified with testing).
Thanks for the fix. We can include the newer changes with another fix in main for 9.2.
Yes, thanks for reverting, I am planning to investigate with PyPortal.
The symbol font Fork Awesome that is used in some Adafruit guides and that I was introduced to via Adafruit devs is unfortunately showing a deprecated notice on their Github. https://github.com/ForkAwesome/Fork-Awesome I'm not sure how that might affect some Adafruit projects or if the project will be deleted someday. Might be worth a dev having a quick look into it to see if there are any implications for adafruit guides. I have been using the font for some of my recent projects and I don't even know what it means. As long as the font file is included in the bundle for any learn guides then it should continue to function normally, my guess is there simply will not be anymore future revisions to fork awesome.
[adafruit/circuitpython] New tag created: 9.1.1
Includes #9447. Previous post-9.1.0 changes were already on main before the 9.1.x branch was made, so they are not in the commit list.
Automated website update for release 9.1.1 by Blinka.
Hi @dhalbert, everything seems to be working properly and I would appreciate if you could merge this PR. Thank you!
Hi - the headers of the files for boards have changed recently. Could you look at typical board files at the tip of main and redo the headers in these files to match those? Thanks.
The license and copyright lines have been replaced with SPDX-style lines. The files that previously had no header lines now do have header lines.
Great, thank you! This will be merged to main and will go in the first 9.2.0 alpha or beta release.
Thank you very much for your help!
[adafruit/circuitpython-org] Pull request review dismissed: #1436 Add latest round of missing boards
One weird filename. Looks good otherwise. Thanks for adding these!
https://blog.adafruit.com/2024/07/22/circuitpython-9-1-1-released/
A few fixes, most notably backlight fixed on SAMD51 display boards.
thanks for making that release @tulip sleet -- good to have the display big fixed
you're welcome - it was a bad thing to have broken boards
This is fine if it's green (I tweaked the markup so that traceback and traceback.print_exception would become hyperlinks). However, we might also just choose to remove this non-standard python extension: https://github.com/adafruit/circuitpython/pull/9446 and should consider which to do.
Well I didn't expect git to interpret that update as a review dismissal π€·
any time you push something it will dismiss an approval (since there's a change)
Note that https://github.com/adafruit/circuitpython/pull/9343 did not affect backlighting on Hallowing M0, so I'm guessing the https://github.com/adafruit/circuitpython/pull/9343 changes were OK for SAMD21 but not SAMD51.
After further testing, it looks like the backlight breaking change was only the removal of the first while loop ( while (tc->COUNT16.SYNCBUSY.bit.CC1 != 0) {} ), the second loop had no effect on the display.
The first while loop is in a SAMD51 specific section of the...
We noticed that we couldn't find these two boards by searching for "ESP32-C3" and "ESP32-C6".So it needed a change in the title of these two boards, changing "ESP32C3" to "ESP32-C3" and "ESP32C6" to "ESP32-C6". Thank you!
My main need would be the Adafruit web libraries like the adafruit_httpserver
and the USB/web workflows.
Relying on frozen modules in Micropython for run-on-boot capability doesn't even come close to the convenience of the CircuitPython USB worflow imho.
Zephyr OS offers very easy portability and very wide hardware support. Especially Ethernet support (for internal MACs) is one major feature that is missing fr...
We go by the manufacturer's name, and Seeed chooses not to include the hyphens. So I don't think we should change these names. There are other boards with similar non-canonical names, such as the "Lolin C3 Mini" or Unexpected Maker "TinyC6". We would not change the name of the "TinyC6 "to the "Tiny ESP32-C6".
So I don't think we should take this PR, sorry.
If you search for "C6", you can find the board. You can also click on "Filters" and choose "esp32c6" as the Processor family.
Thanks. We need to remember to remove this in the main branch, now, but it's also nice to have the other non-applicable docs removed.
I apologize for not making my personal information clear, I do in fact work for seeed, and this change was agreed upon!
I apologize for not making my personal information clear, I do in fact work for seeed, and this change was agreed upon!
I apologize for not making my personal information clear, I do in fact work for Seeed Studio, and this change was agreed upon.
Best Regards,
Carla
@Carla-Guo Thanks. Are you going to change the product names on your website too? Or is this only for getting the search to work on https://circuitpython.org ? If we had a different search mechanism that matched "ESP32-C3" with "ESP32C3", would you be requesting this change? I am concerned about the inconsistency between the official name and the name we are using here.
I think many people would just search for "C3" or "C6", and then the boards would be easily found.
@dhalbert Thank you,
Yes, this is just for getting the search to work on https://circuitpython.org/, and if there is different search mechanism that matched "ESP32-C3" with "ESP32C3",we will not request this change, and if you can do that mechanism, it's much appreciated!
- Addresses #1438
Some boards uses a hyphenated name for the microcontroller chip or other feature, and some do not. Right now the search will give different results in the two cases. For instance, searching for "ESP32C6" yields different results than "ESP32-C6".
This change makes the match ignore hyphens, producing a more inclusive search.
We used to use a regexp, which would have made for an easy fix, but that was too slow (see #1328), so this is "hand-coded".
Tested locally.
...
This idea came up again to me while doing #1439. The "Processor family" values right now are inconsistent in level of detail: "esp32c6" exists, but not "samd51", only "atmel-samd". Searching for "samd51" does not bring up Metro M4, for instance, only boards with "SAMD51" in their board name.
makes sense. hopefully it doesn't affect speed too much.
@slender iron do you want ipv6 to default on or off? and did you want the "supports_ipvx" constants removed? I'm eager to update that PR so it can be reviewed again.
default off is fine with me if there are security concerns. ya, I'd remove the constants because they don't match CPython
I can do that -- but did you catch that the constants are on the wifi module not the socketpool module/object?
(the circuitpython enabling define says SOCKETPOOL but it affects stuff across wifi & socketpool both)
ya. I think it'd be better to test in a way that matches CPython
OK
I don't want to move to ninja anymore. Ideally it'd be an all-Python build system. No reason to have an issue for this work though.
I'd be happy to review and merge a Zephyr port of some sort. I'm still concerned that Zephyr isn't dynamic enough to build CP on top of. (Pin muxing is the main example.) I'd be happy if someone could prove me wrong.
Weird! You could use UART debugging to try and sort it out.
OSError: [Errno 97] Address family not supported by protocol makes sense to me. One can always catch it.
I can drop these properties if they're not useful. I really only added them so that the documentation could show a "correct" default parameter for
start_dhcp_server, by showing the constantsupports_ipv6instead of a literalTrueorFalsewhich would be incorrect
I wouldn't change the default based on functionality. Code will run different on different platforms then.
I'm happy to change this to default v6 off until we understand the ramifications better. @tannewt say the word
Default off is fine with me. That'll make its use explicit which will make more sense if we throw an exception to say it is unsupported.
@jepler Can you add the warning? RetiredWizard's PR only updates the docs.
It isn't in CPython and we've had the traceback module since at least 8.2.x.
Thank you! #9451 filed to remember to remove it in 10.
Great minds think alike.... :grin: #9450
Thank you! Sorry I missed this.
This idea came up again to me while doing #1439. The "Processor family" values right now are inconsistent in level of detail: "esp32c6" exists, but not "samd51", only "atmel-samd". Searching for "samd51" does not bring up Metro M4, for instance, only boards with "SAMD51" in their board name.
Hmm, yeah. I think the reason we have the ESP chips more granular is because for chips like ESP32-S2 and ESP32-S3, we have a bootloader available, but for chips like the ESP32-C3, we don't.
We have merged #1439. Try searching for esp32-c6 now in https://circuitpython.org/downloads. You should see the Seeed Studio board. You may need to do a shift-reload in the browser to get the new Javawscript.
@hathach This is odd: MSC is mounting read-only in CircuitPython 9 when using a VM or when using certain hubs. Do this ring any bells for you related to some TinyUSB update?
There was a backlight problem on SAMD51 boards in 9.1.0. It is the likely cause of this bug: see #9443. This has been fixed in 9.1.1 in #9447.
I'll close based on that. If it's still not working for you with 9.1.1, please reopen.
Sorry, out of town unexpectedly and haven't been able to grab any logs yet or test with other hubs, but to add:
The specific hub I am having issues with is the D-Link DUB-H7 (https://www.amazon.com/D-Link-DUB-H7-7port-Usb-2-0/dp/B00DMLTG3G/). I haven't been able to test with other hubs, but should be able to in about a week when I return home.
Reverting to CircuitPython 8.x and using the hub works as expected (i.e. write-protect off for fresh CP install with default initial filesystem)...
OK, default is now off, non-standard attributes in wifi module are removed, and attempting to enable v6 dhcp when not supported gets an exception.
thank you for the merge @slender iron ! I look forward to seeing what you can get done with Matter over the next weeks while I'm away.
@slender iron @onyx hinge shall I make a 9.2.0-beta.0 yet?
how is the MP merge coming? I'm not sure 9.2 has much for folks to test in it
good point, I should probably wait for that at least. Not even ready to try to compile yet.
I want to fix some more bugs too
I'm not ready to run the matter stuff on CP anyway
I tried this on a CLUE, and could not reproduce. I uploaded its bootloader to 0.9.3, still could not reproduce. Then I did _bleio.adapter.erase_bonding(), and now I can reproduce. So something about having totally empty bonding is causing the problem.
The display on the CLUE shows that it is doing a hard restart.
the openthread binding is compiling but crashing due to memory access. need to brush up on my C
- Fixes #9442
bleio_user_reset() was trying to do SoftDevice operations after the Adapter was disabled, causing NRF_ERROR_SOFTDEVICE_NOT_ENABLED, which tried to raise an exception after the VM was shut down. Check before trying to do these operations.
CircuitPython version
Adafruit CircuitPython 9.1.1 on 2024-07-22; Adafruit QT Py ESP32-S3 no psram with ESP32S3
Code/REPL
from time import monotonic, sleep
from board import NEOPIXEL, NEOPIXEL_POWER
from neopixel_write import neopixel_write
from digitalio import DigitalInOut, Direction
np = DigitalInOut(NEOPIXEL)
pwr = DigitalInOut(NEOPIXEL_POWER)
np.direction = Direction.OUTPUT
pwr.direction = Direction.OUTPUT
pwr.value = True
epoch = monotoni...
Do you have boards with othert chip families (e.g. RP2040), or do you have an ESP32-S2? Do they have the same behavior?
I have not noticed this happening on my RP2040 board or my SAMD21 board
the ESP32 boards I have are all ESP32-S3
CircuitPython version
Adafruit CircuitPython 9.0.5 on 2024-05-22
Code/REPL
https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer/tree/main/examples/httpserver_start_and_poll.py
Behavior
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
main.py output:
Started development server on http://192.168.20.147:5000
192.168.20.108 -- "GET /" 355 -- "200 OK" 82 -- 27ms
Code stopped by auto-reload. Reloading s...
... It is invalid to connect the external pull-up resistor, and the manufacturer must add a pull-up resistor inside. ...
Glad it is working! Could you explain what you meant by "invalid" above?
Adding an external pullup resistor to the motherboard does not make the touch screen work, but using a touch screen with an internal pullup resistor added by the supplier does.
For updates to an existing board, which branch should we fork from? main ? or 9.1.x ?
9.1 if you want it released as stable soon
Thanks. I will fork branch from the 9.1.x for this minor change.
and then set 9.1.x as the base in the PR if it does not do that on your PR push
@slender iron were you thinking of reviewinghttps://github.com/adafruit/circuitpython/pull/9453 or should I just merge it?
I don't need to review it
This was merged into 9.0.x, not 9.1.x !
adding board identification to support the newer SSD1681 displays (both BW and BWR)
Following Adafruit's lead in switching from SSD1608 to SSD1681 while supporting both old and new hardware
@snkYmkrct @FoamyGuy thanks for your testing and diagnosis! I am trying to reproduce what you are seeing and unfortunately so far everything is working fine for me on a PyPortal Titano with 9.1.0. Can you send me the libraries and application code that you are using?
Not sure if this belongs here, but I'm having trouble being able to copy into and delete files from my CIRCUITPY folder on my Macropad. How do I fix it? I am running MacOS SOnoma 14.5
I think that should go to #help-with-circuitpython, but the short answer is that it's up to Apple to fix it
The problem was originally identified because someone on Discord was trying to run this project Blinka Jump on the PyBadge, and the screen was all black. Same when I tested on the PyGamer board.
But the code is irrelevant, the display goes black on all boards (including the Titano) as soon as the CP version 9.1.0 is installed. There is no splash screen, and it's not showing the serial.
everything is working fine for me on a PyPor...
I looked at the display initialization on both boards. They are mostly the same but the PWM frequency differs:
pyportal:
50000); // backlight pwm frequency
pyportal titano:
500); // backlight_pwm_frequency
@snkYmkrct see video: https://github.com/user-attachments/assets/75904714-98ef-48c6-a600-75375f696a63
@dhalbert thanks, I'm thinking there's something timing-related going on. In the __init__.py it ramps the PWM up and down, and the behavior of something like that will change a little bit when you change from blocking to non-blocking. But so far it is working just fine for me, at both 50000 Hz and 500 Hz. Using libraries in .mpy format except for adafruit_pyportal which is in `.p...
I see the problem with no code.py. The screen is black: no terminal output is showing.
I believe you might be able to run the regular pyportal UF2 on the Titano, and you'll just see a smaller display.
What is the expected behavior with no code.py? Where does the display init take place in that case?
It's done before the VM runs, so it can display the startup text and REPL output.
I can create an instance of { mp_obj_base_t base; otInstance *instance; otOperationalDataset *dataset; } openthread_pending_dataset_obj_t; but when I try to access it, I get Hard fault: memory access or instruction error.
(on the C side)
how do you create the instance?
openthread_pending_dataset_obj_t openthread_pending_dataset_obj;
and how are you accessing it? Are you copying some idiom from somewhere else?
you could point me to your repo
got it, so where are you getting the hard fault?
on any access of openthread_pending_dataset_obj
i don't see the declaration in your repo, it is all from 4 days ago
looks like push is silently failing
so I am
anyway, I'm looking at main right now. Assume you will want to reset --hard main after pushign this stuff to the branch
yes
so are you saying that just typing openthread.pending_dataset into the REPL is crashing?
yes
in common_hal_wifi_init(), there is this, for instance:
common_hal_wifi_radio_obj.base.type = &wifi_radio_type;
do you set the type somewhere?
That's probably it
i think the pointer to the obj is fine, but stuff in the object isn't initialized
if we are not merging 9.0 up into 9.1 then this makes sense.
if we are not merging 9.0 up into 9.1 then this makes sense.
Thanks. 9.0.x is quiescent: I won't be making any more 9.0.x releases.
everything should be initialized in openthread___init__
I'm seeing that inserting a delay before the call to common_hal_busdisplay_busdisplay_set_brightness fixes it. Line is here:
2 ms doesn't do it, but 3 ms does, which makes sense for the 500 Hz PWM frequency.
The question seems to be, what happens if you try to update the PWM duty cycle faster than the PWM frequency?
To me the most logical thing would...
While using a rotary encoder with ESP32-S3, I noticed both the high and low limits were returning the 0 on overflow, which is the default behavior of the ESP32 PCNT when the internal accumulator is disabled.
unit_config.flags.accum_count = true; is set in the code, but watchpoints matching the high and low limits also need to be created for the internal accumulator to work.
This PR should fix that.
I have a script to explore working with SSE. It Β«seems toΒ» work. I can connect and disconnect browser sessions. However, if I then just leave it running with no connections, and come back later (maybe an hour), the app is frozen. ctrl+c in the serial window aborts and gives:
192.168.20.105 -- "GET /sse" 360 -- "200 OK" 101 -- 126ms
192.168.20.105 -- "GET /favicon.ico" 390 -- "404 Not Found" 90 -- 18ms
client ('192.168.20.105', 8332) went away: code 32
client ('192.168.20.108', 47...
[adafruit/circuitpython] New comment on pull request #9459: Fix IncrementalEncoder overflow on ESP32
Thanks for the PR. If you resubmit it to be against 9.1.x instead of main, we can get it into a bugfix release for 9.1.x. Are you able to do that?
Same as #9459, but against 9.1.x branch, and enabled accumulator for other classes using PCNT: Counter and FrequencyIn.
Yeah my mistake, just noticed the "dev" part of this thread. I figured it out in the end and succeeded with my project. It was actually the USB disable mode of the macropad that I forgot existed, but a separate issue persisted and that seems to be a MacOS Sonoma thing. God, Apple sucks.
Here are some experiments where code.py sets the duty cycle of 500 Hz PWM to 10%, then right away sets it to 90%. The top (green) signal is programmed to go high when duty is set to 10%, and go low when it's set to 90%. The bottom (yellow) signal is the PWM.
On samd51 running 9.05, both 10% and 90% are always seen, because the code blocks until it is ready to accept another duty cycle value:
 are set to '1', the related SYNCBUSY bits are set (SYNCBUSY.PATT, SYNCBUSY.PER or
SYNCBUSY.CCx), a write to the respective PATT/PATTBUF, PER/PERBUF or CCx/CCBUFx registers will
generate a PAC error,
Try to clear the status bit for buffer valid before re-writing it.
It would be nice to have consistent behavior across ports.
This delay only happens for the samd51, and removing it was the thing breaking the backlight.
#ifdef SAM_D5X_E5X
Tc *tc = tc_insts[t->index];
while (tc->COUNT16.SYNCBUSY.bit.CC1 != 0) {
}
tc->COUNT16.CCBUF[1].reg = adjusted_duty;
#endif
The rest of your changes seemed to work great.
@tannewt trying various stuff like
tcc->CTRLBCLR.bit.LUPD = 1;
tcc->STATUS.vec.CCBUFV ^= (1 << channel);
tcc->CCBUF[channel].reg = adjusted_duty;
not seeing any change to 9.1.0 behavior. But I have only a vague sense of how these registers work...
```tcc->STATUS.vec.CCBUFV = (1 << channel);` is mainly what I was thinking of. I was assuming the PAC error would cause the second value to not be saved. Unfortunately, it'll take some trial and error. I don't see any related errata.
hello! I'm returning to a CP project with a new hw design.
I wanted to verify that I'm going about the design the right way - or what product has the right hw that I can look at a schematic?
I'm going to use the STM32F746 which has nothing on it AFAIK
Can I help tracking it down? I don't know what it will take to reliably reproduce the failure. I'm a programmer, but not really set up to do debug builds. Main environment is Fedora. I can spin up a VM if other environment (not Windows or Mac) is better for building.
The "internal watchdog timer" that was triggered happens because something was taking far too long, blocking other operations (for example, a tight infinite loop). It reflects a bug, not just a timeout that's too short.
If you can reduce your program to the smallest example that still shows the problem, that would be great. We'll have to let it sit for a while to trigger the error, it seems like.
There is a build: stm32f746g_discovery which uses one of STM's development boards. You could start with that. If you have the dev board that would help, since if something's not working you can compare it with that board.
many of the STM builds are rarely used, so there may be undiscovered problems
I'm not saying there are, but there might be.
that's good advice thanks
Following up from this: https://github.com/adafruit/Adafruit_CircuitPython_EMC2101/pull/34
I have updated the mailmap file in here too. I split my changes into two commits: One is just my own name correction, the other is my best attempt at cleaning up the output of git shortlog -s -e and git shortlog -s -e -n, without making too many assumptions. That does mean there are duplicates in the shortlog still, because I didn't know which email of multiple valid-looking ones to use.
I did...
Another data point... I tried a similar reproducer on an Adafruit Metro ESP32-S3 with an attached Adafruit 2.8" TFT Touch Shield. But, this time I set the display up to echo the serial console. In this case, the TFT console continues working (taking keyboard input from the USB serial connection!), even after the USB serial output to screen -fn /dev/tty.usbmodem... stops working.
CircuitPython version
...
Is there any chance flow control is getting confused? Does a Ctrl-q on the frozen screen do anything. It looks like there is a MacOS command defflow off to set the default flow control for "screens" to off.
Yeah, I agree it does seem a lot like some kind of weird flow control issue. I'm under the impression that when I invoke screen with screen -fn ..., the -fn should turn screen's flow control off. The man screen section about the -f, -fn, and -fa switches mentions 'This can also be defined through the "defflow" .screenrc command'. So, maybe -fn and defflow off do the same thing?
I tried Ctrl-q, but that did not appear to have any effect. It's still the same situation: no local echo and no console output in the screen window, but text output on the TFT console works fine (taking its input from what I type in the screen window)
I did stumble on one post that suggested typing ctrl-A followed by a Q on the frozen screen (I think the caps are significant but :shrug:)
Two things I'd try:
- What happens if you detach your terminal from
screenand lock your Mac? (ctrl-a dto detach, then later,screen --listorscreen -rto re-attach) - What happens if you use
tioinstead ofscreen? Maybe it has different flow-control behavior.
When I do a detach-screen, lock-mac, wait, unlock-mac, then reattach-screen sequence, the result is the same (output stopped during the time screen was locked, no further output shows in screen window, but typing into screen still works as expected). I don't have tio on my mac, but I'll see if I can find some other OS and/or terminal emulator combination that reproduces the same problem.
I tried using the serial monitor of the Mu editor on an old MacBook Air (13-inch Mid 2013) with macOS Big Sur 11.7. The same problem happens (no console output on the mac, but console input works, and TFT console output works). The same problem also happens when using screen on the old MacBook Air.
FWIW, seeing that Mu and screen act the same way across significantly different hardware/OS combinations, my bet is that this has to do with an edge case on the CircuitPython board that is triggered by a USB power saving feature or perhaps by a full TX buffer. I'm assuming that the Macs are entering a standby or suspend mode that slows or stops the CPU. Maybe some combination of TinyUSB, ESP-IDF USB Device Stack, and CircuitPython aren't on the same page about what should happen if the host c...
I have run your first test script on an esp32-s3 in a "screen" window on linux with the output paused using ctrl-s for more than 30 minutes and a ctrl-q resumes the output without issue. I wonder if the Mac might be doing something weird to the USB data lines when the screen locks (maybe security to thwart Rubber Ducky or similar attacks?)
I have run your first test script on an esp32-s3 in a "screen" window on linux with the output paused using ctrl-s for more than 30 minutes...
As long as I don't lock the screen, nothing weird happens for me. But, once the screen has been locked for approximately 100 seconds (sometimes less, sometimes more), something breaks. The screen locking is the trigger.
An important point to note is that I have my systems set so that they can automatically go to sleep when the display is off.
...
The ESP32 can do sub-milliamp current while remaining connected, but I don't see anything about enabling automatic light sleep for WiFi.
Since there's already alarms, would it be possible to add some way to idle in the ESP's automatic light sleep mode rather than sleeping the whole time and messing up WiFi?
Okay, I used the Ubuntu Suspend option and reproduced what you're seeing on Linux. The Neopixel continues to blink but the output is frozen in the screen or tio terminal.
This may be relevant https://www.kernel.org/doc/html/v4.13/driver-api/usb/persist.html#:~:text=By default%2C Linux behaves according,officially correctβ thing to do.
I was actually able to bring a frozen screen back to life using the following script
#!/bin/bash
echo "2-1.1" > /sys/bus/usb/drivers/usb/unbind
echo "2-1.1" > /sys/bus/usb/drivers/usb/bind
I ran dmesg after plugging the controller in to identify the device ID (2-1.1)
You have to jump th...
CircuitPython version
Adafruit CircuitPython 9.1.1 on 2024-07-23; ProS3 with ESP32S3
Code/REPL
import alarm
import board
import time
from microcontroller import watchdog as w
from watchdog import WatchDogMode
# Watchdog and Supervisor
w.timeout = 300
w.mode = WatchDogMode.RESET
print("test")
time.sleep(1)
w.feed()
wakeup_period = time.monotonic() + int(30)
time_alarm = alarm.time.TimeAlarm(monotonic_time=wakeup_period)
alarm.exit_an...
One more observation, I don't seem to be able to reproduce the issue using a Feather RP2040 so it may be limited to ESP boards.
Maybe something is keeping LDO2 enabled? That shouldn't cause 28mA but might cause a few mA. Can you confirm there is no voltage on the 3V3_2 pin when it's sleeping?
If you folks have time, trying some earlier versions of Python would be interesting, since the underlying TinyUSB software undergoes updates fairly frequently.
CircuitPython version
9.1.x, main
Code/REPL
# readthedocs problem
Behavior
https://docs.circuitpython.org/en/latest/shared-bindings/board/index.html is empty, when it should have content
Description
During readthedocs, the empty __init__.py is used for generating the documentation of this module, rather than the __init__.pyi file:
[AutoAPI] Reading files... [ 47%] /home/docs/checkouts/readthedocs.org/user_builds/circuitpython/ch...
Closes #9465
Please check the RTD html build when reviewing this bug! Last time we thought we fixed this, I think only local builds were checked (or something? not sure why the previous PR passed muster)
Will want to merge 9.1.x up to main after this. This is required for fixing the builds of various bundle libraries, fixing e.g., the failure seen in https://github.com/adafruit/Adafruit_CircuitPython_EMC2101/pull/34
π¦ doc building feels like it's been fragile lately
9.0.0 has the same problem on:
Adafruit CircuitPython 9.0.0 on 2024-03-19; Adafruit QT Py ESP32-S3 no psram with ESP32S3
8.1.0 also has the problem on:
Adafruit CircuitPython 8.1.0 on 2023-05-22; Adafruit QT Py ESP32-S3 no psram with ESP32S3
It seems that there is a duplicate copy of the PN532 driver docs in RTD under the more general name adafruit-circuitpython https://adafruit-circuitpython.readthedocs.io/en/latest/
https://readthedocs.org/projects/adafruit-circuitpython/ the maintainer of that project is not us. it was last built 4 years ago. I'll reach out to RTD via e-mail and see if they can remove it.
Something strange seems to be going on inside of RTD. I'm not really sure how to check what the results of building the real docs inside of RTD are going to be.
I tested this PR with a local build and it does show content on the board page. But I found the same when I tested #9431. I even went back to #9431 again today and did another local build and confirmed I do still see content on the board page with a build from that branch as well.
I didn't know these existed, but I found ju...
Yes, at some point we enabled RTD to build docs with each pull request. That's what I was hoping you'd look at when you reviewed it but I wasn't very specific I guess.
What is the board for? We have better CP support for other microcontrollers. Maybe one of them would also work.
To me it seems that looking at those isn't really showing us how it's going to turn out when it's merged and in the real docs though. The 9431 preview build looks correct: https://circuitpython--9431.org.readthedocs.build/en/9431/shared-bindings/board/index.html, as does the new one for 9466. But for some reason in the "latest" real build it's different than the PR preview ones in that it has the blank board page.
In my mind this does look good to merge.
But I'm not certain whether i...
Let's see how the "real" build acts! Thanks for the fix
I suspect tud_cdc_connected() is returning false here:
This is based on the sent line state:
https://github.com/hathach/tinyusb/blob/cfbdc44a8d099240ad5ef208bd639487c2f28153/src/class/cdc/cdc_device.c#L127-L130
I don't know why this would only break on an S3. ESP does run tinyusb processing in a different task. Most run it in the CircuitPython background tasks.
I don't think we need another API. Seems like the existing light sleep API should work. Is this ESP32 only or does it apply to more of the ESP line?
The 9.1 docs are showing the content now on the board page :tada: https://docs.circuitpython.org/en/9.1.x/shared-bindings/board/index.html
Thanks again! One primary email suggestion. Good otherwise.
Kattni is no longer working with Adafruit so I assume her @kattni.com email would be better.
Includes the following:
- bd834182c4 Merge pull request #9458 from weblate/weblate-circuitpython-main
- 8b5869c98e Merge pull request #9452 from weblate/weblate-circuitpython-main
- bffdf3beea Merge pull request #9436 from jepler/veesix
- 3865456c5f Merge pull request #9427 from RetiredWizard/sysdoc
- 2d518a2ade Merge pull request #9449 from adafruit/9.1.x
- 2cd53b03a7 Merge pull request #8798 from lovrojakic/board-support-for-vidi-x
- 758c60c625 Merge pull request #9445 from weblate...
So far, I don't think we know anything one way or the other about ESP32-S2. The ESP32 boards I have are all S3. If anybody wants to try S2, I'd be curious to hear what happens.
These are some other boards I tried, none of which have the problem (timestamps continue printing after screen is unlocked):
Adafruit CircuitPython 9.0.5 on 2024-05-22; Raspberry Pi Pico with rp2040
Adafruit CircuitPython 9.0.5 on 2024-05-22; Adafruit Trinket M0 with samd21e18
Adafruit CircuitPython 9....
I can't seem to cause the issue using a QTPY ESP32-pico
I can't seem to cause the issue using a QTPY ESP32-pico
That makes sense because that's strictly a USB-serial converter chip, no native USB involved: TinyUSB and its associated code like the tud_cdc_connected() call above are not used.
The full bin option means that it also sets up web workflow. Upgrade means it erases and flashes only. I think there are issues if the flash isn't erased, but perhaps that's not necessary.
There are definitely times that if you don't erase the flash, it may look like it was successful but you'll have problems with the file system down the road so I understand wanting to always flash first. That being said, I do frequently risk it :grin:
Modifying this function to always return "false" seems to prevent the issue from occurring.
I'm guessing that suggests that either the OS isn't marking the device as no longer suspended or the device isn't recovering properly from the suspended state.
Without this function properly operating the ESP32 board continues to output while the computer is suspended, ie there are no ...
CircuitPython version
origin/main (pull request)
Code/REPL
GITHUB_EVENT_NAME=pull_request BASE_SHA=901dd228cbdb2069e66fae8c2108d44466ab1e7f HEAD_SHA=d335a10574a1eaf78c94e566399d96150f269636 GITHUB_SHA=7dd3bf81e44bfb73880cc34d418bf7ed09223bad python tools/ci_set_matrix.py
Behavior
Should build many boards, but actually builds none
Description
Encountered while building https://github.com/adafruit/circuitpython/pull/9467
Additional infor...
@dhalbert the build is not occurring due to an apparent bug in ci_set_matrix; I filed an issue. https://github.com/adafruit/circuitpython/issues/9468
The specific $GITHUB_SHA seems to have been a temporary merge commit created for building the PR; I pushed it to jepler/git_ref_value_pr9468 because it is now otherwise missing/unreachable as far as I can tell.
It's still wrong in main branch now that it's been merged up: https://docs.circuitpython.org/en/latest/shared-bindings/board/index.html
I am perplexed but don't have any time to work on it now.
or maybe I needed to shift-reload. can someone else take a look and close if appropriate? I'm at my wits' end.
another data point... I was able to prevent the serial glitch on ESP32-S3 with storage.disable_usb_drive(). If I put this in my boot.py, then do a hard reset, the USB serial output does not glitch:
import usb_hid
import storage
usb_hid.disable()
storage.disable_usb_drive() # CAUTION: THIS WILL HIDE YOUR CIRCUITPY DRIVE!!!
For anybody reading this who isn't already familiar with recovering from a disabled CIRCUITPY drive...
To fix your boot.py so CIRCUITPY co...
Issue with defining a group of Neopixels
pixels = neopixel.NeoPixel(board.NEOPIXEL, n :4) if i post this i get a syntax error
on the N: 4
The ide tells me it should exist, but it won't work.
@grizzled thunder pixels = neopixel.NeoPixel(board.NEOPIXEL, 4)
that's correct, this is a syntax error, don't use llms for programming
thanks, i thought i tried that too.
Seems like my crashes are due to an openthread config issue or something because just running otInstanceInitSingle(); triggers a crash.
Merging from micropython-v1.22-release branch.
- added background tasks and interrupt checks to new routines
mp_event_wait_ms()andmp_event_wait_indefinite(). - Note that
QDEFis nowQDEF0andQDEF1. pyexec.cis still hard to merge due toatexitconditionals. Maybe there's some way of formatting them so there are fewer changes.raspberrypi/libm_extra.cfixes ROM floats to handle infinities correctly, but I did not pick this up yet.
As of the initial draft PR, a...
I did some more testing. I have sample code that reliably triggers a non-responsive httpserver, and most of the time safe mode on restart. My initial pointer to .poll() is back in the mix. I tried a couple of variations. When I use server.server_forever(β¦), I do not see the failures. Change that to start plus while True and server.poll() triggers the problem. Idle time is also part of the mix. If I do a fresh request every 5 minutes, the error does not trigger β¦ until I leave it idle for abou...
Yeah, seems like there is a voltage on 3V3_2 during sleep.
And if you pull IO17 LOW before entering deep sleep, does it keep it low (LDO2 off)?
No, it only stays low until deep sleep starts, and then it goes back to ~3.3V
Ok, that shouldn't really be possible at a HW level as the LDO enable is controlled by a logical AND and requires both Io17 and VDD_SPI to be high, and VDD_SPI is shut down during deep sleep.
Just to be sure - you're not testing with power from USB/5V right? It's being powered from a battery?
Yep, I'm testing on two separate boards. One with alkaline batteries, the other connected to a power profiler on 3V3_1.
I have no idea what has changed under the hood in CP for 9.1, so I'll need to make some enquiries.
I know there's a way in the board configs to tell CP not to touch certain IO, but that should not be needed as it was working correctly before 9.1.
@dhalbert Can you think of anything off the top of your head (apart from possible IDF level changes) that could have changed the behaviour on the IO when going into deep sleep? Maybe some other bug fix that might have caused some knock-on effect?
We updated to ESP-IDF 5.2.2. Also #9324 was merged.
We updated to ESP-IDF 5.2.2. Also #9324 was merged.
Ok, so the only way to fix this now for my boards is to add something like this to board.c ?
void board_deinit(void) {
// Turn off LDO2
gpio_set_direction(17, GPIO_MODE_DEF_OUTPUT);
gpio_set_level(17, false);
}
Didn't there used to be a way to tell CP not to touch certain IO when going to sleep?
I haven't yet, but I think looking carefully at the code in #9324 would be good.
Yes, we had "never reset" certain pins, and "never ever reset" certain pins. Some of that logic has been simplified. A code comparison between 9.0.5 and 9.1.1 would be helpful, or a bisect.
It appears that this is not going to affect the project that it was initially encountered in. The problem was seen when doing development and testing of separate sections. With everything (so far) merged together, there is no 'idle time' that is needed to trigger the failure. The project shows the sensor data both on a local display, and on web pages. It seems that the processing needed for the display portion is enough to prevent the watchdog timeout seen in server.poll(). Even with the web ...
CircuitPython version
Adafruit CircuitPython 9.1.1-5-g901dd228cb-dirty on 2024-07-28; Adafruit ItsyBitsy ESP32 with ESP32
Code/REPL
import mandelbrot
Behavior
>>> import mandelbrot
Traceback (most recent call last):
File "", line 1, in
ValueError: incompatible .mpy arch
Description
Building a C-based extension module for circuitpython based on one for micropython, works fine one ARM e.g. itsybitsy M4, grand central M4, Teens...
I note that native extensions are unusual in the circuitpython ecosystem but I am sure it should work and this does work on ARM so felt the issue report was justified. Please let me know if there is anything I can do to help
I note from discussion in https://github.com/adafruit/circuitpython/issues/6040 that this is somewhat unsupported but I have found in the past that it works following the upstream conventions (though I have not tested this with the 9.x series)
Reading over the code provided in that, this does look like exactly the same case: CP 9.1.1, ESP32-S3, server.poll() that is idle 'long enough', watchdog timer. Smaller code sample here, which could be shrunk further if logging not useful.
If the problem can be prevented by adding some code to .poll() that heartbeats or restart the watchdog timer i can make a PR for adafruit_httpserver, although I would like to know whether it is possible and if it is something that should be done there, because maybe that is not something that the library should do.
As far as I know, every popular Espressif chip has an equivalent, I don't think I've ever seen or used one without it.
Adding it to the existing API seems reasonable, but I'm not sure what it would look like, since there are several similar modes, and the WiFi and CPU have separate sleep settings, and the power consumption is more than full light sleep without automatic wakeups for the WiFi hardware.
Here is a bit smaller sketch that can produce the same symptoms. Note that the first cycle had the server stop responding, but on control C abort and control D reload, it restarted successfully. That restart also did not stop responding after a 16 minute idle period, then a 22 minute idle period. It did not respond after a following 27 minute idle period, and the following forced abort and restart showed the watchdog timer expired problem. For most of my previous testing 15 minutes idle time ...
When I was working on ESP32-nn sleep, I gave up on using light sleep because of the first paragraph below:
WiFi/BT and sleep modesο
In Deep-sleep and Light-sleep modes, the wireless peripherals are powered down. Befor...
Should we go ahead and make a release for the cookiecutter repo? We haven't done that in the past, and it's not required for usage during cookiecutter execution. But as changes get made over time it might be easier to keep track of them and be able to refer back to different versions by some easier to use tag number rather than back through commits or PR history.
Also if we do want to make one can anyone think of anything that it might cause issues with? To the best of my knowledge cookiecutter doesn't interact with much if anything in the nightly automated tasks and I can't think of anything else that could be impacted.
A release is just a tag. I can't think of anything that would break if it were tagged. I think this is a good idea.
Any thoughts on what to use for the version number? I know it's arbitrary and doesn't matter much. I'm inclined to think something like 1.1.0 or 2.0.0 to try to indicate that there is some history that comes before the first numbered version.
FYI -- I used the latest cookiecutter on my RFM repo and the transition to ruff went fairly smoothly. I had to use a few #noqa:s
Thank you for the feedback.
that is fine. You could look back at any major transitions. You could even tag some previous merge commits but probably not worth it. This is definitely a major release due to the shift to ruff
I am getting this failure on github when I update my repo. Does anyone know what I have to fix? ```Checking dist/circuitpython_rfm-1.2.3-py3-none-any.whl: FAILED
ERROR long_description has syntax errors in markup and would not be
rendered on PyPI.
line 51: Error: Unknown directive type "todo".
.. todo:: Remove the above note if PyPI version is/will be available at
time of release.
Checking dist/circuitpython_rfm-1.2.3.tar.gz: FAILED
ERROR long_description has syntax errors in markup and would not be
rendered on PyPI.
line 51: Error: Unknown directive type "todo".
.. todo:: Remove the above note if PyPI version is/will be available at
time of release.
Error: Process completed with exit code 1.```
This is a link to the github actions failure https://github.com/jerryneedell/CircuitPython_RFM/actions/runs/10147209464/job/28057054022#step:2:1417
@solar whale CI is creating files to upload to pypi. during this process, checks are made for errors in the project's "long description", and it fails because the ".. todo::" blocks are not OK in the "long description". You should resolve whatever the todo notes pertain to, and then delete them. The text it's talking about is probably in readme.rst
Thank you! That was it!
OK -- progress, now when I try to generate a release, I get Uploading circuitpython_rfm-0.1.1-py3-none-any.whl 25l 0% ββββββββββββββββββββββββββββββββββββββββ 0.0/38.6 kB β’ --:-- β’ ? 100% ββββββββββββββββββββββββββββββββββββββββ 38.6/38.6 kB β’ 00:00 β’ 117.3 MB/s 100% ββββββββββββββββββββββββββββββββββββββββ 38.6/38.6 kB β’ 00:00 β’ 117.3 MB/s 25hWARNING Error during upload. Retry with the --verbose option for more details. ERROR HTTPError: 403 Forbidden from https://upload.pypi.org/legacy/ Invalid or non-existent authentication information. See https://pypi.org/help/#invalid-auth for more information. Error: Process completed with exit code 1. Am I lacking some permission or am I doing something wrong?
is this still your repo or was it transferred to the adafruit organization?
Still mine.
do you want it to be on pypi now? You need to get an accoun on pypi and supply credential info to upload from the CI. If you are willing to wait until it's transferred, it can be uploaded then
I'm happy to wait. No rush to see it on PyPi from my perspective. I just wanted to get it ready for people to test and review.
I may have misunderstood, but in last weeks meeting, I thought you suggested that I should create a release so it can be added to the "community bundle" for review.
that's the lowest overhead path for someone wanting to try it. The CI uses GitHub secrets PYPI_PASSWORD and PYPI_USERNAME to upload to pypi. We have our own secrets for our account, of course. You can add secrets to your repo under settings, or you could make an organzation and add organization secrets. Former is easier for now
Sorry, I am missing some part of the "big picture" . So are you suggesting I create my own PyPi credentials or transfer the repo to Adafruit?
I am more than happy to transfer it.
we could go ahead and transfer it. You have a paid seat in our GitHub org.
the name would be changed to Adafruit_CircuitPython_RFM. let me see who has to initiate it
Ah -- OK so should I rerun Cookie Cutter to make it an Adafruit library?
yes, though I'm not sure of the details that will change
you would initiate the transfer from "Settings" in the repo. Scroll down to the "Danger Zone" section on that page.
In the past, I think someone then created a template Adadrutit library and I then pushed to it.
I could do that too, since it's not a lot of stuff to copy over
would you prefer that or do you want to keep the commit history of your repo
How about I just create an empty repo and you can do a fresh cookie cutter and copy things in?
That sounds easiest to me - I don't need to preserve the history. If you don't mind creating the template.
Hopefully Adafruit will find this worthwhile!
There is no rush on any of this.
ok, here you go: https://github.com/adafruit/Adafruit_CircuitPython_RFM. It's empty except for the license file.
Great -- thank you!
I had it mostly working at one point in Micropython, but never made a PR because nobody replied to the thread and eventually someone else made one.
But now with the C6 and 802.11ax, there's also target wake time, which I believe they say can last for years on a battery, so the APIs should probably support that.
And it seems there's also the ability to sleep for more than one DTIM interval for a similar effect on older WiFi, but it can break broadcast traffic.
Seems like everyone else...
where is neopixel_write defined?
It appears to me that this is resolved now. I see the content inside the board module docs page on the currently live docs. I also saw an actions run that was previously failing due to this that was able to pass now.
i donβt really care, iβm trying to port some stuff to Rust and Iβm looking to see how to interact with gpio21 on the adafruit feather rp2040 CAN board. The adafruit rp2040 example for rainbow doesnβt work, and iβm pretty sure itβs because the pins are different. So i just want to see the source for how to communicate with the neopixel. Either python or C would be fine. But i pulled the circuit python community bundle and the circuit python bundle and itβs not in there from what i see
ugh, itβs not a simple serial connection, thank you for this!
Adding some debug info was useful: to persistentcode.h:
#define VALUE_TO_STRING(x) #x
#define VALUE(x) VALUE_TO_STRING(x)
#define VAR_NAME_VALUE(var) #var "=" VALUE(var)
#pragma message(VAR_NAME_VALUE(MPY_FEATURE_ARCH))
Emits at compile time:
In file included from ../../py/builtinimport.c:37:
../../py/persistentcode.h:86:9: note: '#pragma message: MPY_FEATURE_ARCH=(MP_NATIVE_ARCH_ARMV6M)'
86 | #pragma message(VAR_NAME_VALUE(MPY_FEATURE_ARCH))
| ...
My reading of this is it has only ever been tested with ARM Thumb instructions - but should be a relatively easy fix if I get a chance.
Nope. PIO is the best way on RP2040 (and most other micros)
@tulip sleet I forked the new Adafruit_CircutPython_RFM library and created a brach to update it. When I try to push the branch, I am getting this... ```(blinka_venv) jerryneedell@gjnpi5nvme:~/projects/combined_rfm/Adafruit_CircuitPython_RFM $ git push origin jerryn_initial_commit
Username for 'https://github.com': jerryneedell
Password for 'https://jerryneedell@github.com':
Enumerating objects: 89, done.
Counting objects: 100% (89/89), done.
Delta compression using up to 4 threads
Compressing objects: 100% (86/86), done.
Writing objects: 100% (87/87), 64.82 KiB | 3.81 MiB/s, done.
Total 87 (delta 45), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (45/45), completed with 1 local object.
To https://github.com/jerryneedell/Adafruit_CircuitPython_RFM.git
! [remote rejected] jerryn_initial_commit -> jerryn_initial_commit (refusing to allow a Personal Access Token to create or update workflow .github/workflows/build.yml without workflow scope)
error: failed to push some refs to 'https://github.com/jerryneedell/Adafruit_CircuitPython_RFM.git'
I gave you some extra privs. Try again. If that doesn't work let me try one more priv.
<@&356864093652516868> Sorry for the lack of additional warning today. But the weekly meeting is set to begin here on on discord in just a few moments.
still same failure
ok, try once more
even though i'm here i'm text only
same failure π¦
π»
π±
the error is "refusing to allow a Personal Access Token to create or update workflow .github/workflows/build.yml without workflow scope)". Maybe your personal access token didn't have all the right privs checked when you created it. There is a long list of privileges
OK -- I'll try to regenerate it and try again
First hae to remeber how I created it in the first place π
An introduction to Proteus VSM for MicroPython. A unique product combining the ability to program directly in MicroPython code with simulation of popular boards such as Raspberry Pi Pico and ESP32 along with thousands of embedded peripherals and ready made breakout boards.
I loaded up the Qualia S3 with 9.1.1 last night, works well.
takes go kart to another level. never saw that coming.
Will we get a notice of some kind when everything switches from pylint & black to ruff?
not necessarily. Things are mostly just changing as they get worked on for other reasons.
looking forward to the singular RFM library. thank you for all the work on it!
All of the matter stuff looks super complicated. Glad we have you working on it. π
Ya, its been a bunch of new stuff for me.
Complicated but I think understandably so
Thank you for hosting @lone axle Have a great week everyone!
I also dove into some JPG imageload this morning. Was able to cut out about 50 lines of code. It works very well.
the difference in using jpegio decoder and imageload is night and day.
We'd be happy to merge any changes you have to get this working. It isn't a high priority for us though.
You can print from C code using mp_printf(&mp_plat_print, <format string>, <args>);. Happy to help with debug tips in the #circuitpython-dev channel on Discord.
Could you translate a wake_interval to beacon count? That way you only need one more setting.
There is an existing light_sleep API: alarm.light_sleep_until_alarms()
We'd be happy to merge this in if you get it working.
Didn't there used to be a way to tell CP not to touch certain IO when going to sleep?
alarm.exit_and_deep_sleep_until_alarms() has a preserve_dios kwarg that you can give DigitalInOuts to be preserved.
Here is the notes document for next Mondayβs CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1vwgVemFzcQIq3IEBjD66LEsObJawdNTniufYQoimPdc/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for August 5th, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you canβt make the meeting and woul...
@tulip sleet want me to review the mp merge today?
@tulip sleet -- all set with github personal access token now. Not quite sure what was necessary to add, but it looks like I added enough....
I was thinking of that, but I'm not sure how you would get the beacon
interval, I'm not seeing any APIs for that in the ESP-IDF, maybe I haven't
looked hard enough but I suspect it's not even sent by the AP.
You could assume it's 100ms, or measure it? But the value of 1 beacon is
special regardless of the interval because of broadcasting, some users will
likely want to do DTIM1 regardless of time, so we'd want the ability to
explicitly set DTIM1, right?
On Mon, Jul 29, 2024, 12:45β―...
Start with the bare minimum. We can always add things that folks want.
So, I'd suggest getting the light sleep working under the existing API first.
CircuitPython version
Adafruit CircuitPython 9.1.1 on 2024-07-22; Adafruit Feather ESP32-S3 TFT with ESP32S3
Code/REPL
import os
import ssl
import time
import wifi
import board
import displayio
import terminalio
import socketpool
import adafruit_requests
import adafruit_ntp
displayio.release_displays()
display = board.DISPLAY
# The time of the thing!
EVENT_YEAR = 2024
EVENT_MONTH = 8
EVENT_DAY = 16
EVENT_HOUR = 0
EVENT_MINUTE = 0
# we'...
CircuitPython version
CP9.1.1
Boot_out.txt:
Adafruit CircuitPython 9.1.1 on 2024-07-22; Adafruit Feather RP2040 Prop-Maker with rp2040
Board ID:adafruit_feather_rp2040_prop_maker
UID:DF625857C7736034
Code/REPL
any code. the issue is in saving to the micro
# SPDX-FileCopyrightText: 2020 Jerry Needell for Adafruit Industries
# SPDX-License-Identifier: MIT
# Example to send a packet periodically between addressed nodes
import adafruit_ds3231
from ...
i switched over to an earlier version (Adafruit CircuitPython 9.0.4 on 2024-04-16; Adafruit Feather ESP32-S3 TFT with ESP32S3) and the issue doesn't seem to be present
This could possibly be related to #9454 (ESP32-S3 USB serial output stops working). Both involve odd behavior with ESP32-S3 sleep modes when USB mass storage is enabled.
Feather ESP32-C6 Rev B pin changes:
A2,A3swapped with A4, A5- Remove e and
D25pin names. Not sure where these came from. @ladyada: I cannot find similar definitions for these, and I cannot find them in similar Arduino board defs. But happy to put them back if needed. - Rename
I2C_POWERtoNEOPIXEL_I2C_POWER
Feather ESP32-C6 Rev B pin changes:
A2,A3swapped with A4, A5- Remove e and
D25pin names. Not sure where these came from. @ladyada: I cannot find similar definitions for these, and I cannot find them in similar Arduino board defs. But happy to put them back if needed. - Rename
I2C_POWERtoNEOPIXEL_I2C_POWER
How were you running the code? In a code.py started on board reset, or through an IDE like Thonny or the Web workflow editor?
I've seen something similar when the flash file system was created but damaged. The host OS would mount the CIRCUITPY drive and appear to write/update files but nothing was actually written. I think the Host OS would hold a cache so it would appear from the host side that the changes were made but if the micro controller attempted to run or access a file the changes...
I think I might have some free time so I was planning to work on this in a bit.
If I understand correctly, the idea for now is:
Have the existing alarm.light_sleep_until_alarms use automatic light sleep, letting the chip handle actually entering sleep and waking as needed so peripherals keep doing their thing, preferring correctness over minimum power consumption.
Add a radio.listen_interval property that enables WiFi power saving, matching the API that the IDF exposes, letting you...
pardon the delay - reviewing now!
ah vacation, time to work on the "posix" port again. Down to 3 failures + 97 skips, compared to unix coverage port 0 failures + 34 skips. As always, still a ways to go.
Vacation? Sounds like a "busman's holiday" to me.
Sounds good @EternityForest! Let us know if you need any guidance about where code lives. #circuitpython-dev on Discord is a good place for realtime help.
Does this still occur if you eject the device before unplugging?
There isn't much we can do from the CircuitPython side if you unplug without eject. Windows caches writes to the file system and unplugging prevents those from completing. Eject will write out those changes.
Right now the only thing that seems to be confusing is this file: https://github.com/adafruit/circuitpython/blob/2f626121867efa429b7484fa3ca5a315021cc506/ports/espressif/common-hal/alarm/__init__.c
It uses port_idle_until_interrupt(), which seems to call xTaskNotifyWait, but I don't see how that enters actual light sleep, unless CONFIG_FREERTOS_USE_TICKLESS_IDLE is set somewhere outside the repo.
Does light sleep until alarms actually sleep? The comment `// We cannot esp_light_sleep_st...
Trying to enable compiled modules on esp32 (ItsyBitsy) and I have it so that this now works, but hit
>>> import mandelbrot
ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 271414342, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:396
ho 0 tail 12 room 4
load:0x40078000,len:13916
load:0x40080400,len:4
ho 8 tail 4 room 4
load:0x40080404,len:3156
entry 0x40080558
Serial console setup
Is there any guidance for how to debug this? Context:
https://github.com/adafruit/circuitpython/issues/9471
Appreciate that this is a low priority for the adafruit team so keen to try and get this working myself
Work in progress at https://github.com/graeme-winter/adafruit-circuitpython (detatched fork) now hitting
>>> import mandelbrot
ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 271414342, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:396
ho 0 tail 12 room 4
load:0x40078000,len:13916
load:0x40080400,len:4
ho 8 tail 4 room 4
load:0x40080404,len:3156
entry...
This is not heavily tested, and is posted for review and discussion as part of work on #9463.
It allows you to set the listen interval of the WiFi hardware to reduce power consumption.
When listen interval is 1, WIFI_PS_MIN_MODEM is used, when it is more than 1, WIFI_PS_MAX_MODEM is used.
The listen interval is set in units of whatever the AP's beacon interval is, most likely 100ms.
Without it, and running at 80MHz, power consumption hovers around 110mA with 140mA spikes. When se...
The main risk of WIFI_PS_MAX_MODEM (which doesn't sound severe for most use cases) seems to be that "broadcast data may be lost"
Yeah, I'm not sure if it also affects multicast, but broadcast isn't super commonly used so it might be fine.
The advantage of capping at 1 is that it could then be completely safe to use higher values on all boards, and there could just be one parameter for DTIM beacon sleep and target wake time.
But I'm not actually sure higher DTIM values are actually doing anything, ping times and power look the same as when set to 1.
@tardy bluff Do a debug build and look at the UART output. It should have a backtrace. I bet that reset is due to a call to reset_into_safe_mode()
Thanks for the pointer, will have a look at that in a bit (will need to solder some pins on π€¦ββοΈ) but good to know that is where the output goes, appreciated
thanks for looking into compiled modules! Others will be excited to have it
Thanks for the addition! Please add it to all wifi ports even if it raises an exception from the port code.
It also looks like you have a code formatter that disagrees with ours. I think setting up pre-commit will format it back for you.
Don't conditionally enable this here. We want it on all ports. If unsupported, then assigning to it can raise an error using mp_raise_NotImplementedError().
//| """Wifi power save listen interval, in DTIM periods, or 100ms intervals if TWT is supported."""
Right now the only thing that seems to be confusing is this file: https://github.com/adafruit/circuitpython/blob/2f626121867efa429b7484fa3ca5a315021cc506/ports/espressif/common-hal/alarm/__init__.c
It uses port_idle_until_interrupt(), which seems to call xTaskNotifyWait, but I don't see how that enters actual light sleep, unless CONFIG_FREERTOS_USE_TICKLESS_IDLE is set somewhere outside the repo.
Does light sleep until alarms actually sleep? The comment `// We cannot esp_light...
Does anyone have any recent experience with cookiecutter on windows? I didn't realize there was a different branch of the cookiecutter template and instructions for using ansys-cookiecutter instead of "regular" cookiecutter noted here https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/creating-a-library#running-cookiecutter-windows-3114568.
It looks like this windows branch is out of date though and a user other in #help-with-circuitpython is having some trouble trying to use it on Windows.
I'm wondering if there is some way we could make the process easier on windows or if there is interest in doing so. Could we maybe have some Github repo which uses specialized actions to run cookiecutter and then make the resulting project zip available for download? Kind of like how we have a way to make a custom build of core circuitpython via github actions?
If we could change that process from command line tool requiring a few libraries and other utilities to be installed over to just a "form" page that allows the user to enter their answers into standard inputs on a webpage it could help lower the friction for people wanting to share their libraries.
It also turns out that ansys-cookiecutter which the guide recomends doesn't seem to exist any longer. https://pypi.org/search/?q=ansys-cookiecutter returns no results by that example name and pip install ansys-cookiecutter fails with the error No matching distribution found for ansys-cookiecutter
Re: using github actions to run cookiecutter. Looks like this has at least been done before https://medium.com/@jimmfan/automation-with-cookiecutter-and-github-actions-f7dd8f7f042e
CircuitPython version
Adafruit CircuitPython 9.1.1 on 2024-07-22; Adafruit-Qualia-S3-RGB666 with ESP32S3
Code/REPL
import time
import board
import displayio
from adafruit_qualia.graphics import Graphics, Displays
graphics = Graphics(Displays.ROUND40, default_bg=None, auto_refresh=False)
bitmap = displayio.OnDiskBitmap("/img.bmp")
# Create a TileGrid to hold the bitmap
tile_grid = displayio.TileGrid(bitmap, pixel_shader=bitmap.pixel_shader)
#...
i'm on windows but use linux subsystem whenever i run cookiecutter
Thank you all for all the support on this project! You guys really seem to
care about making CircuitPython the best it can be!
I have basic WiFi power saving working in the draft PR, and I'm working on
tickless idle at the moment.
I'm getting down to 20mA while remaining ping-able, and some of that may be
the USB serial chip.
My current approach is:
-
Enable tickless idle only during light sleep until alarms
-
Disable the tick timer during that period
-
Set everything ...
Sounds good, I'll make these changes tonight after I figure out this
pre-commit issue... I thought it looked a bit odd, but pre-commit didn't
show any errors, maybe I just need to manually run it once or something.
In further testing I'm not actually quite sure values above 1 are doing
anything, ping times look the same as they do for 1.
The advantage to capping at 1 would be that using a higher value would
always be totally safe, so you could use the same code for WiFi 6, and it
c...
I am seeing the same issue with the SQUARE40_480X480 display and qualia board. Also 9.1.1. Have not (re)checked 9.0.5, but do not remember noticing problems when I was using it.
One side of the display twists up, then falls back down. One my display, that is the right side, but I have rotation set to 90, if that makes a difference. Whole display can shift up a couple of pixels too, but that is a lot less often.
I think I've partially figured out the issue! It was running the normal system uncrustify instead of the micropython-uncrustify version.
Not sure what to do about the error string translation stuff for the notimplemented error, looks like there's an existing string "can't set attribute" that would fit?
Images automagically compressed by Calibre's image-actions β¨
Compression reduced images by 78.8%, saving 24.59 MB.
| Filename | Before | After | Improvement |
|---|---|---|---|
| assets/images/boards/large/8086_usb_interposer.jpg | 146.85 KB | 134.76 KB | -8.2% |
| assets/images/boards/large/adafruit_feather_rp2040_adalogger.jpg | 1.57 MB | 1.16 MB | -26.5% |
| assets/images/boards/la... |
@lone axle cookie cutter is now tested during ci that it works (that is, runs to completion) on Windows. The need for a fork is no longer true.
[adafruit/circuitpython] Issue opened: #9478 Audiomixer can't play multiple different files in a row
CircuitPython version
Adafruit CircuitPython 9.0.3 on 2024-04-04; Raspberry Pi Pico with rp2040
Code/REPL
import time
import board
import audiocore
import audiomp3
import audiomixer
import audiobusio
import storage
import sdcardio
import busio
spi = busio.SPI(board.GP10, MOSI = board.GP11, MISO = board.GP12)
cs = board.GP15
sd = sdcardio.SDCard(spi, cs)
# Mount SD card
vfs = storage.VfsFat(sd)
storage.mount(vfs, '/sd')
audio = a...
Just solved my problem on which I've been working for a while now. Updated to the latest CircuitPython, and it works fine.
I too would like this feature. More to protect the code from tinkerers than hiding the code.
More updates: My very early progress on using auto light sleep is here. Sleeping for too long will trigger the watchdog and there's some peripherals that may break, but it's a start.
Considering the USB chip likely use 18mA or so, 20mA power consumption is pretty good!
https://github.com/EternityForest/circuitpython/tree/auto-light-sleep
I created a proof of concept server app that basically converts cookiecutter questions into a web form instead of CLI https://cookiecutter.foamyguy.com/cookie/?template=gh:adafruit/cookiecutter-adafruit-circuitpython. It appears to be working successfully but I haven't done exhaustive testing or validated everything inside of the generated projects. I think something like this might be a little more approachable to some folks than the existing CLI cookiecutter process. Theoretically it could handle other cookiecutter templates by changing the URL param, but I've limited it with an allow list to only work for this one ATM. Because I kept it general enough to work with any cookiecutter the "hints" given in the form page are kind of cryptic since they're just the default values, if you don't understand jinja template and cookiecutter they may not mean anything to you. There could be a form made more specific to circuitpython cookiecutter though with more specific and helpful hints if this is something that we think might be a useful tool.
Moving this into a server has the benefit of taking the burden of getting python and cookiecutter CLI setup out of the end users hands and into a central server that anyone can use from any OS with only a browser and no additional setup. Initially part of my motivation was the differing process on Windows, but I understand now there is no longer a need for that different process, though we do still need to update the learn guide to reflect it.
Currently it's a Django app because that is what I'm most familiar with and could throw together quickly. I do think it might be possible to utilize github actions to move the generator "server" into workflow runners instead of an actual server deployed and accessed via the browser. However witht he github actions method I don't know about the possibility of making simplified all the way down to a form like this. The process might end up still being something like: fork/Clone the "cookiecutter wizard actions repo", edit a JSON config file with the answers to your cookiecutter questions, then commit / push and the actions workflow can grab your config file and run cookiecutter with it then upload the resulting zip into the repo, or maybe elsewhere. "The barrier to entry" is maybe lower than cookiecutter CLI directly, but not by very much I think.
Signal quality is never going to be good with the RP2040 ADC so I'm shifting focus to an I2S audio codec, TAC5212. I've got the ADC and DAC working and am working on implementing I2SIn a la #5456.
Bumps rexml from 3.2.8 to 3.3.3.
Release notes
Sourced from rexml's releases.
REXML 3.3.3 - 2024-08-01
Improvements
Added support for detecting invalid XML that has unsupported
content before root element
GH-184
Patch by NAITOH Jun.
Added support for REXML::Security.entity_expansion_limit= and
REXML::Security.entity_expansion_text_limit= in SAX2 and pull
parsers
GH-187
Patch by NAITOH Jun.
Added more tests for invalid XMLs.
GH-183
Patch by Watson....
hmmm - i'm having that crazy [expletive deleted] pre-commit issue on a CP library: i'm using Ubuntu 24.04, Python 3.12 and I've tried using "fresh" virtualenv and venv without any success (plus the "well did you install pip" stuff) -- any clues or hints?
i can try later on an Ubuntu24 WSL image, for the sake of reproducing it:
python -Vshows 3.12- then, you make a new env with
python -m venv some_name - then
. some_name/bin/activate(orsourceinstead of.) - then
pip install pre-commit - then
pre-commit installfails? or is it an error thrown when actually running the checks (when doinggit commit)?
yes - AttributeError: module 'pkgutil' has no attribute 'ImpImporter'. Did you mean: 'zipimporter'? which is all over my search but i've not found an actual working solution
- fresh image, ran
apt update && apt upgrade apt install python3(which in fact is 3.12)- then, trying to run
python3 -m venv venvfails with a hint message apt install python3.12-venv(as the hint suggested)- now we can actually
python3 -m venv venv+. venv/bin/activate pip install pre-commitworks π€
python3.12-venv/noble-updates,noble-security,now 3.12.3-1ubuntu0.1 amd64 [installed,automatic]
pre-commit -V pre-commit 3.8.0
so it seems to be installed (pip install pre-commit worked)
does it fail when you try to configure it on the repo (pre-commit install)?
when you try and commit and the hook gets to run?
yes, it fails with the above attribute error on run
i asked whether it fails with a command or another, "yes" doesnt answer that π€£
if it fails when running the hooks on your .pre-commit-config.yaml, maybe they are not compatible with 3.12, and is not a pre-commit issue on itself
it's failing on run with the error above -- and it's the Blinka library, so not a new one -- i'm re-trying to do my change on a Raspberry Pi that has 3.11
(it's so stupid simple i might just give up and do it on github itself π )
I think this is an error related to python 3.12 and some specific versions of pylint that we had pinned that get used by pre-commit. As a temporary workaround you can update the pylint version to 3.x locally and then run your pre-commit successfully. In the longer term we're working on moving to Ruff instead of pylint which will also mean this problem goes away.
thats a cute I2S codec, i ordered some samples of the TAC5242
For the workaround, inside of .pre-commit-config.yaml you can change the version on the 2nd of these lines:
- repo: https://github.com/pycqa/pylint
rev: v2.17.4
to
rev: v3.0.4
so yeah, it was a problem with some code on the hooks that pre-commit was being told to use, not something within pre-commit itself
yes, it's the pylint version -- i can do a PR for this one, too π
I've got ~5 populated breakout boards for the TAC5212 that are up for grabs, if anyone's interested in messing with it.
Has there been any progress in this?
Hey all! I'm working on the ESP32 light sleep project, and kind of hitting a wall here. It just doesn't seem like it's possible in any nice/satisfying way on most boards.
Light sleep is supposed to keep everything running in the background, but there's no way to tell if you're connected to USB if it's through a USB to serial chip.
There's also no way to receive serial data while in sleep mode as far as I can tell. You can wake on serial, but the first character is lost.
I suspect there's plenty of other edge cases like this too. We could do some kind of "Assume connected until X seconds after the last char" but that's not completely reliable.
Is there something I'm not seeing here? It seems like making effective use of sleep just isn't possible without some kind of compromise to the existing APIs, new flags to disable certain features during sleep, or software implementations of stuff on the ULP cores.
I'm trying to implement rgb png images for imageload, and when I try to create a 24-bit displayio.Bitmap, I get ValueError: value_count must be 1-65536 β am I supposed to somehow be converting the image data to RGB656 on the fly or something?
Also, which colorspace should I use for grayscale images?
Is there Nordic NRF Bluetooth support ?
what are you trying to do?
Frequency counter counts frequency 20 or 50 times/sec and PWM peripheral drives LCD lens. Controller communicates 9600 bps with external device to set PWM as function of frequency deviation (diff. to se table ref. frequency).
Iβm not sure using AI in Forth could solve/learn relationship between frequency difference and required PWM value starting with some initial settings? If this would be possible this could be a next candidate for smallest FPGA ICE40 device of new 130nm CMOS ASIC
it's hard to beat an fpga
Size and power is the issue here⦠With ICE40 relative low power is possible but load config by startup from onboard flash consumes much more energy then in sleep/action modes
circuitpython really isn't designed for low power or efficiency
you are probably going to get best results with low-level languages
Have done it already with less than 256 lines assembly code
Maybe HANA1 cpu [ Christopher Lozinski ]
the only nrf mcu supported at the moment is nrf52840, it's pretty big and beefy
that's because circuitpython needs a lot of ram
Are there some examples. Sending some parameters for the embedded control loop and receiving embedded measurement data to/from mobile Android/IOS device ?
something like this? https://learn.adafruit.com/circuitpython-nrf52840/mobile-movement-data
you probably want to go to #help-with-circuitpython, there might be more people able to help you there, this channel is mostly for development of the circuitpython and its libraries
or even better, in #help-with-projects people might be able to suggest other solutions than circuitpython
No support yet for nrf5340 dual core ? Would like to use one core for Bluetooth and the other as control loop handling some peripherals. Or nrf52840 but then scheduling is required I believe and donβt know if it is supported yet in circuit Python
Running Bluetooth and embedded control loop at βthe same timeβ
The traditional layout of pixels in bitmaps of depth less than eight is with the order of values in a byte reversed, but with bytes in the same order as the pixels on the line.
Before now, displayio.Bitmap did reverse the values, but did it on a word (four bytes) basis, not byte, which resulted in groups of four bytes being in the order opposite to the screen order.
This patch fixes this, by making processing of pixels in bitmaps of depth less than 8 bits based on bytes, not words. Sinc...
I need to fix the code that generates the bitmaps for the fonts and the blinka logo, but I can't find it. I tried changing gen_display_resources.py, but it doesn't seem to have any effect. I'd really appreciate any help with this.
if anybody is familiar with the font bitmap data generation, I would love some help with https://github.com/adafruit/circuitpython/pull/9479
There are more problems with how the bitmap is ordered. I need to work on this some more.
Are you talking about the bitmap font for terminalio and blinka logo for repl?
I reverted to 9.0.5 and confirm that no display glitches are occurring.
Before rolling back, I tested rotation changes. The physical side of the display that glitches the most stays constant with rotation changes. That is the side where the ribbon cable attaches.
yes
A board from LILYGO. Got it from the official aliexpress store. Similar to lilygo_twatch_2020_v3.
Note:
For supporting all of the hardware out of the box, a few frozen modules were added that are not by adafruit, or by me.
While I am actively testing them, these modules seem pretty final.
If adding frozen modules of 3rd parties without their knowledge is an issue, I am willing to fork & pledge to maintain them.
Task checklist:
- [x] Display.
- [x] Pins.
- [ ] [USB-PID/VID PR...
It was the gen_display_resources.py file after all, I just didn't realize that I also had to change the shift and mask in the data, since they are now computed for a single byte, not a word.
This should be ready for review now.
Hello! No circuitpthon work to report. Instead, I'm on safari. Group hug!
It says "1 failing checks" but all the checks have a green checkmark. How can I learn which check failed?
Hmm, it looks like the "windows" job is failing with the "This environment is externally managed" error. Did Python get updated?
I dont recall seeing that on my Win computer, and i use 3.12, which afaik is the latest stable release
it happens in recent versions of Python when there is a special file in /etc that tells people to install stuff witht he package manager and not pip
Oh, ok
I noticed the windows job failure in https://github.com/adafruit/circuitpython/pull/9469 and have a fix there. This job vets that building on Windows still works.
files changed: 362 π±
that is less than the usual merge from upstream π
should I include the fix in my patch, or just wait for that patch to be merged?
or maybe a separate patch with just the fix?
we will just ignore the failing windows jobs when considering whether to merge PR's right now. That job is not on any critical path.
ah, ok
i'm not sure if there's a better way to do this, but setting a venv and using it in different build steps does not seem easy to me.
yeah, I remember the pep that introduced that functionality
see the comment there. I researched this a bit and it seemed like the easiest way. Since msys2 does not depend on a "system" python as far as I know, this seems ok (unlike, say, doing that on an ubuntu base system)
it's a virtual machine anyways, so you don't care about mangling system packages
I mean, single-purpose virtual machine