#circuitpython-dev
1 messages · Page 396 of 1
@tulip sleet maybe https://github.com/adafruit/circuitpython/pull/5570 ?
but it's not a released board so maybe it's unimportant
no
then I think this is easy. I will wait for #5570. Taking a walk now anyway, so it's not imminent.
I'm not sure it's a good idea anyway, and it errors in the build (for uninteresting reasons) and whatever we do should be applied to wavefile as well
enjoy your walk
I don’t think I have anything either
Looks fine, though I don't have HW to test and I didn't check the schematic about pin assignment.
(its gonna change a bit for rev b anyways, but this makes it easier for me to test stuff)
WooHoo! they are in stock and going fast! https://www.adafruit.com/product/5000
@proven garnet I don't l know if I made it clear - the /docs/requirements.txt file should look exactly like this: https://github.com/adafruit/Adafruit_CircuitPython_IS31FL3731/blob/main/docs/requirements.txt
wait...
Yes.
Woah, thought for a second I was looking at a different update we did recently. Too many updates 😄
Spent a few hours figuring out power usage testing methods with a PPK2 and a MagTag. Generated some potentially useful data, figured I'd share it here:
https://github.com/fivesixzero/circuitpython-experiments/tree/main/magtag-esp32-s2/power-testing
Most interesting bit for me in this first test was a more-than-double increase in idle power usage (~29 mA to ~79 mA) after importing wifi but before doing a connect. After the connect idle was back to normal-ish, aside from spikes I'd expect from keep-alive activity, etc.
If anyone has any suggestions for improving my methods or code, or things that might be worth testing, let me know. I'll probably be tinkering with this a bit more this week. 🙂
wow, it's incredible how many pages of compiler errors you can generate by leaving off a semicolon
hihi, i tried this - its nifty and seems to work on the tft feather proto ive got
does it have a plugin with wireshark or something? e.g. what should i use to decode the datadumps?
Imagine what would happen if you left off a colon 😉
There's no emoji for snickering while rolling my eyes. 😄
It doesn't output pcap files or anything like that right now. It's raw 802.11 packets, easy to parse (the headers at least) in CircuitPython. I can post some code or a gist.
oh yeah please, that would be cool.
Management packets are 24 bytes header, plus 0-12 bytes of fixed length body depending on management subtype, then comes variable body "Information Elements".
OK, not pretty, but a rough parse and dump that I used for testing is here:
https://gist.github.com/anecdata/27aca4a8c8d87a4b3f43d3ee21f90818
Allow Station MAC address to be set for MAC address randomization, private wifi address, etc., just like the big kids do.
wifi.radio.mac_address = bytes((0x7E, 0xDF, 0xA1, 0xFF, 0xFF, 0xFF)) changes the MAC address of the Station and it connects to wifi, shows up on the router with the new address, and operates as expected.
T...
But I bet you could do a perfect deadpan voice over.
Wouldn't be the first time.
@proven garnet For future reference, leave the license the same as it is in the other files if the file is the same, which is to say, the docs/requirements.txt should look like this: https://github.com/adafruit/Adafruit_CircuitPython_NeoPixel/blob/main/docs/requirements.txt No worries on the ones I merged. 🙂
I took the library, put it in the Circuit Python/frozen folder, and did make, but the following error occurred.
Is there anything else I need to modify?
circuitpython/ports/raspberrypi$ make -j4 BOARD=raspberry_pi_pico
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
FREEZE ../../frozen/Adafruit_CircuitPython_BusDevice ../../frozen/RP2040-HAT-CircuitPython
fatal: no tag exactly matches '30049537445f72f555c8835b21f2bb07ba97...
In the latest main, this code:
import traceback
try:
print(5/0)
except Exception as ex:
traceback.print_exception(ex, ex, ex.__traceback__)
Results in:
code.py output:
Traceback (most recent call last):
File "code.py", line 5, in
TypeError: tb must be of type traceback
While this code:
import traceback
try:
print(5/0)
except Exception as ex:
print(ex.__traceback__)
Just hangs, forcing a reset.
Tested on Raspberry pico. Seems to come f...
importing wifi has a side effect, calling all the code inside common_hal_wifi_init which seems to create an 'ap' and an 'sta'. This probably turns on the radio or something and would explain increased power usage. ```c
self->netif = esp_netif_create_default_wifi_sta();
self->ap_netif = esp_netif_create_default_wifi_ap();
station is on/enabled (started) by default, not AP (though the netifs for both are init'ed)
you can disable wifi when not needed wifi.radio.enabled = False ...trade-off is how often you re-enable it, it takes a burst of power when re-connecting to do a new (implicit) scan, etc
ah, I see @dusk mauvedid that in Phase 7 🙂
I didn't read it all but it seemed quite thorough.
There is a wifi power mode that isn't exposed https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/network/esp_wifi.html#_CPPv415esp_wifi_set_ps14wifi_ps_type_t but when we looked at that for ESP32/Airlift, there were rumblings of compatibility issues https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/pull/101
I was happy to see that flipping to False dropped power usage back down. Thanks (and thanks to @onyx hinge ) for sharing some context on how things work behind the scenes. Makes more sense now.
Automated website update for release 7.1.0-beta.0 by Blinka.
New boards:
- seeeduino_xiao_kb
- pycubed_mram_v05
- pycubed_v05
- microdev_micro_c3
- adafruit_feather_esp32s2
- adafruit_feather_esp32s2_tft
- ai_thinker_esp32-c3s
- lolin_s2_pico
- challenger_nb_rp2040_wifi
- challenger_rp2040_lte
- melopero_shake_rp2040
- jpconstantineau_pykey60
- odt_bread_2040
- adafruit_kb2040
- solderparty_rp2040_stamp
- swan_r5
@dusk mauve Just a small note on the code.py: wifi.radio.ap_info takes a moment sometimes to become valid after a connection. The definitive way to know that your station is connected to an AP is whether you have an wifi.radio.ipv4_address (that's how the common-hal code defines "connected")
Awesome, thanks for that. Is that because the C code does some stuff in the background? I did notice a lot of power activity that was out of sync from the begin/end of the Python code segments
I'm not sure, some of it is opaque (to me, at least) since it's deeper down still. And I'm pretty sure there are chunks of Espressif code that are not open source.
The opacity there isn’t really a huge deal if the abstractions are clean enough and things work fine, I guess 🙂 It’d be interesting to dive into the build/toolchain and see if when/if binary blobs find their way in there. I guess I kind of expect that from heavily integrated platforms like this
fast tft refresh by not rotating
Yay for 7.1.0-beta.0! 🙂
I couldn’t write the whole release but I’m happy to have been able to have helped with it this week. 🙂
I need to get some more boards I’m working on added to Circuitpython. I realize I have a few coming up and they’re not yet added
tnx @ornate breach
Thanks for the opportunity to help out 🙂
@tulip sleet do you mind if I add my name on the beta notes, I'm co-author on the monitor pr? I'm usually pretty low-ego on this stuff, but I put in a lot of effort on that one... initial poc, api, testing
sure, np, I just went by the fork it came from. I'll add it to the release notes; I have to add it to the blog post and the forum post as well.
do you have an order to suggest?
microDev1 did the heavy lifting to write shared-bindings and merge it all together, they should be first
is your github id also anecdata?
yes
changed three places (two of which aren't published yet)
i often update the notes for one reason for another, absolutely np
cool, thank you, it seems petty I know, but now there's someone else to blame if someone doesn't like it 😉
i have to wait for the build to finish before publishing everything
The website update seems to have created a number of "unknown board"s
Got it, thanks!
Yeah, I’m counting 8
Very interesting
This was fixed in the data generation phase elsewhere.
uh-oh, now what, too big for one device in the German translation... shorten my exception strings?
uh-oh, now what,
feather_m0_adalogger for de_DEfailed... shorten my exception strings?
This code is not included in feather_m0_adalogger, so the problem is something else. I build 7.0.0-beta.0 last night without difficulty, so this is surprising. I will take a look and try to replicate the overflow here.
@onyx hinge anecdata submitted a PR which added some message strings. The feather_m0_adalogger de_DE build is too large, even though the strings are only used in the espressif port, and I assume would not be included in the feather_m0_adalogger build. Nevertheless, the string presence must have disturbed the Force in some way and caused the remaining strings to be compressed slightly less efficiently? Does that make sense?
@tulip sleet that's interesting, I'll try to figure out what's going on.
I rebased the PR against the tip of main locally, so I know it's not due to something before the tip (which is 7.1.0-beta.0 right now)
Fix a bug introduced by my bugfix of another bug. 😅
The object base type wasn't being set which led to the crash.
@tulip sleet the git describe --tags of the ref being built appears several times in the output (firmware.elf). Going from 7.1.0-beta.0 to 7.1.0-beta.0-5-g314deaf0e adds a minimum of 33 bytes, as the string appears 3 times. This seems to be rounded/padded to an increase of 40 bytes when I build locally.
(tested on trinket_m0 de_DE which does fit)
aha, that makes sense; thanks for thinking of that; I think we will just turn off something on that build.
One of the builds I tried locally had exactly 0 bytes free (!)
@tulip sleet we could eliminate the date from os_uname_info_version_obj. That gets back some bytes.
I tend to disfavor storing build date/time in binaries, because it makes builds not byte for byte reproducible
or we could do it just for samd21 in the name of saving space alone ```diff
--- a/ports/atmel-samd/common-hal/os/init.c
+++ b/ports/atmel-samd/common-hal/os/init.c
@@ -43,13 +43,14 @@ STATIC const qstr os_uname_info_fields[] = {
#ifdef SAMD21
STATIC const MP_DEFINE_STR_OBJ(os_uname_info_sysname_obj, "samd21");
STATIC const MP_DEFINE_STR_OBJ(os_uname_info_nodename_obj, "samd21");
+STATIC const MP_DEFINE_STR_OBJ(os_uname_info_version_obj, MICROPY_GIT_TAG);
#endif
#ifdef SAM_D5X_E5X
STATIC const MP_DEFINE_STR_OBJ(os_uname_info_sysname_obj, "samd51");
STATIC const MP_DEFINE_STR_OBJ(os_uname_info_nodename_obj, "samd51");
+STATIC const MP_DEFINE_STR_OBJ(os_uname_info_version_obj, MICROPY_GIT_TAG " on " MICROPY_BUILD_DATE);
#endif
STATIC const MP_DEFINE_STR_OBJ(os_uname_info_release_obj, MICROPY_VERSION_STRING);
-STATIC const MP_DEFINE_STR_OBJ(os_uname_info_version_obj, MICROPY_GIT_TAG " on " MICROPY_BUILD_DATE);
STATIC const MP_DEFINE_STR_OBJ(os_uname_info_machine_obj, MICROPY_HW_BOARD_NAME " with " MICROPY_HW_MCU_NAME);
I can just turn off CIRCUITPY_ONEWIREIO, that will be more than enough
I have already done that on other boards
I think your idea is interesting anyway: I think there are arguments both directions re the date. The commit "dirty" is not very interesting, and harder to distinguish
Happy Friday! Trying to apply the RTD and Pylint patch to libraries and ran into an issue with building the docs, seemingly not recognizing the usb_hid library? https://github.com/tekktrik/Adafruit_CircuitPython_Ducky/runs/4190196508?check_suite_focus=true
Relatedly, the library referenced was typing things as usb_hid.device instead of I think the correct usb_hid.Device but I'm not as familiar. I'm preparing the PR to fix it if someone can confirm that.
Library link: https://github.com/adafruit/Adafruit_CircuitPython_HID
yep, that looks right; Device is a class name and is capitalized
will approve as soon as it passes
Still not sure why the other repo fails on building the docs, huh
NameError: name 'usb_hid' is not defined
you may need to mock it; hold on
Add usb_hid to autodoc_mock_imports in docs/conf.py. Here's an example of that from the HID library: https://github.com/adafruit/Adafruit_CircuitPython_HID/blob/d79dd180cf6062e97d6a12cbc8dc7fdbedcc752b/docs/conf.py#L41-L42
Oh awesome, thank you!!
Is there a way to tell ahead of time when that might be needed? Is it specific libraries only I assume?
I think another PR I have might need this fix but just want to know how I might know that.
@proven garnet if it's something that can't be installed from pypi using requirements.txt then it'll need to be listed as an autodoc_mock_import, I think.
Got it thanks!
If it's included in Blinka, or installable by PyPI, and Blinka and the PyPI-installable libs are in requirements.txt, you do not need to automock it. Sometimes you simply don't know until Sphinx fails what to put in automock. I suggest not guessing on adding things because you may end up adding things you don't need to. So if you're certain, toss it in the automock. If you're uncertain, let Sphinx run and fail.
Awesome, thanks everyone for the explanation!
For what it's worth, it doesn't hurt anything to have things in automock, we simply try to avoid it now that Blinka exists and allows for Sphinx to actually load the modules and libraries.
This allows testing & debugging of bitmaptools routines like alphablend & dither on host computers. It shouldn't change anything about how displayio/bitmaptools work on microcontrollers.
$ ./micropython-coverage
MicroPython 7.1.0-beta.0-3-gd55388a17 on 2021-11-12; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import displayio, bitmaptools
>>> b = displayio.Bitmap(32, 32, 65536)
>>> bitmaptools.dither(b, b, displayio.Colorspace.RGB565)
Hi Everyone! Is there a way to contribute to the translation of CircuitPython. I am a native Chinese Mandarin speaker. I found the PinYin version of CircuitPython clearly needs some improvement.
Sorry, I am new to "open source" so I am not sure where to start from.
@midnight current yup! we use weblate to manage translations: https://hosted.weblate.org/projects/circuitpython/main/zh_Latn/
it will submit pull requests to the repo for you
Thanks! I will look into that.
thank you!
The default values should not be necessary if the arg is required. Is the compiler complaining/
Ah, it is looking for a git tag to mark the release. Make sure you added it as a submodule and have a release tag at the commit. The format of the version should be x.x.x to match the semantic versioning expectation.
Yes. There's a diagnostic flag that seems to be enabled on the unix build but not the others. Typical diagnostic text:
| ^~~~~~~~~~~~~~
../../shared-bindings/bitmaptools/__init__.c: In function ‘bitmaptools_dither’:
../../shared-bindings/bitmaptools/__init__.c:685:9: error: missing initializer for field ‘defval’ of ‘mp_arg_t’ {aka ‘const struct _mp_arg_t’} [-Werror=missing-field-initializers]
685 | ...
I looked at micropython, and they do indeed add a value for this field, except in a few routines in some ports (which are probably old). However, they use MP_OBJ_NULL instead of a 0. Maybe use that just for consistency.
I wonder if we should turn this on in general. It might break a bunch of things, though. Maybe that's what you already discovered :)
Just curious. Is the reason for PinYin some encoding issue? What encoding is actually used? The only thing I know is that might not be ASCII.
pinyin is ascii, that's the whole point
there wouldn't be enough memory to fit all the required Chinese characters
also, it might be hard to draw them in a 5x3 font
Teach me, please. How you get that tones in ASCII
líkê thìs — ok, this is extended ascii, but still way smaller than Chinese characters, and besides I have never seen a Chinese who actually writes down tones in pinyin — they just imply them
of course that is purely my own limited experience
I see, but didn't see ǎ as part of Extended ascii.
depends on which encoding you pick
CircuitPython automatically includes the characters that are used
looking at the translation file, it in fact includes the tones
Yes I know, I am editing that. I am curious about how it was implemented. I betted that ǎ is not in ASCII so there must be some Unicode going on. Looks like i don't have enough understanding of how they are stored in the system.
it's unicode internally, but it only picks the glyphs from the fonts that are actually used
the way the messages are stored is a bit complex, because they are compressed
I think using Huffman encoding
you can use Chinese characters in your program, by the way, they will just not display properly on the displays, because they are not included in the font — but they will print fine in the REPL
as long as you have the right fonts on your computer, of course
I think I get it better now. Luckily. I know Huffman.
That makes a ton of sense.
My experience as a native speaker is that PinYin is never used as a written language, so my speed of reading PinYin is very slow. Tones are important if they are written down, otherwise, they will be even harder to read. There is not a popular input method for typing PinYin OUT. So if we have to we usually do things like zhe4 yang4 jiu4 ke3 yi3 kan4 dong3. But what you are doing is cool.
I suppose all the pinyin I've seen was on signs and mostly for tourists
Pinyin is one of the larger translations, so if you have a choice of phrasings and one is shorter, it will save space and possibly prevent the translation from overflowing
in Shanghai all the signs have pinyin text under the Chinese text
@upbeat plover has been doing most of the Pinyin translations; you may want to communicate with them to see what kind of self-imposed guidelines they are using.
It's OK. That is what we call Latino "translation", based on PinYin, but not exactly the same. For example "Shaan Xi" in PinYin is shan3 xi1.
I see, makes sense
maybe we should rename pinyin to latino?
it does makes life a lot easier for bumpkins like me
The ones with tones are PinYin.
Currently the CircuitPython is PinYin.
The official name is zh_Latn_pinyin
That Latino I mentioned is only for names of places.
anyone have a zero 2w and want to test for me?
I do have one
zero2w
flash that to an sd card with rpi-imager
usb isn't actually working atm
close 🙂
@midnight current thanks, I learned something
so i need to use a usb-serial?
ok, i'll need to solder headers first,so it will be a bit
I learned something as well.
@slender iron
🎆 !
i used balena etcher, since I already had it installed
on a 16gb sandisk card
>>> os.listdir()
['.fseventsd', '.metadata_never_index', '.Trashes', 'code.py', 'lib']
imager will only do first and last MB for me
nice!
so sd is working
you could try plugging in usb but it'll probably hang
I have a timing-ish bug I can't figure out
and my loop doesn't have a timeout
yeah, the serial REPL is no longer responsive
thanks for making the LED come on, that was gratifying (unless they added a power LED)
the LED did not come on if I powered up with no card, so something is turning it on
I'm not sure 🙂
uart port went away, something else is wrong, I think. Maybe Linux got upset
It was me.
put down that wand
ok, I plugged the USB-serial into another USB port.
Linux USB support is not robust
this is my problem: https://github.com/tannewt/circuitpython/blob/rpi/ports/broadcom/common-hal/sdioio/SDCard.c#L179-L189
ha! are those in the RPi kernel code too, or is that in a binary blob?
I'm not sure what you mean
the delays you had to put in; was there guidance for those in some existing emmc code?
no, and they aren't working on the zero2
in linux I did see something about rate limiting writes to the peripheral
I should probably have those loops timeout anyway
i'm not sure what that code has to do with usb, or are you talking about another problem?
usb mass storage triggers a read that fails and loops infinitely
and starves the usb connection
i agree
timeouts are always wise though
is cmdinfo->data a register?
no, its a memory buffer
but you are checking READ_RDY and WRITE_RDY for each word in the buffer
cache flush??
READ_RDY should be in the uncached region
since its on the peripheral
it works sometimes
USB does do multi-block reads
i mean the buffer, maybe the buffer has not been flushed out of cache?
or does the USB peripheral access through the cache?
so its a slightly different path from startup
I don't think there is actually memory shared with usb
I think it's a fifo register
it is just weird that you need a delay before just writing or reading data to the buffer. there is no delay in the loop, which I might expect to be necessary even with the READ_RDY check.
but I know nothing
ya, I have no idea why. I just noticed it worked with prints there and not without
the status register also has a read ready equivalent that is set
ah, ok, it was empirical 🙂
ok, time to exercise
In #5575 I had to fix some diagnostics that occurred when enabling bitmaptools & displayio bitmaps in the Unix port, because this diagnostic is not enabled on our 'real' builds.
This can be done one architecture at a time, closing this Issue when all the architectures are done.
For code that comes from SDKs and submodules, it's reasonable to disable the diagnostic. See how this is done e.g., for the missing-prototypes diagnostic.
would you need to wait for this? EMMC->INTERRUPT = EMMC_INTERRUPT_CMD_DONE_Msk
have fun
Looks good; thanks for experimenting with testing with the Unix port, which will have advantages in the long run. Will wait for a clean build to merge, or you can if you see it first.
To give the idea of the scope of this, enabling the flag in atmel-samd and building metro_m4_express with make ... -k so it continues after an initial error, there are 143 -Werror=missing-field-initializers diagnostics to investigate and resolve.
The pycubed_mram failure is just a CI hiccup.
@midnight current I have no guide lines... do as you please! I'm not a native speaker and I failed Chinese class in high school. I'm sure many mistakes have been made.
I'll give you an example of inconsistencies within the translations.
"Code done running."
I used to translate like this
"Dàimǎ yùnxíng wánbì"
but
switched to something like this
"dài mǎ yǐ yùn xíng"
some translations are like the first way but newer ones are like the second way
what are your thoughts on that?
For the example given, the first is better.
I think the first thing I will do is to go over all translations and correct the obvious errors. Like what brought me here "zui4 hou4 yi2 ci4 da3 dian4 hua4".
And for the terminology, I will add English comments. That is because, in Chinese programming classes, we sometimes hesitate to translate the terms. For example, I bet nobody uses the Chinese translation of tuple. Even though there is one, but very few people use it. I will make it like yuan2 zu3 (tuple) zi4 fu2 (char). And make it consistent in all translations.
@tulip sleet I realized I could split my multi block reads into single blocks
and avoid the whole issue
I myself don't know how to use the tone numbers. If native Chinese speakers normally do that then I feel like all of them should be converted to that. The main purpose I started this translations was to allow ciruitpython for Chinese users.
I found this to convert it back to what I had so people that don't have the tones memorized like me can still read it. http://huginn.net/foolsworkshop/ptou/index.html
@midnight current are you substituting the non-ascii characters here for ascii for convenience, or do the tone numbers substitute for the diacritical marks?
or are they completely separate meaning?
e.g. yùn vs yun
For reading propose, tones on the letters are more proper than Arabic numbers. I type that down simply because I don't have a proper IME to type PinYin OUT. I think it is better to keep doing what we are doing now, unless some tech issues (for example, if you want to make it pure ASCII)
no technical reason, the diacritics take more space internally when compressed, but we are assuming that. The German and Japanese translations are currently the largest.
are you saying that "zi4 fu2" is the translation for "char" above?
That tool is convenient I will also use it.
giving both the Pinyin and its translation will enlarge the translation significantly if we do it in every messge
the best choice for the tones is what is best for the user who is reading the message; I assume the diacritics are best
Yes, agree. I think the current way of dealing with the tones is the best for readers.
Yes, zi4 fu2 is the translation of char. If that is going to take a large space. I personally prefer just keeping char and not mentioning zi4 fu2
Because you have to know what char is to write python.
But some Chinese translations are not widely used.
yes, if you think that anyone reading it is going to know what "char" means, I would say that's fine. Giving both is wordy, and we don't tend to do that in other languages. But in most, I think the translators use the native term if it is available
but that is more about education and language style than anything else (e.g. French has made a big effort to come up with native words0
our audience is both professionals and non-professionals, even young students
OK, 🤔, I will postpone this term thing and think about it more. I will need to read more documents to get a better conclusion.
i think sometimes the message mentions a specific python keyword, and sometimes it is a generic term (e.g. "bytes" vs bytes). For instance, "file" would probably be translated, unless it's typical to use the english word
example in german:
#: py/objstr.c
#, c-format
msgid "%%c requires int or char"
msgstr "%%c erwartet int oder char"
vs
#: py/obj.c
msgid "%q indices must be integers, not %s"
msgstr "%q Indizes müssen Integer sein, nicht %s"
keywords in the former, translated word in the latter
I left a few things untranslated, but I could have left more out.
So, are you saying that if it is clearly a python keyword, like tuple, we prefer not to translate it?
if you are referencing the actual keyword for some reason, then it might not be translated, but if it is a generic word that people would know, then you could translate it. For instance, in the German (I don't speak German by the way; it's just a good example.):
#: shared-module/vectorio/Polygon.c
msgid "%q must be a tuple of length 2"
msgstr "%q muss ein Tupel der Länge 2 sein"
Tupel == tuple, it's a cognate. If "tuple" in Mandarin is a well-known word (e.g. from mathematics or general computer science), and you'd expect the reader to know it or be able to look it up easily, then you could use the Mandarin term.
really, it's a highly cultural/language decision, we don't have a rule or anything, whatever you think would be the clearest
in this case it's referring to a Python term, but the average German reader knows that Tupel refers to the Python datatype
we don't wish to dictate translation style
across all languages
I get your point. I think I need to refer to some educational books and documents in Chinese to avoid personal biases. I will postpone this thing and focus on the translation errors first.
thank you for the discussion! We really appreciate your working on this!
... and they are all "uninteresting" warnings about missing initializer for field 'defval' of 'mp_arg_t' {aka 'const struct _mp_arg_t'}. It may be highly amenable to search&replace.
I just checked the Japanese version. I saw there are many kanjis (Chinese Characters). Maybe that is the reason why it is large. Maybe if it is all Hiragana/Katakana, it will save a lot space considering they are coded in Huffman. Or even “Romanization of Japanese“ might also work. Sorry, I only know maybe less than 10 Japanese words, but it looks like a similar idea to PinYin. Just my thoughts.
Old bug was in wifi init: station was started manually using ESP API rather than using common_hal_wifi_radio_start_station, leaving self->sta_mode = 0; This was OK on most typical runs, but caused problems when going into and out of station mode later. The manual start station was an artifact from when common_hal_wifi_radio_start_station did more than just manage the wifi mode.
wifi.radio.mac_address behaves like wifi.radio.hostname, but not exactly. The Espressif docs are a li...
The only storage you can format in CircuitPython is the built in flash, and we don't ship any devices which are so big that fat32 is required. So, save space by compiling it out by default. Seemed to save 508 bytes on Trinket M0, 512 bytes on Clue.
Testing performed: that storage.erase_filesystem() on a Clue created a fresh filesystem usable by Linux & CircuitPython.
Then I made it possible to test rainbowio and optimized it for size, saving about 88 bytes of flash storage without cha...
You'll want to leave FAT32 in for anything that should support SD cards as well.
It's likely that this is a relic of my early testing.
This does not disable accessing fat32 filesystems. It disables formatting them. If we have a device with built in flash (or, like the raspberry pi / broadcom port, an SD card that might need FAT32) we can enable that with a preprocessor define.
"Why does it seem like the LEDs have no gamma applied to them"
"Well you put a flag in to let the user turn gamma on and off and forgot to turn it on and its off by default"
🤦♂️
No testing performed, as I don't have a fomu.
I'm tinkering with struct and I can't for the life of me remember what the right format string is for a simple 8-bit signed int. I thought it might be b but -1 ends up being 11111111 instead of 10000001 😓
this is the field description in the datasheet. Using UnaryStruct for it works fine for a value up to 127
I'm a bit rusty on my int<->binary things so this is stretching my brain a bit
ahh, ok that makes sense
write the absolute value and then set the high bit if it's negative
huh, not a bad idea. was really just hoping I could get away with setting the field as a UnaryStruct without the need for custom-ish logic
you could make a new data descriptor for sign/magnitude
but I could just do a RWBits for 0-7 and use a setter for the sign
ya
is this kind of structure common enough to bring into register or struct? or just one the zillions of random quirks of i2c/spi/uart bitfields that's best just handled in the library driver?
I haven't seen it before but I wouldn't rule it out
CircuitPython version
main
Code/REPL
# n/a
Behavior
The functions uart_reset and i2c_reset exist but are not called. Most likely, they're intended to be called from reset_port() but are not.
Description
No response
Additional information
No response
cool, thanks for that. 🙂
@upbeat plover Maybe you can help me with the translation. Does "All state machines in use
" means "All state machines are in use"? I see a lot of similar messages. Just to make sure..
Also, is there a channel dedicated to translations? I feel like this channel is mostly for tech issues. Is it proper to ask detailed translation questions here? like the one above?
I think the -O2s were from #3190. I had to change back the SAMX51's because 512kB of flash was no longer sufficient.
Yes, the "are" is implied. It's not standard English, but dropping a form of "is" is common in English to save space. You'd see this on signs a lot: "no coffee today", "delivery available", etc. When people started sending telegrams and they paid by the word, it was easy to drop conjugations of "to be" and still be understand. Also articles like "the", "a", can be dropped.
It's fine to ask translation questions here, since the developers who wrote many of those messages are active here.
@tulip sleet Cool thanks!
I get it. I ask because the original translations constantly think those are nouns instead of sentences. I guess that is auto-translated.
yeah, they are not complete sentences, and we are all taught in school to write in complete sentences in normal written communication. No one is taught to write in this style, but everyone knows the rules implicitly. Interesting that the auto-translate tools are really looking for complete sentences. I guess there are many fewer examples of this "telegraphic writing" style.
While working on prospective I2C device driver improvements I’ve become curious about priorities. Many I2C drivers push a large amount of traffic on the I2C bus by repeatedly/continuously reading/writing registers for device state, requesting data, etc. But some seem to keep state semi-cached in class vars, only reaching out to the bus if there should be a change.
Coming from a world where “external calls” (ie REST) are usually expensive/retry-prone I’m used to carefully tracking/replicating/caching external state in my objects representing those things to avoid unnecessary traffic, retry delays, or bus contention.
So I guess my actual question is: What’s more important to optimize for in CircuitPython drivers? Memory/storage usage reduction (less class vars/constants and helper methods) or bus traffic reduction (less i2c traffic)? Or am I just overthinking/pre-optimizing this because I had my morning coffee to early?
Is the data in class variables, or instance variables? We should not be storing changeable data in class vars, in case there's more than one instance of the device.
Ahh, yep, instance vars. Sorry, nomenclature fail 🙂
Storing a few dozen or hundred bytes is not consequential. In terms of what to emphasize, the trend has been to write drivers that were quite comprehensive, but they ended up being large and not fitting well on small boards. Using the Register library is very convenient and reduces errors, but can increase the size
Constants in class vars, how many are too many, are another question
I would include only those that are really needed. Also read about using const() with underscore names: that reduces the size of the library because they are substituted at compile time.
note that using an underscore with const() makes the name go away and not take up space at run-time
In particular I’ve been looking at the APDS9960 lib. The device is super powerful but requires a lot of config to get each of its functions working well. So I’d like to expose a lot of its config registers and make it easier to work with. But the driver size on disk, in memory at import, and per-instance can grow a lot if more functionality is added.
So I started thinking about optimization. One thing I thought about was using optionally loaded classes for each function - prox, gesture, color/light - so that the user import or instantiate a stripped down version of the driver with kwargs maybe. The gesture function as it is know kinda does this, only instantiating a 129-byte array if it gets invoked, but it’s a bit wonky.
Not sure if there’s precedent/examples for this kind of “only features I need” operation, to provide a comprehensive driver while allowing users to shed dead weight they don’t need on import/instantiating?
The model of using const class vars with a helper method for read8 makes a lot of sense given the delta in memory usage compared to register. But it’s so much more error prone 😦
yes, that's why we went to register: much faster to write and fewer errors. If you feel you can improve on register's memory consumption that would be great, but I'm not sure there's much to be done. If Python had macros, that would be a different story, but it doesn't
Maybe I’ll poke into that when I’m all grown up 🙂 For the next few weeks/months I’m planning on doing higher-level driver improvements/debugging to cut my teeth and get in good CircuitPythonic habits 🙂
Thanks for the chat, @tulip sleet. 🙏
BTW, to show when a const name really disappears:
from micropython import const
CONST_1 = 1
CONST_2 = const(2)
_CONST_3 = 3
_CONST_4 = const(4)
class C:
CONST_11 = 11
CONST_12 = const(12)
_CONST_13 = 13
_CONST_14 = const(14)
def test():
print(CONST_1, CONST_2, _CONST_3, _CONST_4, self.CONST_11, self.CONST_12, self._CONST_13, self._CONST_14)
$ mpy-cross ctest.py
$ strings ctest.mpy
ctest.pyP$$d
CONST_1
CONST_2
_CONST_3T2
CONST_11
CONST_12
_CONST_132
testQc
_CONST_144
(Ignore the trailing digits: that's just noise.) You see that only the global name _CONST_4 truly disappears. Underscore doesn't help for class variables
@dusk mauve ^
Great illustration 🙂 Thanks for that. Helps so much for readability to have register addresses, magic values, etc in those kinds constants. Good to see that doing it right doesn’t grow library size massively.
https://circuitpython.readthedocs.io/en/latest/shared-bindings/busio/#busio.SPI.readinto
readinto(self, buffer: _typing.WriteableBuffer, *, start: int = 0, end: int = sys.maxsize, write_value: int = 0)
Keyword states
end: int = sys.maxsize
Docstring states
end (int) – end of buffer slice; if not specified, use len(buffer)
@solarjoe. I wrote it this way because end: int = len(buffer) cannot be used to specify the default arg, since it's not a constant. The calculation internally is basically min(end, len(buffer). How do you think this might be rephrased to be clearer?
@tulip sleet ^^ that's a great const cheat sheet example! worthy of putting in a guide somewhere if not already 🙂
Yes, I think we should put it somewhere. The micropython doc does not really explain it thoroughly. Missing from that is what gets substituted at run_time, i.e., does const() with a class variable really save a lookup?
I keep forgetting how it really works.
not a complete explanation, though
@tidal kiln better explanation here, though not with examples: https://circuitpython.readthedocs.io/en/latest/docs/design_guide.html#use-of-micropython-const
Original MicroPython doc, which is somewhat ambiguous: https://circuitpython.readthedocs.io/en/latest/docs/library/micropython.html#micropython.const
how about adding your two code block examples above to the design guide? no further discussion, or at least very limited. let the code and resulting output generally speak for itself. nice compact reference.
Good question, the keyword is None by default, right?
I found this and it seems to be a common workaround for computed keyword arguments to use None and
calculate later.
https://stackoverflow.com/a/21804648/7919597
You could use the Optional type hint like
readinto(self, buffer: _typing.WriteableBuffer, *, start: int = 0, end: typing.Optional[int]=None, write_value: int = 0)
and
end (int) – end of buffer slice; if None use len(buffer)
Good question, the keyword is None by default, right?
In this case and in similar methods, it's not None, it's actually what the signature says: sys.maxsize. We do use None sometimes, but not here. Here it's less code internally to use only an integer in the readinto() and similar cases. And here if you gave, say, 10000 as the arg, and the buffer is smaller than that, it would use len(buffer).
I can add that to the design guide, for sure. I think it would be good to have it in a Learn Guide too, though I'm not sure where.
If any circuitpythonlibrarians (or anyone interested in reviewing) has a moment sometime, would appreciate a review on this PR: https://github.com/circuitpython/CircuitPython_Library_Screenshot_Maker/pull/10 that fixes an issue that was noticed with the library screenshot maker utility.
Similar to the RGBMatrix (and also borrowing from I2CDisplay) this is a native driver for the IS31FL3741 chipset. I am releasing this is draft for others to take a look at but still requires some cleanup and I have some questions about the best way to implement some options. I have only tested this on the Adafruit Eyeglasses as they are the only IS31 board I have.
The main question I still have outstanding is how to pass in mapping from the display to actual LEDs. The glasses matrix is cur...
If I have a small fix for CircuitPython RTD documentation, should I submit a PR to main or is there a better branch? Just a tweak to a Sphinx formatting mistake.
(adafruit/circuitpython, to be clear haha)
Also, the library infrastructure issues page shows a bunch of libraries missing "readthedoc.yml" but the repos have ".readthedocs.yaml". Is that "check" looking for something different, or should it be pointing towards the latter?
Had a friend stop by the lab for the first time in awhile (they needed some soldering help with a busted DC jack on their fish tank pump relay 🐟) and gave them an in-person demo of the PyLeap beta with a Circuit Playground Bluefruit.
I wish I could share the expression of joy on their face when they tapped the "Glide on over to rainbows" button and saw the neopixels light up!
"OMG its a rainbow! SO COOL! Did I do that?! Really?! NO WAY!"
Even in beta it's already bringing some rainbow happy vibes to humans. ❤️ 🌈 
@dusk mauve just for completeness, there's another variable, though I doubt it will affect ESP32-S2 power much: start_station() vs. stop_station() (but similar start/stop for _ap would affect power)
Ooh interesting. Thanks for that tidbit. I got distracted by bugfixing/improving APDS9960 driver for a bit before I dive deeper into power usage stuff.
Very interested in something like this; Managing the several devices scattered about would be magnitudes easier once this is implemented.
main is the best branch. RTD is actually built off it for the "latest" version
Got it, thanks! I'll submit now.
value_to_latch param had a Sphinx RTD formatting mistake I noticed, just a quick PR to fix
Since I'm in the guts of the apds9960 driver already I did some testing with adding underscores to constant names and figured it was worth a PR. Added a bunch of notes with more details there.
https://github.com/adafruit/Adafruit_CircuitPython_APDS9960/pull/37
TL;DR: ~10% mpy file size reduction, ~5% memory-used-after-import reduction.
Not too shabby for a basically 'free' optimization!
One open question to anyone who has a thought: Any idea how to allow someone to take advantage of the glasses' rings. You could use the python library to otherwise address them or maybe another helper python library that is aware of the displayio display (and which pixels overlap) would be beneficial?
This was set to 32 bits (as opposed to 24) as in other place some division took place and 24 would require more changes. Handling 24 bit color in 32 bits is done in other systems but not sure if it is the best option here or not?
Looking at ideas on how to pass this data into the display driver
Would it make sense to calculate this at run time (using RAM) vs compile time? A bonus of run-time is the gamma level could be user controller.
@slender iron been experimenting with the rpi branch this weekend. I still can't get working builds out so I couldn't test this, but gcc 10 was giving warnings about some out-of-bounds access on SD spec stuff, so maybe this will help with that instability you mentioned. fyi i'm not sure if the endianness is correct for that last one either
Disappointed to learn that CircuitPython doesn't support interrupts. I'm working on curriculum to teach *Python on the Pico for a college class and interrupts are an important concept. I'll have to use MicroPython for that exercise.
Like this:
`import machine
import time
from machine import Pin
led = Pin(25,Pin.OUT) #pico on-bard LED
button = Pin(20,Pin.IN,Pin.PULL_UP) #button
def button_int_handler(pin):
led.toggle()
led.off()
#call the interrupt handle when the but...
As a guy who is interested in electronics and programming, I'd like to participate in CircuitPython translation. I strongly believe that CircuitPython will be the next milestone in the Russian maker sphere.
With the appearance of rp2040 and raspberry pi pico on the market, AliExpress in particular (this is the primary place where we source our components from) and its' low price tag, I strongly believe that CircuitPython will be the revolution in the Russian maker community. As for now, p...
Thanks! I’ll try it tomorrow. I m happy to help get it working for you when I’m around this week. What time zone are you in? Let me know what time works for you
EST so there should be a good three hours when I’m off work that won’t be a bother to you 👍
I'm working on curriculum to teach *Python on the Pico for a college class and interrupts are an important concept. I'll have to use MicroPython for that exercise.
Note that MicroPython has strong restrictions on what you can do in a hard-interrupt handler: no storage allocation, etc. We are avoiding hard-interrupt handlers in CircuitPython to make it harder to make those kinds of mistakes. Functionality that needs hard interrupts we code as native modules. keypad does not actually use...
Progress report on all this: we enabled async/await some time ago on most CircuitPython builds, and are now providing a preliminary port of MicroPython's asyncio implementation so you can do cooperative multi-tasking. This is in 7.1.0-beta.0 and later. A preliminary Learn Guide with examples will be available soon.
We chose asyncio because it's standard in CPython and MicroPython already has done a great job on the implementation. However, asyncio is not so easy to use or under...
@tulip sleet what is the policy on updating the frozen modules ? I'm waiting for the next stable CP to switch the layouts to using the base layout class added to adafruit_hid. (Hopefully it fits on all boards that have it frozen in).
We definitely update the frozen modules before a stable release, and kind of as needed during a string of alpha's or beta's.
If we update it now, will it break things other than your library? I think it might be invisible to the casual user of adafruit_hid. Would it be possible to add a little detection code to your library to either compensate or just complain if the old library is in use?
I made some tweaks in the implementation and also converted SPI and UART to allow multiple instances.
I'll try and merge my branch with yours.
updating adafruit_hid should not break anything, the new layout base can just be ignored, on the layout side updating to latest implies removing the keyboard_layout.py file, making the download simpler (and reducing the memory needed for loading where the library is frozen in), and switching the imports from keyboard_layout to adafruit_hid.keyboard_layout_base
I could try/except the import to make it backwards compatible and warn about updating or downloading the missing file
Given the wide variation in experience level of people who use your library, I think catching these errors will save you support time 🙂
I can make a trial PR that updates the frozen libs now for beta.1 and we'll see what doesn't fit anymore
it is very easy to make that PR
does adafruit_hid 5.2.0 include everything you need now?
I kind of wish it was possible to have a code_out.txt, accessing the REPL is not the easiest thing to ask some people to do to diagnose issues 😉
yes, 5.2.0 is right
an idea would be to have an error_out.txt that just captures uncaught exceptions, and gets written only if there is no serial connection
we do want to train people to use the REPL, there are arguments both ways about making it easier vs making people think a bit
but we have to remove it if it exists at the beginning, etc. It may cause more issues than it helps
See whether adafruit_hid still fits, with keyboard_layout_base.py now present.
speaking of REPL, having code.circuitpython.org also work with web serial would be nice
I have tried the sample web serial impl provided by Google and it does not work well; I'm not sure what's wrong.
I think they updated it since I tried it too, it looks to work better, though it's probably gonna stay Chrome only
@crimson ferry can you enable commit from contributor on your PR #5571.
The feather_m0_adalogger overflow issue was fixed in main, so I did a rebase and merge from main.
Lots of new documentation, but this https://googlechromelabs.github.io/serial-terminal/ still gets <CONNECTED> <DISCONNECTED> a lot for me
from August: https://web.dev/serial/
I'm not sure what that is. I have Allow edits and access to secrets by maintainers checked.
I also cannot edit; this is odd.
I can't push to my fork either so I think its a problem on my end.
my anecdata repository is set up as default, is it something there, like adding you as collaborator?
ah, ok
that should not be necessary
but I can't edit one of the changed files either
I don't think there is a missing collaborator; we do this all the time with new folks who submit PR's
okay... I can push to my fork now but still can't access yours
triple-checking, you see this on your PR in the lower right hand corner:
it was checked when I mentioned it before, but just looked again and it wasn't. It is checked again now.
now I am seeing I can edit a file; did you change something?
all's well that ends well
yes I can push now 👍
@tulip sleet are you still working on https://github.com/adafruit/circuitpython/compare/main...dhalbert:arg-validation-updates
I have started looking into standardizing some of the error strings. I am thinking of starting on top of your work.
sure, go ahead, do you want me to PR it as it stands, or will just cherry-pick it or whatever?
It did not gain that much, so I thought I should work on it some more
i checked size changes after every significant change: lots of 1 step forward, 1 step back, occasionally two steps forward
I still think it is worthwhile from a cleaner-code point of view
I'll merge your branch with mine at a later point... I am working on standardizing other types of error strings atm.
@idle owl when you have a sec I'm interested to get input from you on this: https://github.com/adafruit/Adafruit_CircuitPython_FunHouse/pull/24/commits/2980950d7683e3a5a3a2e925871df9fa245a1448#diff-63a9c44a44acf85fea213a857769990937107cf072831e1a26808cfde9d096b9L27 If I understand correctly we recently gained the ability to use this duplicate-code disable in the pylint / pre-commit config. It appears it was applied to example code in the config file. Are we also wanting it to apply to library code as well?
oops boot_out.txt is not created if it does not exist
(like after erase_filesystem)
Ok, so here's the deal with that. We do have the option to disable it. That said, what should really be happening, if at all possible, is a refactor into a base class and subclassing it from there. With regards to the latest Pylint update, the directive was to simply disable the duplicate code check for now. I specifically put it in the pre-commit config so it's in a more obvious place for us to find it later and consider refactoring the code. What I would have preferred, but this will still be easy to do, is to have an issue created on every library we disabled it on suggesting the library be refactored if possible. Tekktrik was instructed to include the duplicate-code disable in the event that they ran into it in one of the PRs where they were applying the updated Pylint. I was not clear that it shouldn't be done elsewhere, but I hope that was implied.
Basically, trying to include a full refactor in a library-wide Pylint update was not reasonable.
ah but it is after a power cycle
@lone axle So in the case of this PR, it shouldn't be needed or it should already be in the library. Because that isn't a Pylint PR.
Does adding the type hints trigger the check?
Hmm. It appears to be related to an import section.
the PR for the added type hints does run CI when it gets pushed to. Without the duplicate-code disabled it's currently failing the checks. I haven't looked into the specific lines it's tripping on yet though. I can try to see how large of an effort the refactor would be.
It's set to ignore imports, but that try/except block is, I think, causing it to not see that it's an import block.
I'm not sure this is a refactor issue.
Ah, I could see that.
I think this is triggering it. try: from typing import Optional, Dict, Union, Callable, Sequence, List from adafruit_dotstar import DotStar except ImportError: pass
In fact, I'm certain of it.
That's annoying.
It's not exactly the same, but it's claiming it is. Only needs 4 lines to be the same to trigger it, so... Here is the exact block that's getting caught ``` from adafruit_dotstar import DotStar
except ImportError:
pass
version = "0.0.0-auto.0"
repo = "https://github.com/adafruit/Adafruit_CircuitPython_FunHouse.git"```
I'm unclear on why the dotstar import is in the try.
But I'm not sure that would stop the failure.
I don't think it would. Because it would still be four lines.
We need a build in "more" function in the REPL that you would use like this: more("code_out.txt") or boot error and let you see them. Before using CP, I was using MP and I made my one copy and directory listing and cat function manadge the file system from the CLI (because the flash was not visible as a USB disk).
hmmm the dotstar is in the try because it's not used in the code, only in the type hints, and placing it after the others will make it ignored due to the exception being triggered
@proven garnet @lone axle I'm trying something now. I'll get back to you in a minute here.
In the case that the import is used only for typing in that file we've been putting the imports inside of the try/except after the typing import. That way when it runs on a microcontroller it won't actually import the thing (dotstar in this case) to save a little RAM, since it's not actually used at run time.
Yeah, sorry, I added it as part of a pylint PR to that library prior. Not sure if it was needed for that specific PR because I didn't let it fail first, I think this was when I originally misunderstood the instructions, sorry!
I'm catch up on this now
Yeah I didn't want to have it import in execution if it was only for type hints
Happy to help or edit the PR as necessary! Let me know 
@proven garnet @lone axle Ok, my idea doesn't work. I don't see a code way to get around this right now. Please include duplicate-code in the .pre-commit-config.yaml as you did previously for the Pylint PRs. Then, please file an issue on the library that includes the Pylint failure and suggest we should look into how to fix it. Here is the failure that should be included. ```************* Module adafruit_funhouse.peripherals
adafruit_funhouse/peripherals.py:1:0: R0801: Similar lines in 2 files
==adafruit_funhouse.init:[38:46]
==adafruit_funhouse.network:[37:44]
from adafruit_dotstar import DotStar
except ImportError:
pass
version = "0.0.0-auto.0"
repo = "https://github.com/adafruit/Adafruit_CircuitPython_FunHouse.git"
(duplicate-code)```
Thanks for your patience with this, @proven garnet!
I'll handle this as soon as I get back to a computer, thanks for the help! And no problem!
Thank you @idle owl .
@jaunty juniper I'd love to see USB support in code.cp.org. @midnight current did it in their online editor: https://forums.adafruit.com/viewtopic.php?f=60&t=180435&p=878535
@tulip sleet need any help with the meeting today?
I am trying to get the audio working right on recording. I may ask for a test with you and/or Kattni soon.
kk, I'm around
As am I.
@proven garnet Thanks so much! Exactly what I was looking for.
hmmm -- just got a new adafruit_feather-ESP32S2 with bme280 --- the bme280_simpletest does this... ```Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 7.1.0-beta.0-18-g18b3e6c4f on 2021-11-15; Adafruit Feather ESP32S2 with ESP32S2
import bme280_simpletest
Temperature: 20.9 C
Humidity: 71.3 %
Pressure: 607.1 hPa
Altitude = 4116.94 meters
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 19] Unsupported operation
Oi... No. I don't remember if I ordered one, I'm pretty sure I did. Supposed to be here later today. I'll test it then.
If anyone has a PyBadge, I'd love some help testing a PR to remove gamepad from this library
Espressif has new ESP32-S2 boards (ESP32-S2-DevKitC-1), same as Saola as far as I can tell except that they have both USB connectors and are narrower so fit in a breadboard with a row to spare on each side. I've been running them with Saola firmware. Question: is there any need to make new board files for these, it would just be naming, nothing functional.
the lc709203f_simpletest runs OK
there are alias boards, like the pyportal and pyportal pynt, that use the same firmware (but only built once)
Good to know. Noted.
that allows having the firmware file named and linked to from the circuitpython.org
interesting, I'll look into how that's done
I think all you need is add on there: https://github.com/adafruit/circuitpython/blob/18b3e6c4fc2909af70bd8ccef06bb93bf02dce28/docs/shared_bindings_matrix.py#L35-L44
even stranger -- sometimes it fails after more then one pass.... ```Adafruit CircuitPython 7.1.0-beta.0-18-g18b3e6c4f on 2021-11-15; Adafruit Feather ESP32S2 with ESP32S2
import bme280_simpletest
Temperature: 20.9 C
Humidity: 71.3 %
Pressure: 607.1 hPa
Altitude = 4116.94 meters
Temperature: 20.9 C
Humidity: 71.3 %
Pressure: 607.1 hPa
Altitude = 4116.94 meters
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 19] Unsupported operation
Oh that's lovely. 🙄 OK. Have you tried running it as code.py and not through the REPL? I don't know why but sometimes that matters.
@idle owl could you join me in Valentina for a sec to check recording?
so you still need all the board files in the port, but that matrix file suppresses a unique build?
same behavior via code.py and REPL
At least that's better than not, in my opinion.
agreed
@idle owl it's working: I am in Windows instead of Linux, where it seems to work a bit better
@jaunty juniper oh, I see, there are no board files, it seems to be a pure alias
I tried it on a second board and it is working ok...:-(
I can test that out tonight if no one has a chance before that. Thanks for working on this!
Oof. That's kind of a bummer. But not impossible.
yes, I'm not sure exactly when the duplicate uf2 file is uploaded to S3 though, since the link does reference pyportal_pynt
at least it points me in a direction....
For sure.
I reflashed CP to the board and now it is working....
@jaunty juniper oh, yikes, I take it back... a complication is that there seems to be a variation with more flash (though I don't see those at the distributors yet)
Something intermittently outside sounds like a far away dragon. I keep waiting for it to get louder and the sky to darken. It is not happening as one might hope.
Hmm. Glitch I guess?
bad karma...
just an FYI -- the feather esp32s2 boards (with and without bme280) appear to be shipped with an Arduino sketch. I had to do an erase_flash then flash with CP to get them to boot CP.
the UF2 bootloader is not installed.
Tested on a Trinket.
>>> import storage
>>> storage.erase_filesystem()
The board resets with a fresh CIRCUITPY, but boot_out.txt is missing.
Creating a boot_out.txt file makes it be correctly populated on reset.
Hmm.
I observed similar yesterday on PyPortal. Hard reset does it, but not microcontroller.reset().
Oh good! Maybe this will also convince me to get my hands on one haha. Thanks!
@proven garnet I sent you a direct message - I hope that's ok!
I think this could do it but that might not take into account all the possible cases.
} else {
write_boot_output = true;
}
A Russian translation would be amazing! I've added it to our Weblate, the system we use for translations. You should be able to add translations for it here: https://hosted.weblate.org/translate/circuitpython/main/ru/?q=state:<translated
We can likely automate this with the data update for circuitpython.org when we do a release. It really should be something managed with a release.
We can likely automate this with the data update for circuitpython.org when we do a release. It really should be something managed with a release.
That's not a bad idea. It would probably look better than what we could do on the website alone.
<@&356864093652516868> CP Weekly meeting in under 30 minutes. Looking forward to seeing folks there! Please remember, if you want to participate or have your updates read off during the meeting, please include your Hug Reports and Status Updates in the notes doc. Thanks! https://docs.google.com/document/d/1ROYIKjHd8lfuKZJEgcWpzsnfbV4AaZjyvmRipSjxKXs/edit#
CircuitPython Weekly for November 15, 2021 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 participa...
Skipping the meeting without notes, but I might listen to the latest news on the Pi Zero port... strongly wondering if I should invest if 2GB micro SD card for that kind of usage.
Of course! Never a problem, please feel free to (open invite) since I'm not the greatest at seeing @'s sometimes so please don't hesitate!
@solar whale I have a potential solution for you for the BME issue. There's an I2C_POWER pin (or something like that). It needs to be pulled opposite of what it is (we can't remember what it starts at, so high if it's low or vice versa). Pin 7 maybe?
Also, it should have shipped with the bootloader, but it's a pain to get into.
ooh..- I try the I2C_POWER Pin. thanks -- I tried several rates of double taps...
Does the LED turn purple during startup?
You have to click again during purple.
Or I guess it wouldn't yet until CP was flashed.
It comes with the Arduino core though, it turns out.
not that I saw -- I have another board, I'll try it.
Limor added that feature, so you can even update the bootloader by loading from Arduino. So that original sketch should have resulted in the bootloader being included.
I don't seem to be able to trigger it
Ok, I'll give it a try when I get mine and let you know.
@tulip sleet @slender iron I'm likely going to be late to the meeting. Don't wait up.
kk
I had another meeting come up today as a scheduling conflict, won't be able to attend. But I've left notes in the doc and will catch the recording later on.
I am not, in fact, late, after all.
CircuitPython Weekly for November 15, 2021 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 participa...
@crimson ferry Are you text only?
👋 Been meaning to listen in for aaaages but it's so early 😜
less early now 🙂
Yes, almost manageable 😉
@gilded cradle I should have read your notes first!! -- I'll try the new pitft installer soon.
6:30 is still too early for me
whew -- not just me!
@solar whale the camera still doesn't work. Waiting on them to make some updates.
No apparently not. The LED turns purple on both like it's supposed to, but I can't get it to work.
I'm not sure what you mean. Which LED?
Status LED. The NeoPixel or whatever it is.
Like on FunHouse or MagTag
On the braincraft?
I replied to the wrong person 😄
@solar whale That was meant for you.
Ah, ok. 🙂
A test of the bargraph and neopixel displayio widget classes along side of existing scale and magic eye objects. The 7-segment display widget is under development.
When you said you "erased the flash and loaded CircuitPython", what exactly do you mean? What process are you referring to?
orbit.love: opt-in by each user?
I am building CP locally so I did: esptool -p /dev/ttyACM0 erase_flash then make BOARD=adafruit_feather_esp32s2 flash PORT=/dev/ttyACM0
Ok thanks.
what about tagging you commits with your discord name?
Orbit.love was mentioned on Changelog 465: https://changelog.com/podcast/465
Robby Russell is back on The Changelog after more than 10 years to catch us up on all things Oh My Zsh — a delightful, open source, community-driven framework for managing your Zshell configuration. It comes bundled with plugins, themes, and can be easily customized and contributed to, because hey, that’s how open sour...
Social score...
👍
o/ thanks all
Thanks folks, always good to hear what's going on in CircuitPython land!
I'll try and drop in more regularly 👍
@solar whale Ok, so at Limor's suggestion, I tried to see if I could get a bootloader by loading an Arduino sketch, and it worked. So there may have been an issue on the tester-end of things. Because I now have a UF2 bootloader from loading an Arduino sketch.
interesting -- I will try that.
@solar whale I loaded the strandtest_wheel sketch, though I think the pin I put in for the NeoPixel is wrong because the NeoPixel did not rainbow, but I got a bootloader out of it.
From the NeoPixel library.
I even verified the pin. 😕
Also, it took three tries to get Arduino to play nice.
@blissful pollen I may ping you for a build for some random board to test the PR (unless the PR built assets already).
Sure thing, I was thinking of trying to build it for a few boards. Just hadn't got to that
recording is O K 😓 🙂
Excellent!
@idle owl I don't think I have esp32s2 BSP for Arduino yet so it will take some time to test.
You add a URL to the preferences panel in the IDE, and then install it from the Boards manager. Is that what you're referring to?
I had to update mine to have it include the Feather. It wasn't there at first.
yes
I still had it in clipboard 😄
Then search the board manager for "ESP32" and the one you want was the only one that came up for me. It did NOT list the Feather as included, but it was there once installed.
ah -- are you using Arduino 2.0 ...
No? I just updated to whatever the most recent version is
1.8.16
is what I have
I guess I knew 2.0 was available, but I haven't used it.
Put the URL in that box. Then when you search the Boards Manager, it will have the ESP boards
(sorry if you already knew this)
doh -- never-mind -- its been too long. Yes -- I do know how to do that !
No worries 🙂 It's one of those things that once you do it, you have no reason to remember. Until you need it 😄
Passing in a byte buffer is how I'd do it. I'd assume we'd provide libraries that do the init. So, most folks wouldn't need to worry about it.
If we want user control then RAM is a good choice. I'd start simpler and just hard code it like you did here. The generation code will also take space so the savings will be < 256 bytes. Simplicity is worth whatever the difference is.
I think we usually capitalize letters.
{ MP_ROM_QSTR(MP_QSTR_IS31FL3741), MP_ROM_PTR(&is31fl3741_is31fl3741_type) },
I think I added this as 32 bits for the raspberry pi too. In that case, the last byte is actually alpha. So, this works well for me :-).
How is the speed of this? Would you consider buffering the whole memory and then blasting it all out at once?
@idle owl Do you see the adafruit feather es32s2 in your arduino boards list? I cant find it.
It was here for me.
did you install the ESP32 BSP?
Yeah.
ah -- missed a step.
Now I understand what you meant 😉
I will try loading the "blink" sketch and see if that loads the uf2 bootloader...
Keen.
takes awhile to install...
I used NeoPixel, it shouldn't matter.
Yeah it took a bit for me too
I learned the hard way, it takes a while.... I quit in the middle and borked the whole setup a while back.
I thought it had hung.
I see the I2C POWER pin { MP_ROM_QSTR(MP_QSTR_I2C_POWER), MP_ROM_PTR(&pin_GPIO7) }, Should it be High when using I2C?
I'm not sure. Check what it is by default and do the opposite is what the instruction was. Because we couldn't remember. 😄
OK -- thanks 😉
@atomic summit do you know the S3 support status in CP?
hmm it seems to be working now with it in either state... I'll keep poking at it.
Ok, sorry I didn't have better info to begin with.
No problem
I've not really looked at it in a while, sorry. I was originally blocked with some missing peripheral support (ADC, I2S etc) but they have been added since in the IDF and seem to be ok in MP.
I looked at continuing CP-S3 the other day and was unable to bring in all latest changes into my branch... so much has changed since I did the initial stuff 😦
np, limor has some dev boards so it's higher on my list
@analog bridge probably knows too
tried for about 15 mins to fix conflicts and then just reverted the rebase
The work I did was pre @analog bridge moving to 4.3, and he re-implemented the "split mcu support" for C3 very differently to me, so there stacks of conflicts
maybe it's easier to start again... especially if you are moving to 4.4 anyway
kk
I'm not sure if you are aware, but Espressif decided to remove the DAC peripherals in S3.... boo hoo... so that pretty much breaks compatibility with any DAC based shields/wings etc.
huh. is that used for more than audio out?
sorry, for more? well, a DAC is useful for other things.
a bit more info -- if I set it True-- it does fail intemittently -- If I set it False it seems to run reliably --- at least so far.....
OK that would make some sense.
but mainly for non I2S audio out uses - just something to be aware of.
You can still PWM those pins to get sound out of a buzzer... but no DAC means no wav/audio file playback etc
are there featherwings using DAC pins ?
@idle owl Loading a blink sketch does indeed load the UF2 Bootloader!!! Thanks!
Great! Thanks for testing!
@jaunty juniper i think the propmakers are maybe some others
audio wings seem to have their own codec chip
anything that has a non I2S/decoder on it.
I always have better luck with i2s
Here is the notes document for 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/1RgQT9ewtW6Cv9KzgOScNCrulTTyw6J9XdErM7ZnrsLU/edit
CircuitPython Weekly for November 22, 2021 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 participa...
I know not all Feathers have DAC pins... but ESP32 always has had them... this will be a breaking change from what ESP32 users are used to.
design choices... 🤷
@atomic summit would you mind posting an s3 mp build? do you have one handy?
I can make you one in a hour or so, if you can wait. Or you can make one - basic S3 support is already in MP, and I have a PR for PSRAM + SCcard and more waiting for approval.
ya, no rush
Ok, I'll make you one for the S3-Devkit in about an our
Yeah, they don't have all boards being auto-built yet 😦
that page is progress though
it is - needs a "non-engineer" UIX makeover though 😉
Actually... maybe I can remote into my work machine and build...
@slender iron do the boards Limor's got have SPIRAM on them?
I don't think so
Want me to send here? or another way?
MicroPython ESP32-S3
Here are both with and without, but with SPIRAM should ignore missing PSRAM if not found... but not tested.
kk, thanks. you are ahead of me 🙂
@atomic summit i get a COM port but nothing happens when i connect to it?
is that normal
esptool.py --chip esp32s3 -p COM11 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 4MB 0x0 firmware.bin
Is it OK if I use the chat for communication, since I don't have a mic
Using the code at: https://learn.adafruit.com/ano-rotary-encoder/python-circuitpython on a QTPY RP2040 the code works perfectly except I'm getting a single count every two clicks of the ANO. adafruit-circuitpython-adafruit_qtpy_rp2040-en_US-7.0.0, adafruit-circuitpython-bundle-7.x-mpy-20211112. Any suggestions? Thx!
It's a hardware limitation. The very latest CircuitPython has a new feature in rotaryio that allows setting the divisor of counts per transition. That's 7.1.0 Beta 0. So if you install the unstable version of CircuitPython, and set up, for example like this: encoder = rotaryio.IncrementalEncoder(D1, D2, 2) your issue should be resolved. I haven't tried it out yet though!
This is for native USB only. You need to flash it with the native port (put it into download mode first) - then manually reset after flashing
Sorry @meager fog - I should have mentioned that bit. 😦
You should then be able to connect to it via rshell/screen/putty etc.
Thanks, katnni. I tried and died. It bricked the QTPY and I had to nuke it and reload 7.0.0. I figured it was a count divisor thing, but I guess I'll just have to wait until 7.1.0 stabilizes. I'll keep pushing forward with my project and clicking twice, NP.
What would be the recommended size for microSD card for Pi Zero 2W? I am shopping for small card, but maybe that mean slow too. Price are not really much cheaper, just that I know a 1GB or 2GB card will not be used for Pi OS and can be saved for booting into CP or data logging.
Oh, flash is at 0x100 like regular MP flashing. -z 0x1000
Just like flashing the S2
https://micropython.org/download/featherS2neo/
Oh! I'll try to put together a test then, if it's causing issues like that, we need to file an issue on GitHub for CircuitPython so we can fix it. Are you on GitHub?
I'm asking because I would like to tag you on an issue if I end up filing one.
thankfully the s3 mini seems to have the same pinout as s2
@thorny jay I'd get the largest one that is cheap
no reason to restrict yourself to 1 or 2 gb
no reason to pay extra for speed though
2GB SD cards are typically more expensive than larger ones lately.
Who'd ever need 128GB 😉 /ducks
I do for $19
hahaha
That's crazy pricing. And how do they squeeze that much space into an sdcard!
pretty amazing
You still need to have a 1gb/2gb or two lying around for hardware that can't handle larger though.
some larger cards might have >512 byte sectors, i think
Does that mean anything for the issue I'm experiencing?
speaking of SD cards scott, how did that patch look? I'm going to hook my pi up to hdmi and uart and double check if my builds were working, and if not then maybe I'll be bugging you about that in a bit 😬
@sour river the patch was only in the _mmc file that I don't think I'm using
since it is an sd card
ah, i was wondering if that was the case... gcc seemed to want it but that doesn't mean it was linked in
though i wasn't able to compile without it on gcc 10
I'm on 10.3 aarch64-none-elf-gcc (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621
that's the version string
lemme check in what I have now
yeah that's the same gcc as me
commit 07e1b9359e6881f0e915d452ba8c9355ef284a66 (HEAD -> rpi, origin/rpi) for circuitpython
that's what I was on. just pushed: 522dd3f93
hmm but you don't get a bunch of out-of-bounds warnings when building for raspberrypi_zero2w?
nope. when I run make -j 32 BOARD=raspberrypi_zero2w DEBUG=1
I'm on arch linux
make version 4.3
the changes didn't look like an issue to me
interesting... was it the DEBUG=1? i just got a build with that
ya
without DEBUG it fails because -Werror
though that's also there if DEBUG is true so.... idk haha
¯_(ツ)_/¯
maybe with debug it optimizes that compile idk. anyway, good to know, now once i find a mini hdmi adapter and solder some headers i'll see what else is wrong with me
ah, I see the errors you have when non-DEBUG
yep. the current version of that code that i could find was pretty different but looked like it was fixed
oh, did you look at main idf? maybe I started with 4.3
main branch? i just pulled whatever was on rpi
oh that main idf
yeah i'm making my comparison to that repo where they malloc a uint8_t array
ah, right. I removed the mallocs
ah, gotcha
also i know i have mini hdmi adapters somewhere and i can't find them. infuriating. I curse every device ever that uses mini hdmi
yeah and i'm trying to convince myself to commit to headers on one side or another because it will help a lot, but then it's just not thin anymore
so i guess if i ever need a thin rpiz2w i'll just have to buy another... :P
digikey still has them: https://www.digikey.com/en/products/detail/raspberry-pi/SC0510/15298147
wow, i'm amazed! i'll have to think if i really have a project in mind haha. could be good for octoprint, for sure
I ordered some as spares
always good practice. crazy that they're almost consumables at this point
i mean the original 0 was even more
did you ever try the NTC chip? sad that went away. I still have 3 and never really found a good place for them
ahead of their time, though
no, not sure what you are referring to
👍
I think it came out maybe... a month or two before the original Pi zero
oh no. poor timing for them
still, it had wifi and battery input and a bunch of neat things like that, so it was worth it until the zero W came a couple years later
yeah
I had one of those. Two actually.
only really made sense for embedded or really retro emulation since you needed a $15 adapter for hdmi
i had a pocketchip too. still do, and i'd like to make it my serial terminal for things like this
is it weird to think of it as 3-year-old retrotech? haha. it's like seeing an original pi model A
I haven't seen a hardfault in the five days since the watchdog issue was fixed, so I'm closing this. Will open a specific issue if any new hardfaults arise.
https://github.com/adafruit/circuitpython/pull/5565 notes that there is a design bug on v1.2 of this board: The MOSI and MISO pins to the external flash were switched. Also see https://github.com/sparkfun/MicroMod_Processor_Board-SAMD51/issues/2, which notes they hope to have fixed ones in stock. I'll open a new issue about fixing the pin mapping; let's close this one.
I would suggest that we not do this. #3190 found significant performance improvements with -O2. On SAME54 right now, we have plenty of flash, so let's not do this unless necessary. It's too bad the SAMx51 builds are filling up enough to have to go back to -Os, but that's the price of features :)
what's the baud rate for uart?
thanks. here goes...
#5565 notes that there is a design bug on v1.2 of this board: The MOSI and MISO pins to the external flash were switched. Also see sparkfun/MicroMod_Processor_Board-SAMD51#2, which notes they hope to have fixed ones in stock soon. They are going to offer an exchange. When we know the new pin mapping, let's make a new PR that corrects the pin assignments.
Closing in favor of a new pull request that will resolve #5590, when we know exactly what the new pin mapping is and can verify it.
Closing based on my review, but can revisit.
hmm nothing from uart on my image but no surprise
gonna try with your image from DD
sweet, that works. so my method to copy it is fine. even had my code from friday haha
i can compile with DEBUG=1
I'm trying without debug and getting stuck in the mmu setup
-O3 is trying to use q0 so that may be the issue
bingo
nice!
just curious, how do you see it's getting stuck there? I'm not getting anything on uart with the no debug build
openocd
-void setup_mmu_flat_map(void) {
+__attribute__((target("strict-align"))) void setup_mmu_flat_map(void) {
in peripherals
nice, that's the fix? lemme try it...
nice, works for me now too
great!
the cpu can't do unaligned access before the mmu is going
so the mmu init code needs to be aligned 🙂
i'll have to read up a bit to understand that better! but i'm glad you found it!
also USB works for me
the drive appears?
its weird to me that the cdc works still
right now everything stops for me when I plug in usb
I copied those changes into mine too
hm, well when i power mine from the second usb port i can access ttyACM0 and it shows the same output as my UART terminal
hrm
yay sway with screenshots
are you powering up and then plugging in USB or powering from the second USB right away?
¯_(ツ)_/¯
anyway, that's at least one mystery solved! pretty good for today
thanks for your help too. I'll see if I can keep up with this port when i have time 👍
thanks! good to have someone confirming my work
yep 👍 also it's pretty freakin' cool to be running code on a pi bare metal! didn't think you'd get there so quickly so this is awesome
well, i guess from when i heard you mention it to now it was a few months, but i was busy in between and so it was kindof the next deep dive for me haha
hah, i bet. well, if there are things I can test or experiment with that would help, i'd enjoy the challenge! I think i saw a github issue for it, not sure if that's current
I have some but not all Pi's, and a healthy assortment of SD cards and cables :P except those mini hdmi adapters wherever they are... but that's really only so i can mini-HDMI to mini-HDMI for my portable display. maybe it's an unhealthy assortment of cables
things get easier once usb is relatively stable
not enough 🙂
hahahaha
maybe you should get some NTC Chips of your own 😉 they would have been perfect for this...
I'll be in microcontroller land after this
yeah? what's up next, if you know?
esp s3 unless someone beats me to it
This should fix all those pesky unknown boards.
Thanks for doing all these! Just one addition.
that's a pretty powerful looking chip, wow. do you do anything with the vectorization/AI stuff?
though i guess half a meg of sram puts it lower than a lot of other ones
I don't do anything with it yet
Updated after a discussion with @Neradoc, to make sure that the new KeyboardLayoutBase code will fit on all boards when frozen. It does!
Anyone can review, thanks.
hmm not sure if this is the pi or my computer, but if i leave the serial connection unattented for a while, screen closes and I can't see neither the pi nor the other uart adapter until I reboot... 😬 so there might be some driver there that's crashing for me, or i just have a garbage laptop
@slender iron I created a branch post my C3 work, containing mine, yours and @atomic summit's S3 work but I haven't updated it since then so apart from the merge conflicts and code updates for a newer v4.4 commit... a PR can be made with S3 support and idf v4.4.
This fixes the last unknown board. Board is not is CP anymore: https://github.com/adafruit/circuitpython/tree/main/ports/espressif/boards
@analog bridge thanks for the link. That’s good place for us to start
I am already working on it 🙂
Do we want to ditch the "no inline" flag though?
Thanks, but I’m not new here
I guess I wanted to ask something here but i forgor 💀
My brain switched off
Sorry for off-topic btw
CircuitPython Weekly for November 22, 2021 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 participa...
It can be found in pinned messages.
OK, -O2 fits on the big SAME54, so let's get better performance in this case.
Great!
Let's see if the new Russian translations cause a new language to be added. We may need to add ru a few places.
ru builds are not being done. Will investigate.
Well I'll try to translate it as fast as possible. I'm studying atm
I'm deep in the weeds working out gesture analysis on the popular APDS-9960 prox/gesture/color/light sensor as a combo learning exercise and (hopefully) contribution to improving the somewhat flaky gesture detection in the driver. Its been a fun adventure with a pretty cool sensor.
I'm a bit frazzled by trying to interpret gesture data though. It feels like a simplified 4-pixel computer-vision problem. That's a space I have almost no experience in, which makes it appealing. 😂
Basically, the FIFO provides batches of 4 reflective "proximity" type measurements in ~1.6 ms to ~155 ms increments (depending on config). The implementer has to ingest, process, and "decode" this data to determine what the sensor may or may not have seen.
Does anyone here have experience processing this kind of data? This kind of problem feels like the kind of thing that someone with domain experience would know exactly what to do with.
I found some very helpful examples in an Arduino library for the sensor, which has helped with producing a working proof-of-concept in CircuitPython. That code is probably way to heavy for a SAMD21 board but today (or this week) I'm hoping to whittle that down to something I can put in a PR. 🙂
Here are my (way-too-verbose) notes so far, in case anyone else is crazy enough to take a peek into this rabbit hole with me.
https://github.com/fivesixzero/circuitpython-experiments/tree/main/clue-nrf52/apds9960-testing
You headed deep into the danger zone. Gesture related whatnot with this sensor has been frustrating from the beginning. 😄
I'm drawn to this stuff like a moth to a flame... Or like a caffeinated non-neuro-normative coder to a hyper-focus brain-sink? 😂
Imma go with choice B on that one. (From experience 😆 )
Either way its massively educational already. I love my little Proximity Trinkey so if I can make its gesture responses even a bit more deterministic I'll chalk it up as a win.
For sure, on all counts. If I have the time, I'm happy to test. I definitely have the hardware. 😄
May take ya up on that this week. When one finds themselves this deep in the mines I've found its helpful just to have someone else use the code in their own environment. At least once. 🤕
Absolutely. A. There's always something you missed, and B. I'm really good at breaking things.
Thanks for the initial work :)
Like #5571, but for Access Point. Allow setting the AP mac_address. Also, when hostname is set, set it for AP as well as Station.
Test code, with results in the comments:
import time
import wifi
from secrets import secrets
# after init, wifi is started/enabled, wifi mode is station
# hostname is default, mac_addresses are default
print("# Defaults:")
print(wifi.radio.hostname)
print(f'{wifi.radio.mac_address[5]:02X}')
print(f'{wifi.radio.mac_address_ap[5]:02X}')
...
FYI, there's been some indication that Mu doesn't work on Windows 11.
I'm running Win11 on a few systems, can test it out if it'd help. For my
stuff I use the VSCode plugin though
I just installed Mu 1.1.0-beta.6 on Windows 11, without there having been a previous install. It installed fine, and I was able to connect to a CircuitPython board and the REPL without difficulty. Someone had trouble starting beta.6 on Windows 10, and uninstalling the previous version first, uninstalling beta.6 and then reinstalling fixed the problem.
Thank you for testing. It was guide feedback, so I can't provide further feedback.
Looks like Dan got to it.
@idle owl let's put in a hint to uninstall previous versions before instalilng a new version. It even says on https://codewith.mu/download : Windows users: due to the nature of MSI installers, please remove old versions of Mu before installing the latest version.
Ok
i didn't know whether it would work or not, but glad that it is; one less support headache
Is this another one of the NEOPIXEL_POWER_INVERTED cases? https://github.com/adafruit/circuitpython/blob/c8b7206248d5e3905e2d4a6b230531e143e72467/ports/espressif/boards/adafruit_feather_esp32s2/pins.c#L47 (with TFT too)
maybe we should change the pin name right away
I won't have the board for another few hours, so can't verify, but a thread in #help-with-circuitpython seems to indicate it. No schematics posted yet.
@tulip sleet Note added to Welcome page. Copied the Mu text. Feel free to tweak it if you would rather it be something else.
i think that's fine
that's the basic, let me get the BME280 one
that looks OK, but I was mistaken, it's the I2C power control that was reported inverted
I'm not sure how to interpret that one on the schematic
I think it turns off the BME
i think it is inverted, we were talking about it internally yesterday
open circuit, I would guess, on the non-BME version
I'm receiving only the non-BME version
FYI -- I was playing with one of the BME280 feathers2's yesterday. I found that if I set I2C_POWER=False it seemed to work reliably but if I set it True, it became intermittent. works sometimes -- or gice an OSError (19) unsuported operation
floating input / high-Z if not set to False, presumably
seems so.
sounds inverted to me
happy to submit a PR if we're confident though... duplicate the pin like MagTag, or change it wholesale and lose the old uninverted name?
My testing was not exhaustive.
ladyada mentions in the TFT PR that pins may change in RevB board
The LC709203F did not seem to be impacted. Now I see from the schematic that i uses VBat, not VSENSOR so that makes sense.
Thonny IDE allows testing local scripts without saving them to the device first -- when the user selects "Run" command, the code will be submitted to the raw (or paste mode) REPL.
Before this it tries to clear the environment (in order to not depend on the state from previous commands). With MicroPython device it simpl orders soft-reboot in the raw mode, which disables running main.py. With CircuitPython this can't be used, so it simply soft-reboots and tries to interrupt code.py as quickl...
I would be willing to drop the old name, since there's only one release with the old name. It will be obvious the name needs to be changed for people's code
you could submit it that way and we can discuss it in the PR. Scott can weigh in
We are now building boards with a Russian translation. There is no release yet, but this will get set for it.
I don't have the board to test, but this was reported and discussed on Discord. Probably only relevant for the BME280 version of the board.
From the schematic, VSENSOR also goes out to the STEMMA connector - so this may also impact the non BME280 version
Unfortunately, today, I have been unable to get it to fail regardless of whether the I2C_POWER pin is set to True or False...
this is the code I am using to test -- I just change the ip.value from False to True but today , it does not seem to care.
# SPDX-FileCopyrightText: 2021 ladyada for Adafruit Industries
# SPDX-License-Identifier: MIT
import time
import board
from adafruit_bme280 import basic as adafruit_bme280
import digitalio
ip = digitalio.DigitalInOut(board.I2C_POWER)
ip.switch_to_output()
ip.value = False
# Create sensor object, using the board's default I2C bus.
i2c = board.I2C() #...
@jerryneedell Do you have a Rev.A board?
huh, maybe only gets the silk treatment when it changes to Rev.B
The schematic I saw is Rev B -- what changed from Rev A?
rev A did not have power control
How can I tell Rev A from Rev B board?
I am looking at the V+ pin on the STEMMA connector with a scope. If I set I2C_POWER to False, it stays steady at 3.3V.
If I set it to True, then the voltage drops just below 3V and when the BME280 sensor is accessed, it drops briefly (10ms) to <1.5 V. Does this sound like Rev A or Rev B?
I2C_POWER = True

I2C_POWER=False

@idle owl (carrying over from the help channel)
Has APDS-9960 gesture handling with the CircuitPython driver always been wonky? Or is it just me? Probably should've asked that before starting my epic (educational) journey. Issues page seems to point to "pretty much" but I'm still pretty new around here.
Always.
you're probably seeing parasitic power thru the I2C pins. you definteitely need to pull the power pin low to access i2c
<insert "challenge_accepted.jpg" here>
I was super excited about the concept, and had a project in mind, and Limor was quick to temper my excitement with the reality of the actual gesture sensing.
"It has a steep learning curve, you have to be really close to it, and it's still finicky."
etc.
So.... Yeah it's always been iffy. It's not what we necessarily promote about the sensor, since it does a lot of things. Heh.
@ladyada should I assume I have a rev b board.?
Yeah. Not wrong, at all. But the sensor itself basically leaves 99% of that stuff up to the implementer, for better or for worse.
"Here's a whargarbl of sequential 4-byte prox-count data! Good luck with that! Hope the FIFOs haven't overflowed! Oh, they have? AGAIN? Lol"
Definitely a case where async pin-interrupt callbacks would provide a much cleaner implementation. But could still useful in a single-use-case synchronous script, possibly, as long as it, you know, works reliably.
Well.... I mean.... we have async now.
Things have to be backwards compatible for now,. but... have at?
We were looking for something to try it out with. The LED Animation library was up first, but it turns out it was written so well that it doesn't really need asyncio. (It would still benefit from it, but it doesn't need it)
Its been in the back of my mind, for sure. There are so many different ways to handle things that I'm not even sure async handling would be the best approach.
Nice, thanks for pointing me in that direction. I did see the lines in the 7.1.0-beta release notes but haven't dug in too much yet. Soon(tm). 😄
Back to my favorite jupyter notebook... 😄 🗒️
The jupyter notebook to melt your brain!
if you're not me or i think scott, you have only a rev B board. we never shipped rev A thru the shop :)
@Pixel-Clay your translation work is now available in the latest builds at https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin. 7.1.0-beta.1 will also include Russian builds.
@tulip sleet do you have the settings to upload to s3 from cli?
I'm trying to upload the aarch64 compiler from the web console and it's failing
I uploaded it to the usual place. Do you want to figure out your credentials?
nah, I was able to login and attempt the upload
i was off making popcorn 🙂
I'm working on the asyncio learn guide