#circuitpython-dev
1 messages ยท Page 51 of 1
@tulip sleet here now. need anything from me?
I got two small PR's: 8.2.x merge and update frozen libs. If you review and approve those I will make an alpha.3. Howzat sound?
I think you want the flash to be qio as well.
CIRCUITPY_ESP_FLASH_MODE = qio
CIRCUITPY_ESP_FLASH_MODE = qio
In C, should I return null after raising a python error?
It shouldn't get there but ya, I return after mp_raise sometimes
mp_raise routines are declared NO_RETURN
@slender iron I copied the CIRCUITPY_ESP_FLASH_MODE from UM's definitions in 8.2.x. There did they matter? Maybe they didn't, except for esptool.py args, and now they do?
right, they only used to be for esptool.py
sdkconfig would determine boot mode
now it determines the sdkconfig inclusion and the esptool.py mode is derived from them
are there any dio ESP32-S3 boards?
I don't think UM has published schematics for these boards yet
@atomic summit CIRCUITPY_ESP_FLASH_MODE now matters, could you confirm what mode is used for bling and tinywatch_s3?
All of my boards should be using QIO for flash mode. Iโll be at my desk in 20mins.
that's all I need to know now, thanks
Hmm, I just found some GitHub emails from you and Scott (and others) in my spam folder.. grr.
@slender iron dio changed to qio ; ready for re-review
Scott, totally missed your request on my main line PR!!!!
And your request yesterday Dan. So sorry ๐ฆ
Hey, folks! I scanned through the channel hoping for a resolution on the Sonoma issue, but it appears that it's still outstanding. Is that correct?
that is correct, and I've tested the latest developer beta, and it still has the same bad behavior ๐ฆ
Oof.
No problem!
At what point is the issue occurring? I'm asking in the context of, is it possible to spin up a VM with an earlier version of MacOS, and be able to work with CircuitPython again?
At least I think I can VM an earlier version....
@atomic summit i didn't even realize that PR was there, so I kind of redid things, so see if there's anything in my PR that needs changing. We can close yours, or you can rebase after I merge mine, and we'll just pick up your changes to overwrite mine (after you change yours to qio)
yes, still works fine in Ventura. Erin downgraded her system after having considerable troubles.
the workarounds in the issue also work, but are a nuisance
if there's some weird issue about how the USB devices get passed through to the VM, maybe, but I hope not.
I might give it a try then. I'll let you know if there are issues.
I gave the VM route a shot with Parallels, but the MacOS VM has no USB passthru.
Oh that was my plan. ๐
That means it doesn't work?
Please just close mine. Iโll do a new PR against whatever you did, if needed. Thanks heaps for updating my stuff.
Sorry for the obvious question.
sure, np
Yes, it doesn't work. Sorry.
No apology needed. Thanks so much for jumping in before I went to the effort of trying. That's super frustrating.
it looks like any drive 8MB or below has the problem; there are a few boards that are 16MB
I wonder if contacting the MacOS news sites might help.
Is there any place I can look to learn more about the IDF allocations?
The IDF won't allocate with increasing addresses necessarily. Instead, it uses TLSF for the allocation which tries to do a good fit allocation. It is interesting to see the heap layout when the allocation fails and to also know what the IDF says is the largest free section.
Please post complete zips of code for your large project if you want me to look at them.
maybe... if we could come up with a "this bothers regular consumers" story that would help. It does really mess up classroom use.
That's what I was thinking, too. Apple failing education.
I'll dig into the issue again with the purpose of finding the workarounds to see if I can integrate them into a workflow that's not absurd for me. I can understand Erin not wanting to deal with it, though. That must have been rough for her.
Thanks so much for the prompt responses. I appreciate knowing not to bother with the VM ahead of time instead of banging my head against it for however long that would have gone on.
I recommend the re-mount workaround.
Ok, I'll check that out, thank you.
I only scanned the issue previously hoping it had been resolved. I didn't look too deep into any of the workarounds.
I found the "breaking version". This version allows me to
import adafruit_qualiawithout error:
Do you still have the pystack size change with the old version? I think there are two issues here:
- We need to adjust pystack size for newer MP core. (Covered by this issue)
- We need to tune the split heap behavior. (Covered by #8573 )
I found the "breaking version". This version allows me to
import adafruit_qualiawithout error:Do you still have the pystack size change with the old version?
I commented the CIRCUITPY_PYSTACK_SIZE line in settings.toml before finding the breaking version.
Ok, that's interesting. Maybe I broke the pystack size with the split heap PR. Still worth a separate issue (this one.)
and remove CIRCUITPY_RESERVED_PSRAM.
Fixes #8581
clarified a little, and gave current default
Sets the initial size of the python heap, allocated from the outer heap. Must be a multiple of 4.
The default is currently 8192.
The python heap will grow by doubling and redoubling this initial size until it cannot fit in the outer heap.
Larger values will reserve more RAM for python use and prevent the supervisor and SDK
from large allocations of their own.
Smaller values will likely grow sooner than large start sizes.
CIRCUITPY_HEAP_START_SIZE
~~~~~~~~~~~~~~~~~~~~~~~~~
Tests are going to fail until adafruit_asyncio uses the CancelledError from _asyncio. Opened https://github.com/adafruit/Adafruit_CircuitPython_asyncio/pull/55 for this unless there's a different way this should be handled.
Thanks Scott!
I wasn't really thinking that you'd be looking specifically at my use case. I'm running the PyBasic version of Adventure from within PyDOS. There's also an interactive component as once everything loads and appears to run okay I can continue to stress the memory by playing through the game for a bit.
If you really want to do some testing with PyDOS/PyBasic let me know what board you'll be testing on and I'll zip up a set of files for you but I'm also fine with posting any ...
I've been a little scarce lately... is there a description of the new memory architecture somewhere? is it across all ports? do ports besides espressif have an inner heap and outer heap (is the inner heap espidf memory)? do the gc and espidf module functions still give good indicators of memory usage? are C stack and Py stack unchanged?
adds the Heltec ESP32S3 WiFi LoRa V3 as a supported espressif board
this board doesn't connect USB by default and instead supports interactions via a CP210x over USB
the USB VID/PID was pulled from their repository but it's the standard espressif VID and a PID I don't recognize
Closing this as superseded by #8575, but no problem with a new PR that adjusts things slightly as needed.
Do I need to request a CIRCUITPY_CREATION_ID somewhere for this? Otherwise Bluetooth doesn't seem to build.
The outer heap is all of free RAM besides the C stack. From that the Python heap, the PYSTACK (if used) and non-Python-VM storage are allocated. If the RTOS (ESP-IDF) wants storage, it also allocates from the outer heap. Not sure about gc memory reports now.
@slender iron can correct me as needed and explicate.
Hi,
Recently bought a couple Espressif ESP32-C6-DevKitC-1. Tried installing CP, but hit an issue of some kind.
I can build/flash examples from ESP-IDF, but flashing CP's .bin to 0x0 or 0x10000 doesn't start CP.
When powered, the LED flashes GREEN once every few seconds (RPLE success?).
Board brand: Espressif
Board model: ESP32-C6-DevKitC-1 v1.2
ESP32 board: ESP32-C6-WROOM-1 (bottom left beside QR says MAN8)
esptool --chip esp32c6 --port COM5 write_flash 0x0 adafrui...
Thanks, Dan. It helps to have a mental model of resources (and how they might change) when writing and debugging.
I was able to run Ubuntu under Parallels on Sonoma and Ubuntu had no issues with CircuitPython devices over USB in the VM. The main pain point was having to keep the USB device assigned to the VM rather than macOS.
Hiii, been using circuitpython with rp2040 and stm32f411 (blackpill) from weAct. These were already in the prebuilt circuitpython downloads page so it was a breeze. I'm now trying to get circuitpython working on another board which is not listed in the official page for now with an stm32f405 mc (same as the adafruit feather express).
Where should I start and any good advices? Thanks in advance.
MP found some people confused by gc.mem_free() differences. I think itโs free space in allocated python heaps + largest consecutive free space in the outer heap. Espidf functions may change because spiram is now managed by idf. This should make it easier to have more network connections and other idf uses.
Followup to #8571 on the fix of issue #8570.
While testing with more complex board layouts, the fix proved unstable, especially during the __exit__ of I2SOut but also while performing I2C operations. There seemed to be something I/O related. And indeed, I didn't use claim_pin to claim mclk. This commit fixes this issue.
Are you connected to the "USB" port?
Wow. That was the issue, taking notes lol. I had not tried switching over to the USB port and connecting over serial, only to check if a drive was mounted.
Thanks for the help, got the REPL now!
kinda feel dumb for that one ๐
C6 cannot show a usb filesystem. The "USB" port is only capable of serial + jtag for debugging.
The "UART" port is just attached to some of the board's gpio.
Do I need to request a
CIRCUITPY_CREATION_IDsomewhere for this? Otherwise Bluetooth doesn't seem to build if I omit it.
Using these suggested params in settings.toml
CIRCUITPY_HEAP_START_SIZE=1024000
CIRCUITPY_PYSTACK_SIZE=4000
FWIW I did the following:
factory reset
installed adafruit-circuitpython-adafruit_qualia_s3_rgb666-en_US-20231106-ccd667d.uf2
ran qualia_paint.py
RESULT: WORKS
factory reset
installed adafruit-circuitpython-adafruit_qualia_s3_rgb666-en_US-20231109-3ca9802.uf2
ran qualia_paint.py
RESULT: FAILS see below
soft reboot
Auto-reload is on. Simply save files over USB to run...
Automated website update for release 9.0.0-alpha.3 by Blinka.
New boards:
- lilygo_tdeck
- unexpectedmaker_bling
- unexpectedmaker_tinywatch_s3
- weact_esp32c6_n4
- weact_esp32c6_n8
That's progress :grin: try doubling the heap start to 2048000
Do I need to request a
CIRCUITPY_CREATION_IDsomewhere for this? Otherwise Bluetooth doesn't seem to build if I omit it.
Got it. Since this already has a USB VID and PID from espressif should I use the community documented VID & PID for espressif s3 boards?
Thank you. I will use weblate for the future changes.
Interesting. Thanks for the tip!
Before I go and do a whole lot of github actions weirdness to get grab the full circuitpython sources & build the unix micropython binary just to run tests via CI in the asyncio repo..
Is the micropython unix build hosted anywhere I could fetch instead?
Context: it's for this PR to get automated tests running -- https://github.com/adafruit/Adafruit_CircuitPython_asyncio/pull/58 -- which I wanted because I was hoping to bring CircuitPython's asyncio implementation closer in line with CPython's.. which I wanted because I could use the asyncio.wait func.. for.. a project I was doing but.. sheesh. Rabbit hole I'm down. ๐
lib/tlsf was missing from tools/ci_fetch_deps.py. Due to CI caches, I think this worked OK for PR's, but it failed when made a new release, 9.0.0-alpha.3. I removed all the caches. Not sure if the PR will test this. I think in any case I will need to make another release.
How do I get a PR accepted in a non CP repo? There doesn't even seem to a Discord channel for that?
The USB VID/PID are irrelevant since they will not be used. The creator ID should be based on the actual manufacturer, in this case, Heltec. When possible, we use the manufacturer's USB VID as part of the creator ID, but it sounds like they don't have their own VID? So just make up a creator ID -- anything that makes sense. Then for the creation ID, you could also see if there's a part number or something, or else just choose one. You might get some ideas from the other ones.
We only build the unix build to run tests, and we build the coverage variant for that:
in ports/unix:
make VARIANT=coverage test will run the tests
make VARIANT=coverage TEST_EXTRA=micropython/viper_addr.py test will run the particular test listed
which repo is it? Not sure what you mean about there not being a discord channel
Right - that all makes sense. I'll see what I can do with getting tests running in the asyncio repo, then.
that is an admirable task ๐
This seems to be the only dev channel?
This is my PR. https://github.com/adafruit/Adafruit_LED_Backpack/pull/76
Seems abandoned, the earliest PR is from 2015?
There aren't as many people working on Arduino libraries as CIrcuitPython lbraries, and they have other primary reponsibilities, so they get addressed as time permits, which often isn't very often. If there are bugs, they'll be addressed sooner. But enhancements don't get very immediate attention. There's a large backlog of Arduino library PR's and issues, sorry.
In general the strategy has been: write a library for the new product, make sure it's debugged, and then it's "good enough".
I am writing a library that depends on that library. SO what you are telling me is to look elsewhere.
no, squeaky wheels can get the grease. I just reviewed it.
not always ๐ , but this was easy
I've created a helper library for the LILYGO T-Deck on CircuitPython. Development for the peripherals will continue here. Contributions are welcome!
I was actually planning to make a PR for the docs instead.
you mean the README? that would be good, but a diagram right in the .h, or at least a cross-reference, would be good. And/or in the example, since the example code is often the easiest thing to see from the Arduino IDE
you are spoiled by the CircuitPython rapid response team ๐
No, I mean the page in the learning system.
we don't have PR's for that, but you can use the "Feedback" link in the left sidebar
the learning system is a CMS, not driven from github (except for the code in the Learning System Repo)
Ah, OK.
let me know when you add feedback and I will check on it.
Done!
ok, check out the edits in the guide
Oh, that is SO much better than I imagined!
Hello.
I've found a work around that requires deep sleep. I was confused as to how to implement it at first. However this is what I have and it works as intended.
# import
import alarm
import board
import simpleio
import time
# Time values set by user
seconds = 10 #testing
minutes = 1
hours = 0
days = 0
# math
minute = minutes * 60
hour = hours * 3600
day = days * 86400
val = seconds + minute + hour + day
time_alarm = alarm.time.TimeAlarm(monotonic_time=t...
There are two different implementations of "get some needed submodules in the tools/ directory.
Unify them, possibly by changing the make fetch-submodules / make fetch-port-submodules commands invoke ci_fetch_deps.py and remove fetch-submodules.sh.
ci_fetch_deps.py may need to be taught about using --filter=blob:none in the process.
Sunday puzzle: can I install CircuitPython ESP32 on an Airlift shield?
The Saola 1 w/ WROOM port would probably be installable. You'll use esptool.py and a USB-serial adapter, or use the passthrough program on some board to make a USB-serial adapter
there are other ESP32 WROOM builds that are probably fine too
Automated website update for release 9.0.0-alpha.4 by Blinka.
New boards:
- lilygo_tdeck
- unexpectedmaker_bling
- unexpectedmaker_tinywatch_s3
- weact_esp32c6_n4
- weact_esp32c6_n8
- teach ci_fetch_deps about --filter=blob:none
- change logic ensuring tags in frozen/ are fetched
- since check=True was all the time, remove unused kwarg
- add fetch-board-submodules
Closes: #8588
a little light-hearted link for your sunday (plays music): https://starlogs.dev/adafruit/circuitpython
I'm pretty sure this is how the weekly meeting should now do the reviews of the core
@main furnace it looks like there's an issue with redirects in learn. that link should 301-redirect to https://learn.adafruit.com/upgrading-esp32-firmware/old-upgrade-an-external-esp32 -- and it does for me, if I'm logged in to adafruit.com. In a fresh incognito window I reproduce your behavior of a 404 page instead. I will raise this with the "learn dev" team via e-mail.
thanks
@onyx hinge did you just fix the link? It looks OK now
I have done a lot more research into the issue, but found nothing of value.
The current CircuitPython esp wifi code is nice and clean, much simpler than the rp2 wifi code.
I did compare idf examples and the arduino underlying code, but unfortunately only found minor differences in how they handle their wifi stack on esp.
The main stuff is basically identical, with only some tiny stuff being different (pdTRUE and pdFALSE for the bit waiting).
I did look deeper into how the wifi is ...
I've updated the link so that it goes to the current version of that content: https://learn.adafruit.com/upgrading-esp32-firmware/upgrade-external-esp32-airlift-firmware-2 -- the "old" page has been un-published, which is why it worked for me (I have editor rights on learn ). so you were "supposed" to see that 404, I guess. In the future, you can report errors like 404 using the feedback link on the left hand side of the page. (and then I got called away before sending this messge, whoops)
@main furnace (repeating myself) I've updated the link so that it goes to the current version of that content: https://learn.adafruit.com/upgrading-esp32-firmware/upgrade-external-esp32-airlift-firmware-2
It also doesn't help that the wifi spec is basically ungooglable, and I have no clue what the issue really is in nature.
I am basically just throwing pebbles down a ravine to hear how deep it is.
Also I should make it clear, I did test about 20 different combinations of tiny changes with absolutely no effect.
Even trying with an incorrect wifi password the result is always the same.
This leads me to believe that the issue is in the forked idf. But it could be somewhere in init or the ...
At first I was unable to reproduce this problem, but that was because pull #7101 had turned the crash into a "Stopping AP is not supported." in common_hal_wifi_radio_stop_ap(). Looking into the reason for that I found https://github.com/georgerobotics/cyw43-driver/issues/47 which notes that "Something needs to call cyw43_wifi_set_up with up set to false...". Doing that solves this issue and makes wifi.stop_ap() functional for RP2.
Implement wifi.stop_ap() in RP2.
Resolves #8138.
@rgrizzell Thanks for your work on this!!!
Using artifact Adafruit CircuitPython 8.2.7-6-g2aa5b443a7 on 2023-11-12; Raspberry Pi Pico W with rp2040:
LGTM, can start and stop AP, and alternate between Station and AP, repeatedly, without issue.
import time
import os
import wifi
AP_SSID = "TEST"
AP_PASSWORD = "picow1234"
ITERATIONS = 10
time.sleep(3) # wait for serial
print("="*25)
def connect():
while not wifi.radio.connected:
try:
wifi.radio.connect(os.getenv("WIFI_SSID"), os.getenv("WIFI_PASSWO...
Steps:
- Erase and factory reset
- copied in adafruit-circuitpython-adafruit_qualia_s3_rgb666-en_US-20231109-3ca9802.uf2
- D:\lib is empty; copied in adafruit-circuitpython-bundle-9.x-mpy-20231109
- D:\settings.toml now includes
CIRCUITPY_HEAP_START_SIZE=1024000
CIRCUITPY_PYSTACK_SIZE=4000 - copied example qualia_paint.py to D:\code.py changing to "Displays.ROUND21" on line 13
$$$$$$$$ FAIL $$$$$$$$
code.py output:
fw_version: 10, chip_type: 11
Traceback (most...
Hi Team,
We have an issue with PWIO deinit.
Crash happen due to sl_pwm_deinit function run many times with same input pwm_instance.
Current code is missing a variable reset.
This pull request adds the missing code l_tim->pin = NULL;
Thanks!
I think this is helpful information, especially since you're example is pretty easy to reproduce. I've been using a START_SIZE of 3072000 on boards that have enough RAM and 1536000 on the boards with less.
@jepler asking for a review from you, given your expertise on this, but looks good.
thanks! no testing performed.
@tulip sleet good morning! Getting started, do you have any github issues in mind for me to start with?
welcome back! let me take a look
News!
Commit 39192cc896d09cb72794bdf5d81726a8a6bfb520 works! So it's a matter of finding where the issue was introduced.
really anything 8.2.x or 9.0.0. It would be nice to think about the split-heap issues, but maybe we should do that with Scott. Maybe there is a pystack issue in there. We can talk at the meeting. I am just picking random ones that seem approachable and dealing with them. Assign yourself if you start on one.
OK, I'll see what pops out
It looks like we already use it. It's listed among the source files and I checked an object file from the build for trinket m0:
jepler@bert:~/src/circuitpython/ports/atmel-samd$ arm-none-eabi-nm --plugin /home/jepler/.local/gcc-arm-none-eabi-10-2020-q4-major/lib/gcc/arm-none-eabi/10.2.1/liblto_plugin.so.0.0.0 build-trinket_m0/shared/runtime/stdout_helpers.o
00000000 T mp_hal_stdout_tx_str
U mp_hal_stdout_tx_strn
00000000 T mp_hal_stdout_tx_strn_cooked
I was wondering whether we should pick up the revised version of the code:
CircuitPython version
(recent main)
Code/REPL
...
Behavior
Limor reports: " I noticed that I wasn't able to change the jpeg quality? [I'm setting the .quality property dynamically and] it does not seem to actually change the jpeg quality"
Description
No response
Additional information
No response
I found extreme values unreliable which is why I wrote in the documentation:
The exact range of appropriate values depends on the sensor and must be determined empirically.
I recommend making a build that will show esp-idf log messages & seeing if anything useful turns up. Or, try the same jpeg settings in their sample app that builds without circuitpython to see if the failure occurs there too.
There's a very simplisitic calculation of the needed buffer size based on resolution in e...
[slapping myself on the forehead emoji]
I will be getting more camera boards soon (you will see the PRs), so I plan on logging and comparing different cameras and their settings success rates then.
@strong violet hi - I want to debug some CircuitPython crashes that happen only when CPy is used with Thonny: https://github.com/adafruit/circuitpython/issues/8038 https://github.com/adafruit/circuitpython/issues/7544
https://github.com/adafruit/circuitpython/issues/8364
The problem may occur when an exception is raised on the CPy side. We should not crash.
But I'd like to see everything that Thonny is sending to the REPL and all the replies. I turned on Debug Mode and Log Program Usage Events in the Thonny Options, but backend.log does not contain everything sent . Many months ago I added some print statements inside Thonny to try to do this, but I was not completely successful. Is there a hidden option I could set, or do you have a suggestion about what to print where? Thanks.
I do not see the safe mode crash when using a simple terminal program, but I do see a crash when using Thonny. I'm guessing you're using Thonny: is that right?
Seems similar to #8038 and maybe #7544.
CircuitPython version
9-alpha4
Code/REPL
``
Behavior
``
Description
Looks for TinyUF2 for qualia, release doesn't exist.
The device (qualia) seems to show up as TFT experimenter when booted into uf2 bootloader after using factory reset.bin
Interesting to note because adafruit tft experimenter does have a tinyUF2 release.
https://github.com/adafruit/tinyuf2/issues/358
Additional information
No response
CircuitPython version
I got a PYSTACK Exhausted Error.
Added to settings.toml **CIRCUITPY_HEAP_START_SIZE =** and adjusted it from 8192 up to 32768 with x2 in each step: Not fixed.
Removed CIRCUITPY_HEAP_START_SIZE.
Added CIRCUITPY_PYSTACK_SIZE = 8192: Fixed.
Code/REPL
# SPDX-FileCopyrightText: 2023 Liz Clark for Adafruit Industries
#
# SPDX-License-Identifier: MIT
import os
import time
import wifi
import busio
import board
import ipaddress
...
Yeah, the bootloader ID (https://github.com/adafruit/circuitpython-org/blob/main/_board/adafruit_qualia_s3_rgb666.md?plain=1#L11) needs to be removed from the board file and it shouldn't try and use a file that doesn't exist.
Commit at fault: 16d1dc2be07ee7f35079515b081dd817319ab311
It's not a buildable commit, the next buildable is faa445e347d4508d7bb6bf2b8cb175702cea2d63 and exhibits this issue.
The last WORKING commit is: 6649b17fb5b98efed97e9234c670bb16cdf6cac3
This could be interesting for running a separate program on a subsequent CPU core: https://github.com/micropython/micropython/pull/12961
This is a work in progress to add support for OpenAMP in MicroPython, to allow communications between cores on multi-core micro-controllers (specifically the H7). As a first step, I've implemen...
A while back I was using one of the DVI boards with Thonny and noticed that all the Thonny back end stuff was being mirrored on the DVI output. Maybe you could plug into an HDMI capture device to grab what you're looking for.
๐ก thanks. or maybe any SAMD21 or nRF board with a display. CLUE is the easiest one to try first
There was a lot of stuff so I'm not sure you'll see what you need just on the screen
is there any table listing the modules/features implemented for each port, or a list of desired functionality from standard lib (or anything else that is not port-specific)?
would like to check them to see if there's anything i could do (:
also, im planning to PR my TOML library to the community bundle, does helpers/toml sound like a good location?
i was thinking more on a MCU-based than board-based table of things, but i guess that's pretty much the same, thx!
Wondering if anyone has used nRF sniffer with the ItsyBisy nRF52840 Express or similar?
Please just delete these lines. Thanks for the fix!
Instead of commenting these out, just remove them. That'll inherit the default settings instead.
<@&356864093652516868> Heya! we're about 35 minutes away from the weekly meeting. See you in the CircuitPython voice channel! Please add your notes to https://docs.google.com/document/d/1GChyaFlm9dC-TNY4DgkKVXk51ZxJCHfd42bJOstZmIg/edit?usp=sharing if you have them.
CircuitPython Weekly Meeting for November 13, 2023 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canโt make the meeting and would still like to pa...
have you seen https://learn.adafruit.com/ble-sniffer-with-nrf52840
i tended to use nRFConnect on Adndroid (turn it landscape for a better view), and also nRFConnect on desktop with a Nordic dev board
Yes. That's what got me interested. OTA sniffing is just what I need about now. Hoping I could do it with what I have on hand.
it might be possible to (re)install the Nordic bootloader on a non-Noridc board and have it pretend to be a PCA10056 or somethign
I'll give it a shot. Thanks for the tip!
https://www.digikey.com/en/products/detail/nordic-semiconductor-asa/NRF52840-DONGLE/9491124 is cheap and I think should work
above, I meant nRFConnect on an Android tablet, not Arduino
on iOS ois more limited due to iOS security restrictions
Hey @alextremblay , got the VID/PID allocation =) , the commit in the raspberry pi repo is here : PID-Commit
For clarity, here is the VID/PID allocated for the Elite-Pi :
Vendor ID = 0x2E8A
Product ID = 0x1072
You can update your PR or I can update it later this week when I have some free cycles =)
ALso @alextremblay, side-note : If you make the change, sould you also update USB_MANUFACTURER to "Maple Computing" in mpconfigboard.mk? Thanks =P
this is obsoleted by the new split heap code :tada:
CircuitPython version
Adafruit CircuitPython 9.0.0-alpha.4 on 2023-11-12; Adafruit Metro ESP32S3 with ESP32S3
Code/REPL
import ipaddress
import wifi
import socketpool
import time
import adafruit_requests
Behavior
import adafruit_requests
Traceback (most recent call last):
File "", line 1, in
MemoryError:
Description
No response
Additional information
No response
The newest releases need CIRCUITPY_HEAP_START_SIZE set to a pretty large value in settings.toml. Take a look at #8574
Works normally with 8.2.7 -- same settings.toml
hey all! I'll be back in just a few minutes to get the public meeting started.
The newest releases need CIRCUITPY_HEAP_START_SIZE set to a pretty large value in settings.toml. Take a look at #8574
This is a temporary workaround. We shouldn't need it for 9.x.
Is adafruit_requests a .py file or .mpy file?
OK
CIRCUITPY_PYSTACK_SIZE=4000
``` works
The newest releases need CIRCUITPY_HEAP_START_SIZE set to a pretty large value in settings.toml. Take a look at #8574
This is a temporary workaround. We shouldn't need it for 9.x.
Is
adafruit_requestsa .py file or .mpy file?
.py
Awesome! Thanks a lot!
I've gone ahead and made those changes
I had to set both:
CIRCUITPY_HEAP_START_SIZE=1024000
CIRCUITPY_PYSTACK_SIZE=4000
setting only
CIRCUITPY_HEAP_START_SIZE=1024000
resulted in
Adafruit CircuitPython 9.0.0-alpha.4 on 2023-11-12; Adafruit Metro ESP32S3 with ESP32S3
import wifi_test
ip 10.0.0.106
8.8.4.4
ping 0.0
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "wifi_test.py", line 19, in <module>
File "adafruit_requests.py", line 711, in get
File "adafruit_requests.py", ...
I'm going to mark this a duplicate of #8574. I think I found the issue. PR soon.
Right?
I went through that over a year ago when moving out of my office and decided to finally sort everything.
Original code used uint32_t* so / sizeof(size_t) was needed. It is a uint8_t* now so that division makes it 4x smaller. Whoops!
Fixes #8574
Hooray! ๐
I can't see my floor.
What's a floor?
No floor, no dancing. ๐ฅน
Thanks, everyone! Thanks for hosting, Jeff!
thanks Jeff
thanks for hosting Jeff!
Thanks for hosting Jeff. Hope everyone has a nice week!
Thanks Jeff
@lone axle โ๏ธ
interesting, I'll take a look at that. I didn't think any adjustment would be needed for the dependencies because toml was already in requirements.txt here: https://github.com/adafruit/circup/blob/main/requirements.txt#L50
Though I also noticed some of these are pinned to very old versions. Maybe it's worth trying to unpin some of them.
Ah, I think it maybe that there is a difference in requirements.txt vs. dependencies listed in setup.py (or pyproject.toml for newer style setups.) I'll make an empty venv locally and figure out how to add it so that pip handles the install with dependencies automatically.
I just saw this issue too
I am not sure requirements.txt is actually used for anything in circup.
I think inside of actions it may still try installing with something akin to pip install -r requirements.txt but I don't know whether it'd break it if that file is gone. I also do not really know much about the particulars of packaging and whether it's really necessary or helpful to have both ar requirements.txt and a list inside of pyproject.toml / setup.py. If there isn't a good reason for it I do think it'd be nice to only manage 1 list.
Closes #8510
No testing performed
This change adds CircuitPython for the Oxocards boards based on ESP32 (https://oxocard.ch/en/).
I was not sure about the copyright notices in the source files. I left "Scott Shawcroft" and "Dan Halbert" in board.c and mpconfigboard.h. Let me know if I must put my name instead.
I also ran pre-commit run --all-files, but it changes many other ".c" and ".h" files. Is this normal, or do I have a problem with my configuration ? I also had many errors with uncrustify (such as `circuitpy...
Here is a picture of CircuitPython running on the Oxocard Connect.
The USB VID/PID are irrelevant since they will not be used. The creator ID should be based on the actual manufacturer, in this case, Heltec. When possible, we use the manufacturer's USB VID as part of the creator ID, but it sounds like they don't have their own VID? So just make up a creator ID -- anything that makes sense. Then for the creation ID, you could also see if there's a part number or something, or else just choose one. You might get some ideas from the other ones.
Got it! I ...
Oh, I missed the weekly call today, but thank you for the hug report danh!
I've been enjoying poking at it and learning - both about CircuitPython internals and asyncio internals - so a hug to everyone that's helping me learn and answering my questions. :)
Having another set of eyes on https://github.com/adafruit/circup/pull/163 would be much appreciated. I was initially a reviewer, but ended up committing changes necessary to get the --auto functionality working, so I'm hesitant to merge on my review alone. I have tested the PR version successfully on both USB and Web workflows.
Hello. I made my first pull-request and I noticed that the uncrustify of the pre-commit produced a lot of warnings :
circuitpython/tools/uncrustify.cfg:411: option 'sp_type_question' is deprecated; did you want to use 'sp_before_ptr_star' instead?
circuitpython/tools/uncrustify.cfg:905: option 'sp_before_tr_emb_cmt' is deprecated; did you want to use 'sp_before_tr_cmt' instead?
circuitpython/tools/uncrustify.cfg:908: option 'sp_num_before_tr_emb_cmt' is deprecated; did you want to use 'sp_num_before_tr_cmt' instead?
Option<NUM>: at circuitpython/tools/uncrustify.cfg:1058: Expected number , for 'indent_shift'; got 'false'
circuitpython/tools/uncrustify.cfg:1124: option 'indent_sing_line_comments' is deprecated; did you want to use 'indent_single_line_comments_before' instead?
Option<NUM>: at circuitpython/tools/uncrustify.cfg:1205: Expected number , for 'indent_comma_paren'; got 'false'
Option<NUM>: at circuitpython/tools/uncrustify.cfg:1209: Expected number , for 'indent_bool_paren'; got 'false'
circuitpython/tools/uncrustify.cfg:2044: option 'nl_func_var_def_blk' is deprecated; it has been replaced by 'nl_var_def_blk_end_func_top'.
You can also use 'nl_var_def_blk_end' for additional functionality
Option<UNUM>: at circuitpython/tools/uncrustify.cfg:2538: Expected unsigned number , for 'align_nl_cont'; got 'false'
Option<UNUM>: at circuitpython/tools/uncrustify.cfg:2727: Expected unsigned number , for 'mod_full_brace_if_chain'; got 'false'
circuitpython/tools/uncrustify.cfg:2892: option 'pp_space' is deprecated; it has been replaced by 'pp_space_after'.
Option<NUM>: at circuitpython/tools/uncrustify.cfg:2947: Expected number , for 'pp_indent_brace'; got 'true'
Is there something wrong with my configuration ? Thank you in advance for your help.
I'm having a problem with the "uncrustify" of the "pre-commit".
It seems to run fine on my machine :
find ports/espressif/boards/oxo* -name mpconfigboard.h | xargs pre-commit run --files
Check Yaml...........................................(no files to check)Skipped
Fix End of Files.........................................................Passed
Trim Trailing Whitespace.................................................Passed
codespell.................................................
Hi Team,
We have an issue with characteristic properties:
When properties = (Characteristic.READ | Characteristic.WRITE_NO_RESPONSE), can change the value of characteristic normally
But when properties = (Characteristic.WRITE_NO_RESPONSE), cannot change the value of characteristic.
This pull request adds code handle for this case.
Thanks!
I have a potential explanation.
I am using a mac and I installed uncrustify using Homebrew. Homebrew installs the version 0.77.1_f.
The github actions uses the uncrustify from the Ubuntu packages and it installs the version 0.72
The versions 0.77.1_f and 0.72 do not produce the same result! I guess that the uncrustify configuration files on CircuitPython are not yet ready for the version 0.77.1. Should I open an issue for this ?
Ugly hack time!
It seems like stdout has flush issues when I don't do any ansi
So I just went ahead and spammed more ansi
Has anyone seen a Py 3.12 issue that results in errors like this?
[INFO] Installing environment for https://github.com/pycqa/pylint.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
An unexpected error has occurred: CalledProcessError: command: ('/home/runner/.cache/pre-commit/repoxsh055ra/py_env-python3.12/bin/python', '-mpip', 'install', '.')
return code: 1
stdout:
Processing /home/runner/.cache/pre-commit/repoxsh055ra
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'error'
stderr:
error: subprocess-exited-with-error
ร Getting requirements to build wheel did not run successfully.
โ exit code: 1
... stacktrace ...
AttributeError: module 'pkgutil' has no attribute 'ImpImporter'. Did you mean: 'zipimporter'?
That bottom message seems to be the most relavant, but the full trace is here: https://github.com/adafruit/Adafruit_CircuitPython_TestRepo/actions/runs/6863971735/job/18664772706
Searching around online I saw threads with people having the same error while trying to install numpy and a few other things with py3.12 but haven't been able to figure out which thing our action is using that is failing. Perhaps pylint inside of pre-commit? that looks like the last thing that it was successfully working on to my eye in the log.
Some additional oddities are 1) the same commit that now raises the error actually passed successfully a week or two ago, but there was a delay until the release, and now the same action failed when it ran for release. and 2) another repo doesn't seem to exhibit the same problem currently, but to my knowledge the actions are pretty much centralized now so if it were as simple as a certain version of something not being able to install I'd have thought it would affect all library repos.
What version of uncrustify do you have? You need uncrustify 0.71 or 0.72. older and newer versions are not OK (0.75 is mentioned as not OK in BUILDING.md, probably based on a user report).
Uncrustify-0.72.0_f
interesting thank you. I'm not sure how pip gets installed in the actions container. I'll dig a bit further later on today.
Thank you @onyx hinge. You are right. I was using the version 0.77.1 of uncrustify (default on macos with homebrew). Sorry, I missed this information from the BUILDING.md file. I installed 0.72 and now it works.
I'm glad that helped you. It's hard to find all relevant information like that, no worries.
@lone axle where's your actions yml file? Is it using actions/setup-python ?
@onyx hinge, I have another question concerning the building process with virtualenv and ESP-IDF. Is it OK to post my question here ?
Sure!
Thank you. The file ports/espressif/README.rst says that we must install ESP-IDF using ./esp-idf/install.sh. I had some trouble with this because by default, it installs the tools in ~/.espressif and I already have a native installation of ESP-IDF there. I was able to solve this issue by setting the IDF_TOOLS_PATH environnement variable somewhere else than ~/.espressif.
Then the document ask to type ./esp-idf/export.sh, but I was actually used to source this file and not to just execute it. But when you source this file, you get a new virtualenv and the previous packages installed by pip3 install --upgrade -r requirements-dev.txt are no longer there. What I did was to redo the pip install in the virtual env of ESP-IDF.
For me, it was easier to do so than adding the ESP-IDF tools to the path. Is this the correct way to do it ?
ports/espressif/README.rst: ./esp-idf/export.sh
This looks like a plain error and a PR to correct it would be greatly appreciated.
Yes, I have also seen that you have to re-do the "pip install" of CircuitPython's pip requirements once you've activated the esp-idf environment. This should be properly documented.
My impression was that ~/.espressif tries to organize things so that you can have multiple copies of the esp-idf on your system; for instance, it organizes each esp-idf environment in a different directory such as python_env/idf5.1_py3.11_env and each dependent tool such as tools/cmake/3.20.3/ so I'm not sure why you encountered the need to use a different environment setting to avoid interference. That said, I don't doubt you, I just don't use many non-CircuitPython esp-idf projects, so again this technique might be worth documenting even if it only is needed by some users.
goes afk for breakfast
I had some interesting discussions with @jepler on Discord and I actually missed the information concerning the version of uncrustify in the doc. Sorry.
Thanks!
Two questions:
- Is it actually correct that a BT_GATT_CHRC_READ property (without _WRITE or _WRITE_WITHOUT_RESP) should be settable?
- if none of those bits is set, the sl_bt_gatt_server_write_attribute_value call is not made but sl_bt_gatt_server_send_notification / send_indication calls could occur if those bits are set. Should an exception be raised in this case? This is what the (incomplete) implementation of sl_bt_gatt_server_send_notification in the ble-hci implementatio...
Here is the notes document for next Mondayโs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youโll be attending the meeting - itโs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weโll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1wQlnIywB9v88w8W-PSWXyB9DKKyS06AnKd6TS4s87pk/edit?usp=sharing
CircuitPython Weekly Meeting for November 20, 2023 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canโt make the meeting and would still like to pa...
@tulip sleet weird "CIRCUITPY not showing up" issue if u have any ideas?
https://forums.adafruit.com/viewtopic.php?t=205863
CIRCUITPY drive could not be found or created. safe mode is usually because there is something wrong with the external flash chip or its connections. I specifically added that check and message because figuring out the flash was bad was otherwise difficult. It looks they are using the right UF2. I would just replace as a hardware failure.
thanks. i was starting to guess hw fail, but there's also like 5 million software/OS quirks out there ๐
it's weird it still shows up as drive, but that might be the USB code getting ahead of the rest of things
It would be nice to have way to know (from python) what language is the current build of CircuitPython.
This way advanced applications could read it and apply the correct language, without user input.
Has anyone noticed that the clock runs fast on the Metro-M7? It gains 10m in one hour.
Adafruit CircuitPython 8.2.7 on 2023-10-19; Metro MIMXRT1011 with IMXRT1011DAE5A
@silabs-ChatNguyen
@silabs-BelaV
Silabs port builds fail intermittently during GitHub Actions CI runs. Re-running the failed job usually succeeds.
Examples (which will disappear within 3 months, I think):
https://github.com/adafruit/circuitpython/actions/runs/6778521612
https://github.com/adafruit/circuitpython/actions/runs/6723361060
We're wondering if there's a race condition in the silabs makefiles, such as some missing dependency. The jobs get run with -j2.
This looks fine. As for copyright, you could change the files you change to be copyright by you, but it's not a requirement.
As discussed in discord, we use a specific version of uncrustify, with specific settings, to match up with what MicroPython uses. This prevents needless skew from upstream.
I won't merge immediately in case you want to change the copyright, but it doesn't really matter.
Hmm! please file an issue!
@danh I was unable to locate the bootloader binary that Nordic flashes onto their nrf52840 dongle. Tried various combos of other bootloaders and the nrf sniffer via j-link with no success. If you happen to have their bootloader binary handy, I could use it. Otherwise, I've got an official dongle on order from Digikey, so if it's an effort on your part I can wait.
the on board clocks are often not too precise, but 10 minutes/hour is pretty bad. Is this the time.monotonic timer or the time.localtime RTC?
See "Revert to production bootloader" way down the page
Got it! Thank you.
def get_time():
now = time.localtime()
a = f"{now.tm_year}-{now.tm_mon:02d}-{now.tm_mday:02d} "
a += f"{now.tm_hour:02d}:{now.tm_min:02d}:{now.tm_sec:02d}"
return a
time.localtime() on Metro M7.
Want the circuitpythonista role? That'll get you pinged once a week about the meeting notes.
CircuitPython version
Adafruit CircuitPython 8.2.7 on 2023-10-19; Metro MIMXRT1011 with IMXRT1011DAE5A
Code/REPL
def get_time():
now = time.localtime()
a = f"{now.tm_year}-{now.tm_mon:02d}-{now.tm_mday:02d} "
a += f"{now.tm_hour:02d}:{now.tm_min:02d}:{now.tm_sec:02d}"
return a
while True:
time.sleep(1)
print(get_time())
Behavior
Compare printed time with computer clock. The M7 clock is fast.
Description
_No ...
pystack should be fixed by #8598
With the latest PR now only the
CIRCUITPY_HEAP_START_SIZE=1024000
is needed.
Adafruit CircuitPython 9.0.0-alpha.4-5-ged7c714fe2 on 2023-11-13; Adafruit Metro ESP32S3 with ESP32S3
import wifi_test
ip 10.0.0.106
8.8.4.4
ping 0.0
200
This is a test of Adafruit WiFi!
If you can read this, its working :)
200
{'timezone': 'America/New_York', 'utc_datetime': '2023-11-14T17:40:00.336035+00:00', 'raw_offset': -18000, 'client_ip': '71.232.151.158', 'dst_from': None, 'unixtime': 1...
and as suggested, reducing it by a factor of 4 still works
CIRCUITPY_HEAP_START_SIZE=256000
works
What's the determining factor on whether the new heap will grow automatically vs. needing a custom CIRCUITPY_HEAP_START_SIZE= in settings.toml... some interaction with esp-idf memory usage?
This works in MicroPython with GPIO32, so I'll see what they are doing differently.
tlsf_add_pool: Memory must be aligned by %u bytes.
tlsf_add_pool: Memory size must be between %u and %u bytes.```some tlsf error messages that should never occur end up embedded in the binary, because it calls printf() on them. couldn't figure out a way to change it without modifying the submodule.
CIRCUITPY_HEAP_START_SIZE=128000 also works now.
CIRCUITPY_HEAP_START_SIZE=65536 does not....
could we just #define printf(...) to be nothing, just in that module?
add it as a command -line arg to the compilation of lib/tlsf
I'm ok if we fork the library. it isn't that big
I can run the Quotes Request Test from:
https://learn.adafruit.com/pico-w-wifi-with-circuitpython/pico-w-requests-test-adafruit-quotes
on
Adafruit CircuitPython 9.0.0-alpha.4-5-ged7c714fe2 on 2023-11-13; Raspberry Pi Pico W with rp2040
and
Adafruit CircuitPython 8.2.7 on 2023-10-19; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3
without a custom value for CIRCUITPY_HEAP_START_SIZE=
What BLE service requires that the server write a WRITE_NO_RESPONSE characteristic? Doesn't that say only the client is writing to the characteristic?
One sdkconfig piece I don't think you need.
I doubt you need this if the native USB isn't connected.
What's the determining factor on whether the new heap will grow automatically vs. needing a custom
CIRCUITPY_HEAP_START_SIZE=insettings.toml... some interaction withesp-idfmemory usage?
It will grow automatically either way when it needs more memory. I'm not sure why setting the start size helps. Maybe fragmentation of the IDF heap? I'm planning on looking into it more.
I was in over my head but when I looked at it, it looked to me like each allocation wasn't continuous so the small allocations were fragmenting the memory.
Oh, that would be nice! How do I get that?
just added you!
@lone axle when you're around i have an android/circuitpython question for you
I am around mostly for now, whatcha got?
so i was going to make a video talking about android support in alpha 9 but i've had issues saving an updated code.py file on android. i found your guide about your app but it looks like my phone is on a newer version of android so it can't install. i was wondering if you had any tips for being able to edit a file or get into the REPL?
That worked! Happily capturing BT LE traffic. Thank you again.
It has been quite a while since I've used the Android app for editing on a device. My understanding of some of the most recent changes is that they'll make it so that app and the way that it edits code via the REPL may not be neccessary any more. If I understand right I think CIRCUITPY drive can show up as a storage drive now, like it does on a PC. Then any text editor or code editor app could be used to modify and save the code.
As for REPL I think there are other Serial Terminal apps that may be able to access it. I tested with those before I ended up making that CircuitPython specific Android app.
I have a newer device I can test with. I'll try a few things and report back in a bit
Hmm, probably not. I thought I enabled it for a reason but I can't remember why.
I'll try disabling it, building, and flashing.
If it works fine I'll remove it. If it doesn't, I'll add a comment describing what reason it should be enabled.
okay, thank you! and it does show up as a device now and i can view/open files but i haven't been able to successfully save updates to code.py (tried pydroid, quickedit and Acode)
I guess the vendor documentation was corrected as this is the new version of that sensor on https://www.seeedstudio.com/Seeed-XIAO-BLE-Sense-nRF52840-p-5253.html
I was super confuse to read that this board could also speak through the the microphone. I guess that was lost in translation.
Do they give you any specific errors? Or just fail to load the file entirely?
it seems to fail uploading to the board. i can tell the board is getting a save but then it blinks an error or goes into safe mode
Thanks. Yeah, I think the original sentence was a bit unclear even to a native English speaker.
@candid sun I was able to access REPL with this app: https://play.google.com/store/apps/details?id=de.kai_morich.serial_usb_terminal however the stock Android soft keyboard doesn't really have the concept of control, so it's tricky to press Ctrl-C / Ctrl-D. There might be alternative soft keyboards that could be installed to get them. I ended up adding them to the editor app UI so that there would be easy access without a custom keyboard in that app.
okay awesome, thanks! i'll try that app
I think this is a hardware issue, not a software one. The same build for a slightly different S3 ESP kit works ok. Printing out all of the io mux and gpio registers looks correct.
Loads just fine, not sure where I thought I needed it. Removing!
@candid sun Does your device have Google apps on it? Like Play Store and perhaps others?
I've found that I am able to successfully save modifications to code.py using text editors but I did have to jump through some hopes so to speak. To see the contents of CIRCUITPY and to open code.py file I used this official Google "Files" app: https://play.google.com/store/apps/details?id=com.google.android.apps.nbu.files when I click on code.py in there it gives me the option to select from the text editor apps I have installed. I had success with this one: https://play.google.com/store/apps/details?id=com.simplemobiletools.filemanager.pro (it's not free, I must've bought it at some point). I'll test Quickedit as well, I tried it was but was getting some gnarly full screen tiktok ads and things mixed in by it. If the ultimately goal is to point people toward the best practices for mobile dev it'd be nice to find one that works without intrusive ads. I can poke around and try to find some other options later.
My hope is that the old Editor app won't be necessary, and I have hope that will be the case after having success editing the file on my device. But Android is a bit finicky sometimes especially with different hardware thrown into the mix. If it ends up being the case that the old Editor can work in some cases where file editing cannot I'll try to get that updated so that it can be loaded onto newer versions of Android OS.
Lastly, I also worked out that you can send Ctrl-C and Ctrl-D from that USB serial app by longpressing on the "macro buttons" that are just above the keyboard. You can set them in Hex mode and use the values 03 for Ctrl-C and 04 for Ctrl-D. I'm not sure what magic is in those numbers but it seems to work.
Strangely the "Simple File Manager" app was unable to properly load the contents of CIRCUITPY. it shows it as empty. But the Google Files app can see it's contents correctly, then will allow you to choose which editor to use when you click on a file.
thank you! i had just started looking at the macros in the serial app and the hex mode is a great tip. i do have google play so i'll try the file manager app. i was also concerned with the ads in quick edit, i had done a search for reliable text editors on android and it came up in a few list articles but not great
I did get a successful save from QuickEdit too, so it can at least work.
macOS Sonoma 14.2 beta 3 is out today. Sad to say it does not fix the issue with copying files to FAT12 drives.
Boo. Thank you for testing!
I have one of these boards. vid is 0x303a, pid is 0x1001
Bus 001 Device 004: ID 303a:1001 Espressif USB JTAG/serial debug unit
It was setting the DMA capability requirement which excludes PSRAM.
Fixes #8597. Fixes #8573.
@tulip sleet โ๏ธ plus the pystack fix probably warrants an alpha release
looks good, yes!
I'm getting up from my desk now but will have my laptop with me if needed
i'll make another alpha tonight or tomw morning. I can test your latest PR easily
I think 8590 is on the 8 branch... can it be brought up to 9? that way we can use AP+STA and restarting AP together (on raspberrypi)
yes, we can re-merge from 8.x to main
i can do that before an alpha
had some good luck with saving with jota+ (google play) and editor (fdroid). i'm planning to write up a playground note with settings and such for folks. thanks for your help!
anyone seen a behavior where loading a (recent) latest UF2 onto an ESP32-S3 won't work and the bootloader just shows up again? I've quadruple-checked the UF2 is correct for the board
@jerryneedell @RetiredWizard interested in testing this from the artifacts? Thanks.
nope, I have never seen that..
And I do have a pretty decent number of S3s
I only use uf2 on usb-capable boards
Not even aliexpress boards do that..
iโll erase flash and try again, itโs an adafruit board
i can load 8.2.7 fine after those failures
if you are super sus of the cable, you can try using the deprecated --verify idf parameter
this reads back the written things after flashing ends
As discussed in discord, we use a specific version of uncrustify, with specific settings, to match up with what MicroPython uses. This prevents needless skew from upstream.
Thank you very much for the explanation. This makes the contribution somehow harder for Mac users, but it really makes sense. I might write a document to explain how to do it.
I won't merge immediately in case you want to change the copyright, but it doesn't really matter.
I don't need my name in the copyright, so feel free to merge the pull request whenever you want.
Looks great to me. I'm running my largest programs without any START_HEAP_SIZE set in settings.toml :grin:
Title and name entries indicate S3 not C6.
Thanks for the quick fix! Another alpha soon.
which s3 board and what is the name of the UF2?
did it work before?
Thanks for giving it a try. Bummer.
The CREATOR_ID and CREATION_ID are not yet registered. I plan to do it once the pull request is accepted.
Feel free to keep the creation ID listing in a repo you own so you don't need us to review it. Linking to it from here would be nice: https://github.com/creationid/creators
QT Py ESP32-S3 N4R2 board - adafruit-circuitpython-adafruit_qtpy_esp32s3_4mbflash_2mbpsram-en_US-20231113-ed7c714.uf2 - it does it on both of my boards of that type. I'll test some other UF2s, they load 8.2.7 fine, could be just som ething funny with that particular snapshot.
the qt py 8/0 and 4/2 boards are indistinguishable except by the chip markings, I think
want to make sure it's 4/2
right, I bought two of the 4/2 boards... oh, they may not be what I ordered o_O
we redid the sdkconfig to have a lot more defaults, so maybe the old one worked by accident, or maybe there's something really wrong. this build is past alpha.4 but it's not absolute latest. Scott just fixed a certain thing which is building now.
FH4R2 on the chip```py
import gc
gc.mem_free()
2046576
try artifact from this build: https://github.com/adafruit/circuitpython/actions/runs/6868862256
merge is still building
it won't take alpha.4 or absolute latest
(oh, interesting, you have to be logged in for the artifacts to be download links)
nope, adafruit-circuitpython-adafruit_qtpy_esp32s3_4mbflash_2mbpsram-en_US-20231114-95fc7e3.uf2 didn't stick either
8.2.7 is still fine, it's def 2MB PSRAM
did you try erasing completely and reinstalling the bootloader? I'm grasping at straws
I haven't done that yet, but will... I think I noticed these recent versions were larger files, maybe something high in bootloader flash got bonked
the only other quirk I can think of is... I usually expand filesystem on espressif boards with 4MB or less of flash (and did so on these two)
nope, same with unexpanded filesystem (no surprise)
I will try it in a few minutes
I'm erasing now
I'm seeing the same thing, blinking blue (or purple?) and it's boot-looping
before you load the uf2, you could try loading the bin
after erasing
that's actually what I'm doing
yup, bootlooping
(no lights on or blinking)
must be board-specific issue in the config somewhere? surely plenty of folks have tried other S3 boards
I'll try a Metro S3
works fine. I'll look at the board config files
Metro S3 UF2 is fine
that's in a module, the other is bare
ah ah ah
CIRCUITPY_ESP_FLASH_MODE = dio
qio on Feather. I'll check on that in a minute
p.10 https://www.espressif.com/sites/default/files/documentation/esp32-s3_datasheet_en.pdf quad on ESP32-S3FH4R2
that didn't use to matter (it was only used for flashing), but now we use it
rebuilding...
is dio somewhere in the QT Py S3 config? I only saw qio
oh, n/m, looking at Feather
also flash size is wrong
i am trying qio, will revert back to dio if it doesn't work
i bet fixing those two things will work
probably just a copy-pasta from the nopsram
8/0 qtpy is also dio
I am not succeeding with either dio or qio, and flash size is correct. Going to take a break on this for the moment.
also tried .bin
I was debugging some analog stuff on esp32
curiouser
something different about this
go ahead and open an issue so we don't lose sight of this
will do
CircuitPython version
Tried several 9.x from
adafruit-circuitpython-adafruit_qtpy_esp32s3_4mbflash_2mbpsram-en_US-9.0.0-alpha.4.uf2
to today's latest
adafruit-circuitpython-adafruit_qtpy_esp32s3_4mbflash_2mbpsram-en_US-20231114-95fc7e3.uf2
Code/REPL
no code
Behavior
Dropping UF2 onto bootloader drive... file copies, but then bootloader drive re-appears. Tried expanded and non-expanded filesystem. Tried fully erase_flash-ing, then loading `.b...
I found an error in the pin table for IO32: it had the wrong ADC1 channel. The other pins are OK.
2819 is the value that corresponds to a grounded pin: a read of zero.. This is the result of looking up an actual read value of 0 in the calibration LUT (look up table).
After correcting the IO32 channel value, I was able to read reasonable values on variable ADC1 pins. It is a mystery to me why pins other than IO32 were not working for other people. I understand why IO32 was not working. I...
- Fix ADC channel for IO32.
- Use better constant names when checking pin validity.
Tested on a Feather HUZZAH32 breakout.
It was a late night with much frustration, so I'm prepared to accept my
code may also be faulty :)
Looking forward to the PR
On Wed, 15 Nov 2023, 11:28 am Dan Halbert, @.***> wrote:
I found an error in the pin table for IO32: it had the wrong ADC1 channel.
The other pins are OK.2819 is the value that corresponds to a grounded pin: a read of zero..
This is the result of looking up an actual read value of 0 in the
calibration LUT (look up table).After co...
With CircuitPython loaded on this bad boy you get about 15M of flash filesystem space.
Artifacts to test are available here: https://github.com/adafruit/circuitpython/actions/runs/6871521986?pr=8607. Scroll down the page a bit.
Verified that a board with >8M of filesystem flash will not suffer delayed writes by testing with an Adafruit RP2040 Metro with 16M flash (about 15M FAT16 filesystem).
What BLE service requires that the server write a
WRITE_NO_RESPONSEcharacteristic? Doesn't that say only the client is writing to the characteristic?
Hi @tannewt
This issue is raised by a user. He uses a custom BLE service.
With only Characteristic.WRITE_NO_RESPONSE, we can't set value for "TestSVC.TestValue = random.randint(0, 255)"
When properties = (Characteristic.READ | Characteristic.WRITE_NO_RESPONSE), The value can change normally.
You can see the below example.
-------...
@tulip sleet are these two strings intended to be identical? I noticed that the way it's written, it puts two copies in flash.. c static const char midi_in_jack_name[] = USB_INTERFACE_NAME " usb_midi.ports[0]"; static const char midi_out_jack_name[] = USB_INTERFACE_NAME " usb_midi.ports[0]";
(changing it to char *midi_{in,out}_jack_name = merges the strings; this has to do with C rules about whether the two objects are permitted to be stored at the same address, I think)
This returns the localization of the running CircuitPython, such as en_US, fr, etc.
Additional changes are needed in build infrastructure since the string "en_US" should not appear to be translated in weblate, ever; instead the value comes from the translation metadata.
Closes: #8602
MicroPython 9.0.0-alpha.4-6-g00e3478320-dirty on 2023-11-14; linux [GCC 12.2.0] version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> help()
Willkommen bei Adafruit CircuitPython 9.0.0-alpha.4-6-...
I think the release exists under that bootloader id now, so do I just do a PR for the bootloader versions to bump ESP32 S3 (and maybe S2) to v0.18.1 here: https://github.com/adafruit/circuitpython-org/blob/main/_data/bootloaders.json#L13
This is the new release:
https://github.com/adafruit/tinyuf2/releases/download/0.18.1/tinyuf2-adafruit_qualia_s3_rgb666-0.18.1.zip
This differs ever so slightly from what I observe on my Linux system, where the encoding is shown as "UTF-8", not "utf-8"; we already had the latter as a qstr so I saved a few bytes by re-using it.
Otherwise, the timing of tasks is inconsistent, because C code and userspace code are using incompatible epochs.
For whatever reason, a bunch of asyncio tests would consistently fail in the Unix build locally; this change fixes it. I don't know why those same tests succeed in CI!
Closes: #8500 (probably, didn't test)
Hi,
It seems the problem occurs when building boards with parallelism.
I will check the makefiles again.
@eightycc is there anything we can do as a community to help you with your work on this?
Silabs uses the SLC tool for generate code before build process.
In 2 examples above, code generation failed on first build:
I don't understand why, but i can try to update new version of SLC tool.
This is for the Alert Level characteristic in the Immediate Alert service part of the Find Me profile. The Alert Level should only have WRITE_NO_RESPONSE so can be written remotely, however the alert should also be able to be cancelled locally on the device, hence the need to update the characteristic value locally in addition to remotely.
Looking at ulab, the C parts of the code live in a separate repository - why isn't asyncio following that model?
because it's not a separate project
They aren't? I'm mostly looking at modasyncio.c, not the way async & await work.
I guess they're both maintained as part of circuitpython.
ulab existed before it was included in micropython
oh, that makes sense.
and I think it might be used by other embedded environments too, not sure
in any case, it's maintanined by a different group of people
That makes sense that it's by different people.
Just trying to catch up on the asyncio package for historical context as I'm working on it. Thank you! :)
Was asking since the fact that it's split between part submodule & part C built into circuitpython directly makes for some odd development woes.
I suppose it was done that way becuase it's easier to try things out in python, and maybe rewrite it in c later on when you know exactly what you want
adafruit_busdevice is an example of that
CircuitPython version
main
Code/REPL
mp_raise_NotImplementedError(MP_ERROR_TEXT("Only 8 or 16 bit mono with " MP_STRINGIFY(OVERSAMPLING) "x oversampling is supported."));
Behavior
This places only the following string in circuitpython.pot:
#: ports/atmel-samd/common-hal/audiobusio/PDMIn.c
#: ports/raspberrypi/common-hal/audiobusio/PDMIn.c
msgid "Only 8 or 16 bit mono with "
msgstr ""
Description
Please change the message ...
ooh, whoever added readthedocs to the CI of adafruit/circuitpython, ๐ป
I think someone commented recently that it might have to do with a race condition about signature generation (?) in the slc setup, though I cannot find that comment right now
@onyx hinge gonna work on that? i would like to take a look and learn about how the strings are handled (:
but of course, doubling work aint cool
@spare jacinth I was going to leave changing that string as low hanging fruit for someone else to work on.
@markmcgookin Thank you for the kind offer of help. Over the past few weeks _bleio has slipped into the background due to some more pressing issues. Now, the decks are cleared and I'm back on it. I'm hoping to have some CP version 9.0.0 based test builds later next month or early January and will need help testing them. Until then, I'd like to hear how community members plan to use _bleio and if possible give me code samples to work with. It's fine to use this issue to communicate with me.
...
can't 100% understand what the chained commands to generate the file are doing, so im not gonna try and fix the parse/codegen
throwing a %d should work and is quite easy
would we like (no promises on this) some script to check cases like this one? ie: detect if there's a string-closing " before closing the text "constructor" with )
we use a program called "xgettext" for the purposes of extracting the messages from the source files and creating the circutpython.pot file. I don't think we want to start developing xgettext.
I'm converting this to draft because I think the best alternatives are still being discussed.
actually, the value should be constant, right? ie: can hardcode it on the string instead of adding overhead parsing a format specifier
I looked real quick and didn't spot an option for xgettext to treat this as an error or warning, which is unfortunate. I only noticed this because I was going through the whole list of translated strings
Yeah hard-coding it in the string was one of the options I suggested. What I wrote was a little bit unclear, no doubt
i didn't open the thing on github and missed a good part of the text ๐
mp_raise_NotImplementedError(MP_ERROR_TEXT("Only 8 or 16 bit mono with 64x oversampling is supported."));
MP_STATIC_ASSERT(OVERSAMPLING == 64);
could be an mp_raise wit varg instead
mp_raise_NotImplementedError_varg(MP_ERROR_TEXT("Only 8 or 16 bit mono with %dx oversampling is supported."), OVERSAMPLING);
agree though the hard-coded version might be a few bytes smaller overall
@tulip sleet if you responded to this message I sent late last night I missed it
I agree it could be better. Scott did MIDI and I think he chose those.
i am not too worried about saving 4 bytes or whatever here
i like %d much better too, but idk how worried we are about code size or the small overhead of parsing it (specially, given the value is probably never going to change), thus why i asked
you can remove the "is " to save 3 bytes. It's not worth worrying about. ๐
or replace " with" with " ,", etc. I'm not actually suggesting these, just that there are many ways to squeeze a few bytes
Nice simple additions.
@onyx hinge is the locale PR ready, would you say?
i am shooting for an alpha.5 later today. Still would like to fix the qtpy esp32s3 build. That's confusing.
I am going to redo it; my testing may have been off.
@tulip sleet I think it's ready
thank you!
@crimson ferry I was testing with a QT Py ESP32-S3 8/0, not a 4/2. No wonder it didnt' work. I'll drop two .uf2's here for you to test.
I don't have a 4/2, will order one, but would like to get this fixed before the alpha release.
@onyx hinge do you have a QT Py ESP32-S3 4/2 ?
@tulip sleet https://www.adafruit.com/product/5700 ? no, store doesn't seem to think I have any past orders of it
np, I'll see if anyone else has one, or maybe anecdata will come on. They're not online now.
I'll put it in my cart in case I make an order soon.
I saw some of the discussion go by but didn't have anything to add.
I think this is definitive from the datasheet:
the qt py is using the S3FH4R2 variant
so I will just fix that and PR
I don't have this board to test but this change matches the datasheet. The flash size was wrong in any case.
dio vs qio may work either way, with dio just being slower. There are many S3 boards with dio, so we should audit those.
reading xgettext documentation (a bit confusing) and doing some tests to see if i can somehow blacklist MP_STRINGIFY, will open a PR soon either way
Yes, it was way too big otherwise.
@tulip sleet I'll test QT S3 4/2 as soon as the artifacts are built
Also there is the ulab-growing issue
changes make sense, but please hold merging until someone's been able to test.
afk for breakfast & walk!
CIRCUITPY_ESP_FLASH_MODE used to only be used in a Makefile target for flashing the board. Now it is used to select the proper sdkconfig* file. Many ESP32-S3 boards, and maybe other ESP32-xx boards have it set to dio, when it may be able to be set to qio.
My understanding is that dio will work, just slower. (Am I misunderstanding?). However, if we fix the ones that are now dio to qio, we should see improved performance, I believe.
We should audit the board `mpconfigboard.m...
As commented on discord, replaces stringified value which was later concatenated, by a %d format specifier.
Tried to mess with xgettext a little but i couldn't find any way to "blacklist" the use of MP_STRINGIFY or something similar, guess it may be interesting to have some tool to check for weird cases like this in the future... But im not doing it (for now? ๐)
Thx jepler for the catch :)
Erased flash and installed the .bin. Oddly, CIRCUITPY mounts, but I can't get anything on serial... it connects, but no output or control-C response, then disconnects. I'll keep trying, maybe I'm doing something wrong.
Is the -Os relevant?
I wonder if the serial problem is due to https://github.com/adafruit/circuitpython/pull/8599
i will check an artifact from that elsewhere
YES
breaks serial
@crimson ferry I will build you a version with the qt py change but reverting that.
sounds good, thanks
do you have the .bin handy? if not I'll install bootloader
no change, CIRCUITPY mounts, but serial misbehaves (connects and disconnects, no output or response to keyboard)
NeoPixel slow flashes green
maybe i built it wrong, because i was testing on an ESP32-S3 rev tft board and it fixed serial. i'll check things further
now I'm really confused, because I saw that same behavior on the feather, reverted, and it fixed it, but now building on adafruit/circuitpython with the serial change above, it still works
ah wait, it does behave badly after a hard reset
every OTHER timne
yeah, there's a difference right after flashing vs. after a hard reset
Right after flashing, serial stays connected but no interactivity (CIRCUITPY doesn't mount). Subsequent hard resets will still get CIRCUITPY mounted, but serial connects then disconnects within a second.
I verified it's fixed by reverting on the feather. I don't see anything wrong with the order of my build steps.
revert revert lol
not sure, I re-erased and re-flashed qtpys3-4-2-fix-revert-serial-change.bin several times
i think these are the same
ok, will test new files
could try reinstalling the UF2 bootloader anyway
but we'd want to know the bin doesn't work
the .bin's did differ but it might just be a timestamp
nope, same behavior as before, weird
I'll try bootloader
erased, installed bootloader (curiously, serial can connect when it's in this state, but no interactivity), put in bootloader mode, copied UF2... CIRCUITPY mounts, serial can't connect until after hard reset...
$ tio /dev/cu.usbmodem14601
[tio 10:09:13] tio v1.32
[tio 10:09:13] Press ctrl-t q to quit
[tio 10:09:20] Connected
I (821) esp_image: segment 3: paddr=00150ec0 vaddr=3fc9e810 size=026f0h ( 9968) load
I (823) esp_image: segment 4: paddr=001535b8 vaddr=40374000 size=187ech (100332) load
I (846) esp_image: segment 5: paddr=0016bdac vaddr=600fe000 size=01064h ( 4196) load
I (857) boot: Loaded app from partition at offset 0x10000
I (857) boot: Disabling RNG early entropy source...
[tio 10:09:22] Disconnected
[tio 10:09:37] Connected
```then connect/disconnect on subsequent hard resets
tested with the 8/0 qtpy:
Adafruit CircuitPython 9.0.0-alpha.4-9-g8c9aeb21bc on 2023-11-15; Adafruit QT Py ESP32-S3 no psram with ESP32S3
>>>
[***pressed reset]
[tio 11:09:43] Disconnected
[tio 11:09:44] Connected
[tio 11:09:45] Disconnected
[tio 11:09:46] Connected
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
...
do you ever get an opening prompt?
double-checking that this is the same qt py you were testing, not an 8/0
yup, FH4R2 on the chip
i'm at a loss. you are testing on a Mac, I could try that
but you have a feather or other S3 you can try?
I have S3: devkits, xiao, adafruit TFT, UM FeatherS3, MetroS3
anything that's also 4/2
wait, the TFTs are modules, but 4/2
Adafruit ESP32-S3 Feather TFT (not reverse)
.bin? that lets me erase flash every time for testing (more easily)
doesn't matter, it's just one line
they are both built of course
that works
noticed that on the QT Py, the serial name doesn't change from a generic name based on the USB port to the specific name based on the MAC address
the TFT does change the name of the serial port, like all working espressif boards normally do
OK, huh, something was wonky with serial, hadn't seen it before... had tried tio in new windows even with the QT, but...
after testing the TFT, putting the QT Py back on the same USB, it worked!
sorry about all that, I'd never seen serial behavior like that before
in the past, if something gets wonky, I do it fresh in another Terminal tab and it's good
but this was deeper than Terminal... USB wasn't renaming correctly
that is really weird, I think the revert is important anyway, because I see the same thing; maybe the original badness put the port in a bad state
anyway, the board does come up, so I'll note that in the qt py PR
thank you for persevering on this testing
thank you!
I have a workaround for race condition issue.
Run slc-generate with single core -j1. After slc-generate done, the Makefile continues to run with multiple core normally.
https://github.com/adafruit/circuitpython/commit/0a6e92d001dbc416bacda09b5ff568dd1a407018
Sounds good; a simple PR would be fine. Later you can work with the slc folks (or is that you :) ) to see what is going on there.
Workaround for race condition issue.
Run slc-generate with single core -j1.
After slc-generate done, the Makefile continues to run with multiple core normally.
Pull request for issue: https://github.com/adafruit/circuitpython/issues/8603
Thanks! looks like what I was suggesting. Appreciate you jumping on it
I wonder why. thanks for the revert.
@tulip sleet reviewed the PRs you mentioned
@lone axle if you know .. do we have the ability to include "data files" in a lib installed with circup? any special steps to take, or an example I can look iat? This is a ".bin" file. I could put it inline as a b"" string if I have to, it's about 4kB
Thanks! Now I just have to wait for a bunch of builds ๐
reverted serial fix is mysterious -- in testing, is intermittent, seems like uninitialized something, or maybe unicode vs not, but we weren't printing unicode
I do not know of a way. I poked around briefly at one point to try to figure it out because there is a font.bin file used by some libraries that is included in the examples directory but not the library itself. I can't say that I dug too deep, but I didn't find any examples of our libraries including non-code files.
I'm sure it must be possible though, I imagine there must be libraries deployed to pypi that include some non-code data files. Maybe they can be listed inside of pyproject.toml for inclusion somehow.
@eightycc I'm hoping to use _bleio on the Pico W for wireless keyboard builds with KMK firmware (based on CP). They've already got an early general BLE implementation for keyboards, including split-style keyboards, which are the kind that I build and sell. Given the memory, pinouts, and flash available on the Pico W, it's a contender for wireless builds, even if that means a fat battery.
I'd be happy to help, too, but my time is sorely limited.
I am curious if there are aspects of ...
adafruit_framebuf is the one that caused me to look into it at the time. It has a font.bin file in the examples here: https://github.com/adafruit/Adafruit_CircuitPython_framebuf/blob/main/examples/font5x8.bin which is referenced in the code as a default value in a few places in the library itself https://github.com/adafruit/Adafruit_CircuitPython_framebuf/blob/main/adafruit_framebuf.py#L493
@onyx hinge looks like we may need to do a make translate?? weblate auto PR failed: https://github.com/adafruit/circuitpython/pull/8614
it deleted a lot or all of circuitpython.pot
make check-translate does not complain on the tip of main
I THINK that diff is saying that the pre-commit change is to delete all of circuitpython.pot
yeah
and yet locally:
halbert@cod:~/repos/adafruit/circuitpython$ pre-commit run --all
Check Yaml...............................................................Passed
Fix End of Files.........................................................Passed
Trim Trailing Whitespace.................................................Passed
codespell................................................................Passed
Translations.............................................................Passed
Formatting...............................................................Passed
so weblate is confused
i don't think this needs to hold up the release
from https://docs.weblate.org/en/latest/faq.html
In case the translation file for the source language is needed, but should be ignored by Weblate, please adjust the Language filter to exclude it.
but that's the .po, hmm
OK, I sort-of see what happened. I'll file a PR to fix it.
The very name "synthetic.po" caused problems with weblate
.. because it would add every term from circuitpython.pot to it; then in turn, "make translate" would remove almost every message from circuitpython.pot, and then give a pre-commit error.
Hopefully "synthetic.pot" won't get the same treatment.
This may require manual intervention on weblate to resolve a merge conflict and undo weblate's chyange to synthetic.po/.pot.
This also aims to fix problems that could have resulted f...
CircuitPython version
Adafruit CircuitPython 9.0.0-alpha.4 on 2023-11-12; Adafruit PyGamer with samd51j19
Code/REPL
https://learn.adafruit.com/elements/3054787/download?type=zip
PyGamer_Thermal_Camera//CircuitPython 9.x
Behavior
Default CIRCUITPY_PYSTACK_SIZE 1536 won't even get to splash screen:
code.py output:
Traceback (most recent call last):
File "code.py", line 17, in
File "adafruit_pybadger/__init__.py", line 16, in
File...
This is probably fixed by #8598. I am releasing 9.0.0-alpha.5 very soon and you can re-test.
Automated website update for release 9.0.0-alpha.5 by Blinka.
New boards:
- heltec_esp32s3_wifi_lora_v3
- maple_elite_pi
- oxocard_artwork
- oxocard_connect
- oxocard_galaxy
- oxocard_science
@bullwinkle3000 Thank you for that info. Every little bit helps.
Problematic isn't the word I'd choose, I'll stick with difficult. There are a number of reasons for that. The BLE support is built on top of the Raspberry Pi SDK plus the CYW43-driver. Both are excellent projects but are a little thin on documentation for BLE. So, I've had to deep dive into the source for each. Infineon doesn't provide a public specification for the CYW43439's API, so I've had to make a lot of inferences by...
Looks like 6 more boards to add to my PR I'm working on...
I've been disabling BLE on 4MB flash S3 boards
Plus a new Blinka board from this morning...
@eightycc
I'm hoping to use bluetooth as a remote macropad and to communicate communicate p2p with other pico's(or bt devices). Simple strings would work fine :)
It seems to fit OK with -Os and camera turned off. The Adafruit Feather S3 did that.
This release fixes pystack storage issues.
The Elite-Pi picture is the bottom of the board. Maybe use the top? https://keeb.io/products/elite-pi-usb-c-pro-micro-replacement-rp2040
is 8.x re-merged into alpha.5, or is that for the next version?
why my xiao esp32c3 board doesn't get recognized by mu editor but it's ok with Thonny?
not specifically (I did it for alpha.4), but there was little or nothing since then. There will be an 8.2.8 soon to handle some flash chip substitutions.
there are two raspberrypi wifi AP PRs, one in 8 (8590) and one in 9 (8326) (stop_ap & simultaneous station/AP etc)
Is there something I need to do to fix the name and maker of the heltec board I added for https://circuitpython.org/board/unknown/?unknown_id=heltec_esp32s3_wifi_lora_v3 ? Or I just name the board markdown file the same as the board and it automagically works?
My understanding is that
diowill work, just slower. (Am I misunderstanding?). However, if we fix the ones that are nowdiotoqio, we should see improved performance, I believe.
This is my understanding too.
If this change is what I think it is, (actual flash speed while running), the speed improvement should be pretty considerable, just like with psram.
Actual seconds for big projects like mine.
Though it needs to be actually tested for every board.
I will do it for every board I have, though it takes time.
Also, won't esp32 (non -Sx) also benefit from it?
iirc my camera board has octal connections and is esp32.
It looks like makermelissa has taken care of it with https://github.com/adafruit/circuitpython-org/pull/1281 but if you want to help for the next one you can check out https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website
Want to add your CircuitPython or Blinka board to CircuitPython.org? Here's how.
I see there's a new submodules option for boards. Is there a new way of running it or the fetch-port-submodules, it seems to be failing.
fetch-all is giving me the same error as well
why my xiao esp32c3 board doesn't get recognized by mu editor but it's ok with Thonny?
The ESP32-C3 chip does not have full native USB. It cannot present as the CIRCUITPY USB drive. Mu only works when a USB drive is available. Thonny reads and writes files by sending invisible (to you) commands to the REPL over USB serial.
Though it needs to be actually tested for every board.
For various classes of boards, we shouldn't need to re-test. For instance, the Espressif chips with integral flash, and modules with in-module flash, will all have the same settings (for each chip or module). It's only when there are external, not pre-packaged flash chips that we have to check the board for how many data lines are connected.
Okay, updated the git repository so I went from 2.34.1 to 2.42.0 and the submodules seems to be working now ๐
In case anyone else on Ubuntu runs into this:
sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install git
I didn't catch this: I thought the breakpoint was at 2.36.0 for partial clones, not 2.27.
@onyx hinge set the version brekapoint for using partial clones at git 2.27.0. But I think it is at 2.36.0 (hence your experience). ^^ We can change this.
partial clones are a lot better than shallow clones, so I'd recommend sticking withe the ppa version
I changed this around, and tried to make it detect whether "--filter:blob=none" was supported. perhaps my test was wrong. what version of git are you usuing?
2.34.1 was the version that I was using that failed
I read the release notes and have a memory that it was added at 2.36.0
I researched this months ago.
https://github.com/adafruit/circuitpython/pull/8073 aha yes, 2.36
mea culpa
np - I should have caught it in the review
I know I looked at various versions at https://git-scm.com/docs/git-fetch/2.27.0 and thought I saw --filter support in 2.27 but clearly I was incorrect.
i rather laboriously went through the release notes
oohh I made the mistake of looking at "git clone" manpage, not "git fetch". https://git-scm.com/docs/git-clone/2.27.0 lists
--filter=<filter-spec>
yes, it was added for submodules only later
sorry for the trouble retiredwizard, thanks for bringing the correct information dan
and goodnight ๐
๐ no trouble, thanks for all you guys do....
๐
I discuss this in the second part of https://learn.adafruit.com/building-circuitpython/build-circuitpython#fetch-submodules-3141425
i am looking forward to Ubuntu 24.04, when they will finally advance git again
(debian stable supports it; and on debian oldstable, bullseye-backports has a new enough git)
but yeah I guess ubuntu lts didn't get it
Ahh, not reading docs is one of my weaknesses ๐
well, there's a lot there, and it changes out from under you every time I find a new thing to mention
OK, let's try this out!
@jepler Note OSError: Syntax error in po file (line 1) :/
This caused the build failure during pre-commit / make check-translate.
It's not clear to me why this didn't come up during #8617's CI though!
--filter was partly added in git 2.27.0, but was not available for submodules until 2.36.0.
@onyx hinge I just made a PR for the git version
W25Q16JVxQ might be substituted on a variety of boards for GD25Q16C. Fixes an issue with new-production Metro M4 AirlLift Lite boards.
@ladyada
thanks for fixing my mistake.
the ci error is just a blip.
I double checked that all Adafruit boards that were previously listed with GD25 now list W25.
@tulip sleet should I click merge on 8621?
sure, I will make an 8.2.8
@tulip sleet I started looking at merging 8.2.x to main but there are a fair number of conflicts. The shared_bindings_matrix one should be resolved by taking the main branch version. but I don't know about how to resolve the rest, particularly the unexpectedmaker board config differences.
just take the main version for the UM boards
@tulip sleet OK, can do
there may be some inconsistencies, but UM is aware of that
@onyx hinge weird profusion of commits in latest translations pr. Looks like they updated something about line breaks
oh no
it doesn't look bad, just different
fwiw I've put weblate into "locked" status so people aren't touching messages at this time
"X-Generator: Weblate 4.18-dev\n"
"X-Generator: Weblate 5.2\n"```oh they did have a big jump in version didn't they.
some files are jumping from 5.1 to 5.2. I think 5.2 changed something about line lengths and/or how to break long messages across msgstr lines
Weblate 5.2
Released on November 16th 2023
The concatenated text of the messages seems to be the same.
nothing noted in the release notes https://docs.weblate.org/en/latest/changes.html fwiw
Released on November 16th 2023. New features Azure DevOps pull requests. Improvements Faster statistics updates., Better e-mail selection in user profile., Automatic fixups are now applied to sugge...
I never even noticed they had multi-line msgstrs that appear to be concatenated
it must be a standard feature of gettext. I see some of the commands have options about how to wrap ``` -w, --width=NUMBER set output page width
--no-wrap do not break long message lines, longer than
the output page width, into several lines
I used the weblate web interface to "Reset all changes in the Weblate repository" (getting rid of the erroneous change to synthetic.pot) and then "Force writing all translations to the Weblate repository" which is what caused the last-translator, x-generator, and wrapping changes to occur. (I don't know why last-translator would have changed, but :shrug:).
I visually verified that all the changed strings appeared to just be wrapping changes, not meaningful changes.
Hopefully CI comes ou...
Thanks~ These are the changes I was expecting.
const mcu_pin_obj_t pin_GPIO32 = PIN(32, ADC_UNIT_1, ADC_CHANNEL_1, TOUCH_PAD_NUM9);
const mcu_pin_obj_t pin_GPIO32 = PIN(32, ADC_UNIT_1, ADC_CHANNEL_4, TOUCH_PAD_NUM9);```oh was that the solution to the ADC problem you were chasing? surprisingly simple
I think so. In the issue people said other pins did not work, but I could not reproduce that.
it was a mis-transcription from the datasheet.
ESP32-S2 and S3 have much less random numbering of the ADC channels
I also double-checked the touch numbering
Automated website update for release 8.2.8 by Blinka.
Closing this, as there isn't a clear solution I can implement for this and there isn't any interest for this either way.
Maybe in the future I will try making board. stuff not be deinitializable, but that's a seperate thing.
working on getting a library (https://github.com/elpekenin/circuitpython_toml) in the community bundle, couple questions:
- is requirements file required for
circurpor whatever? i dont have any dependency... in case the travis file for mpy is required... can i blacklist a file (little test suite) from it? (i dont quite see how it "finds" them)nvm, just read the comment which i tought was a copyright header
oh, apparently not required, goodbye then ๐
more to come soon, probly ๐
Fix now incorporated into CircuitPython 8.2.8. I'm closing this issue. Please reopen or open a new issue if you find other ESP32 AnalogIn problems on certain pins.
Note that 2819 is a valid reading for a grounded pin. This is due to the calibration lookup table used to try to linearize the output.
@WoutStandaert So this is on Windows? Which version? What is the text editor you are using?
Could you say more about the data coming in over the UART port? Is it continuously being sent from the source? If the UART is opened, but you disconnect the data source, do you still see the problem? I am asking so we can try to set up a similar test situation.
If you could also test with 9.0.0-alpha.5, that would be great. Thanks. That updates the underlying Espressif software by a major version.
fwiw I received a feedback on Learn that some RGB Matrix project, possibly the "two line" scroller isn't working in any stable version since 8.2.2:
The example programs appear to not work with circuitpython versions after 8.2.2. The issue is discussed here: https://github.com/adafruit/circuitpython/issues/8303
I spent days trying to get the examples to work with circuitpython 8.2.7. I was only able to get them to work once ...
Does your minimal code still have the gc.collect(), is the I2SOut needed, or not? It would be interesting to remove either or both. It would also be interesting to try on 9.0.0-alpha.5 or later, which has major ESP-IDF updates.
I did not realize that there are three args in CPython.
SSLContext.load_verify_locations(cafile=None, capath=None, cadata=None)
So #8392 makes it more incompatible with CPython.
Edited the OP to add four tasks.
belated remembered to unlock circuitpython's weblate so folks can get back to translating messages.
New superboard.
Mandatory port checklist:
- [x] TinyUF2.
- [x] Pins.
- [x] Dual I2C busses.
- [ ] Ensure camera pinout works.
- [ ] Do something about GDI.
- [ ] Do power management stuff with PWR pin.
usb vid/pid:
The camera currently doesn't work as upon init the board safemodes due to memory.
It's 3 am, I am not even gonna think about it.
The pin definition is pretty massive, if someone wants to, I would appreciate a double check.
Schematic: https://dfimg.dfrobot.com/5d57611a3416442fa39bffca/wiki/a2283283b455fe95377e5d0d423539d9.pdf
Pinout: https://dfimg.dfrobot.com/nobody/wiki/0aa4e609926355484ad0cab49548d2f3.jpg
Addresses one task in #8381.
Make arguments in SSLContext.load_verify_locations() match the CPython signature.
SSLContext.load_verify_locations(cafile=None, capath=None, cadata=None)
cadata must be the third arg, or be specified by keyword. cafile and capath are not implemented.
Tagging @tyeth for interest.
Tested on CircuitPython 9.0.0-alpha.5, which was updated to ESP-IDF 5.1. There are many I2C fixes. The test program now works nicely. Closing as fixed in 9.0.0 and unfixable in 8.x.x.
Makerfabs obtained a Product ID from Espressif but they only requested a single ID rather than an ID for each of the resolutions. I've been using @jepler's original 800x480 build with just the resolution changes from this PR on the 1024x600 tablet, so I believe the two resolution tablets are functionally identical other than the screen resolution.
This PR adds the timing tables for both resolutions so the user can select the proper timing definition for their particular tablet, however if ...
Hey @tulip sleet- Has anyone started looking at C6 support yet, that you know of? I have my TinyC6 boards ready to go into my store - but I have nothing to ship on them ๐
I was going to have a look myself at getting it working, but if someone else has started, I'll wait.
we have c6 builds for 9.0.0: https://circuitpython.org/downloads?q=c6
Oh wow, was not expecting that! Ok, that makes my life MUCH easier, thanks ๐
I was expecting to have to do some heavy lifting to get this going, but I'm relieved to know I don't - it's really not my forte
well, I think your customers may be a bit on the bleeding edge, but the low-hanging bugs have been dealt with
Can you please remind me where I can add CIRCUITPY_CREATOR_ID and CIRCUITPY_CREATION_ID stuff for my board?
The github site? https://github.com/creationid/creators
Thanks!
Just finished digging through all that for a PR, not sure I got it all straight yet ๐
Yeah, I remember I added a creator_id for myself ages ago, but cant work out how to create a "creations_id" - do I just make that up ?
yes, whatever makes sense for your part numbers or whatever, completely your choice. Too much choice is not a good thing sometimes
0x00c3_something is good for c3 boards
you'll see that in a bunch
yeah, I did 0x00C60001
i can approve PR's in that repo
Ok, not added it to a fork yet - just want to get this all building first, so I can do a PR for CP first
Is there a restriction preventing me from adding a hug report to the weekly meeting notes - as long as it's under my name & follows the format?
Nope
Okay, wonderful. Thought so, but always nice to ask first. :)
@tulip sleet are there docs on how to flash the built .bin to the board? Usually the build sysatem spits out an esptool..... command, but I got a complete/successful build bt no command for flashnig.
trying a clean build again to see if I get one
esptool.py -p /dev/ttyACM0 -b 921600 --before=default_reset --after=no_reset write_flash 0x0000 but I don't know if the offset is right. I almost never use the Makefile commands
can you just make flash?
i have that command in an alias
yeah, it's the offset I am looking for - but I will also need the bootloader part right ?
are you holding down the boot button and pressing reset? Then it gets into the ROM bootloader. The second stage bootloader is bundled into firmware.bin
ok, I'll try to write this to 0x000
that's what make flash does
firmware.bin is made out of bootloader.bin, partition-table.bin, and circuitpython-firmware.bin. It's all packaged up into a .bin that is meant to load at 0x0000
I'm pretty sure
certainly true for the c3
don't have a terminal program connected to the same serial port, it will mess up esptool
you have carefully avoided these non-full-USB chips ๐
Not really - My TinyPICO and TinyPICO Nano are original ESP32 ๐
But I didn't do anything with the C3 as it really didn't interest me... but my brain is overflowing - so new data in pushes old data out ๐
Ok, so now I have to integrate this inbto my test jig - so I can flash CP on all tested TinyC6 boards!
Thanks for the help Dan and RetiredWizzard!
Added my new TinyC6 ESP32-C6 board
Big thanks to @tannewt for getting C6 support in and for those working on bug fixes!
Anyone tested espcamera after the new split-heap?
I am having a lot of trouble with hardfaults.
Wait, debug mode says.. GPIO39 is in use..
???
But in my definition it's not defined anywhere else
GPIO39 is just for Y2..
Is it some usb thing or something?
It's one of the jtag pins..
Is jtag enabled by default on this board or something?
that sounds wrong, can you report a bug?
I am already doing
Ran into this today, as I needed GPIO39 (MTCK) for the camera.
For reference, see the firebeetle 2 esp32-s3 board definition (currently in PR).
Also, in normal mode (not debug mode), using io39 was a hardfault.
Non-reset pins may be kinda broken
nah nvm espcamera still does it
Wait, nevermind, I made a mistake in the debug mode things and jtag pins were not reset.
Jtag pins are apparently treated seperately
And I accidentally built a normal build in the midst of testing
and I thought it fixed it
I am kinda stuck between jtag not letting me use the camera pins and normal builds just being wonky with ram.
Yea, I finally found the hardfault reason. espcamera evaluates None pins are >0
No quibbles here. We try to be consistent across our own boards, but use whatever standard you want. If you have silkscreen with a certain name, that makes sense.
Yea, NO_PIN apparently does not evaluate as 0 or -1 anymore. So cameras without xclk, pwrd and reset pins, just do not work.
Thankfully it can all be fixed in common-hal.
Also, I think I gave the board the best uf2 name. "FIRE2BOOT"
@tulip sleet Do you know waht language is the biggest build for the feather_m0_rfm69 -- I have cread a PR for the rfm69 library and I want to make sure i will still build. I added about 50 bytes of code
looking at https://github.com/adafruit/circuitpython/actions/runs/6893476418/job/18754294658, looks like ja. 9.0.0 is smaller than 8.2.x
Thanks -- I'll give ja a try
Well -- it fits for ja in 9.0.0 -- just barely ```jerryneedell@Mac-mini atmel-samd % gmake -j4 TRANSLATION=ja BOARD=feather_m0_rfm69 clean
- Verbosity options: any combination of "steps commands rules", as
make V=...or env var BUILD_VERBOSE
rm -rf build-feather_m0_rfm69
jerryneedell@Mac-mini atmel-samd % gmake -j4 TRANSLATION=ja BOARD=feather_m0_rfm69 - Verbosity options: any combination of "steps commands rules", as
make V=...or env var BUILD_VERBOSE
FREEZE ../../frozen/Adafruit_CircuitPython_RFM69
MKMANIFEST ../../frozen/Adafruit_CircuitPython_RFM69
GEN build-feather_m0_rfm69/genhdr/mpversion.h
Root pointer registrations updated
Module registrations updated
GEN build-feather_m0_rfm69/genhdr/root_pointers.h
GEN build-feather_m0_rfm69/genhdr/moduledefs.h
QSTR updated
GEN build-feather_m0_rfm69/genhdr/qstrdefs.generated.h
MPY adafruit_rfm69.py
GEN build-feather_m0_rfm69/frozen_content.c
Memory region Used Size Region Size %age Used
FLASH_BOOTLOADER: 0 GB 8 KB 0.00%
FLASH_FIRMWARE: 188072 B 188160 B 99.95%
FLASH_FILESYSTEM: 0 GB 64 KB 0.00%
FLASH_CONFIG: 0 GB 0 GB
FLASH_NVM: 0 GB 256 B 0.00%
RAM: 4948 B 32 KB 15.10%
188072 bytes used, 88 bytes free in flash firmware space out of 188160 bytes (183.75kB).
4936 bytes used, 27832 bytes free in ram for stack and heap out of 32768 bytes (32.0kB).
EN has 1412 bytest to spare
I wonder if we have a native speaker in the community who could go over the translations and shorten them where possible? I did that for Polish once.
at some point I think we will give up on those boards, hence the RP2040 RFM boards. I would not necessarily want to see library development held back by the space issues.
Agreed!
they were designed before CPy existed
I am even using bossac to load them ๐
The last two contributions to the "ja" translation not from someone I know doesn't speak japanese were 2022 and 2020. The translation completeness is 37%. Another possibility is to decide to not publish the japanese translation at all.
If it has no active contributors, its usefulness goes down over time as we add messages & revise existing messages.
the de_DE translation is close behind ja in size
possibly because it's more complete
making "supports localization at build time" a feature like any other CIRCUITPY_ feature would let us turn translations off for all those super-full samd21 boards.
and of course as dan alludes to, someday we will have to declare old & small boards as orphans, with a last supported CircuitPython version of ... ???
I'm happy to have stirred up this discussion.... good luck! I have to go offline for a few hours but I'll be following it.
nice to see you drop in @solar whale ! take care
or just use LLMs to suggest shorter messages without knowing the language yourself. e.g., for "Code wurde durch automatisches Neuladen gestoppt. Wird bald neu geladen." I got "Code angehalten. Wird bald neu geladen." ("Code stopped~~ by auto-reload~~. Reloading soon")
in my experience, changing text in languages you don't understand leads to hilarity
like that time where Nintendo translated "miss" in rpg combat to "madchen" in German
Does anyone remember if E (37870) i2c: i2c_driver_delete(451): i2c driver install error is an ignorable thing?
It's been there for a long while, I recall that much
oke then, thanks
I am so deep in debugging, sanity is plummeting
I (229510) cam_haler: hal i2c: 0
I (229510) s3 ll_cam: DMA Channel=4
I (229510) cam_hal: cam init ok
I (229520) camera: Using existing I2C port
I (229520) camera: Sending i2c: 0
I (229530) camera: Searching for camera address
I (229540) sccb: Starting probe.
I (229540) sccb: Current i2c: 0
I (229540) sccb: Current ownership: 0
E (229550) camera: Camera probe failed with error 0x105(ESP_ERR_NOT_FOUND)
(the i2c messages are mine)
I can't get the camera to work no matter what.
I can see the i2c addr in the scan, but espcamera doesn't see it..
Some boards may need to disable localization as the least bad trade-off against disabling other features. However, it should only be done rarely.
This is done for the Feather M0 RFM69 as a proof-of-concept. It appears to correctly build only English during CI and only list the en_US translation in the release json file.
Tested locally with
PYTHONPATH=../docs:adabot/ BOARDS=feather_m0_rfm69 python build_release_files.py
DEBUG=yes RELEASE_TAG=testing PYTHONPATH=../docs:adabot/...
That may be a bad idea worth rejecting and I'm OK with that.
Personally I'm more into disabling locales than chopping features constantly.
Those boards are the kind you use just to do your job, not to learn and play around.
cameras are maddening. I have not followed all the debugging you've been doing, but: consider manually supplying clock from PWM and doing an I2C scan as a very basic sanity check. cameras won't respond on I2C bus unless they have their input clock. Add a sleep between turning on power & clock and trying to i2c scan. Also, the clock duty cycle has to be close to 50% with low jitter, which means only a few PWM frequencies are actually OK. (main system clock divided by 2 or 4 are good choices) Some camera modules may be pickier than others.
oh this board doesn't have power control to the camera
and of course checking that the camera works in not-circuitpython
This board basically has no camera control pins.
waiwaiwaiawait XMCLK??
I missed that. I deserve that for doing the pindef 3am.
I am also guilty of not wanting to touch arduino.
I have been spoiled by CP way too much.
Oh.
The board has a power management thing AXP313A, that needs to enable camera power..
The despair is starting to set in.
Ah it has MP driver
if camera == 0:
self.set_camera_power(1.2,2.8)
else:
self.set_camera_power(1.8,3.3)
๐
We set voltages by hand..
Oh? We can also time shutdowns with this
budget acpi
Oh wow someone did already
and didn't do a board port
Oh but it so means I have to make a C module and add it to the core..
Board porting, hardcore edition.
If I make a mistake, the camera is gone.
Checked with multimeter, the voltages change accordingly
Question though. What's the best way to ship the module?
It needs to be on the board kinda..
Without it, the camera will never power on.
Made the module a lot more general purpose, but preserved the camera-specific voltages as I really don't want to let the users set voltages by hand
Got the camera working, HOWEVER we need to add a new frozen mpy for the AXP313A pmic, since the camera starts up with 0V supplied to it.
The rest of the port definition is done.
@tulip sleet in the porting of MP 1.2x for the 9.0.0 series, I understand things that are not deemed "needed" in CP get cut out, but I was curious about removing bits that mpremote requires for use, like ilistdir ?
Is that just to reduce build size? Is it gone gone, or is it just not enabled?
I understand that the "official" workflow for non native USB ESP32 boards is the web workflow, but I think mpremote is an awesome workflow for working on boards without mass storage, and though it does work for most things, it's broken for others, like calling mpremote ls as ilistdir doesn't exist in CP.
Is there an official ruling on this? or is it just omitted because no one thought to include it?
I've not done extensive testing on what does and does't work with mpremote, but basic functionality like connect and cp work, but others like ls and soft-reset don't work.
We don't use it so we don't know if it is broken.
It'd be ok to include APIs for it as long as they match CPython APIs for CPython modules. (I don't know what ilistdir is)
we have our own version of the os module, so we'd have to move over the extra stuff they added
it's not that we deleted it, it's that we migrated os to shared-bindings, and we no longer merge from extmod/modos.c or wherever it is now
mostly we recommend Thonny for non-USB-drive boards, but there are things that are awkward to do with Thonny. I looked briefly at mpremote at one time but it was full of uos stuff. That's been fixed for v1.21, for sure, and I haven't looked again.
there is no such thing as os.ilistdir in python: https://docs.python.org/3/library/os.html
I never said ilistdir was part of os - just saying it's not in CP, when it is in MP ๐
I've not looked into the MP side yet to see what's what as there was no point until I understood if getting it working in CP was an option.
we used to have ampy, which is vagulely like mpremote. Having a tool like that would be useful. Whether mpremote makes sense for CPy I don't know.
@slender iron I was helping this user https://forums.adafruit.com/viewtopic.php?t=206024 and came to the conclusion that connectin to a BLE peripheral doesn't work at all on ESP32-S3. scanning and advertising work. I went back to 7.3.3 and tried several 8.x versions, and it's not working. It appears service discovery is failing in some way. Did you ever actually get it to connect and use a service? If not, I will revise the info about what ESP32-S3 BLE can do in the guides.
it does connect, but looking up a service doesn't work
it crashes hard sometimes
Fair enough. Thonny would be my last choice in the ide/tool I'd use to dev with for non native USB boards, so I'm looking for a solution for CP dev in VSC, and mpremote works great for this in MP.
I don't remember. Its been too long
right now I'm also using it on my testjigs for flashing and testing non native USB boards, so it's integral to my workflow for production and development.
My guess is maybe no, i never tried myself until now. You just ended up hitting the dynamic service problem really early
maybe it would be possible to code around the lack of ilistdir and maybe some other things
make a cpremote
This is what I was looking at briefly. I actually didn't find the CLI UI for mpremote all that intuitive, but I didn't look at it for very long
Honestly, I'm not a fan of a cpremote - that's kinda how things stated when CP split from MP ๐คช I personally don't want to use 1 tool for CP and 1 for MP.... especially if one tool can be made to work in both ๐
mpremote allows you to mount a local FS folder as your devices flash and code away without ever copying over or editing files on device. It's def not a beginners workflow, but it's really great.
Get mp to move ilistdir somewhere out of a CPython module and then we can add it
Ok, I'll leave this one alone for now. I was really just curious as to why bits were missing, but I remember now Scott mentioned the move to make things more CPyython like, so it makes sense.
MP does want to do it over time. They just haven't yet
yup, I'll have a chat with Matt and Jim about stuff and see what can be done
Thanks for the info Dan and Scott!
Got the camera working, HOWEVER we need to add a new frozen mpy for the AXP313A pmic, since the camera starts up with 0V supplied to it.
Why do you need to freeze it? Generally you should only do that when you need to save RAM space.
I'd rather not do this because it demotes some languages. Existing boards should be able to stay small when no new features are added.
Why do you need to freeze it? Generally you should only do that when you need to save RAM space.
Because I do not know how to include a python module, for one specific board, inside the core, in another way.
You will need to advance the submodule commit for the asyncio library.
If it's just a library, why put it in the core? If it's a separate library, it can be updated without having to rebuild CircuitPython. It's ok to have a library for one specific board.
It's a library yea, but the board needs it to use it's camera. It cannot use it without it.
So out of the box, the camera would be unusable.
So out of the box, the camera would be unusable.
That kind of thing is true of boards we have with onboard accelerometers or other onboard things, too. You just have to load the library. It is a trade-off of convenience vs flexibility.
We do have a few manufacturers who have elected to freeze a lot of stuff, mostly on educational boards.
This board has an n16r8 module (it's the only spec, it has a -U variant though), on a regular build it has over 500kb free flash on the app partition and around 250kb on a debug build (with nothing removed).
The gains far surpass the costs of including it, especially considering it's just 1.6kb.
I want to make this port perfect.
Unless something better is proposed, or the inclusion is NACK'ed, I will continue trying to make it a frozen mpy.
I am willing to transfer the repo once it's done.
Dear @tulip sleet,
I found CP code to implement BTHome (v2 unencrypted) and communicate in Bluetooth with Home Assistant.
The example is on a XIAO, but should be easy to adapt for Adafruit nRF boards with build in sensor such as CLUE or Feather Bluefruit Sense.
However the author, Koen Vervloesem, explain the following way that he is using _bleio:
Note that this code uses CircuitPython's low-level BLE module _bleio, which is meant for internal use according to its documentation. The code has been tested with CircuitPython 8.0.2, but _bleio's API can change at any time. I decided to use _bleio instead of adafruit_ble because the latter's documentation was unclear.
I was wondering if you could have a look if it can be implemented with adafruit_ble or if the API is missing something that force the use of _bleio?
And maybe it is important to receive this message about the documentation of adafruit_ble, Koen is also the author of books on BLE, so I find it strange he could not find his way with the documentation...
The code was written for 8.0.2 but I tested both on 8.2.8 and 9.0.0-alpha.5 and it seems to work fine (I still need to setup a Home Assistant, but with a BLE scanner I get the advertisement).
Regards
Better with a link: https://github.com/koenvervloesem/BTHome-Inertial-Sensor-in-CircuitPython
Lately, I have been experimenting with utilizing synthio.Note as a sampling engine. This is done by loading audio data into the note.waveform property and manipulating the note.bend in such a way that the frequency of the note object reflects the actual frequency of the audio sample data (view code).
Currently, a limitation is that waveform da...
so my hopes of using mpremote (or anything really) to talk to my TinyC6 running CP on my test jig - or for any dev work has been dashed - constant serial failures when using mpremote cp xxxx
It fails 90% of the time, sometimes at 30%, somtimes up to 60% transfer... and if it does success, if I attempt to do a second cp is fails that 100% of the time.
so right now I have no way to put code on the DUT when it's running CP ๐ฆ
even just from the command line, mpremote fails cp 90% or more of the time.
and if it fails, the board has to be reset for anything to work on it again
example:
cp /home/pi/testjig/shipping_files/tinyc6/tinyc6.py :
could not complete raw paste: b'\x01'
pi@raspberrypi2:~/testjig $ mpremote cp /home/pi/testjig/shipping_files/tinyc6/tinyc6.py :```
The second cp has hung now and will never return until I reset the board.
even on my Mac it constantly fails and hangs
I don't know how desperate you are, but before web workflow came out I wrote something to transfer files to the C2 boards. The "careful" versions of the copy commands worked reliably on that chip https://github.com/RetiredWizard/Serial-File-Manager
Oh, wicked, wil give this a go now
The note about binary files is not longer true since the BCOPY and CFOLDER commands were added
The interface is also pretty wonky, I kinda stopped working on it (web workflow) but you might be able to grab the core code and set something up that works for you
This doesn't seem to be working - I can list remote files with RDIR
but cant RDEL or COPY or set LFILE or RFILE etc
Oh, I worked it out
so I'll try to convert this to not be a command line tool p needs to all be automated, but it does seem to copy 2/2 times so far
that didn't make sense - to not be a prompt driven tool
Cool, ๐ I do think the binary copies were working reliably, a bit slow but....
all of my files ate python scripts so all text based