#circuitpython-dev
1 messages · Page 60 of 1
circup doesn't use the readme for anything that I am aware of. I think the two places it can look for requirements are requirements.txt and in pyproject.toml under a specific argument name (that I don't know off the top of my head)
I'm pretty sure by the time I'm done with ConnectionManager, I'll have touched every repo but 5...
Should the requirements.txt and README.rst be recursive? I see things like the MegTag requirements that has both portalbase and requests (and portal requires requests)
It doesn't look like we will get a response from espressif soon. In the meantime I would propose to enable the FSM ULP for all boards. Then the API is consistent across all ESPs (unlike now, where RISCV is enabled on some and FSM on others).
@tannewt What do you think?
I've noticed that happens a lot. Things can get double imported through various levels of abstraction between code.py and multiple libraries requiring the same base library. Requests, PyPortal, & Portalbase is a good example. If you have multiple helper libraries that call requests it'll still work. Circuit Python seems to work fine no matter how many helper libraries call upon the same base library in different instances.
The multiple levels of abstraction buried in PyPortal is intended to make things easier for beginners but I found it actually made it far more complicated. That's why I started using Requests only for all my projects, it's much easier to use and removed a ton of overhead from PyPortal & Portalbase.
@slender iron basic PWMOut is fine in terms of finalizers. espcamera allocates a PWMout and has a deinit(), but it does not have a finalizer. I think I need to add that.
BusDisplay.c still has
common_hal_pwmio_pwmout_never_reset(&self->backlight_pwm);
should this be removed?
@crimson ferry ```Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Wiznet5k WebClient Test
http text test
This is a test of Adafruit WiFi!
If you can read this, its working :)
https json test
{
"args": {},
"headers": {
"Host": "httpbin.org",
"User-Agent": "Adafruit CircuitPython",
"X-Amzn-Trace-Id": "Root=1-65dfa1ee-610a5eea3653af38294dd85f"
},
"origin": "162.210.7.8",
"url": "https://httpbin.org/get"
}
Code done running.
MemoryError:
Press any key to enter the REPL. Use CTRL-D to reload.
That's interesting, it manages to throw a MemoryError after the code finishes running 🤔 but .. it works! ssl request on wiznet (with modified core code & modified wiznet library).
Yeah, python doesn't care (and once it's imported it doesn't import again), but just trying to figure out what the "policy" is, so I can get things correctly updated
OMG @onyx hinge that's amazing!!! (and if we did that first, I would have done CM differently....)
Note the pre-commit failure. If you install pre-commit locally, it will catch these before you commit: https://learn.adafruit.com/building-circuitpython/build-circuitpython#install-pre-commit-3096511
what part of that is related to CM? did it need wiznet workarounds or something?
I didn't change much in wiznet
and it doesn't change esp32spi which is still its own thing
Few things:
- wouldn't need
create_fake_ssl_context(assuming it also works with esp32spi) adafruit_connection_manager.get_radio_socketpoolwould be much simpler
In the end, it will just be removing code if it ends up working
we probably can't just add CIRCUITPY_SSL on most boards, it adds a lot of code
so in summary I bet what you did is good and you shouldn't second guess it just because of this proof of concept code
mmmaybe? the only requirements are to obey enough of the socket "protocol" (duck typing) & use SOCK_STREAM=1
but esp32spi's SSL is maybe accelerated by esp-idf code and this is generic unaccelerated code, and it takes away flash space we might not have to spare on existing boards, so it's probably not just a "switch & forget with no trade offs" kind of change
👋 I'm headed out again, ttyl!
ssl-anything branch updated with my latest code
I don't know that we have any official policy around it or anything. I think some libraries have a more thorough list in the readme than others. I'd say generally I'm in favor of including the recursive ones in the list though so in that case list both portalbase and requests even though portalbase itself does require requests too.
That's awesome! I worked on it for a few hours last week but didn't get past Invalid socket for TLS. Proof of concept opens up a lot of new possibilities.
- Fixes #8985
espcamera object needed to have a finaliser, so it could deinit the PWMOut it uses.
@tannewt Should this "never reset" be removed, in line with #8966?
https://github.com/adafruit/circuitpython/blob/54e78c89fc9e0d2b31544dfd03c30a159e8540a4/shared-module/busdisplay/BusDisplay.c#L128
If you open a draft PR, we could see what boards fail on space, and I can try it on as many boards as I have to see if the errors are the same everywhere...
I'd be happy to test too. The WIZnet RP2040 EVB Pico 5100/5500/6100 are step one. The Adafruit EtherNet FeatherWing could potentially go on a variety of processors if space permits. There is also a hat version of the WIZnet EVB Pico that could go directly on a Pico, or Pico W which already has ssl 🙂
I hope it will fit on some S2 or S3 feathers.
unrelated Q: is the CP I2C implementation intended to support multi-controller (e.g., two MCUs talking to a shared peripheral)?
Oh cool, didn't know about those boards
Oh, duh, S2 and S3 already have ssl ...I was testing with an S3 TFT + Ethernet FeatherWing. Pico W + 5100 hat is also ready out of the box.
There is no deliberate support for multi-controller in CircuitPython
Ya, I'm surprised I didn't delete that common_hal function completely. Does espcamera do bulk reset? You could call deinit on the pwmout then
it works! I connected one SHT31 to two ESP32-S2 QT Py boards with Stemma QT cables (cut the power wire on one of them), and both processors get looping results successfully from simpletest.
last night i found that 9.0 beta2 was causing the pycamera library to be incredibly slow while beta0 was normal and speedy. using absolute newest this morning and PR8990 seems to have fixed it 🎉
I have dived into this and able to find the root cause, there are 2 issue
usb.core.find()return currently attached device with vid/pid, but the returnned device has self->configuration_descriptor set to NULL. In order to use read/write endpoinnt API, you will need to get connfiguration descriptor with
config_descriptor = adafruit_usb_host_descriptors.get_configuration_descriptor(device, 0)
or set_configuration() which also try to read configuration as well.
- Seconnd is...
@jepler I am able to reproduce the issue with my generic low speed usb keyboard. I will try to find an full speed usb to test with as well, just curious if your keyboard is low speed or full speed ? they are handled differently in pio-usb.
Finishes remaining needed removals from #8966 and https://github.com/adafruit/circuitpython/pull/8990#issuecomment-1970468546, and some other unused code.
@tulip sleet and @slender iron I opened up 9 Fix README requirements PRs. There are a few others that don't need Requests but need MiniMQTT, but the MiniMQTT PR hasn't been reviewed/merged so will wait on that
Approved all of these with some very minor tweaks. Asked Brent to review MiniMQTT.
I haven't looked at the Learn Guide one yet
Thanks. Sorry for the ABC's I missed
np 🙂
Scott mentioned that the corresponding guides from my Learn Guide changes need to be updated. Is this something I can do?
hi @slender iron, i saw your live on youtube on usb host debugging
i want to know how can i develop by myself the vendor specific host, because i have a board with stm32s working in device mode as vendor specific device and i want to connect it to the usb of the pico w to communicate through wifi
It depends on two things essentially. If the part within the guide that needs updating is actually an embedded code file from Github. Then the change needs to get made in a PR to https://github.com/adafruit/Adafruit_Learning_System_Guides repo, and you can do that. If the change is needed in the text of a guidepage or in some code snippet that is not embedded from Github then you can only change it if you have editor access in learn.adafruit.com.
This about https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/2743. So the code will get updated automatically, but we'll need to look to see if there's related text that becomes obsolete
I think in many cases it's a mirrored page, so it will only need to be changed once.
Ahhh, I see
@short tendon Is the Learn Guide PR above dependent on the MiniMQTT library being updated first?
It is not. This is all just switching away from set_socket similar to some other PRs I opened. Technically those guides will stop working once MiniMQTT is released
great - I'll work on that PR and look at what Learn Guide changes are required
Cool. If there is a way I can help, let me know. My goal isn't to give people a bunch of work
https://docs.circuitpython.org/en/latest/ is Welcome to the ulab book!
I've never done vendor specific stuff. The low level pyusb API that circuitpython implements shouldn't care though. It just reads and writes endpoints.
archive.org shows the most recent two snapshots were on 2/14 (or perhaps 2/15, the page header disagrees with the calendar). It looks like it was loading the appropriate docs page at that time.
The pages in question are mostly a single mirrored page. It's actually out of date in a lot of ways (talks about secrets.py, etc.). I started to edit it, but something broke and some of my changes were lost. It needs considerable rework and someone (maybe me or not) will be doing it. ex: https://learn.adafruit.com/adafruit-pyportal/internet-connect
also there is a lot of redundant info in there
checking on this - we didn't change this recently, as far as i know!
it is broken
something bad is going on with the docs build, not sure what. make html locally doesn't even work
this may be some tool update that broke things. I can't even build 9.0.0-alpha.6 docs locally
what is the error?
a bunch, hold on...
also ERROR setuptools_scm._file_finders.git listing git files failed - pretending there aren't any but I think that may be old and innocuous
I didn't deliberately update my pip3-installed tools recently
but the ulab-replacing-circuitpython above may be something else, or may be a different manifestation of this
the intersphinx inventory thing may reflect some change at rtd. I should look at their news
ya, feels like a tool update
yes, getting same error even on 8.2.x branch
let me know if you want me to look too
It doesn't look like we will get a response from espressif soon. In the meantime I would propose to enable the FSM ULP for all boards. Then the API is consistent across all ESPs (unlike now, where RISCV is enabled on some and FSM on others).
@tannewt What do you think?
If you want to get it working with FSM only that's fine with me. I'd be happy to review it. It isn't a priority for me at the moment.
Sorry for misleading you on this. I think we do need the indirect pin never_reset calls. We can remove these once the blanket pin reset is removed too.
This is why we still need this. Or at least, we need to replace the pwm never_reset with pin never_reset.
Since this is innocuous, and we probably don't want to do the pin never-reset removal for 9.0.0, I can make this a draft and mark it 9.x.x.
I have dived into this and able to find the root cause, there are 2 issue
1. `usb.core.find()` return currently attached device with vid/pid, but the returnned device has self->configuration_descriptor set to NULL. In order to use read/write endpoinnt API, you will need to get connfiguration descriptor withconfig_descriptor = adafruit_usb_host_descriptors.get_configuration_descriptor(device, 0)or set_configuration() which also try to read configu...
I updated aeveryting, including Sphinx, to 7.2.6 from 6.something and am now getting different errors. Could you just do a make html locally and see if it works for you?
yup
there is now something broken in make stubs --python is not an option
subprocess.CalledProcessError: Command '['/usr/bin/python3', '-Im', 'pip', '--python', '/tmp/build-env-fuqkaxvi/bin/python', 'install', '--use-pep517', '--no-warn-script-location', '-r', '/tmp/build-reqs-oftqxpb9.txt']' returned non-zero exit status 2.
/home/tannewt/repos/circuitpython/shared-bindings/busdisplay/index.rst:447: WARNING: more than one target found for 'any' cross-reference 'ParallelBus': could be :py:class:paralleldisplay.ParallelBus or :py:class:paralleldisplaybus.ParallelBus``
i didn't even get there yet, I'm failing further back
lemme update to main
I believe my keyboard is low speed as well.
@slender iron maybe create a temp venv and pip3 install -r requirements-*.txt and then see how that goes. I basically did that (without the venv)
@lone axle are you looking at the connectionmanager underscore issue or don't have time at the moment? I was going to but I am about three interrupts deep at the moment
I'll run down the breaking package
I dumped my working venv state before switching
I'll look into it. I'm digging a bit off and on. Working on something different but it has long periods of waiting for things to load and save so I'm poking around on that circup / connectionmanager thing during those times.
i thought maybe circup had a special-cases list
That is odd that adafruit_bus_device seems unaffected, good catch on that. I first I thought maybe it had the same problem but wasn't noticed because it's a core module now too on most devices. But that isn't the case. Circup does correctly convert its pypi name to import name.
That could be. I do think there are some JSON data files that it pulls some of the meta info from. Perhaps in there or hardcoded somewhere within circup it's got handling for it.
@tulip sleet It builds for me just fine after installing requirements-docs.txt
(and fixing parallelbus)
If the value is null, Read the Docs will try to find a conf.py file in your project.
will PR to add it explicitly shortly
find . -name conf.py
./extmod/ulab/docs/manual/source/conf.py
./lib/tinyusb/docs/conf.py
./conf.py
...
no idea why the order changed
¯_(ツ)_/¯
fail_on_warning: true -- we'll see if that uncovers other things
I think that's what make html does already
looks like the scheduler is skipping docs builds too
ah, it only does as needed it looks like
Thanks for figuring this out so quickly!
docs builds have succeeded. I will cancel the board builds and merge.
@tame creek Please give me a ping, I'd like to discuss #8824.
watches RTD build
The --python error I am seeing is due to this: https://github.com/pypa/build/issues/745
unfortunate coincidence
undone 39 minute ago
I just was fiddling with the webhooks a few day ago
but I don't remember adding one, maybe I did
thanks
¯_(ツ)_/¯
i tested with absolute newest (Adafruit CircuitPython 9.0.0-beta.2-11-gf4166ce3e5 on 2024-02-29; Adafruit MatrixPortal S3 with ESP32S3)/PR8990 since that had fixed some MEMENTO issues but the error is still occurring
@slender iron my local doc build is fine now
i may have updated something with pip at the exact time build was wrong in pypi
popping my stack a few levels
fantastic!
@gilded cradle did you see my reply to you? https://github.com/adafruit/circuitpython/issues/8980#issuecomment-1965522826 I'm not sure you've found a bug
@tulip sleet MiniMQTT was merged, so opened 3 more README fixes
And at this point, I have a bunch of examples to fix and a call in Adafruit_CircuitPython_ESP_ATcontrol. Should I fix ESP_ATcontrol? It would be similar to ESP32SPI, but I don't have a way to test
@argonblue Please give me a ping, I'd
all the above are set_socket
all merged
are there guides that use ESP_ATControl
The code is in the ESPAT_WiFiManager
If I create the PR would someone be able to test?
I would say fix it and we'll merge it and wait for PR's to fix anything wrong. We aren't supporting it anymore.
we aren't going to test it
Sounds good
Print output muddies the serial output. Setting warnings to crash could actual raise an exception.
Fixes #8981
I suspect https://github.com/adafruit/circuitpython/pull/8926 because it changes SSL on ESP to match pico w. Any chance this fails on older Pico W builds?
Unsure. The test I was running fails on a Pico W:
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Raspberry Pi Pico W with rp2040
>>>
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Connecting to WiFi...
Connected to WiFi!
Year seems good, skipping set time.
Connecting to Azure IoT Central...
89.781: DEBUG - Attempting to connect to MQTT broker (attempt #0)
89.784: DEBUG - Attempting to establish MQTT connect...
Adafruit_CircuitPython_ESP_ATcontrol PR open
@justmobilize The test might work on a Pico W if you mpy-cross it first to get an .mpy
@jepler I remember you doing something with negative error numbers in #8926 or elsewhere but I cannot find it.
Checking is_writable_from_python always follows USB policy even if it is unplugged. Fixes #8986. It also makes writing from Python work when not on USB. It'll be interesting to see if folks have trouble with code only working off-USB.
Also does bare minimum for #8961.
@tulip sleet you were right, cicup has a dictionary that maps the non-standard names which includes adafruit_bus_device. I'll submit a PR that adds Connection Manager.
I wasn't able to reproduce this on a Feather nrf52840 Express. If it can't allocate to RAM for the scratch buffer it will use the very end of the SPI flash. Maybe the flash on the XIAO can't do that?
Here is my output:
mem_free: 1552
opening file
writing file
flushing file
closing file
mem_free: 1024
opening file
writing file
flushing file
closing file
Traceback (most recent call last):
File "code.py", line 24, in <module>
MemoryError: memory allocation failed, allocati...
Okay, I can look at that 1st thing tomorrow, maybe tonight depending on how things go
We should factor out the code that stores an erase sized block and overwrites the writable blocks within it. We have it shared for CP managed external flash but it isn't used for SDK or XIP managed external flash. We should share one implementation based on the external flash implementation because it is most flexible (allocating multiple write sized blocks instead of an erase sized block.) https://github.com/adafruit/circuitpython/blob/main/supervisor/shared/external_flash/external_flash.c#L57
Actually, had just enough time. confirmed it fails the same way on a Pico W in both 9.0.0-beta.0 and 9.0.0-beta.2
Also what's odd is it seems to be specific to some flow. when I get a NTP timeout, it's the right error...
The error on line 1090 above is from this library code:
try:
res = self._sock_exact_recv(1, timeout=timeout)
except OSError as error:
if error.errno in (errno.ETIMEDOUT, errno.EAGAIN):
# raised by a socket timeout if 0 bytes were present
return None
raise MMQTTException from error # <-- line 1090
Note that the library was just updated today to use ConnectionMan...
Getting everything to mpy did work (as in no memory error), and failed with an MQTT exception in new and old versions (and it's a MQTT exception, since it's -116).
Sorry I wasn't clear in my previous message.
Images automagically compressed by Calibre's image-actions ✨
Compression reduced images by 43.2%, saving 1.51 MB.
| Filename | Before | After | Improvement |
|---|---|---|---|
| assets/images/boards/large/cytron_maker_uno_rp2040.jpg | 222.72 KB | 47.81 KB | -78.5% |
| assets/images/boards/large/espressif_esp32_devkitc_v4_wroom_32e.jpg | 179.47 KB | 76.98 KB | -57.1% |
| assets/images/... |
@lone axle, when do you usually go through and create the releases for the CP helpers?
Monday's are typically when I go through the report and make releases for libraries that have new commits since their last release.
(I work a full day on CircuitPython on Monday's, the rest of the week my activity is more limited to evenings and weekend.)
Great. All I have left for set_socket removal is some examples. I'll get them knocked out tomorrow (and hope they get merged)
And apologize in advance for all the extra work...
Sounds good, and no need for apologies. I appreciate the work going into improving the libraries!
I think I'll surpass 30 PRs...
Oh I see, you're fixing things behind the scenes for me... 😉
Also, I see requests in Mismatched versions in .pre-commit-config.yaml, so it doesn't run daily, but my changes are clearly the problem
I'm thinking about taking a look at this canio issue. I know this issue is old, but can @jepler, @tannewt, @dhalbert, or anyone on the CircuitPython team point me in the right direction? I'm about to switch to Arduion/C just to avoid this bug.
I'm confused about the semantics of this. It doesn't seem to be guaranteeing exclusive access. If the filesystem is not locked, then you attempt to lock it, and if that fails you return false. If you succeed in locking it, then you increment the lock count and return true. But if it's already locked, then you also return true. Wouldn't you want to return false if the lock count is already > 0? And it's not guarded by interrupt guards. Is that an issue?
Since this is no longer just a check, I'd call this something like filesystem_lock_raise() instead.
Hey @romkey, have you had a chance to try beta 14.4 5 yet?
@UnexpectedMaker yes, just tested it in fact! Sadly no change, still slow but at least it also still works.
Other Apple beta OS's are on their release candidates now but macOS 14.4 still isn't, so we may have a couple more betas before it's released.
It is done! 8 final set_socket PRs to update examples
@romkey Thanks for checking. I'm not going to hold me breath about a fix coming in 14.4 ;)
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Adafruit Feather nRF52840 Express with nRF52840
Code/REPL
import time
import adafruit_ble
import adafruit_ble.advertising
ble = adafruit_ble.BLERadio()
connection = None
while True:
print("# ble scanner")
for adv in ble.start_scan(timeout=5):
if adv.complete_name:
if "E14_" in adv.complete_name:
print(f'{{"E14_2_NAME": "{adv.c...
@short tendon re the create_fake_ssl_context() additions. I don't understand this exactly. Would SSL work, but without actually checking authenticity or ? If Seesion was given a None ssl_context` instead, how would things behave differently?
I am not objecting, I just do not know.
It's the same as what requests.set_socket did, just under the covers. So if SSL is supported, like on an ESP32SPI it works fine. On a WIZNET5K it will throw a proper exception.
so what is "fake" about it? (I know that's the terminology that's used.) Is it becuase the SSL is set up later?
It just returns the same socket back
it's fake because SSL is handled in a different way instead of with an actual SSL socket, is that right?
I'm trying to understand how I would explain this in, say, a Learn Guide
Ahhh. Thinking
In *ix CPython, the context can wrap an actual SSL-capable socket, like https://docs.python.org/3/library/ssl.html#ssl.SSLContext.wrap_socket
So that's what it's doing too
ok, looking at this more, the context itself doesn't have a socket, but it has info about doing SSL (cert info, etc.). The "fake" context doesn't have that info: the device handles that itself
ok, I have never really paid attention to this boilerplate before, and now I have to.
The naming was the same in both requests and minimqtt. I can rename it to something better...
Sounds good
If Jeff gets wiznet5k working with ssl, we can revisit to see what we want to change
Since the helpers will need to be updated
Also @tulip sleet since I don't get notifications on issues. If something pops up from my work - feel free to ping me. I'll get to it quickly
what's the usage difference between create_fake_ssl_context() and get_radio_ssl_context()?
end users only ever use get_radio_ssl_context()?
you mean you haven't enabled notifications (email or otherwise) on all issues? Or just that you get it in email only?
Oh I guess I could do that... Normally I have it set on the organization level. Forget that I can do it individually
@short tendon - @crimson ferry 's q is for you, I think
@short tendon the ConnectionManager example (which works on ESP32SPI) haspy pool = adafruit_connection_manager.get_radio_socketpool(radio) ssl_context = adafruit_connection_manager.get_radio_ssl_context(radio) connection_manager = adafruit_connection_manager.get_connection_manager(pool)but the Requests ESP32SPI example has```py
ssl_context = adafruit_connection_manager.create_fake_ssl_context(pool, radio)
requests = adafruit_requests.Session(pool, ssl_context)
Oh, I should probably double check some of my changes...
Users should use get_radio_ssl_context, unless it's for something unsupported like the fona or ESP_ATcontrol
ah, ok, thanks
would it help if ESP32SPI, etc., had "get context" operations added, instead of ConnectionManager having to know about the boards?
@short tendon if you revisit the docs, these I think would have return values: https://docs.circuitpython.org/projects/connectionmanager/en/latest/api.html#adafruit_connection_manager.get_radio_socketpool & https://docs.circuitpython.org/projects/connectionmanager/en/latest/api.html#adafruit_connection_manager.get_radio_ssl_context
Yup. I did work on an unsupported board, and then didn't change back. Fixing now
yes, but we would need to add that to all "radios"
it could be a new requirement for radios
in the long run
ConnectionManager could check for the attribute for now
Added reference to https://learn.adafruit.com/circuitpython-with-esp32-quick-start/overview since the ESP32C3 chip requires different installation and workflow than is typical.
True, we could added and remove the special casing as we go...
Add reference to https://learn.adafruit.com/circuitpython-with-esp32-quick-start/overview since ESP32C3 chips don't get installed or used the same was as typical cp devices.
@tulip sleet I'm going to open a bunch more PRs. They will look like this: https://github.com/adafruit/Adafruit_CircuitPython_AdafruitIO/pull/118
Which removes the whole fake wording. except for the 2 old radios
I created PRs #1337 and #1338 to address this issue.
This issue is relevant to #1115 , although my PRs do not address that issue (which recommends a holistic approach to documenting board quirks).
So, suppose each "radio" had something you could import as ssl, and could do ssl.create_default_context(). Then you could remove knowledge about specific radios from ConnectionManager.
as with pool right now
since you can import blah as pool from various radios
Although at that point the spi radios would need to import connection manager to get the wrapper
the create_fake_ssl_context one for wrapping the socket
yes, I'm saying that code could be in the radio class instead. It could be duplicated, or could be imported from ConnectionManager
I can look at esp32spi and draft a PR to see how it looks
I just finished fixing the examples for the ones I pushed last night. 7 new PRs (Fona didn't need one)
I have been out of the loop on this. @slender iron may have an opinion
Adding some additional notes here after testing on a Pico W with
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Raspberry Pi Pico with rp2040
and this code:
import alarm
import board
import digitalio
import time
# Just to make sure we're awake.
with digitalio.DigitalInOut(board.GP14) as status:
status.switch_to_output(value=True)
time.sleep(2)
status.switch_to_output(value=False)
# Create an alarm for 10 seconds from now, and also a pin alar...
Okay, I found all the incorrect uses of create_fake_ssl_context. Should have 10 PRs. Sorry about that
and thanks for catching that @crimson ferry
some are drafts and some are not. Did you mean to distinguish some?
Fixed. Was waiting on tests to run. With the GitHub issues, it's been slow
for the helpers, do you think keep the names the same:
pool = esp.get_radio_socketpool()
ssl_context = esp.get_radio_ssl_context()
?
I thought that's what you did in the new PR's?
I am willing to wait for @slender iron 's comments here, since these are just in the examples.
The IOT repo examples make me think they really need to have wifi examples as well as ESP32SPI examples
I"m not asking you to do that!
e.g. there should be multiple groups of examples. There's a lot of boilerplate for ESP32SPI, unfortunately.
So that was the agreed upon methods originally. What happened is I switched to fixing things for Fona and ESP_ATcontrol and started to grab the wrong helpers
If we moved things into the "radios", the code would be even cleaner and you wouldn't need to import adafruit_connection_manager
and then the next set of PRs could go from:
pool = adafruit_connection_manager.get_radio_socketpool(esp)
ssl_context = adafruit_connection_manager.get_radio_ssl_context(esp)
to:
pool = esp.get_radio_socketpool()
ssl_context = esp.get_radio_ssl_context()
And would it be hard to add that to wifi.radio?
does the ethernet TLS case complicate things... ssl is independent of the 'radio'
yes, so that's why I was thinking of an ssl to import from the non-wifi radio classes
is the ethernet library different? @crimson ferry
I mean, ConnectionManager is still useful as a library because of the socket managment, is that right?
It doesn't. Because it could attempt to import ssl, and if works use it. if not it wouldn't
And yes ConnectionManager is still very much needed
I think ConnectionManager is useful with any library or combination of libraries drawing sockets from a common pool
Have you tested this with an external pull-up? Please be aware that pulling it high in software before going to sleep is not relevant, the pico won't keep the state when in deep-sleep.
i am thinking just esp.get_socketpool() and esp.get_default_context() or esp.ssl.get_default_context, trying to make it as close to CPython API as is reasonable. Do you need esp.get_socketpool(), or isn't that just a class?
I think that makes sense, native ssl would get imported by the WIZnet library
Yup
you were already doing from blah import blahblah as pool
so that pool is the same as blah.get_socketpool()?
yup
the point of get_socketpool is that you can write code for multiple devices, and not need to think about the imports
if we had radio.get... it would do the same
yes, could try to make the boilerplate to getting the socketpool and the ssl context be the same in the example. So that goes back to using connection manager rather than hiding it by calling it on the radio. Either you use import to make the names the same or you use connection manager to make fetching them the same
so my idea of pushing it down to the radio is not necessarily better
It depends. If we were to start adding other external radios, we would need to update the helpers... Not sure how frequently that happens
I think what we have now is good, and not needing to change it
if you push it to the radio, then it's the radio's responsibility to add an implementation
that was my motivation
and we can always update adafruit_connection_manager.get_radio_socketpool(radio) to try to call radio.get_radio_socketpool()
Probably best to roll out what we have and see what people say
so would you like the current crop of PR's to be merged to keep it all consistent?
I would
on it
I think you're paying plenty of attention 🙂
not sure what you meant, you mean radio instead of fake?
where?
is Adafruit_CircuitPython_AWS_IOT?
oops! sorry, now merged. They will all get new library versions in the next release sweep. but I won't do that now, since it's only example code, right?
@mortal kernel of historical interest to you concerning BLE on Pico W: <#1012732018183913513 message>
Some of them need new releases (for actual code changes), but they can all just wait for the release sweep
I don't have strong opinions about the 'fake' changes
I was able to reproduce this yesterday. It isn't clear what is going wrong so I've got more debugging to do.
I am reproducing watchdog timer crashes after five or so hard restarts due to errors caused by my not having the logo files. I am trying to trim to a small reproducible example
I was able to reproduce this bug just running a variation of the BitMap demo: https://learn.adafruit.com/circuitpython-display-support-using-displayio/draw-pixels
@tulip sleet forgot to respond to your examples comment... One of the things I tried to do in requests (and partly taken from minimqtt) was to make a base example for each (onboard, esp32spi, wiznet5k, fona) that had the same calls, and different init for the radio. And then since it's cleanest, the bigger examples are all WiFi based.
I am pruning the original-post example and still getting hard crashes (without printing of exceptions), and also seeing safe-mode after up to a dozen restarts.
But most significantly, I changed the name of one of the wifi parameters to xCIRCUITPY_WIFI_SSID to prevent the web workflow from starting up. After that, I see the exceptions printed, and am not seeing safe mode. So I think it may be related to wifi workflow.
This is copied from the shared implementation. The filesystem locking is for a shared blockdev lock. I'm happy to rename if you can think of something better. https://github.com/adafruit/circuitpython/blob/main/supervisor/filesystem.h#L51-L53
@jamesjnadeau may I ask how to get this flashed onto the device?
I found your post here: https://www.reddit.com/r/CardPuter/comments/19f7num/how_to_start_writing_your_own_codefirmware/kjhv4dg/ that mentions loading the bootloader using the instructions from the UM Feather S3 page. I followed those instructions and I think that I loaded the combined.bin bootloader successfully. Once that is loaded the device connects as a serial port but I don't seem to ever get it connected as a BOOT driv...
Hi,
Is there any documentation for what CP outputs on the serial port at boot up?
I have the SiLabs EFR32MG24 Dev Kit, and my custom board, both running the exact same 9.0.0-beta.2 build, but the captured output is different from each board. Trying to understand why I can’t connect to Thonny with my custom board, and why the transmitted serial boot sequence is different, with the same FW.
Thanks,
JT

On Feb 27, 2024, at 8:12 AM, Wayne Weeks @.***> wrote:
I lo...
Hi @bablokb - thanks for verifying! Yes, this is with an external pull-up resistor that's grounded to wake the device.
I also saw your power-tests repo (nice!) and that prompted me to poke a bit deeper, and wondering if the issue is seen when both pin and timer wakeups are used at the same time?
This is the sample code I used (with commented sections changed as appropriate) together with a pullup resistor at G14 and an LED at G15.
``...
CircuitPython version
Adafruit CircuitPython 8.2.9 on 2023-12-06; Seeed Studio XIAO ESP32C3 with ESP32-C3FN4
Code/REPL
# web workflow, not Python, not the REPL:
http://10.0.0.1/code # but use a valid IPv4 address for your unit.
Behavior
Instead of going to the device, I am presented with the
dialog which sends me to circuitpython.local if...
Added information:
http://ipv4_address/ does go to the welcome page
http://ipv4_address/fs/ does go to the file browser
http://ipv4_address/cp/serial/ does go to the limited serial interface
Commenting out _PM_row_handler also prevents the problem. That is the interrupt that updates the matrix.
I managed to get Circuitpython loaded. For anyone that might find this page in the future before there are steps published elsewhere these are the steps I took, I'm not entirely certain if they were all 100% necessary, but I got there in the end.
- Loaded the combined.bin bootloader using the instructions from the UM Feather S3 download page at circuitpython.org (hold GO while powering on to get into bootloader to use with the web flasher)
- Inside of this branch in
ports/esspressif/ra...
When both are used, the device wakes up only at the timer interval regardless of whether I ground the pin or not. However, in any period where I have grounded the pin, upon wakeup the device flashes once - so it must have still recorded a PinAlarm. Somehow it's not actually fully waking up the device in this situation for me.
I'm not familiar with the code, but at first glance like the pin alarm logic does [this](https://github.com/adafruit/circuitpython/blob/73fc021c1ac9f4066964...
Hi @dhalbert,
thank you for your comments.
I just pushed requested changes.
I thought I would throw some thoughts together on ConnectionManager (and at the same time try out the new adafruit-playground. If anyone wants to take a peak, it's here: https://adafruit-playground.com/u/justmobilize/pages/connectionmanager
A few things that puzzled me as I was looking through how ports/unix is getting built:
a) it seems like it maybe predates the conventions suggested in https://docs.circuitpython.org/en/latest/docs/porting.html ? So I shouldn't read to much into that organization for the unix port at least?
b) I'm also assuming this is pretty much only used to run basic tests, and nothing here really relates to circuitpython on a linux SBC?
c) I'm trying to follow why many of the modules aren't included in the current build here: https://github.com/adafruit/circuitpython/blob/54e78c89fc9e0d2b31544dfd03c30a159e8540a4/ports/unix/Makefile#L197-L210 - e.g. modmachine.c and modffi.c aren't included (the only place where SRC_MOD is initialized just includes the ulab module)
Hello all. It has been a minute since I have posted to this discord. I had retired several years ago but kept up with the Adafruit YouTube. I have ended up contracting for a company in their Reasearch and Development department. I have become the bridge between Project Technical Design and Software Development that supports what ever the business and the design teams come up with. So much fun that I get to do what I have a passion for and get paid.
So, during some research to solve a problem, I found a ready-made device that fits the bill. The idea is to remotely server files to a device that makes a request based on an alert signal, then have the device present these files via USB to a connected host.
What I came up with is the Lilygo t-embed. I saw that @lethal abyss created a port for this device and I am anxious to get busy. So, I have downloaded the latest version of CP 9.0 beta, from the lasty build.
I flashed the ESP32S3 chip and I am able to see the "Hello World" on the screen. Getting exited now.
Then, when I looked at the code provided, I saw the '/SD' folder and read the text inside.
So, my question is, can I use the Wi-Fi to download files to the built in SD card reader and then resent them to the USB host as a simple file list?
Any feedback will be appreciated.
This question is about CircuitPython not the t-embed.
I'm new, so forgive me if this isn't the right spot to ask. I'm interested in working towards getting a currently unsupported ESP32 dev board device working with CircuitPython. While I have no doubt I can make it work for myself, I'm curious if there's any way to include my work in the official port for others to enjoy, or if that is reserved for the board makers themselves to handle.
You can make a PR into the circuitpython repo: https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython
We all benefit from users adding new ones
Perfect. I had read that but the language therein was unclear if community could contribute or just the board makers, as it starts with "You've designed a circuit board ..."
I've seen many of us ordinary folks open up PRs 🙂
@fringe yarrow Adding a board, especially one similar to others out there, is pretty straightforward
choose the board closest to yours (same SOC or module, etc.), and tweak what's necessary for special pins, peripherals, etc
Thanks.. It wasn't so much the technical component I was unsure of, but the policy regarding who can add new boards.. I've done the preliminary pin reassignments from a similar board, now I'm at the whim of the postal service until I get the device.
Curious, which board is it?
"MakerGo ESP32-C3 SuperMini". Very similar to the Seeed XIAO ESP32C3.
ports/unix is very close to the micropython unix port. Its main use is to run tests. jepler is working on a "posix" port that would be more in line with standard CircuitPython. However, it is still not necessarily a substitute for the Blinka library. modmachine and modffi are more MicroPython.
some mention of posix port here: https://github.com/adafruit/circuitpython/pull/8900
I have "Featured" your ConnectionManager Playground post.
Could you add something that makes clear some examples are "old way" and some are "new way"? Maybe with headings.
Thank you for the pointers @tulip sleet ! I was casting about for some way to run basic automatic tests on some of the CP modules - if @onyx hinge is working on something that maybe was intended, or could do that - sounds perfect. I'll poke around at https://github.com/jepler/circuitpython/tree/port-posix in the meantime
it's far from ready for prime time but you're welcome to look at the tree!
posix port isn't going to include "modmachine" or "modffi" you mentioned, as those aren't used in circuitpython.
Very cool! Were you intending to use it for also implementing some sort of virtual hal to test modules, or was it for a different purpose?
My main goal right now is to be able to test everything that is implemented in shared-modules. I have added some of those things to the circuitpython posix port, "coverage" flavor, but each one is an ad-hoc addition, rather than using the circuitpython-specific py/*.mk files like the ports that run on hardware
I wouldn't rule out implementing things within its common-hal (like, say, some kind of mock digitalio) but that is out of scope for me right now, I'm more interested in just passing existing tests.
Fantastic - I'll continue looking at that branch, and best of luck with merging it back, sounds like it'll be really handy.
right now the posix port status is 799 tests performed (49823 individual testcases), 177 tests skipped, 48 tests failed
vs the unix port 890 tests performed (53158 individual testcases), 890 tests passed, 86 tests skipped
So there are 48 failures + 91 skips to investigate and resolve
Ha! Congratulations that there are 600+ tests already passing 🙂
and many of the skips are fine too, like vfs_lfs (circuitpython does not use littlefs)
at least 26 failures are due to differences in floating point behavior (test output includes printing floating point numbers)
@tulip sleet done! I made them h2 which makes them linkable as well
Nice - getting quite close then.
I'm not sure when I'll get back to work on it, I have had this last week off and I suspect there's lots of issues & new hardware stuff to tackle before I do this "fun stuff". goodnight for now, and thanks for the interest in what I'm working on!
Thank you for this! It's been requested a number of times.
Tested on Trinket M0
#8989, which allows renaming the HID interface, is a potential model for code to do this for MIDI.
@short tendon was working on porting my fitbit project from 8.2.2 to 8.2.10 and loaded up new libraries. Was pretty neat to see my code.py requests error with "no module named connection manager exists".
Even though I know connection manager is a dependency of requests it didn't affect my old code at all. Still works great. My guess is there should be some transitional code for 9.x in there somewhere?
and yes i found the lib and added it immediately
So anything using onboard WiFi, will be 100% seamless
I put this together yesterday: https://adafruit-playground.com/u/justmobilize/pages/connectionmanager
It definitely was. Great job. Didn't notice a thing other than the missing module error.
I should probably add something about circup on that doc, since it would have taken care of that for you...
i don't use circup, just manual 8.x bundles drag and drop from circuitpthon.org/libraries
And thanks, it was a fun project
I don't either, but I want to try it (especially for fonts)
Now I get to watch help-with and see if there's anything new to tackle, or if I want to work on some personal libraries
it isn't 8.x vs 9.x, should work on both. The latest circup 1.5.4 handles ConnectionManager (its naming without an underscore is special-cased: there is a list of such special cases). I was old-school and was not using circup, but then I discovered how much time it was saving me. It also does upgrades/downgrades properly with 9.x now.
I was just trying this and can't get it to work. Anything special I need to do to get it to detect the version? Everything looks like this with verbose:
03/03/2024 10:20:46 INFO: C:\Users\justi\AppData\Local\adafruit\circup\adafruit\adafruit-circuitpython-bundle-py\adafruit-circuitpython-bundle-py-20240301\lib\adafruit_requests.py
03/03/2024 10:20:46 INFO: Extracted metadata: {'mpy': False, '__version__': '0.0.0+auto.0', '__repo__': 'https://github.com/adafruit/Adafruit_CircuitPython_Requests.git'}
And so it's not upgrading from anything
The .py bundle files are not rewritten to include the version information when they are bundled. So they have the EDIT: This is wrong. They used to have the version number.0.0.0+auto.0 version number.
we could argue about whether this is good or bad, but they are the original source files, as found in the repo
So I'm assuming I'm doing something wrong... I assumed circup update would update requests==2.0.3 to requests==3.0.0. Does it not do major versions? I assumed since it installed adafruit_connection_manager that it would
But it's not even doing 2.0.3 to 2.0.5
I am on 9.0.0-beta.2
It will not update the .py files. what is circup --version
1.5.4. I don't have any .py files. They are all .mpy
03/03/2024 10:20:48 INFO: {'path': 'D:\\lib\\adafruit_requests.mpy', 'file': 'adafruit_requests.mpy', 'name': 'adafruit_requests', 'repo': 'https://github.com/adafruit/Adafruit_CircuitPython_Requests.git', 'device_version': '2.0.3', 'bundle_version': '0.0.0+auto.0', 'bundle_path': 'C:\\Users\\justi\\AppData\\Local\\adafruit\\circup\\adafruit\\adafruit-circuitpython-bundle-9mpy\\adafruit-circuitpython-bundle-9.x-mpy-20240301\\lib\\adafruit_requests.mpy', 'mpy': True, 'min_version': '9.0.0-alpha.1', 'max_version': None}
03/03/2024 10:20:48 INFO: {'path': 'D:\\lib\\adafruit_connection_manager.mpy', 'file': 'adafruit_connection_manager.mpy', 'name': 'adafruit_connection_manager', 'repo': 'https://github.com/adafruit/Adafruit_CircuitPython_ConnectionManager.git', 'device_version': '1.0.0', 'bundle_version': '0.0.0+auto.0', 'bundle_path': 'C:\\Users\\justi\\AppData\\Local\\adafruit\\circup\\adafruit\\adafruit-circuitpython-bundle-9mpy\\adafruit-circuitpython-bundle-9.x-mpy-20240301\\lib\\adafruit_connection_manager.mpy', 'mpy': True, 'min_version': '9.0.0-alpha.1', 'max_version': None}
which board are you doing it on? I will try to replicate
A UM FeatherS3 with ESP32S3
I just put an old version of requests.mpy in the lib folder and then copied a random example from the requests repo
i am seeing what you're seeing, but I thought I fixed this. I certainly tested it a while ago. I had to change how it finds the version number in .mpy files for 9.x
the bundle files look OK. They have a version number
this is wrong 'bundle_version': '0.0.0+auto.0'
I also tried specifying the version and board, but got a cpv undefined error (assuming CP version). Happy to get the whole exception if needed (when back at my laptop)
i will do some instrumentation locally of the current circup code to see what is going one
Thank you. I'm also happy to dig in, now that I know I'm not crazy
@short tendon The version info is extracted from the .py bundles. I was wrong when I said we don't rewrite the version number. We did, and it broke between the 2023-12-10 bundle and the 2023-12-15 bundle (there are no intervening bundles there, so there was some change in the bundle build code).
Add some missing Pin definitions for the senseBox MCU-S2 with ESP32S2
Ahhh. Hopefully a small set of changes to look at
Please let me know if I can help
Something in here, I think: https://github.com/adafruit/circuitpython-build-tools/pulls?q=is%3Apr+is%3Aclosed. I will not be able to work on this for the next several hours.
Build tools not working? Sorry, catching up while I update my desktop.
The issue is that it isn't replacing the version text now, so it still has the placeholder in libraries?
Oh, it's not a library, but the bundle?
@tulip sleet and @proven garnet found it
PR here: https://github.com/adafruit/circuitpython-build-tools/pull/115 waiting on tests before I mark it ready for review
And it's ready
@tulip sleet is it possible to rebuild the bundle? Or just need to wait until it runs tonight?
I did run the rebuild, but it said it was already there, so it didn't upload. I could try removing today's files and try again.
Makes sense. I'll leave that up to you. Can easily wait until tomorrow to finish playing with it
I can make a release of something in the bundle. It's actually rebuilding the March 1 bundle -- no changes since then.
released requests 3.0.1
They'll be a bunch when foamyguy, runs through all my updates...
rerunning again...
@Justin this release does not have the versions in the .py, but I forgot to make a circuitpython-build-tools release with your PR change. Now I did, but I'm not sure I can do it again. I could try, but we might have to wait for the day rollover
It's the weekend. I can wait 😉
I manually set the version in the downloaded files and that worked. So I'll just update my doc after the release tomorrow
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; M5Stack AtomS3 with ESP32S3
Code/REPL
import displayio
import board
# Display setup
display = board.DISPLAY
display_group = displayio.Group()
display.root_group = display_group
# Try this with a red image, it shows up blue
# Create a TileGrid to hold the bitmap
logo_tile_grid = displayio.TileGrid(logo_bitmap, pixel_shader=logo_palette)
# Position the image in the upper m...
This was added by @jins-tkomoda in #8474. @jins-tkomoda have you seen this issue?
I tried this simpler example:
import time
import adafruit_ble
import adafruit_ble.advertising
ble = adafruit_ble.BLERadio()
while True:
print("# ble scanner")
for adv in ble.start_scan(timeout=5):
if adv.complete_name:
print(adv.complete_name, adv.rssi)
time.sleep(1)
# Stop scanning whether or not we are connected.
ble.stop_scan()
I ran it for a while and it did not crash. You are looking at advertisements from a particula...
Immediately after posting the above, I saw this, after running for a while. Have you seen something similar?
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "i8995.py", line 9, in <module>
File "adafruit_ble/__init__.py", line 275, in start_scan
MemoryError: memory allocation failed, allocating 51370 bytes
@dhalbert
I will check on it over the weekend.
I did not check to display images, so the process may be BGR order in the middle of the process.
I think the "MemoryError: memory allocation failed, allocating 51370 bytes" or similar message appeared with CircuitPython 8.x that I tried before. Then I have read something about a memory fix in CircuitPython 9.0.0beta so I have tried. Here comes the "RuntimeError: buffer too small" error output. The device is a commercially available bike component based on a Würth Proteus 2 (nrf52832). Do you have some test code for me to get the raw advertisement data that might help localize the problem?
- add tuh_event_hook_cb() in SRAM, required when updated to latest tinyusb
- bump up pico-pio-usb to latest
- bump up tinyusb to latest for new tuh_hid_receive_abort(), and all endpoint abort when SET_CONFIGURATION
- fix #8885: issue is resolved by either
- detach driver from kernnel or
- SET_CONFIGURATION which also abort all pending trannsfer for all non-control endpoinnts
https://github.com/adafruit/circuitpython/pull/8999 should fix this issue, resovled by either
- detach driver from kernnel or
- SET_CONFIGURATION which also abort all pending trannsfer for all non-control endpoinnts
This PR resolves #8998 issue.
Eliminated unnecessary color order commands.
Please review and merge.
I’m trying to figure out if the recent 9.0.something “ePaper no longer shows error” is by design or mistake. To be specific, code errors and exiting to REPL no longer writes to my ePaper board.DISPLAY.
@tulip sleet @slender iron - we discussed the underlying behavior issue #8721 and #8675. (I am not using CIRCUITPY_TERMINALIO=0).
I have looked at recent commits and closed issues and can’t find what has changed.
In our prior discussions I was told that errors should show on ePaper displays just like other types of displays. The current behavior contradicts this conclusion.
I am fine with either behavior but I need to know is which behavior is correct going forward.
When a CircuitPython board …
- had an ePaper attached and 1. exposed the ePaper as board.DISPLAY and
- the display has been setup in the board firmware and
- the CircuitPython code has not made any changes related to board.DISPLAY
… and the code stops with an error, will CircuitPython attempt to render the error on the ePaper display or will it suppress the error on the ePaper display?
@short tendon overnight 2024-03-04 py bundle looks good! There is a version for adafruit_requests.py. Thanks!
@tulip sleet I saw. I could of sworn yesterday it still added ConnectionManager when it wasn't there, but now it's not. Should it? Or only on install?
I have just downloaded CP 9.0 beta for a project and noticed that there is an /sd folder with a text file named placeholder. The file contains the text: "SD cards mounted at /sd will hide this file from Python. SD cards are not visible via USB CIRCUITPY."
Can someone explain the last sentence about SD visibility?
Would it be expected that displayio.release_displays() should clear any RAM that was used to initialize the display that is being released? We've run into an issue where a device has a display initialized in the core, but in code.py if you release it and attempt to initialze it again it raises a MemoryError which makes it seem like perhaps the release() didn't give up some portion of the memory since it did fit successfully when the core initialized it. I can share some more specific info and reproducer stesp if it's helpful but I'm mostly trying to understand if that behavior is considered problematic or not, RAM usage and management is still a bit of a black box to me.
I think it means If your project uses an SDCard and your code initializes the connection with the SDCard CircuitPython code will be able to see and modify files on the SDCard (by looking inside of the /sd/ directory). But your PC that you have the device connected to will not be able to see any of the real files inside of /sd/ only the placeholder.
So you can't just connect the microcontroller it to a PC and copy files directly from the SDCard to the PC. You'd have to take out the SDCard and put it into a USB SD adapter or something similar in order to access it's files from the PC.
(Worth noting that web workflow does allow you to see and modify files on the SDCard if it has been initialized in code though. Which is very convenient compared to taking the card out and back in again over and over.)
@lone axle Thanks. I am trying to make the device/board look like a UDISK but only see the SD card. But the CP code needs to make changes to these files on the SD card. I know that I cannot have both configurations in storage at the same time. Basically unless the device has not "turned on" the CIRCUITPY drive it just looks like a regular USB drive.
Is tat possible with CP 9.0?
To the best of my knowledge it's not possible with CircuitPython to have a PC connected via USB be able to view or modify any files on an SDCard that is connected to the microcontroller.
So the SD card is for CP use only?
That is my understanding yes as far as USB connection goes.
I think there is some ongoing work to make that possible, but it can take some time before it's working
if you did update, then maybe it doesn't look at the pre-reqs, though perhaps it should
It doesn't... 😦
But I just pushed up a branch that does. Need to test it a bit more
Would you we willing to peak and see if anything looks off?
I still can’t get my SiLabs EFR32MG24 custom board to connect to Thonny and I have been researching this problem further. With CP 9.0.0-beta.2 the RGB LED flashes periodically so I know CP is running w/o issue. The problem appears to be with the VCOM serial port configuration.
To debug further I took the very simple ‘Platform - I/O Stream EUSART Bare-Metal’ example from the SiLabs SS5 tools, built the code and flashed to the SiLabs xG24 Dev Kit board with no problem. Since this is just a s...
Should we add settings.toml and /sd/ to these generated file screenshots?
That is a good idea, but I think we should do it coincident with 9.0.0 final being released.
Maybe we should make a "to do list" issue in circuitpython for 9.0.0 final. I can do that. Does the PR above need to have submodule update somewhere else, or just merging that PR will fix it?
That would be good I think as well. For the screenshot maker I don't think it's used as a submodule on any repos. It gets executed from an Actions cron task I believe but I don't think it involves use as a submodule.
it looks like the actions just clone it from the public repo URL. So as soon as a change is made and merged the next time that task runs it should use the updated screenshot maker and create the screenshots with whatever modifications were in the changes.
@tannewt pretty sure it's just fancy camera example: https://github.com/adafruit/Adafruit_CircuitPython_PyCamera/tree/main/examples/camera
The files on the SD card aren't readable over USB. We hope to add that in the future.
I checked this recently and did see an error message appear on eink. I'm not sure why it stopped working for you
Edit this as needed.
Before release:
- [ ] Update frozen modules.
Immediately after release:
- [ ] Merge https://github.com/circuitpython/CircuitPython_Library_Screenshot_Maker/issues/16. Adds
/sdandsettings.tomlto library screenshots. - [ ] Change defaults for
stableand other settings on ReadTheDocs.
Not too long after release:
- [ ] Stop building 8.x.x library bundles.
- [ ] Add last 8.x bundle to https://learn.adafruit.com/welcome-to-circuitpython/frequently-asked-q...
@slender iron - what hardware did you test with? I will compare my board to it.
iirc a magtag since the screen is built in
<@&356864093652516868> Reminder that the meeting is in just under 90 minutes. The notes doc is here: https://docs.google.com/document/d/1NxTW_z8Ewhjbh9voOGli4Jt0PIRy9slbp2u51NzX02s/edit Talk to you soon!
I bet it did! I'm slowly working on a new compiler attribute noxip to make this automatic: https://github.com/tannewt/llvm-project/tree/noxip
Connecting a serial terminal to the VCOM Tx/Rx signals there are text strings transmitted out from CP at boot, but all the characters are scrambled.
This sounds like the UART is going the wrong speed.
Is there any documentation for what CP outputs on the serial port at boot up?
When using UART for the serial console, the first text output is "Serial console setup\r\n".
(Written after a oral conversation with @tannewt.)
It's now possible to race against USB and be able to write a file before USB has finished coming up. I tested on a Metro M0 with this code.py:
import time
f = open("foo.txt", "a")
f.write(str(time.monotonic()))
f.write("\n")
time.sleep(2)
print("write succeeded")
If you press RESET, then (at least on my Linux machine), code.py will run before the USB enumeration finishes. It will succeed at writing to foo.txt, and ...
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2-4-gf23205c822 on 2024-02-20; Adafruit Feather ESP32-S2 TFT with ESP32S2
Code/REPL
import socketpool
import wifi
from lib.adafruit_httpserver import Server, Request, Response
pool = socketpool.SocketPool(wifi.radio)
server = Server(
pool,
root_path="/static",
https=True,
certfile="cert.pem",
keyfile="key.pem",
debug=True,
)
@server.route("/")
def base(req...
It's in May
☺️
not voice sorry
I tested with beta2 and did see some flakiness even though I initially thought it was working.
boot_out.txt:
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Adafruit Camera with ESP32S3
Board ID:adafruit_esp32s3_camera
UID:0740D1DC2B0D
[2K[0Gboot.py output:
# SPDX-FileCopyrightText: 2023 Jeff Epler for Adafruit Industries
# SPDX-FileCopyrightText: 2023 Limor Fried for Adafruit Industries
#
# SPDX-License-Identifier: Unlicense
"""Automatically cr...
@onyx hinge could the new core ssl changes also be available on boards that already have ssl, like espressif and Pico W? ssl is big, but maybe not the surrounding changes? this would allow, for example, espressif feather + ethernet featherwing, or Pico W + WIZnet hat.
love the wiznet rj45 pico evb board, thanks @onyx hinge
@crimson ferry yes, the ssl changes would apply anywhere that the ssl module is available. It's just that enabling ssl on new boards is not likely to happen because of the amount of code it brings in, so you could do ethernet on a feather esp32s3 or similar. not that I tested this scenario.
@short tendon haven't forgotten about testing your time library- just haven't had the time (ha)
No worries!
@short tendon these SSL changes I'm talking about might impact the speed of SSL socket operations slightly (because they replace what were C function calls with Python function calls) -- I have a feeling you couldn't measure it for (say) connect() which is once per socket, but it might add up for each internal recv() or send() call. Did you write anything that might help me benchmark this while working with socket manager? I could just find a 100kB file and stream it over https, which should be hundreds of individual calls.
In 9, the framebuffer is initially allocated in the "outer heap"
Not really. I have one thing that might help. If you go to my write-up: https://adafruit-playground.com/u/justmobilize/pages/connectionmanager and search for session_id you'll see something I wrote for multiple sessions. Currently it grabs tiny chunks of data. If you added some timing and maybe a bigger file, it could be a good start...
thanks folks!
Thanks all!
Note that the US changes to DST ("summer time") next weekend
so if you're not in an area that follows the same DST rule the time locally may be shifted by 1 hour
the time will become "2PM in UTC-4" which is a confusing way to talk about it 🙂
Thanks for hosting Scott. Have a great week everyone!
Thanks scott!
It's y2k two times a year. Yey
Thanks
I am glad, for good or bad, Canada flipped to match the US when they changed to avoid mass confusion
OK, wild and I hope to disprove this theory .. but is the failure not happening when at a repl prompt??
(web workflow reading /sd)
Does anyone know if this syntax for string concatenation across multiple lines of code is intended to be supported by CircuitPython / Micropython?
str_val = (
f"firstline"
f"secondline"
)
print(str_val)
I'm noticing that CPYthon allows this but I'm getting SyntaxError: invalid syntax on CircuitPython
Listing it fails completely?
I think its a known issue. Not sure what issue is for it though
@slender iron specifically I'm testing getting the content of a file I know exists on my sd card, /sd/cmdline.txt via curl
that should work as long as the sd cart is mounted via code.py
Hmm, do you know if it's known issue with the slash syntax as well?
timestamp = f"firstline" \
f"secondline"
no, I'm not sure. could be f-strings only too
@lone axle yeah f-string concatenation is not in circuitpython
also not in micropython unless they added it recently
Or a better question might be what is the best or recomended way to shorten a very long string that pylint complains about?
you'll have to use a pylint disable
if the problem is that your expressions are long, you can assign them on earlier lines so your ultimate f-string is shorter, like f"{a}{b}{c}"
you can also use old-school .format()
instead of f"{this is complicated}{extremely complicated}{I have dotted names or function calls}"
yeah, they are basically a bunch of these: {time.localtime().tm_mon} they could be applied to variables with shorter names before being put into the string.
@onyx hinge I would love (LOVE) to get isort, some update pylint global disables and a generic tox in cookiecutter. Asked a question on the current isort PR. and curious if (if it's wanted) would be better as 1 PR or multiple
@short tendon I'm not likely to be working on that right now. I don't have positive experiences with tox but the rest sounds good.
do you know if it's possible to do the :02 type thingy (I don't know the proper name of this formatting thing) with .format()
from something like this {time.localtime().tm_hour:02}
"{:.2f}".format(time.localtime().tm_hour)
Thank you!
I am shocked that adabot allowed this f"{this.... 😉 somehow the term f-strings always makes me chuckle....
When you have a few minutes can you check out the existing isort PR (no rush)? You made a comment on needing another global and wanted to see why and if there's a way around it
@short tendon send me the link here and I'll give it a few moments
this is not ringing any bells for me at the moment, sad to say
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/1wyHuyLhHVop15ZEMZg2WSXNp-kdvO98wNbPvHk5b6WA/edit?usp=sharing
@short tendon yeah I have no idea at this point. sorry 😕
okay. I'll try a few and see
Yup! Similar to https://twitter.com/mariatta/status/1051942829516189696
This is a locking + background tasks problem.
The camera demo is pretty frequently writing to the display bus, which is on the SPI bus shared with the SD card. During this long-running SPI request, background tasks are serviced.
If the SPI bus happens to be locked when the workflow http handler gets called from a background task, then sdcardio_sdcard_readblocks will indicate an error code because lock_and_configure_bus fails. This bubbles up into giving a 404 response for e.g., gett...
@slender iron ^^ I have no idea the fix, but I think I get the cause now.
I instrumented a bunch of code from workflow -> vfs -> oofat but you can easily just add a print for failing to lock the bus in sdcard read to demonstrate this is the source of the failure
you make this change to see on the console that the failures are due to sdcard readblocks failing to lock_and_configure_bus:
diff --git a/shared-module/sdcardio/SDCard.c b/shared-module/sdcardio/SDCard.c
index 20c5afef0e..4a67d1f826 100644
--- a/shared-module/sdcardio/SDCard.c
+++ b/shared-module/sdcardio/SDCard.c
@@ -363,6 +363,7 @@ STATIC int readinto(sdcardio_sdcard_obj_t *self, void *buf, size_t size) {
mp_uint_t sdcardio_sdcard_readblocks(mp_obj_t self_in, uint8_t *buf,...
I think you are on the right track. I don't know what the right fix is either...
I hadn't thought about sharing the SPI bus
this feel like a moment when having an RTOS would be nice
ya, I think we're trending that way. not sure how that'd save you here though
to make the camera demo work better we could have a mode that stops writing to the screen, it should work then.. but you have to know to enter this mode.
or just lock out web workflow during display updates
yeah the specifics are unclear to me, except that with tasks maybe lock_and_configure_bus could just block (yielding internally) in this case, requiring that "the other lock holder" was in a different task.
tcp connections can wait
this seems feasible, I can look into it
you could try to be a little fancier and only do it if an sd card was mounted
Please try an absolute newest build. 8.2.9 is pretty old at this point.
Ok @dhalbert. I reverted everything but the cache fixes, comments and web workflow change.
I'm thinking about taking a look at this canio issue. I know this issue is old, but can @jepler, @tannewt, @dhalbert, or anyone on the CircuitPython team point me in the right direction? I'm about to switch to Arduion/C just to avoid this bug.
We'd love help. You can chat with us in #circuitpython-dev on Discord and we can help with any bumps you hit. Build instructions are here: https://learn.adafruit.com/building-circuitpython The STM canio implementation i...
any known issues using make_transparent with OnDiskBitmap? (not working for me, imageload does work with same bmp)
not off the top of my head
@tulip sleet you looking at rgbmatrix now?
was going to do that soon. Just doing reviews
@slender iron maybe it's me? is this the nominal approach?
>>> import displayio
>>> from adafruit_pyportal import PyPortal
>>> pyportal = PyPortal()
>>> bitmap = displayio.OnDiskBitmap("color_test.bmp")
>>> bitmap.pixel_shader.make_transparent(0xffff)
>>> tg = displayio.TileGrid(bitmap, pixel_shader=bitmap.pixel_shader)
>>> pyportal.splash.append(tg)
@lone axle hey. any chance you've used make_transparent with OnDiskBitmap? (see above for more context)
I'm pretty sure that I have done it successfully in the past. Can you share this .bmp I can try a few things on my end to see if there was some gotcha that I am forgetting.
It's been a year, but I recall looking at that doing OnDiskGif and the code looks correct to me. I have to run out but I can glance through it later if no one has figured it out
@lone axle thanks. there you go. pretty simple test check. just make one of the squares transparent. (i was trying for white)
What color are you intending to make transparent?
okay, I'll give it a try, thank you.
but also tested 0xf800 for red, which also worked with imageload
>>> import displayio
>>> from adafruit_pyportal import PyPortal
>>> import adafruit_imageload
>>> pyportal = PyPortal()
>>> bitmap, palette = adafruit_imageload.load("color_test.bmp")
>>> palette.make_transparent(0xf800)
>>> tg = displayio.TileGrid(bitmap, pixel_shader=palette)
>>> pyportal.splash.append(tg)
^^ that works as expected
this one works to make the black transparent with ODB. I'm not sure about the white though still looking into that I would have expected yours to work, but perhaps the colorspace conversion doesn't come out quite to 0xffff
bitmap = displayio.OnDiskBitmap("/color_test.bmp")
bitmap.pixel_shader.make_transparent(0)
I believe it's ColorConverter, but I'm not sure. ODB creates it internally
it's colorconverter. i checked via type.
@tidal kiln I'm not entire sure how to check it, but I think that original .bmp might be in a weird color space perhaps? I opened it in gimp and re-exported it choosing 24 bit RGB888. with this one I can use bitmap.pixel_shader.make_transparent(0xffffff) and it makes the white part transparent
notably it's a few kb larger as well.
does imageload also return a colorconverter?
i think so. let me double check though.
>>> import adafruit_imageload
>>> bitmap, palette = adafruit_imageload.load("color_test.bmp")
>>> type(palette)
<class 'ColorConverter'>
>>>
interesting, the annotation isn't quite right in that case. It does also allow you to pass a PaletteConstructor to it in order to control which type it will use.
yeah the annotations in imageload are all wrong
I was looking into fixing them, but that requires some advanced stuff
and it would probably not be supported by ide autocomplete, so I see little point
ok, turns out what I was stuck on was not a hang, but a mysterious lack of printing when the web workflow is enabled:
import time
import microcontroller
print("sleep for five seconds")
time.sleep(5)
print("reset in five seconds")
time.sleep(5)
microcontroller.reset()
if the web workflow is enabled
CIRCUITPY_WIFI_SSID = "myssid"
CIRCUITPY_WIFI_PASSWORD = "mypwd"
CIRCUITPY_WEB_API_PASSWORD="something"
then the first print statement's output doesn't show up.
if the web workflow is not enabled (I renamed CIRCUITPY_WIFI_SSID, then the first print shows up
i am not sure that has anything to do with the original issue, but the original issue's test program does a reset, like the above, and I was confused by the missing print for a long time due to trying to instrument the test program
shows up on usb?
maybe the web workflow wifi connect is delaying usb enum enough that it doesn't get going in the 10 seconds you are giving it
right, showing up on USB. I am not connected to the web workflow. Your theory makes sense
The original implementation couldn't allocate to a region that was just freed even though the freed region was the same size as the new request. This was due to allocation sizes being rounded up during search but not when marking the region in use.
Fixes https://github.com/adafruit/Adafruit_Learning_System_Guides/issues/2746
wooo, went down the tlsf rabbit hole and found a bug
made a PR to the esp tlsf implementation too
I had a thought over the weekend.
In CPython, there is os.environ which returns a dictionary of the users env vars.
Since we are doing os.getenv(key) = settings.toml[key]. what if we returned the whole settings as a dict in os.environ?
This way it could help people move from secrets, since it could be the same dict object
macOS 14.4RC out today, no change (if anything it feels even slower but I didn't actually time it)
Ahh CR@P - Well, thanks for the update :)
@short tendon or we could make os.getenv some kind of "environment proxy" that calls getenv behind the covers (but it would need some kind of implemention of keys() then probably).
A lot of the current implementation is designed around the idea that the environment might be big compared to RAM, so it's all processed incrementally. That idea might be wrong.
If there are already "ideas", I'm completely out of the know. The settings.toml I have are all just secure keys I wouldn't commit. I think the biggest I have is 10 keys. Everything else is either in code or a separate config.json that I load and parse. I would agree if settings.toml could be large, this wouldn't be a good idea...
I tested this by fetching a .txt file repeatedly using curl while running the fancy camera demo. (100+ times without failure). I also repeatedly loaded the filesystem view http://.../fs/#/sd/ which worked 10+ times without failure, but does take some time (multiple seconds) to show a listing with a few dozen files.
(I suspect there's an accidentally quadratic behavior in oofatfs to stat every file in a directory, because it repeatedly does a linear search of the directory for the stat info...
Incorrect error handling in send/recv would raise an OSError with an incorrect (negative) code.
It's likely that this bug was always happening in the Pico W implementation, which became the basis of the current shared implementation.
Push handling of WANT_{READ,WRITE} down into mbedtls_raise_error and use it in recv_into and send.
Tested by connecting to google.com:443, sending nothing, and trying to read a byte:
import socketpool, ssl, time, wifi
socket = socketpool.Socke...
ah I think I have the story wrong 🙂 we wanted to be able to read the environment file from C code without doing any allocations at all, a requirement during the 8.x days for stuff "outside the VM", like setting up wifi workflow.
Ahh, but isn't it for both?
- knowing WiFi
- safely storing creds and not committing them
I'm trying to tell you the story of why it's just fetching single values, not all of them
for context, not because that's the best way forever
Ahhh. I think we can have both. I don't think adding os.environ would replace os.getenv or even that the later would use the former...
another thing about os.environ is that it brings mutability. os.getenv is immutable. would a hypothetical CP os.environ be a read-only dict, would edits disappear at the end of a session, would they modify settings.toml?
I know in CPython, the changes only exist in the session. And don't change the actual env vars. But it might be a learning curve with people thinking it would...
I'm excited about this PR but realistically we should probably not rush it in before 9.0.0.
@jepler please let me know if I can do any testing or benchmarks
@jepler When ready, I can also help testing HTTPS serving with adafruit_httpserver
@FoamyGuy @tannewt would you mind re-testing this with latest (after #8999), it seems that PR also fixes this issue as well when bumping up tinyusb
thank you @tlyu and @eightycc for detailed explanation, I have pull out my good-old macbook with mac0s 12.6 and it seems to be able to reproduce the issue. I will do start to investigate and review your PR
I was not involved as much back when it occured, does anyone know if there was some automated utility used when pylint and black were first adopted by the libraries? The adabot automation utility can update the config and infrastructure files that are the same accross all libraries. But AFAIK it can't really make modifications within the code or examples of the library which are different in each of the libraries.
Did we have some utility that was able to run pre-commit after the config files were added and then commit and push the resulting changes? Or was that dones manually by people back then?
I was going to file a Feedback, and made up a USB stick with four partitions (16MB, 512MB, 1GB, 2GB) using gparted. Upon plugging this in to a Mac running 14.4 beta 5, one partition mounted quickly, one mounted slowly, and two never mounted after a couple of minutes. It looks like macOS was trying to set up the .fseventsd and .Spotlight-V100 directories, but maybe was doing so extremely slowly. So I gave up on that as a simple test to submit.
I will try for a simpler report about singl...
@dhalbert - tested on both a Pico W and UM FeatherS3. Works great!
@slender iron - I have narrowed down my "epaper not showing errors" problem but I can't find a solution.
In my board.c board_init() I setup the epaper and I set its power pin HIGH. When I test the pin in CircuitPython I show HIGH and then show LOW. Something in the core is resetting the pin value.
What I am trying to achieve is to set a power pin for the display as output HIGH in the board_init() so the epaper has the normal default behavior but expose the pin to CircuitPython so the user has the option to set it to LOW if they want to disable the display.
@empty salmon I recently had to handle a case somewhat like this: the Adafruit Feather RP2040 USB Host board has a GPIO to control the 5V power rail to the USB "A" connector. We wanted the regulator enabled at power on but still wanted to allow it to be controlled as a DigitalInOut from Python code. I added a new facility so that a board could override the state a pin is set to when it is "reset", including at power on. You can check out the PR https://github.com/adafruit/circuitpython/pull/8937 or where it's used https://github.com/jepler/circuitpython/blob/6fd89b7b13d68d052f1046d91c356c2971f8331a/ports/raspberrypi/boards/adafruit_feather_rp2040_usb_host/board.c#L37
So basically you can set the state for the pin to have whenever it's not in use from Python code, rather than "pad disabled, no pull up/down".
This involves re-working some bits of how in-use pins are tracked, because the pad state can no longer be used for that purpose.
now on my usb host feather I can create a DigitalInOut and when I to...
draft to see if it compiles
@onyx hinge - thanks! I have it working 👏🏼
I did find and odd anomaly in CircuitPython.
If I do nothing in code.py then the error appears on the ePaper as expected.
If I add control = digitalio.DigitalInOut(pin_number) then it's as if I have turned that pin OFF and there is no error output to the display.
This mostly makes sense since I assume CircuitPython has reinitialized the pin. However, if I then print(control.value) it returns True but no error output. It is as if the value managed by CircuitPython is out of sync with the actual value of the pin in the core.
Tested successfully using full featured code editor.
BTW: I should note that in board_reset_pin_number() I don't want it to do anything to the pin. I want it to remain in whatever state is was last in (either from board_init() or from the user).
If the ePaper power pin has been turned off at any point, including any "glitch", then the display will be in its power on state and require the initialization sequence to be sent.
on rp2040 a DigitalInOut is initialized with gpio_init which operates in the following steps: ```c
void gpio_init(uint gpio) {
gpio_set_dir(gpio, GPIO_IN);
gpio_put(gpio, 0);
gpio_set_function(gpio, GPIO_FUNC_SIO);
}
This could be causing a glitch
Yeah. Your code comment was great. I have it working as needed.
It's just the value shown in CircuitPython which is wrong.
I misread what you said
Mostly my fault there. I didn't tell the whole story in the first post.
I initially the pin in board_init(). Then I prevent changes to that pin using board_reset_pin_number().
Is there an external pull resistor on this pin?
good point. NO
(what HW is this? is it a public design?)
board design not yet published (hopefully in May)
then you should probably set the internal pull resistor high or low before checking the value
it's an output pin.
print(control.value)
```The two bits of code you told me were these lines, which will configure `control` as an input with no pull.
DOH! yes, as soon as the CircuitPython code get the pin, it defaults to input 🤦🏼♂️
thanks. Now it makes sense. Easy to document.
good, I'm sorry we were talking past each other for a minute.
Totally my fault. You have been a HUGE help ...
you're welcome
Thankfully, you had already completed the PR for that change 👍🏼
Tested TCP socket-level HTTPS request with these artifacts and the core-compatible-socket-type-numbers branch of [adafruit_wiznet5k](https://github.com/adafruit/Adafruit_CircuitPython_Wiznet5k/tree/core-compatible-socket-type-numbers), on an Adafruit ESP32-S3 TFT + Adafruit Ethernet FeatherWing, just confirming jepler's result. Also fine with Adafruit ESP32-S2 TFT.
PicoW + WIZnet W5100S hat gets MemoryError: in the context.wrap_socket() line, not sure how to debug or proceed from t...
@dhalbert
I was going to file a Feedback, and made up a USB stick with four partitions (16MB, 512MB, 1GB, 2GB) using gparted.
It's a bit of a pain, but you'll need to test with one partition at a time.
I tested with this firmware version from S3
adafruit-circuitpython-adafruit_feather_rp2040_usb_host-en_US-20240304-main-PR8999-0186d9c.uf2
With a basic code.py file that does basically nothing print(1234)
With this version loaded I still don't seem to be able to interact with the REPL using the keyboard plugged in to the USB A Host port until I unplug / re-plug it.
I wasn't certain if the build that has PR8999 in it's name includes that PR or not for certain, so I also ...
Does this work in 8.x? (I don't think it does.) I suspect this is simply due to not enough memory. I wouldn't mark this for 9.0.0 because it is a feature addition.
@furbrain I'm going to close this because I couldn't reproduce it. Please post here again if it is still happening. It may be board specific.
@slender iron are you going to make a new circup release with the web workflow support? I can do this quickly
all set - just need to push the button
I was going to let someone else
but no concerns from me. I think it'll enable more dev on circup
done!
just about to get back into wdt debugging
i have an nrf thing to debug
idf 5.2 and 5.1.3 were released
@tulip sleet / @slender iron did you have thoughts on my circup update PR? I have conflicts now. Happy to fix, but only if you want the change
I definitely want the change. Sorry about causing conflicts. I thought I had merged yours already!
i was just looking at the release notes
I'm hoping the debugging fix in 5.1.3 will help
I've got a pretty good understanding of tlsf now if you want to talk it over
before it leaks out of my brain
The manual remount workaround still works for me (macOS 14.4RC). Doing this gets me fast writes to CIRCUITPY
Using a Matrix Portal S3 here. Before testing I ran
import storage
storage.erase_filesystem()
ran it again after copying files and before manually remounting.
root@JohnsMacStudio ~ # time cp tmptest/* /Volumes/CIRCUITPY
cp tmptest/* /Volumes/CIRCUITPY 0.00s user 0.01s system 0% cpu 16.597 total
root@JohnsMacStudio ~ # umount /Volumes/CIRCUITPY ; mkdir /Volume...
Updated. I retested, but would appriciate another
I noticed this because I was trying to get a simple shell script working that demonstrates the problem using disk images, but I keep seeing fast writes with it. Not sure what's going on here as it appears to be using fskit
Its mount output looks like this
/dev/disk10s1 on /Volumes/TESTDISK (msdos, local, nodev, nosuid, noowners, noatime, fskit, mounted by romkey)
When I manually copy the files it generates to an automatically mounted CIRCUITPY the copies are very slow. When I co...
@tulip sleet I think I found the matrix issue. no need for you to look into it
basically the spi flash cache check is imperfect
I think we're getting an interrupt when the disable is starting and checking to see if it is disabled before it takes effect
and then calling mp_hal_delay_us which is in flash
makes sense. That might also explain why pruning random things out of the program did or did not make much difference. should the delay routines be in RAM anyway because they might be used in an interrupt routine, like OneWire or somethign?
that's my fix for now
and replying to may forum thread about it
updated to 5.1.3 too
The guard against running when flash is disabled isn't perfect and may lead to calling the row handler anyway. We were crashing due to mp_hal_delay_us being in flash. So, move it to RAM.
Also move the panic handler to IRAM so we get nice output when this happens.
Turn off JTAG by default so its pins can be used by code.py.
Fixes #8987
The "in case TinyUSB runs in a separate task" addition: did you encounter that case?
I was going though my stuff and found a Metro M4 Express Beta board. Is it still supported? That is, will the Metro M4 Express build work on it?
I ask because I am having some issues.
all the ones I have say "Beta" 🙂 what color is it?
black
update the bootloader if you have not done so already
I'm happy to toss it. But wanted t see if it is worth persuing.
but it might be bad flash
ah -- I'll try the bootloader
do the files actually run, or do they just appear to have been copied? and you did a storage.erase_filessystem() ?
I was just trying to recall if there was a know issue with the betas.
Yes, it runs - but then if I RESET the board, it is nt there any more.
they said "beta" for at least a few years. They were not really beta
yes, try the bootloader first
OK -- thanks
and also reformat CIRCUITPY
Tested HTTPS server on ESP32-S2 TFT.
Board crashes and restarts upon receiving the first request.
HTTP version still works the same.
@tannewt @dhalbert it seems like all the requested changes have been incorporated here. Is there anything else this is waiting on?
@michalpokusa I didn't get any crashes (ESP32-S3), but the client got connection refused.
@foopod There is an unresolved question about the SPI buses: https://github.com/adafruit/circuitpython/pull/8816#discussion_r1495424100
@tulip sleet It seems to be happier now -- with the updated bootloader and the erased file system....
And I thought I was going to have an excuse to get rid of something 😉
@anecdata Thank fro testing. HTTPS server works on ESP32-S3 fro me too, although I successfully get the response, maybe the problem is due to self-signed cert? When I added -k to curl if works, but this is not really the issue with CircuitPython or library.
The TypeError is also present, which is a result of (I believe) incorrect types being returned by SSLSocket.accept():
![i...
@michalpokusa Yes, ESP32-S3 works and I get the response. The config that didn't work was an S3 with Ethernet FeatherWing, using WIZnet sockets for the HTTPS server.
not sure which made a difference,but glad it's better
Thanks! I think we may see more of this kind of thing in the future.
Lots of firmware overflows are causing the build failures.
I thought I had but no.
a bunch of builds are overflowing. I'm surprised the upgrade to 5.1.3 did that.
will look after a walk
@tulip sleet I updated my playground note with circup info. if you have a moment, would love to know if you recomend any changes
could you give me a link?
Tested on raspberry pi pico.
Add feature to boards/xx/mpconfigboard.mk
CIRCUITPY_RP2CLKIO = 1
Example usage:
import board,clkio
clkout = clkio.ClkOutput(board.GP21)
clkout.clksrc = clkio.ClkAuxSrc.SYS
clkout.divisor = 62.5
clkout.enable() # Output will now be 2MHz from 125MHz clock.
import board,clkio
clkin = clkio.ClkInput(board.GP22)
clkin.clkindex = clkio.ClkIndex.RTC
clkin.set_freq(1000000, 10000) # 1MHz input clock, set RTC to 10kHz
clkin.enable() # RTC will now be 10...
Give a minimum version here: CircUp has recently been updated to add missing requirements on update make sure to install the most recent version (also fix run-on sentence)
I usually add empty parentheses when I mention functions or methods, e.g. requests.set_socket().
Change More to a more descriptive heading.
RIght now this is the "new" way, but it will quickly become the "normal" way. So maybe put the punch-line first, and describe the old way later.
and you can put comments in the "old" examples that say "deprecated way of ...."
so people don't just copy them blindly
This is a nice summary -- the above are minor!
Thanks! Updated
Thanks! I think we may see more of this kind of thing in the future.
Please retest this with an absolute newest build and try to trim down the test code. I was unable to reproduce this with a disconnected bus and no other devices.
Please post the complete example. This one has no imports. I wasn't able to reproduce it because they are missing.
I did some debugging and am seeing bad data showing up as part of an advertising packet., causing some data sizes that are much too large. This might be some kind of internal problem, or it might be a corrupted packet. Will continue on this.
did microcontroller.watcdog.timeout change from seconds to milliseconds on espressif between CP 8 and CP 9? readthedocs doesn't reflect any change
not intentionally! If the API that we call changed something might have gone wrong
#7718 was a refactoring, but I don't see a mention of changing the scale
the timeout is a float of seconds
also```py
w.timeout=4294967295
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: timeout must be <= 4294967295
I'll test some more and file an issue if I can't find another cause
This looks wrong both before and after: https://github.com/adafruit/circuitpython/pull/7718/files#diff-d40fe0f9108540afc8b776d5f3294b72ef8826917062ce458558bffb9b398119
it's setting a time in msec from a float secs. There's a cast on the left and no cast on the right, but it should be casting the float to a uint32_t in either case, and it should be multiplying by 1000, but it's not.
it used to work (e.g., 8.2.8), but now a timeout of 300 resets in a few seconds
OK, I'll file an issue with a simple test case
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2-21-gc91b20fd96 on 2024-03-05; Adafruit Feather ESP32-S3 TFT with ESP32S3
Code/REPL
import time
from microcontroller import watchdog as w
from watchdog import WatchDogMode
time.sleep(3) # wait for serial
print(f'{time.monotonic()=}')
print('setup watchdog...')
w.timeout = 3600 # should be 1 hour
w.mode = WatchDogMode.RAISE
while True:
print(f'{time.monotonic()=}')
time.sleep(1)...
(Paraphrased from my comment in discord:) Looking at https://github.com/adafruit/circuitpython/pull/7718/files#diff-d40fe0f9108540afc8b776d5f3294b72ef8826917062ce458558bffb9b398119 from #7718
it's setting a time in msec from a float secs. There's a cast on the left and no cast on the right, but it will be casting the float to a uint32_t in either case. It should be multiplying by 1000, but it's not.
Tested with W25Q32FV (32Mb, 104MHz, SOIC-8) SPI flash chip soldered to back of QT Py M0
[low priority, just for fun question] does someone happen to have a "skeleton" template (or something analogous to ports/minimal in micropython) to start off a new port? I.e., something that just builds but has stub C code for everything? (Would like to side-step the rabbit hole of understanding how the build makefiles are put together, if there's an easier path 🙂
I just finally found the time to test again with the latest build available on the s3 (adafruit-circuitpython-lolin_s2_mini-en_US-20240306-main-PR9008-e64082d.bin) and can confirm (if that was needed?) that it works great with my setup that was triggering the issue.
Thanks a lot !!
Hi https://github.com/silabs-ChatNguyen do you have any input for the SiLabs CP port specifically for the HFXO. It appears this FW component has an impact on the serial port baud rate likely due to the osc. not being at the correct frequency.
Thank you.
That would be an interesting thing, but do you mean stub code for digitalio, etc? Another thing to do is to take an existing straightforward port, like atmel-samd, and gut the implementation.
that is what I did in the past
Thanks for the tip @tulip sleet ! - I picked litex as it had the smallest number of characters in the Makefile 🙂 and was lost in the Makefile voodoo that was generating the various genhdr dependencies; I'll give atmel-samd a go!
(and yes, this was mostly an experiment to see if I could create a small test-bed to conveniently test some of the native modules. I tried @onyx hinge s fork, but it was a WIP and wasn't able to get a successful build, and didn't want to bug them)
all the ports have some idiosyncrasy or another. atmel-samd is the most straightfoward, but it is dependent on a rather messy very-compile-time-configured hw-specific layer, ASF4, from MicroChip. The nrf port is also pretty straightfoward, but has some unusual stuff to support the firmware blob library known as the "SoftDevice", and has some unusual stuff for BLE. STM has to support many chip variants that are slightly different, and has a lot of copied boilerplate from ST. mimxrt10xx has an unusual memory architetcure. raspberrypi has the pico-sdk, which is quite straightfoward. But, it depends on some cmake stuff. etc.
Ah, interesting - thank you for the overall guidance on these ports; that's very helpful to know maybe where to dig for info. I forsee a non-zero amount of Makefile trawling for this experiment...
(only if it's a quick answer off the top of anyone's head) any hints on where this QSTR actually gets defined? I didn't see it in the "standard" set added in makeqstrdata.py https://github.com/adafruit/circuitpython/blob/e64082d60052f92720031b5a17aec3732a6c4e26/main.c#L220
are you looking for the def of the macro MP_OBJ_NEW_QSTR or the def of MP_QSTR__slash_lib ?
I'm having a compile error for a "minimal" port I'm trying to get working, with that symbol missing. I'm sure I'm probably missing a magic preprocessor or makefile variable somewhere, mostly looking for hints on how to debug something like this. (Happy to throw up the Makefile somewhere if helpful)
I'd suggest starting with a port most similar to the platform you are targeting
that way the compiler stuff would be the same
the problem with having a minimal port is that it won't get actively used at all
Ack - this is definitely something mostly for my fun time to be sure... though, I had some thoughts of eventually being able to run tests with it.
what platform are you targeting?
just unix - I'd like to be able to stub out some of the hal pieces so I can test some of the native modules off device
I was thinking that a renode port could be interesting
Ah, very cool - I wasn't aware of this. I'm guessing it also lends itself to a continuous integration workflow?
ya, I think that's the idea
and aligns with your goal of testing native hardware modules
Fantastic - thanks for the pointer; that likely makes a lot more sense than what I was playing with.
😄
renode could be really helpful for tracing and memory analysis too
qemu is another option but I think it isn't really microcontroller focussed
Yes, I'd actually gone some way towards qemu (and seeing if wokwi might be amenable to at least esp32 emulation) but the renode idea is a great pointer. More toys to play with 🙂
I talked with the wokwi person about it too
and someone here was thinking about using it for capturing memory footprint of library code over time
Very cool. Uri seemed like a nice guy in the few interactions I had with him, hope there's some interesting collaborations to look forward to 🙂
ya, unfortunately we haven't had the time to fully engage with him (or the renode folks)
Renode looks very interesting. Browsing its source tree I see it has verilated (Verilog compiled to C) support for a few riscv variants. That should yield more accurate emulation than you'd get with something like emu.
I like that renode is CI oriented too
In the draft ssl-anything PR I arrange to just pass the original objects down, instead of unparsing them and rebuilding them. So except for compatiblity with a weird nook of cpython this is moot for me.
Thanks for this change! I haven't looked in detail yet but have some thoughts and questions.
- Generally I'd expand
clkiotoclockiobecauseclkisn't as clear asclock. - What is the difference between auxsrc and index?
- Could this be a shared API for clock inputs and outputs where the clock names are defined by a micro-specific module?
bindings/samdalso does some clock stuff. - What are you using this for?
@tulip sleet are you doing #9010?
I can - it's simple.
I don't have any other bugs to work on
so I think its time for an rc
the usb ones aren't super critical
(unrelated) I wonder if switching to picolibc could free up space on samd21 builds
just going to grocery store. The advertising storage problem is I think an issue with not locking ringbuf when advertisements are saved to become ScanEntry objects.
ringbuf was sort of thread-safe (not sure it really was) a long time ago. I took that away during a big cleanup of ringbuf. it was kind of an accident and I didn't realize it was used in that way for scan entries.
anyway probably not hard to fix
that explains it
so did 5.1.3 really grow the builds or was that due to the IRAM flags?
so an rc wuld await a few more fixes
the macOS serial bug is a nuisance for those who encounter it, but i guess macOS has multiple problems right now
ya, and it'll get fixed
I was thinking we should release because of all the existing fixes
so it could be beta or rc
and I feel like we're close enough to call it rc
i would jave said that an rc really is an rc, without further expected fixes. Usually I convert an RC to final. are you thinking we would wait for the tinyusb fixes before the actual final?
The best we'll do on #8824 is a workaround. As @tame creek has found, there's a hardware issue at play.
no, I think we could do final with those bugs
@mortal kernel are the pi folks aware of the issue?
if you want to do 9010 for lack of anything else, go ahead
we'll likely do 9.0.1 quickly anyway because the stable audience will find more things
I told them about the issue. I'm not sure it affects them very much. Maybe it makes UF2 loading slower
It seems that macOS sometimes rapidly issues multiple CDC control requests back-to-back, aborting some of them, when a process closes a CDC serial device. This causes a hard fault in TinyUSB due to...
sorry - i told them about the macOS issue, not the uSB issue
what's preventing PWM on A2, A4,A5 here?
Adafruit CircuitPython 8.2.10 on 2024-02-14; Adafruit Feather M4 Express with samd51j19
>>> import pwm_test
No PWM on: A0
PWM on: A1
No PWM on: A2
PWM on: A3
No PWM on: A4
No PWM on: A5
they have TC's avail per pinmux
output generated from this test:
https://learn.adafruit.com/circuitpython-essentials/circuitpython-pwm#wheres-my-pwm-2984449
(and truncated)
iirc one TC is used internally by CP
I think TC6?
@tidal kiln channel 0 is used to adjust frequency
so only TC[1] can be used for pwm
ah, ok, so anything channel 0 would not be supported?
correct
thanks!
- Make setting timeout "feed" the watchdog.
- Fix #9010, timing on ESP
@anecdata do you want to test this?
I made a new branch from this and pushed in that requested change to expose the second SPI bus, that branch is here: https://github.com/FoamyGuy/circuitpython/tree/m5stack_cardputer_multi_spi with the specific change being inside pins here: https://github.com/FoamyGuy/circuitpython/blob/m5stack_cardputer_multi_spi/ports/espressif/boards/m5stack_cardputer/pins.c#L69-L70
with that change both SPI busses are listed on the board object:
>>> import board
>>> dir(board)
['__class__', '__...
Tested on ESP32-S3. Timeouts are back to float seconds now (up to 49+ days on espressif), upper bounds check is good. If timeout is set too low (small fraction of a second), board boot loops with microcontroller.ResetReason.WATCHDOG.
if tCI was re-run partially (some boards), where are the previous artifacts (other boards)?
@crimson ferry you can look though all the pull request builds. there does not seem to be a way to filter based on PR#. https://github.com/adafruit/circuitpython/actions/workflows/build.yml?query=event%3Apull_request
ah, the run# hides in a menu
Ran into this on Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Adafruit Feather ESP32 V2 with ESP32. Which CP 9.0.x release this will be fixed in ?
Which CP 9.0.x release this will be fixed in ?
In the next release after beta.2.
It will also be available in "Absolute Newest" at https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin for the build that has PR9012 in its name and any thereafter. The PR9012 builds are in process right now.
i think this is good to close. i've been using absolute newest and adding/deleting chunks of code and the issue has not popped up where previously it would have during that kind of use. thank you! looking forward to using it more 🙂
- Fixes #8995
Advertisement-data read/write ScanEntry.c was not atomic. One side of that was done during an interrupt.
Tested with last test program in #8995. Ran for half an hour or so without failure. Previously would fail within a minute or two.
Also made minor fix re signedness of RSSI: no behavior change.
@tulip sleet Thank you for #9014. It may be the answer to some odd behavior I was seeing with BLE scanning on my RP2 work. Time for me to re-base my branch.
Thanks, will give it a try. I don't mind running on the "bleeding edge".
On Wed, Mar 6, 2024, at 22:58, Dan Halbert wrote:
It will also be available in "Absolute Newest" at https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin for the build that has
PR9012in its name and any thereafter. ThePR9012builds are in process right now.—
Reply to this email directly, view it on GitHub <https://github.com/adafruit/circuitpython/issues/9010#issuecomme...
I hope this is not a breaking change, but currently there are two board that are "hard" to distinguish because they have the same name in the main download page:
i think this is good to close. i've been using absolute newest and adding/deleting chunks of code and the issue has not popped up where previously it would have during that kind of use. thank you! looking forward to using it more 🙂
Great! Thanks for the update.
Thanks for taking a look @tannewt.
- clockio seems like a reasonable substitution.
- That is a good question. I admittedly just wrote this as a small wrapper around the rp2040 sdk without digging in further. There is a lot of overlap between the two but they're not identical. Let me dig in some more and see if they can be combined somehow.
- ports/atmel-samd/bindings/samd/Clock.c seems to be a ROM representation of the internal clock tree. It doesn't seem to be doing any IO functions so I ...
If that is the only remaining change needed for this I could commit it here potentially, or make a new PR from my branch that has that commit on it. Let me know if there is anything else I can help to get this moved along, I'd love to see support for it added more officially than the PR.
You can add https://github.com/jamesjnadeau/circuitpython as a remote in a clone of your own repo, pull it, and check out that remote's m5stack_cardputer branch. Then cherry-pick your changes from your...
Thanks! 🚀
Thank you! I've added that commit now.
@slender iron The upstream cyw43-driver MAIN just picked up the two outstanding PRs we had in our local fork. Should I make a PR to revert to the upstream repo now, or wait until they've tagged an official release?
Just took another look and they're in the process of releasing 1.0.3. I'll submit a PR once they've tagged it.
To supplement the original report, here is a screenshot of the (recurring?) duplicate transmission issue.
Thanks for the build instructions and pointer tannewt! I'll start poking at the this sender side code. Hopefully I can make a little contribution here :)
Switch submodule cyw43-driver back to upstream repository at tag v1.0.3.
The additional pulls in our local fork have been merged into the upstream repository. The pulls are: https://github.com/georgerobotics/cyw43-driver/pull/107 and https://github.com/georgerobotics/cyw43-driver/pull/108.
Any comments from anyone before we merge this? Thanks.
Requesting review. Single CI failure looks like the timing related silabs bug we've seen before.
This is likely to be specific to stm32f405 implementation, and appears to be a problem on the sending side but that's just a guess. 3 also happens to be the number of transmit buffers.
@jepler and team, where is this "3" number for transmit buffers defined? I'm looking at some of your later commits for common_hal_canio_can_send: https://github.com/adafruit/circuitpython/commit/e5a0af9216a6d868fad9105a4eb44e0889f54e29 and https://github.com/adafruit/circuitpython/pull/3505/commits/eed3387...
Hello CircuitPython people. I'm starting to poke at https://github.com/adafruit/circuitpython/issues/3644. I'm wondering how to attach a debugger or if I can add in "prints" into the C code? I don't have an ST link or connector for for the SWD port... maybe I should get one.
I think after each tx attempt, we can ensure all "mailboxes" are clear again? Found an implementation here.
This is a substitute for https://github.com/adafruit/circuitpython/commit/e5a0af9216a6d868fad9105a4eb44e0889f54e29
// Wait until all mailboxes are free again.
while (HAL_CAN_GetTxMailboxesFreeLevel(&self->handle) != 3) {
RUN_BACKG...
the three transmit 'mailboxes' are in hardware https://www.st.com/resource/en/datasheet/stm32f405rg.pdf section 2.2.29 (p. 37)
Thanks anecdata. That is a good link for someone who is not familar with low-level stuff such as this (like me). I'm not sure if we can use all 3 mailboxes effectively with the send/receive paradigm we currently have in canio. Maybe there is an ordering I haven't figured out yet.
For the other canio ports:
- It looks like our atmel-samd port only has "one dedicated TX buffer". I am not sure if there is an equivalent hardware buffer behind the scenes.
- I can't find where the `tx_queue_...
I assume can.send should not be blocking...
Here is a non-blocking version that limits to 1 mailbox. I will probably throw up a PR tomorrow unless someone has a better idea of how to use all 3 mailboxes.
// Only use 1 out of the 3 transmit mailboxes to avoid confusing ordering.
// See https://github.com/adafruit/circuitpython/issues/3644 for more details.
// 3 == nothing in use, send away!
// 2 or 1... something is already on the bus... sorry.
if (HAL_CAN_...
Hmm, this might just be a problem with the "ack" demo code.py send/receive scripts sending duplicate packets... and our .receive function getting them in order. Will poke at this more tomorrow.
Attempted to submit a very simple code comment edit on the ht16k33 library and it gave me a weird error
https://github.com/adafruit/Adafruit_CircuitPython_HT16K33/pull/117
https://github.com/adafruit/Adafruit_CircuitPython_HT16K33/actions/runs/8186264263/job/22384315239?pr=117
Artifact bundles has been successfully uploaded!
Run echo docs=$( find . -wholename './docs' ) >> $GITHUB_OUTPUT
Run sphinx-build -E -W -b html . _build/html
Running Sphinx v7.2.6
making output directory... done
loading intersphinx inventory from https://docs.python.org/3/objects.inv...
loading intersphinx inventory from https://docs.circuitpython.org/projects/busdevice/en/latest/objects.inv...
loading intersphinx inventory from https://docs.circuitpython.org/en/latest/objects.inv...
Warning, treated as error:
failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://docs.circuitpython.org/projects/busdevice/en/latest/objects.inv' not fetchable due to <class 'requests.exceptions.HTTPError'>: 504 Server Error: Gateway Time-out for url: https://docs.circuitpython.org/projects/busdevice/en/latest/objects.inv
Error: Process completed with exit code 2.
Would appreciate if the CPY team add the files for the board: Lolin S3 Pro, under:
/ports/espressif/boards
To assist, I modified the files that are present for the Lolin S3. See below and please check.
Regarding the file: pins.c, at the end I commented out the definition for UART because this board does not
have a 2nd USB-C connector called UART like the Lolin S3 board has. I hope I have done OK with commenting out this UART definition.
In file ```mpconfigboard....
i just re-ran it and it passed 🎉 i've run into that before where an http request fails. i'll wait a bit, run it again and it's usually fine
Was hoping it was something simple like that. Thank you for looking into it.
You can print in the console (REPL) channel by adding , for eample, mp_printf(&mp_plat_print, "i: %d\n", i)
What would it take to make the SD card readable over USB. But before you answer that, Does CP expose the ESP-IDF WiFi_provisioning component?
we are working on this here: https://github.com/adafruit/circuitpython/pull/6555. The problem has been getting it to work the same on all three major operating systems.
Thank you!
NP, the PR is in. #9016 ready for review.
Please open a pull request with these changes. Here are two relevant guides:
https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github
https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython
Just in case branches are case sensitive.
I agree standardizing it is a bigger task than need be. Let's call this rp2clockio just to ensure we leave clockio for a unified API. You can remove the Clk prefixes from the class names then too.
Please don't include the IDF change.
also canonicalize use of BOOT (all caps) as safe-mode button name
I think the requested changes are now in. Any further fixes could be PR'd.
Two tweaks since the cardputer comes with a StampS3. Not a core.
@slender iron I finished draft release notes for rc.0. Only PR's #9018 (Feather C6) and #9016 (cyw43-driver update) remain as possible to include.
I would say we could hold off on #9016 just in case it's a regression for non-obvious reasons. #9018 is not urgent and could be added post rc.0.
I approved the C6 one already
I think there are C6 fixes in idf 5.2 that we may want
limor hasn't tested the C6 on proto hw
but it doesn't really matter, it can be fixed
@slender iron so in that case, I could go with the current set of PR's and could do an rc.0 right now
up to you
it's ok by me. I can make a 9.0.x milestone and move some issues to there.
I forgot, I didn't do the CPX testing. I'll try that for a bit
I see cmake files like this and wish it was just python: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/blob/main/CMakeLists.txt
totally agree with that. I don't understand why people keep inventing new weak programming langauges
with idiosyncratic syntax
this is interesting to me: https://github.com/aappleby/hancho
uses asyncio to make a build system basically
cross compiling is such a pain
goes to lunch
Sounds good, I'll make those changes.
@slender iron I am having trouble saving larger code.py's on CPX after about 9.0.0 alpha.4 or 5. Trying to come up with a simple test case. It just hangs and then crashes hard. Fine on alpha.2 and before
First save is ok, then if I remove a few lines or put them back, the second write fails badly. Just going to try it with a non-code.py text file of similar size, and will try it on Feather M0 Express or something else more debuggable with J-Link.
The general public release of macOS 14.4 is out today. As expected, the slow writes are still an issue.
The good news is that it still fixes the original issue and it's still possible to write to smaller filesystems without using any workarounds. So @dhalbert it's safe to update the blog post to tell people to update to 14.4.
Hopefully 14.5 beta will be out soon and we can begin the testing/optimism/disappointment/surprise cycle anew.
It's fine with me to hold this for 9.0.x. There are only a couple of PRs that went into v1.0.3 that weren't already on Adafruit fork we are currently using, none of them affecting CP. I've manually inspected them, and don't see any issues. In the meantime, I'll switch my work to v1.0.3 and continue testing with it.
@slender iron I was able to reproduce the problem on 8.2.10, so it's not a 9.0.0 showstopper. It seems to have to do with do PDMIn and doing a lot of writes to CIRCUITPY at the same time.
I was testing an old CPX program that did audio processing.
Yeah, I finally updated my M2Max Studio to Sonoma today because of the 14.4 release - been on Ventura since I bought it specifically because of this CP issue.
I tried several larger CPX programs from Learn Guides. I did not see glaring storage problems. I did encounter hangs when writing a large code.py frequently with PDMIn running, but I reproduced that in 8.2.10 as well. I will open an issue for that.
So I'll say this is done.
Automated website update for release 9.0.0-rc.0 by Blinka.
New boards:
- adafruit_itsybitsy_esp32
- adafruit_sht4x_trinkey_m0
- m5stack_cardputer
- sensebox_mcu_esp32s2
[low priority] noticed that the python bitbanged i2c doesn't check for ACKs from the peripheral after the initial address ACK, compared to the C bitbangio. Before I go down this particular rabbithole and also recognizing the python module is probably not used much 🙂 was there any other issue that avoids the ACK check here? (context)
Here is a slightly different version of https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/main/FeatherCAN_CircuitPython/sender-ack/code.py that reads in all the pending messages. I tried creating a branch/PR on Adafruit_Learning_System_Guides, but ran into permission issues.
# SPDX-FileCopyrightText: 2020 Jeff Epler for Adafruit Industries
#
# SPDX-License-Identifier: MIT
import struct
import time
import board
import canio
import digitalio
# If the CAN tra...
Hi @silabs-ChatNguyen I have been working on this problem all week. Are you able to help?
From my post a few days ago re the Platform - I/O Stream EUSART Bare-Metal issue, I believe I now know exactly which SiLabs function is causing the problem with my custom board.
Using the SS5 tools, adding the 'clocks' component to the .slcp for Services | Device Initialization | Peripherals | Clocks causes the Platform - I/O Stream EUSART Bare-Metal application UART to fail. Removing the clocks co...
Is the expectation that a canio stm32f405 user will always need to create 2 listeners?
I'm not sure if this is what you're asking, but I believe the bus needs two devices to function as n active mode https://github.com/adafruit/Adafruit_CircuitPython_MCP2515/issues/21#issuecomment-1615381996
I'm sorry I didn't get a chance to test this before the merge but I was out of town most of this week and when I got back this evening my cardputer had just arrived :grin:.
I threw the latest build on and did a few quick tests which mostly seemed to work fine. I did spot this one typo though. I'll give it some more testing tomorrow.
CircuitPython version
Adafruit CircuitPython 9.0.0-rc.0 on 2024-03-08; Raspberry Pi Pico W with rp2040
Code/REPL
import board
import simpleio
# Define pin connected to piezo buzzer.
buzzer_pin = board.GP21
while True:
simpleio.tone(buzzer_pin, 800, 0.5)
simpleio.tone(buzzer_pin, 0, 0.5)
Behavior
Traceback (most recent call last):
File "", line 14, in
File "simpleio.py", line 74, in tone
ValueError: GP21 in use
...
What's the story behind the removal of deinit() ? In my case, I call it before the device (Feather V2) is put to deep sleep, which happens periodically. Maybe calling it is not necessary in such case ?
Nice issue number :-) (sorry, could not resist)
What's the story behind the removal of
deinit()?
The deinit functionality is still present, the API has changed. Instead of calling deinit(), set the watchdog mode to None.
Hi, any update for support enterprise wifi for esp32 ??
@eightycc Did you close this deliberately, or were you just reconstituting your fork?
@RetiredWizard I will wait a bit in case you have a few more changes.
The trace above might be an issue with pwmio not releasing resources in its constructor (rather than a simpleio issue). The test case is in a file tc.py:
import board
import pwmio
def acquire():
try:
with pwmio.PWMOut(board.GP21, frequency=0) as p:
pass
except ValueError as ve:
print(ve)
from the repl
>>> import tc
>>> tc.acquire()
Invalid frequency
>>> tc.acquire()
GP21 in use
>>> import gc
>>> gc.collect()
>>> tc....
Looks like different methods have different levels of implementation (and use) complexity
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/wifi-security.html#wi-fi-enterprise
Which method(s) are needed?
Cleaning up, didn't realize it would kill the PR. Will resubmit.
On Fri, Mar 8, 2024 at 7:41 AM Dan Halbert @.***> wrote:
@eightycc https://github.com/eightycc Did you close this deliberately,
or were you just reconstituting your fork?—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/pull/9016#issuecomment-1985916937,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB5CXR3DFWANJ6HZBZLE23DYXHLZN...
is tests/run-tests mostly a MicroPython thing to test the VM? ( I'm trying to see if there's something in there I could run manually, to verify on a connected device.)
This is a bug in the CircuitPython caused by some recent revamping of PWMOut deinitalization. The constructor should clean up on error. Will fix.
it's for running on the unix port. It is not for testing on a board.
our of curiosity, does anyone know if anyone is maintaining the creationid github / website anymore? I'm going through the steps to begin working on support for a board and at that step, I'm stumped as to what to do to get a creation/creator id for this board, as the link on the github page to creationid.org just returns ssl errors, and the last commit was several months ago. Is there a new procedure to getting a creation/creator id these days?
just submit a PR to https://github.com/creationid/creators
@slender iron are you doing something with creationid.org?
I'm not sure there ever was a website, or maybe it was a redirect to the github repo which broke or something like that
I thought it was something like that. I'm not particularly experience with the collaborative development process, so I wasn't confident in what was required to submit such a pr
who is the manufacturer
"Sunton" its this thing: https://www.aliexpress.com/item/1005006556177475.html
i'll get back to you, I have a meeting in two minutes. seems like there are many clones of this
There are, and no two models would be board compatible, as they all use different screens and pinouts. It's maddening. I found a json dump that has information on most of the variants.. but I'm only working on the one I currently have for now.
so you're considering making a board definition for it?
Yes, I've started working on the pin definitions and such, but in order to do test builds, I need that creatorid.. though I suppose for my own internal tests I could just use random data, as long as i dont submit it that way
Thx @tulip sleet ! Lmk if you can use a PR for https://github.com/adafruit/circuitpython/issues/9021 it seemed fairly small. (I was also able to re-purpose run-tests to run on device for testing fixes quickly, but I'll keep that local for now; happy to submit something for that later if that's more widely useful.)
Is there a description anywhere of technically what happens when I run a "make flash" command like:
make BOARD=m5stack_cardputer PORT=/dev/ttyACM1 flash
I'm interested in how it interacts or relates to the UF2 bootloader. Like is this also flashing the bootloader? or just CircuitPython? Is this flash using the UF2 bootloader somehow? or something different?
After I run this command it seems to succeed and then I press the reset button on my device once and it then reboots and comes up in the UF2 boot mode with BOOT drive. Is that the expected behavior? Is there some command I can run to just reboot into the UF2 BOOT drive without flashing? I've not been able to figure out any successful sequence of reset and boot btns that lead to the UF2 drive on this device. But it does always come up after a reset after this make flash command.
i have a fix to test, and am checking the other ports as well
i just need to move the claim_pin(), I think
maybe you saw the asme thing
Yes, that seemed to be the only thing I could see at least for rp2. (I also initialized ->pin = NULL as I wasn't sure if mp was setting the struct to NULL initially.
(I moved the entire struct block init in addition to claim_pin(), as the de-init is looking for pin != NULL to see if it should do anything)
gc_alloc() zeros out newly allocated blocks
Ah, cool - gtk!
- Working build for the ICBbuy ESP32-C3Mini board
- couldnt get it to build without including a CIRCUITPY_CREATOR_ID and CIRCUITPY_CREATION_ID, so I just copied the IDs from seeed_xiao_esp32c3 (sorry)
- used the USB_VID and USB_PID from the existing SuperMini NRF52840 board
@dhalbert Here you go! Didn't realize deleting the fork would kill #9016. I won't be touching that hot stove again.
Are you associated with the manufacturer or are you a consumer? Is this board identical to an existing one like the Seeed C3 board?
Submit PR's for new creation ids here: https://github.com/creationid/. Pick the appropriate repository.
This board does not need USB_VID and USB_PID because it does not support USB access (except for serial).
This is the flash target in ports/espressif/Makefile. It is not for UF2's. It's just a convenience for flashing the .bin
i don't know if there's a tinyuf2 build (or a compatible one) for this board
I used the one from UM Feather S3.
yes, the creation id is not that important for just testing. I see a grand total of two sales of this board. I am a bit reluctant to add a bunch of clone boards that all differ slightly if they are not popular.
I bought it but never set it up iirc
just a redirect to the repo would be easy
The ESP bootloader tracks which OTA partition is live I think. I generally use flash without the UF2 bootloader. udisksctl mount -b /dev/disk/by-label/RPI-RP2 && cp build-adafruit_feather_rp2040_can/firmware.uf2 /run/media/tannewt/RPI-RP2/ can copy a uf2 from the command line if you just want to use the uf2 bootloader