#circuitpython-dev
1 messages · Page 417 of 1
Fair enough! Whatever makes things go faster, within reason, I'm up for trying.
How would I be able to figure out if a specific port's pin has OPEN_DRAIN available on a given pin as a drive mode? Is that defined somewhere I could see?
If it's complicated, I'm looking at the STM32F405 here but curious about a general case as well
Was able to find it in the data sheet, but still curious anyways!
are there pins that don't have open drain?
I honestly have no idea, I know very very little about the inner workings electrically
it can be fudged in code I believe if the chip doesn't natively support it
I see the I2C bitbang does this I believe
in circuitpython, could write a pin finder to loop through all pins and try
7.2.4 and some earlier versions have a problem with GPIO0 being used for board.UART() on the Feather RP2040. The following program will hang and then USB will disconnect after 10 iterations, due to the gc.collect().,
This is related to #6213 and was found after fixing that bug by setting ringbuf->buf to NULL in ringbuf_free().
import board
import gc
import time
time.sleep(5)
uart = board.UART()
uart.baudrate = 115200
i = 0
while True:
if i % 10 == 0:
...
@onyx hinge I did not have time to look at the GPIO0 Feather RP2040 issue yet, but I wrote it up very quickly as the issue above. Going for a walk now. ^^
Tested 7.3.0-beta.0 and the incorrect voltages still exist. Will investigate further.
The REPL on the QTPY ESP32C# appears to be dropping characters.
I use rshell with my ESP32C3 DevKit (I have modified it to use binascii) and it works well.
On the QPYU ESP32C3, rshell is unable to establish a connection to the board.
If I use screen I can get to the REPL, but cutting and pasting code often misses characteres.
Here is an example of executing help('modules') and you can see the erratic formatting of the output. The columns should; be aligned.
Adafruit CircuitPytho...
executing import wifi on the qtpy espc2c3 causes the board to hang
Adafruit CircuitPython 7.3.0-beta.0 on 2022-04-01; Adafruit QT Py ESP32C3 with ESP32-C3FN4
>>>
>>> import wifi
It has to be power cycled to regain access.
Hmm. Is it still worth including a warning about "You must use CP 7.1.0 or later" in this asyncio template page? Or are we far enough past 7.1.0 that it doesn't need to be included anymore?
i think we could remove it. 7.1.0 is last fall.
Also, with asyncio being a library, how can I verify whether a board supports asyncio? (SAMD21 is obvious, none of them do.) This question is basically specific to the few nRF boards that evidently do not support it. Do I need to try it on those boards to find out if it works? Or is there some where to look it up?
Thanks, will do.
I am not sure but I think if _asyncio is supported, then async/await are also turned on. Hmm, but _asyncio is not showing up in the module support matrix
Yeah that's what I checked first.
_asyncio and async/await don't have to go together, but I think they do now.
Since there are a lot of boards that won't work -- would it be a good practice to use try/except on the import.
Well, this template is designed to go into each board guide. So you simply wouldn't add it if it doesn't work with a particular board.
this is the case of a language feature being on or off. The same is true of, say, long integers. Perhaps we should have a table for that.
Language Feature support matrix
I mean for now I'll probably be the only one using this template. So I can deal with it not containing instructions to find out whether a board is supported or not.
But if it goes beyond me, there needs to be a way to determine whether it should go into a guide or not.
Other than SAMD21
@tulip sleet Is it ok to use the word "simultaneous" when referring to the animations running on the rings? The actual sentence is this: You will use a button to control two simultaneous animations displayed on two different NeoPixel rings.
Or is that incorrect.
I snagged your Blinka event loop image. I link to the overview page twice. but I wanted to include a basic explanation on this page so folks aren't necessarily required to refer to another page to have a basic understanding of what's going on.
the animations look simultaneous, to the user, but the two pieces of code are not running simultaneously: they are taking turns. It's a fine point, but one I emphasize several times.
That is why I asked.
I will remove it.
@tulip sleet I made more changes to the code, but not functional changes, simply variable name changes. I tested whether GitHub can host GIFs (it can), and one step further, you can use the "remote URL" to load the GIF directly from GitHub in Learn. So I can make two GIFs, one for an example of a built in button, and one for an example of an external button, and then have the template-filler choose which one matches the wiring diagram. 🤯 Anyway, point is, I'll submit the GIFs with the code update as a single PR to Learn. I'll tag you on it for the code review since you got tagged by Limor on the last tweak I made. Should be sometime Monday or Tuesday if meetings go long or whatever. FYI.
This is affected by whether or not the TX and/or RX pins are connected to another board. I was testing with them connected to a QT Py RP2040 that was not powered. TX->RX, RX->TX, and common ground. Without the connection, I don't see the failure. To be continued.
Also, once I'm done with this template page, I'll have you review it for content accuracy before handing it over the Anne and Limor.
neato on the GIF!
Right? Didn't think that whole process would work, but surprise, it worked.
Has anyone seen this error attempting to build circuitpython from main? I'm sure something in my environment is messed up or out of date, but not sure what.
Traceback (most recent call last):
File "../../tools/gen_nvm_devices.py", line 2, in <module>
import cascadetoml
File "/home/timc/.local/lib/python3.8/site-packages/cascadetoml.py", line 12, in <module>
import typer
File "/home/timc/.local/lib/python3.8/site-packages/typer/__init__.py", line 12, in <module>
from click.termui import get_terminal_size as get_terminal_size
ImportError: cannot import name 'get_terminal_size' from 'click.termui' (/home/timc/.local/lib/python3.8/site-packages/click/termui.py)
make: *** [../../supervisor/supervisor.mk:75: build-pyportal_titano/genhdr/devices.h] Error 1
make: *** Waiting for unfinished jobs....
there is an issue with the exact versions of click and typer used . See the requirements-*.txt files for what is required now. But the typer person fixed the problem, so if you upgrade typer, it should be ok.
so we can undo the pins. See https://github.com/adafruit/circuitpython/pull/6210
@onyx hinge typer is fixed: https://github.com/tiangolo/typer/pull/375
Installing click 8.0.4 as noted in requirements seems to have gotten me past that issue. Thank you!
click made an API change without incrementing the major version number (which we didn't pin anyway, but still...)
Click 8.1.0 should work with typer 0.4.1
@blissful pollen Is there another word for "returns" in the last sentence here? "await.gather(...) runs until all the listed tasks have finished. If gather returns that means all the tasks listed have finished." I basically get what it means, but I think it might confuse newbies.
"stops" isn't right, because it returning doesn't mean it's halting.
Neither is "finishes" or any other similar word, I think.
"restarts"? Or is that sometimes wrong.
A function does normally return but I know what you mean about maybe being confusing. Returns from running or something? Or maybe completes?
It would never restart though (unless it was in its own loop)
No problem
yay! I saw that and meant to PR the reversion of our workarounds, but didn't get to it yet. (I didn't get to much today, somehow)
should the creation of special files on the drive be conditioned by CIRCUITPY_USB or whatever it's called ? You know, .Trashes and stuff ?
When implementing #6217 I ended up having errors but only after one reload when using the PWM as such:
rgb = adafruit_rgbled.RGBLED(board.LED_RED, board.LED_GREEN, board.LED_BLUE)
Traceback (most recent call last):
File "code.py", line 17, in
File "adafruit_rgbled.py", line 107, in __init__
RuntimeError: All channels in use
Note that the C3 has 6 PWM channels.
Removing the code in supervisor/shared/status_leds.c that sets up the PWM pins as "never res...
This shouldn't be merged until # #6223 is fixed.
Revert most of #6210, because typer is compatible with click 8.1.x again, but keep pull_request: paths changes in windows workflow.
Note that click is up to 8.1.2 now.
Hello all,
I succesfully flashed the AI thinker ESP-C3-32S board with CircuitPython 7.2.4.
I can access/create/edit code files etc. on the board using Thonny.
However, the CIRCUITPY drive is not available.
Is there any way I can transfer some files/directory to the board? (I want to copy some library to it.)
Thank you,
Hey all, sorry to revive a dead thread, but I'm bringing up the 52840 Feather for a Rust project and ran into the same 16MHz QSPI limitation.
This was one of the few places I found that mentioned the limitation. Did anyone figure a way to get it working at 32MHz?
Does anyone know what the level of effort would be to fix this issue? I really need this to be resolved for a project I want to do.
Internal filesystem stubs is used when both INTERNAL_FLASH_FILESYSTEM, DISABLE_FILESYSTEM are set.
CircuitPython version
Adafruit CircuitPython 7.2.4 on 2022-03-31; Adafruit PyPortal with samd51j20
Code/REPL
Adafruit CircuitPython 7.2.4 on 2022-03-31; Adafruit PyPortal with samd51j20
>>> import board
>>> import displayio
>>> board.DISPLAY
>>> displayio.release_displays()
>>> board.DISPLAY
None
>>> type(board.DISPLAY)
>>> board.DISPLAY is None
False
>>> foo=None
>>> foo
>>> type(foo)
>>> foo is None
True
Behavior
After displ...
Did anyone figure a way to get it working at 32MHz?
We didn't. I assume your low-level code is completely different, so it's not just some problem in our setup. You could look in https://devzone.nordicsemi.com/ to see if this kind of thing was mentioned by anyone else, or even open a thread about it.
I think it's just a matter of changing a bunch of uint8_ts to uint16_ts, and allowing a wider range in the argument validation. The construction of the HID Report Descriptors is up to the user -- we don't construct them for you.
CircuitPython version
Adafruit CircuitPython 7.2.4 on 2022-03-31; Teensy 4.0 with IMXRT1062DVJ6A
Code/REPL
import board
import digitalio
import time
import busio
import supervisor
led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT
loop_count = 0
uart1 = busio.UART(board.D1, board.D0, baudrate=1000000)
uart2 = busio.UART(board.D8, board.D7, baudrate=1000000)
while True:
if supervisor.runtime.serial_bytes_ava...
This is the right place to report this, thanks.
Any bright ideas what to do about board.DISPLAY? this has vexed me as well. Changing the type of an object to NoneType is not quite the same as changing the object to be None, as None is also supposed to be a singleton.
Adding a generic "DeinitedObject" type could be interesting. Virtually any operation on it would raise a DeinitedError. Could save code, by removing the need to check for deinit explicitly in any functions.
should have been a callable to begin with, like I2C and SPI
CircuitPython version
Adafruit CircuitPython 7.3.0-beta.0 on 2022-04-01; Adafruit Feather RP2040 with rp2040
Code/REPL
import board
import digitalio
import time
import busio
import supervisor
############################
"""CircuitPython Essentials UART possible pin-pair identifying script"""
"""
import board
import busio
from microcontroller import Pin
def is_hardware_uart(tx, rx):
try:
p = busio.UART(tx, rx)
p.dei...
You can have two UARTs on RP2040, but "you can only do two at a time, and only on separate peripherals, 0 and 1"
https://learn.adafruit.com/assets/107203
Both pairs in the code above use peripheral 1.
Thanks @anecdata,
giving it a try:
import board
import digitalio
import time
import busio
import supervisor
led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT
loop_count = 0
uart1 = board.UART()
uart1.baudrate = 1000000
uart2 = busio.UART(board.D25, board.D24, baudrate=1000000)
while True:
if supervisor.runtime.serial_bytes_available:
text = input()
print("*** Serial input ***", text)
b = bytearray()
...
@dhalbert - I built the example single_read adc application in the ESP IDF from the current CP main tree. It always returns a reading of 8191, which is the max adc reading, and which is what CP is getting to calculate the voltage incorrectly. Building from the main tree of the current espressif/esp-idf on Github yields correct readings. So, is it worth binary searching the 400-some commits between our esp-idf and the current IDF master to figure this one out? Any easier way come to mind?
Thanks for that. I'll see if I can get a build environment working on my Mac so I can try to make the required changes.
barely a size advantage, after converting busio (+12 bytes free flash on trinket m0)
Does it work for the espressif 4.4 branch, or only their master?
@lone axle sorry for sending you on a goose chase! I didn’t know you were doing a live stream, would have joined to chat & help clarify any curiosity. Looks like my comments cost you time.
(e.g., I think I meant “also” rather than “instead” :-p it’s just in my brain somehow more important in refresh areas so I wrote the wrong word)
No worries. I appreciate you're help!
I don't always know what I will work on ahead of time. I had a few ideas going into friday and ended up on that one. But if you are around one week it would be great to have you in the chat.
I'm definitely still "fumbling through" core stuff a bit so it's bound to take me some time one way or another, but I feel like I get better understanding each time I dive in to something like this so moving in the right direction 😄
@low sentinel do you think I have the right general idea about this being something that could be handled inside of Group rather than adding the hidden property to the vectorio shapes? It feels to me like Group should be able to manage that for it's children without them needing the flag specifically. Though the flag on the child elements can be helpful as well so maybe it's worth having it even if not strictly necessary.
using the branch release/v4.4 fails as well. I'll try narrowing down their fix.
Just had all the ESP32-S2 devices from Adafruit in my home start acting like my router doesn't exist, very strange. ("No network with that name" and/or error 205). I suspect it's router related, since they're different ages and usage profiles, but I didn't change anything router related... Maybe it's the new neighbors.
I managed to get a working build of the main branch on my Mac. The changes I think are necessary are:
index 286623b0c..f85cf64ea 100644
--- a/shared-bindings/usb_hid/Device.c
+++ b/shared-bindings/usb_hid/Device.c
@@ -103,11 +103,11 @@ STATIC mp_obj_t usb_hid_device_make_new(const mp_obj_type_t *type, size_t n_args
mp_obj_t descriptor = mp_obj_new_bytearray(descriptor_bufinfo.len, descriptor_bufin...
I'm experiencing the same issue calling the OpenWeather API and others running on 7.2.3. reducing the number of API calls makes it run longer on mine but it still ends up crashing eventually. When my Matrix Portal crashes I'm no longer able to set up a serial connection to the device.
Quick update, I believe my crashing the board, has to do with my attempts to use the board.UART
and maybe specifically with me attempting to figure out how to set the baud rate on it.
That is I tried also starting from simple Neiopixel example (docs should mention you need to download the library...)
And then tried to build out, to use uarts...
import time
import board
import busio
import supervisor
import neopixel
led = neopixel.NeoPixel(board.NEOPIXEL, 1)
led....
Good work! These also need to be uint16_t:
const uint8_t usage_page = usage_page_arg;
const uint8_t usage = usage_arg;
And there may be further ones in shared-module.
I'm looking at trying to get the WiFi/BLE functions of the Seeed WIO Terminal working with CP. Based on what I've found in digging into this, it should be possible, since the SAMD51 in the WIO seems to talk to the RTL8720D via an embedded remote procedure call API over UART (both UART and SPI are connected, but I think the latter is just for flashing the firmware).
Apparently, the more recent RTL8720D firmware supports both WiFi and BLE at the some time. Looking at the PyPortal as an example, it seems like the best way to approach this would be to implement a new class in adafruit_airlift to provide an implementation for adafruit_ble, and then maybe create something akin to adafruit_esp32api (adafruit_rtl8720api?) for the WiFi side of things.
Not sure I can even make this work yet (I need to dig into that eRPC code a bit more), but would love thoughts on how to best pattern this.
@hierophect did you ever get ESP32-NOW working on CP? I have a number of ESP32-S2-based dev boards and I'd be interested in experimenting with this protocol for the same type of use cases where'd I'd use LORA or other lightweight radio system. The advantages of this protocol seem to be:
- No additional radio required for an ESP32
- better suited to low power use cases than WiFi
- does not require a router
- ideal for small (<=250 byte) packets
If this is still ongoing perhaps I can ...
I am fine to remove it. My idea was to state it here for sake of completeness since the function prototypes are declared together in supervisor/flash.h. This piece of inactive code also could be kept and I may comment it accordingly. Does it make sense?
void supervisor_flash_init_vfs(struct _fs_user_mount_t *vfs);
void supervisor_flash_flush(void);
void supervisor_flash_release_cache(void);
@idle owl, @trim elm - wanted to get the rest of the patch stuff done in time for Monday, in case you want to go over that as well:
Proposed changes to cookiecutter:
https://github.com/adafruit/Adafruit_CircuitPython_TSC2007/pull/2
Proposed changes to existing libraries (patch):
https://github.com/adafruit/Adafruit_CircuitPython_BME680/pull/48
Thanks
figured it out eventually:
PU freq: %d 960000000
Pystone(1.2) time for 500 passes = 57769777 ms
This machine benchmarks at 8655 pystones/second
CPU freq: %d 600000000
Pystone(1.2) time for 500 passes = 79864499 ms
This machine benchmarks at 6260 pystones/second
If this is still ongoing perhaps I can help with the code.
@richsad I don't think anybody is working on it at the moment, so if you feel like this, just go ahead and try it. There shouldn't be any problems merging it, as far as I know, and the devs were always happy to review such patches.
I think you have the right idea. about needing to implement something like adafruit_esp32api and adafruit_rtl8720api is probably what that library would get named if it were developed by adafruit folks, but I would guess that is unlikely unless they end up manufacturing a device with that type of wifi chip on it, or some member of the community takes particular interest in it. It could have a different name if developed by the community as well.
As far as best pattern I would probably lean toward trying to mimic the API in the esp32spi library if possible, but it could stray from that API if there are technical differences that necessitate it.
same issue. I tried resetting the Network connection every couple minutes as well, but the issue still persists. Running on the latest 7.2.4 uf2
I think the pins issue is sorted out, but there should never be a crash into Safe Mode. @KurtE can we close this issue, and would you like to open a new issue for the safe mode?
Hi, this is a dupe of #6213 and #6219. I have a fix, but there are still some peculiarities when connecting pins to unpowered pins on another board (#6219).
what a weird bug, dan
Sorry feel free to close if appropriate. Especially if it is a duplicate.
And wait to see what happens when I pick up the changes.
Example just now:
Had simple Noepixel sketch running:
import time
import board
import busio
import supervisor
import neopixel
led = neopixel.NeoPixel(board.NEOPIXEL, 1)
led.brightness = 0.3
#uart1 = board.UART()
#uart1.baudrate(38400)
#print(uart1.baudrate)
while True:
if supervisor.runtime.serial_bytes_available:
...
very confusing until I realized what was going on... tomorrow I will spend some time on it
it hangs when I gc, when the pins are connected like that. totally weird
that doesn't make much sense
it didn't hang when I picked a different pin. I thought it was a GPIO0 issue, but the different pin was not connected, so it worked
so if it took you a bit to realize the pattern that's not surprising
and it's the TX pin. I would have thought maybe it was due to noise on the RX pin causing a lot of interrupts
or maybe the TX pin transitions are bleeding into the RX pin
some microcontrollers can back-power through protection diodes, maybe it draws a bunch of current?
maybe, maybe, but why only on gc?
oh yeah, a tx looped back to its own rx could be interesting. you could also try a tx-only or rx-only uart
or an arduino program
good idea, first thing is that I will see if it's looping or something. Just got the SWD connector working. I had another Feather with an SWD box but I coudn't find it
Thanks for that. Yes there were more locations to update. I think I have found them. Here is the git diff now:
index 642fe9b5a..c7bd91ad1 100644
--- a/mpy-cross/mpy-cross.mk
+++ b/mpy-cross/mpy-cross.mk
@@ -29,6 +29,8 @@ INC += -I$(BUILD)
# compiler settings
CWARN = -Wall -Werror
CWARN += -Wpointer-arith -Wuninitialized
+# Disable errors for array-bounds warnings on "sp[-MP_OBJ_ITER_BUF_NSLOTS + 2]" access
+CWARN += ...
Okay, thanks! My low level code is indeed different, and I have gotten 32MHz QSPI working with other flash parts using the same low level code, specifically the W25Q128JVS (though with a different nRF52 SOM, the Minew MS88SF2). So my best guess is it is something particular to this flash chip, the SOM in use, or the routing between the SOM and flash chip.
Thankfully 16MHz is "fast enough" for my current application, so I probably won't chase this down any further.
Thanks again for the c...
Could you make a pull request? That would be ideal - thanks.
@anecdata @dhalbert - Will go ahead and close this issue.
The crashes do appear to be duplicates of the issues mentioned. As I said in previous post will sync up and try with latest sources.
however it is still very unclear on what is the proper way to use two hardware uarts of the RPI2040?
From the pinout page, I believe I have options on which pins to use for each:

...
If you are not familiar with how to make a pull request, we have a guide here: https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github
f5d90fc84 Switch to port_serial_* hooks
45f9522a6 Fix EVK status led to be inverted
96f5eec2e Add Teensy 4.1 power pin and fix SWD for DEBUG=1
83593a155 Start of USB host API
These are the commits between 7.2.4 and 7.3.0-beta.0 that touch the mimxrt1011 port. Both 83593a155 and f5d90fc84 touch the uart. If you take a look at those commits, it may help you isolate what's changed and help you prepare a pull request.
micropython fixed it in some other way: https://github.com/micropython/micropython/issues/8467 -> https://github.com/micropython/micropython/commit/bb70874111dbb246624a68c013e8f1c3245ca0d8
we'll naturally get this in a future merge of micropython, thought it may not occur before 8.0. So if it's vexing you, we should consider cherry-picking the change now instead of waiting.
@ZodiusInfuser Check the discussion here: #6227, about an issue that came up because board.DISPLAY was an object and not a function like, say board.I2C(). Because board.DISPLAY is only an attribute, it cannot be set to None: the attribute dictionary is in flash and not RAM, to save RAM. It would have been better if board.DISPLAY were board.DISPLAY(). We may eventually make some change that does that one way or another, such as introducing a function, say, board.DISP(), and event...
This seems to work:
Adafruit CircuitPython 7.2.0-alpha.1-224-gac7a80753 on 2022-01-26; Adafruit Feather RP2040 with rp2040
>>> import board, busio
>>> uart0 = board.UART()
>>> uart0.deinit()
>>>
>>> uart1 = busio.UART(board.D24, board.D25)
>>>
>>> uart0 = busio.UART(board.D12, board.D13)
maybe there's a cleaner way to do the deinit?
Finally got around to reproducing this. On Trellis M4, the MP3 audio stops but the playing property of the speaker stays True.
I'm fine waiting for it to be fixed by the upstream merge whenever it happens. Thanks.
Some audio implementations, notably samd, really don't like it when you return 0 samples of data. This was the case when reaching the end of an MP3 file.
Now, we read forward in an MP3 file to the next sync word during "get_buffer", so that we can accurately return GET_BUFFER_DONE when the NEXT call WOULD HAVE resulted in 0 samples.
Tested with @gamblor21's "laugh.mp3" file on a Trellis M4 Express.
Closes: #5415.
This warning can happen on clang 13.0.1 building mpy-cross:
../py/vm.c:748:25: error: array index -3 refers past the last possible
element for an array in 64-bit address space containing 64-bit (8-byte)
elements (max possible 2305843009213693952 elements)
[-Werror,-Warray-bounds]
sp[-MP_OBJ_ITER_BUF_NSLOTS + 1] = MP_OBJ_NULL;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using pointer access instead of array access works around this warn...
Personally I don't get why the change makes the diagnostic disappear (x[y] and *(x+y) refer to the same thing and are valid at the same times) but probably @dpgeorge knows better than me :) :)
I think this is related but not exactly the same as the discussion in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578, about using offsets from fixed addresses, and a compiler thinking it knows better than you about whether you are addressing something out of bounds.
This issue was posted on circuitpython forum, Adafruit admin recommended
opening of issue here.
This is running mostly verbatim (some lines commented) the example ( https://learn.adafruit.com/adafruit-esp32-s2-feather/i2c-on-board-sensors) for using deep sleep on the BME280 equipped Adafruit Feather S2 (with 60 second sleep time). It may have happened with previous versions also, but I never caught it while running with the usb console attached. This occurred after quite a few hours of ru...
This register is ALSO used to tell if the PWM channel should be considered in use by software.
Closes #6061.
Thank you! I'll add this to In the Weeds as well. Will you be able to voice chat in the meeting today, at least for in the weeds? Or is it too late in the day for you to be available other than listening in?
Reminder that we are having a CircuitPython Weekly meeting today, in about two hours, 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/1em2Z3EF5T_eaz04e-XdesuIZrxCEB_3plFVzBiat_jc/edit?usp=sharing
CircuitPython Weekly for 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 participate, add your notes...
TFW you're typing in the notes doc and then the host adds all the things. My typing is many pages away now. 😄
maybe this is a new form of teleportation
@onyx hinge I see all your PR's, getting ready for the meeting, so I probably won't review them until after
@tulip sleet thanks, no hurry!
looks like 7.2.x should be merged to main after those go in as well.
Entering as a draft, because it should be updated after any/all other PRs are merged to 7.2.x. I just wanted to get this started because there was a merge conflict.
@lone axle Yeah, I was hoping to keep hidden out of the vectorio APIs and let it be handled by Group from the Python point of view.
Managing dirty areas at Group makes sense imo; ideally Group could handle it but you might have some challenges, e.g., with cleaning up previously drawn areas especially if there’s movement. As a fall-back, it seems reasonable to put a c-level boolean in the vectorshape struct. Would prefer avoiding it BUT hidden/not-hidden from group is an important enough feature to pay the memory for it 👍
huh I wonder why some of those builds are failing. the error seems to be FileExistsError: [Errno 17] File exists: '/opt/hostedtoolcache/Python/3.10.4/x64/bin/python' -> '/home/runner/work/circuitpython/circuitpython/.idf_tools/python_env/idf4.4_py3.10_env/bin/python' from a virtualenv creation attempt. https://github.com/adafruit/circuitpython/runs/5818926795?check_suite_focus=true
okay thank you! appreciate your perspective. I'll make some more attempts at doing it from the Group. I feel like I was close with that approach, just need a tweak somewhere to make it realize it needs to redraw. Will fall back to property on vectorshape mimicing the ones from TileGrid and Group if I don't end up having success doing it from inside of Group only.
@tulip sleet I took the updated libs out of the notes doc. Over a page is too many, nearly 3 pages is untenable. I deleted them from the notes doc, and added a link to the library report on S3 if folks are interested in seeing the list.
if you're getting Sending request failed mabye check your io user/key
It's not a fix, but an option you have is to try the hardware watchdog, which would reset the whole microcontroller (the one where CircuitPython resides) if your program stops running normally.
Before doing this, be comfortable with entering safe mode on your board, because an errant watchdog reset can make it difficult to modify your code.py.
You'd initialize the watchdog with a timeout:
from microcontroller import watchdog as w
from watchdog import WatchDogMode
w.timeout...
That is good. I was thinking of that, but your decision is more authoritative
No worries. Always happy to help.
I could be in the voice channel :)
Keen! That might be helpful for discussing In the Weeds. I was pretty thorough, but I didn't do the work. 🙂
Thanks, this appears to work on RP2040. Here is an updated sketch I am running, where I also put in a fail safe in that if D5 is not connected to 3.3v it won't run the uart code... I have it still playing with the neopixel, although a little differently...
import time
import board
import busio
import supervisor
from digitalio import DigitalInOut, Direction, Pull
import neopixel
led_colors = [
(255, 0, 0),
(0, 255, 0),
(0, 0, 255),
(255, 255, 0),
(25...
Cool. I'm still digging into the eRPC code for the WIO Terminal's Arduino core, so it'll be a little while before I can say for sure, but I think keeping close to the esp32spi lib will work. Seeed implemented a library that mimics the ESP32 API (rpcWiFIi) so I might take a look at that, too.
I should have realized / tried before... doing board.UART().deinit() directly also works
>>> import board, busio
>>> board.UART().deinit()
>>> uart1 = busio.UART(board.TX, board.RX, baudrate=1000000)
>>> uart2 = busio.UART(board.D24, board.D25, baudrate=1000000)
>>>
Thanks, looks cleaner.
right now waiting for esp32 build...
Oops looks like I need to do something to make it build... does not like cmake...
Back to playin
I battled this as well and worked with staff to figure out the issue. We tried replacing hardware too which helped failure rates but it still fails. Trying the watchdog thing now and it seems to be stable so far, I just started a rather long print so we'll see if it's still running in the morning.
For those of you who had this problem, what version of the NINA-FW firmware are you using on the ESP32 that's on the MtarixPortal? That is printed out by the simple Internet test given here: https://learn.adafruit.com/adafruit-matrixportal-m4/internet-connect. The key value is esp.firmware_version.
Firmware vers. bytearray(b'1.2.2\x00')
Hi all!
Firmware vers. bytearray(b'1.2.2\x00')
Please subscribe at adafruitdaily.com
It's not available everywhere yet. FYI.
Same here:
Firmware vers. bytearray(b'1.2.2\x00')
oof a $140 textbook !? https://www.pearson.com/us/higher-education/product/Schneider-Introduction-to-Programming-Using-Python-An/9780134058221.html
Introduction to Programming Using Python, An
you pasted exactly the information that was needed for me to guess at the problem so yay
Algorithmic Problem Solving with Python https://eecs.wsu.edu/~schneidj/swan/index.php
oh! that's much more my speed 😁
Pasting didn't help either of us figure it out, so still... good on you!
88 boards = 1 piano
🙂
You can get it a bit cheaper if you shop around: https://www.amazon.com/Introduction-Programming-Using-Python/dp/0134058224

@lone axle I can point you to where you need to look, I believe. Not sure I can help, but I can at least get you started in the right direction.
awesome! Definitely appreciate a point int he right direction.
If you didn't already though, you should start by seeing if the API can even return that information.
Happy yearly birth date @onyx hinge !
I assume the API can do that, since it has a ton of info, but assuming has wasted a lot of time in general for me...
I haven't managed to pick up an esp32c3 yet so I haven't tested.
I tried using the watchdog time out as suggested above. Just had it crash and reset automatically. Thanks for the suggestion @jepler
Good point, I will look into the github API before I start digging back into adabot. Would be good to verify that data is available before spend too much time figuring out where / how to add it to the page.
Exactly 🙂
absolutely right to file issues
also if you can find out a milestone for a PR, that would be a good label too (e.g. the 8.0.0 PR's that are in abeyance for a while).
That would be great. I'll check into milestone data availability as well.
nice!
Congrats @proven garnet!
Congrats! That's super exciting!
Preliminary it's looking promising for both draft and milestone data. I figured out how to access both with the gh cmd line utility. I think that utilizes the Github API "under the hood" to get it's information.
Excellent.
I do like the idea of using a minimal .gitignore in the repos as well.
I didn't know about that personal ignore file until Jeff mentioned it on a PR at one point.
and there's .git/info/exclude
Are there any comments as to why there are added blocks in the .gitignore? Some of my personal ones have comments address what a block is addressed for.
It doesn't solve the problem one way or the other, but it might make it easier to see why I have something in a gitignore.
Is it possible to make a CI step that validates that there are no changes inside of .gitignore? Or perhaps even more broadly we could have a larger list of "infrastructure" files that are all checked during CI and get flagged if they are chanaged.
we can add a comment to cookie-cutter .gitignore that explains how to add things to your personal .gitignore
https://git-scm.com/docs/gitignore
Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by core.excludesFile in the user’s ~/.gitconfig. Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead.
a comment in the file that points people toward how they can set up their personal .gitignore sounds like a helpful thing to me as well.
Thanks
I'm out!
Thank you!
Me too
Checked my username and password on io.adafruit.com, it matches what I've got in secrets.py. I'm attaching putty.log file. Lots of lines, but the short story is that it shows 264 "Data sent!" messages followed by 267 "Sending request failed" mesages, after which it goes to sleep then gives the "Failed to allocate wifi memory" message when it wakes up ~60 seconds later.
putty1.log
.
Thanks all!
@patrebert what if you disconnect USB REPL so that the board really goes to sleep - does it work then? check io to make sure messages are coming thru. you can reduce the sleep delay to speed up the test
I tried using the watchdog time out as suggested above. Just had it crash and reset automatically. Thanks for the suggestion @jepler
I had to increase the timeout to 15, and make sure you have the feed call both there and in your loop otherwise it's not fed soon enough to enter the loop.
So major IDEs that folks might use are PyCharm, VSCode, Mu, vim, Atom... what else? So far only the first two add spurious files when using them. (At least with my minimal usage. Am I missing something about the others?)
Nano didn't leave anything either.
What do other folks use?
I've had it quit while operating in its intended remote location, but can't verify that the circumstances are the same without the console output. That's why I brought it inside to test on my desk with with console connected. Will go ahead and restart it with shorter sleep and no console.
Sublime, Jupyter notebooks but I doubt they'd be used here, Emacs, Spyder. (Based on python developer survey, excluding what you've already covered)
@jepler - I am taking a look at it. will look at the two changes you mentioned.
Current sketch, I setup the way I have my arduino sketches...
import time
import board
import busio
import supervisor
from digitalio import DigitalInOut, Direction, Pull
led = DigitalInOut(board.LED)
led.direction = Direction.OUTPUT
check_pin = DigitalInOut(board.D2)
check_pin.direction = Direction.INPUT
check_pin.pull = Pull.DOWN
uart1 = None
last_check_value = check_pin.value
...
Googling sublime cache files gitignore show's a good number of example gitignores: https://github.com/github/gitignore/blob/main/Global/SublimeText.gitignore which might help with figuring out what ide's generate what cache's
Hmm. Sublime isn't leaving any files when I'm editing here.
Oof that's a lot of files.
That the gitignore is saying it might leave.
yeah it's probably special cases ?
Honestly I wouldn't worry about adding them
I'm not getting any files with simple changes.
you might need to setup the dir as the root of a project to get them
from Sublime. So... probably not worth adding.
I wonder if that's if you try to git add * in the same folder as the ide
Oh, so actually use it like it's meant to be used.
Fair enough.
I see a fair amount of people mentioning using Thonny. Don't know if it creates any files though.
Here's my thought on Sublime. It's not currently in any of the libraries.
So I'm not adding it here.
I think that's reasonable
Oh right, Thonny. I have it on this machine, I can check.
agreed
Have restarted with 5 second sleep. It's logging results to io.adafruit.com now.
Don't see anything from Thonny either. When I use it, or in the current pile of gitignore entries.
Plus if it does generate some cache file, you can also just not add it to a commit. Foamyguy's comment about updating the CI so it fails if there's a change to the gitignore would help with this as well once the minimal gitignore is setup.
Agreed.
To feed bme280-temperature-f
It's worth testing whether NINA v1.7.4 improves things, though I couldn't definitively tie any NINA fixes to this problem.
It seems odd to me that this is only reported on MatrixPortal and not other M4+Airlift configs like PyPortal.
How likely is one to run into .pyc files when working with the libraries? I looked up what it is, and I don't quite follow how one might end up with one in a library repo.
Same with __pycache__ ?
Running code using the library. I think it's usually in a Gitignore because there's never a reason someone should need to track compiled python
Hmm.
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1m1PCDAFk9kLs3MF1vEx9e0UW1WTURFB-eTORSQe8a7o/edit?usp=sharing
CircuitPython Weekly for Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting -...
But I guess if the target is an MC it might be different. Sphinx may generate it though?
Sphinx does not.
I get those if I am testing the library with Blinka, etc.
I think both extensions are worth keeping in the gitignore since so many scripts can be run or generated from cpython
I'll include them then.
Last few files I think aren't needed anymore because they're PyPI related, and that's handled by the CI now. You don't do that locally.
Though I guess Scott was doing the one that used pyproject.toml manually or something. We shouldn't be doing it locally anyway.
What would a bundles file be?
looks like it might be something to do with javascript?
What are we doing with JS?
Pretty certain this is all manual-PyPI related: #build*/ #dist #.eggs #**/*.egg-info
We were dealing with those files when we first put all the libs up on PyPI.
We should no longer be dealing with them.
i think if you pip -e install ., some of that might show up. Need to test
Last questionable inclusion is .env. I suppose that one should be up to folks to do globally?
I'll try right now
Ah, I was going to say that 😄
I'll let you test.
Instructions for creating a .gitignore_global - beginning or end of this .gitignore file? I feel like beginning since it's not supposed to be edited, so we're kinda of saying "Before you even look at this file, before you even think about editing it... maybe you need to follow these steps."
*.egg-info shows up when i install the BLE library
I think so, if it supports **
Dunno why it's got extra ** that the others don't...
I'll take it out.
Nothing else uses it, but it's obviously supported.
Conclusions on bundles?
https://github.com/adafruit/Adafruit_CircuitPython_APDS9960
https://github.com/adafruit/Adafruit_CircuitPython_Bundle
https://github.com/adafruit/CircuitPython_Community_Bundle
Those are the libraries where I found bundles in the gitignore.
I *think* that the APDS9960 doesn't need it, I don't know about the libraries bundles, and I think those are out of scope here
This file is so short. Heh. I mean I added comment headers for everything in there, and am about to add how to generate a global gitignore, but still. I can't believe how bloated it got across the libs over time.
Hmm. Yeah, the patcher doesn't touch the bundles, and they could be different, though they might want to be edited as well, while we're in this.
Windows and Linux don't add any stupid files, right? Only MacOS does that?
I would think it's safe to not include bundles then. I don't know js well enough, but I can't see it being needed in the cookiecutter-generated gitignore
This will be the cookiecutter-generated gitignore. Not the actual cookiecutter one.
Right, that nuance get's confusing. I still think that holds
🙂 I can see that.
it's only a monday and my mind is melty. It's going to be an interesting week ahead of me.
I don't know about windows vs linux, I don't notice weird temp files being generated on linux though (but I'm unobservant so someone else should weigh in)
I think it's only Mac.
Explanation make sense? ```# If you find that there are files being generated on your machine that should not be included in
your git commit, you should create a .gitignore_global file on your computer to include the
files created by your personal setup.
First, create a .gitignore_global file somewhere convenient for you, and add the rules for the files you
want to exclude from git commits.
Second, congfigure Git to use the exclude file for all Git repositories by running the
following via commandline, replacing "path_to_your" with the actual path to your newly created
.gitignore_global file:
git config --global core.excludesfile path_to_your/.gitignore_global```
every library includes that instruction in the "building locally" section:
python3 -m venv .env
so I think .env should be in it since we make people create it
Oooooh you are correct.
Agreed entirely.
I had forgotten about that bit.
Thanks, Neradoc.
https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files has pointers to some common lists, including https://github.com/github/gitignore and https://gitignore.io (!).
Yeah. I have that page open.
note that the global gitignore file does not have to be called .gitignore_global.
These instructions need to be short. Should I include that?
It can be called whatever you want it to, as long as you change the command to match.
But that bloats the instructions a bit.
"called, say, .gitignore_global." Windows used to have trouble with files with leading dots, I'm not sure if it still does
Oof. Ok. I'll have to specify the command needs to match the filename as well.
looks like it is not a problem anymore. OK, never mind
Oh. Oki.
I used to have to do _emacs instead of .emacs, but that is from years ago.
Fair enough.
out for food shopping
Oof, that gitignore.io site produces HUGE files, like instead of .idea, it includes literally everything possibly contained in the .idea directory listed out separately.
Apparently build/ is a Python thing.
gitignore.io did not look that helpful to me either
But the Python list included eggs which, afaik, is a PyPI thing. So who knows.
Any other comments on these instructions?
"congfigure"
Thank you. It's not showing misspelled words though it usually does.
I think it doesn't really know what to do with this file. other than comment highlighting.
I would be prescriptive, say: "Do not include files and directories created by your personal work environment, such as the IDE you use, except for those already listed here."
something like that
Ok. That sounds good.
ok now really going
Is it something weird about cookiecutter that makes it not show me a diff on the modified .gitignore file within the repo generation code?
git diff returns nothing. I tried from both the main dir, and the same dir as the file.
OK, weird, now it's returning updates made to the file since git add. Bleh. Shrug.
Oh, now it's working. Must have been something to do with adding it before diffing it.
¯_(ツ)_/¯
On this board the 'effective' watchdog timeout values are slightly above 1, 2, 4, 8, and 16 seconds; values are rounded up.
maybe you wanted git diff --cached ?
It's possible.
otherwise diff diffs between the staged (added) files and the current files
good to know.
Was going to ask for another look at the .gitignore file, but I suppose the PR is as good a place for that as any.
For anyone who is interested: https://github.com/adafruit/cookiecutter-adafruit-circuitpython/pull/179
Is there a process or best practice for taking the changes made to the Adafruit libraries and applying them to community libraries like these changes to .gitignore?
Not at the moment! If we think it should be the same across community libraries as well, this one would be an easier one to do since it's replacing an entire file, vs changing parts of an existing file. But our Adabot patch system doesn't handle the Community bundle, unfortunately. Which is what we use to update the Adafruit libs.
Once it's merged to cookiecutter, we can discuss applying it to the Community Bundle if everyone agrees. Or we can have maintainers update it as desired.
I knew adabot doesn't handle them.
That's part of it, is that they're all maintained by individuals, who may not want the update, necessarily. Cookiecutter will generate it for new libs though.
I know there are other changes that I haven't kept up on like changes to CI (black/click version, etc...)
Understood.
This is definitely something worth discussing with the group. We could try to come up with something to at least notify folks maybe? I don't know how difficult that would be though.
Image for espressif_esp32s3_usb_otg_n8 already existed, I just forgot to add the board file.
Thanks and I agree. I was just making sure there wasn't something in place that I had missed
Kind of like Dependabot, but not so integrated.
Ah fair enough! You're not missing anything.
update: With the above sketch, as I mentioned it did not work from 1->2->1... But did 1->3->1 and 1->5->1...
Have not tried all of them.
So first thought is one or more configuration issues with the pins or uart.. But nothing changed in those areas as far as I can tell, and it looked like it should be setting the pins in to the correct MUX setting as well as the proper Input select value...
So: I wonder what might be not working RX or TX... so connected up Logic analyzer to pins 0, 1,...
@idle owl just to chime in, git core.excludesfile has a default location $XDG_CONFIG_HOME/git/ignore aka ~/.config/git/ignore. Folks that use that location don't need to configure it explicitly at all
Thanks for the input! I'll think on whether it makes sense to include that or not. I got those instructions off of the Git documentation site, though I'm pretty sure they cover that option as well further down the page. I'll see if I can include it and keep it concise. Thank you again!
Make that from the GitHub documentation.
And I'm wrong, they don't cover this.
yeah, the GitHub documentation seems to be old or conservative as it doesn't mention $XDG_CONFIG_HOME at all, but that makes sense as it's relatively recent
some tool/apps are more or less aggressive about migrating to it.
Ah it's a newer thing? (I guess you essentially said that.)
'relatively' i think the XDG standard has been around for at least 10 years now, but lots of software is much older and slower moving
it's ~/.git
I don't have that either.
Looking in the Circuitpython\ports\mimxrt10xx\supervisor\print.c I see:
// TODO: Switch this to using DEBUG_UART.
// static LPUART_Type *uart_instance = LPUART1; // evk
static LPUART_Type *uart_instance = LPUART4; // feather 1011
The only change I see in blame view mode is the TODO line, but now to see who might be calling
port_serial_write_substring(...)
I thought that was a variable to be replaced by the user with their home directory. I didn't realise it was an actual thing.
it's a variable in that it can be redefined where the user wishes, but ~/.config is the default value if undefined
Ahh. Ok.
an overview of the standard, and which apps are compliant with it https://wiki.archlinux.org/title/XDG_Base_Directory
Thanks!
CircuitPython version
Adafruit CircuitPython 7.3.0-alpha.0-38-g862210b3f-dirty on 2022-03-24; Adafruit Feather M4 Express with samd51j19
Code/REPL
import board
import busio
spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)
Behavior
After a soft reboot:
Traceback (most recent call last):
File "code.py", line 4, in
ValueError: SCK in use
The only way out at this point is power cycling as I cannot init the SPI b...
CircuitPython version
Adafruit CircuitPython 7.2.4 on 2022-03-31; Adafruit PyPortal Titano with samd51j20
Board ID:pyportal_titano
PWM frequency testing with 3.5"TFT FeatherWing:
Adafruit CircuitPython 7.2.0 on 2022-02-24; Adafruit Feather RP2040 with rp2040
Board ID:adafruit_feather_rp2040
Code/REPL
display.brightness = 0.4
Behavior
screen contents not visible
Description
Display brightness for the Titano only works for an off-to-b...
What else are you doing with it ? Are you setting up a display ? If so, you need to use displayio.release_displays() first, or the display and SPI bus are retained so it can show the REPL when the board reloads.
@tannewt
I believe the issue has to do with the change:
https://github.com/adafruit/circuitpython/commit/f5d90fc84f001cfd9fa46bbbdcd0af9e8dffe43d#diff-f03765ae6bb99c05c83b89eab7e1043f8083b00003434e5980c8d38f8906dd71R291
With the changes to supervisor\shared\serial.c which now the serial_write_substring is calling:
port_serial_write_substring(text, length);
Which the version in that file is weak and as such the one in the port is being used... And for the T4.x is UART4.
In my full code I did displayio.release_displays() albeit not before setting up SPI but before creating the display.
When I put displayio.release_displays() in the minimal code example above, and before setting up SPI, it seems to solve the issue.
Interestingly, I did not have this problem while using i2c, only when I switched to SPI.
Thank you!
More precise reporting of #6219. This is not really related to #6213 after all.
Running this on or after commit 749bb99863e54e13c130d833b42adab654a86c90 (between 7.2.0-alpha.1 and .2), and then touching the RX pin, will cause a hard crash of some kind.
That particular commit updates the pico-sdk to 1.3.0.
import board
import busio
uart = busio.UART(board.TX, board.RX)
uart.baudrate = 115200 # _might_ make it easier to provoke
i = 0
while True:
data = b'..........
Fixes #6213 by not calling gc_free() on the ringbuf buffer, since ringbuf_free() may be called after the VM has stopped running. Instead, just rely on gc to free the buffer, if the VM is running.
Removes the heap struct field, since it's no longer needed.
This is not related to #6237, even though it seemed that way for a while.
LGTM! Checked the datasheet.
Thanks!
I thought I fixed the issue of handling zero bytes returned from the stream, though. What is an example of code that is doing the wrong thing?
Yeah, I'm not sure why this worked, but it did!
We also had other, similar problems that I could only fix with pragmas: https://github.com/micropython/micropython/commit/dc91024a7312894997020e57502cccf0ebbca4ff
@jwfmcclain Did you see any issues yet? Maybe no new is good news :) .
Got to Blynka!

The REPL and Blynka logo are working. The image is offset due to some timing weirdness that shifts the screen whenever CircuitPython does some processing, or if you type in the REPL (see previous update).
Todo: When the code finishes, the display goes weird, doesn't update anymore and doesn't show the REPL.
@tannewt @jepler @mjs513
I was able to make the code work correctly, by not having the Serial port stubs be created.
That is in the file: circuitpython\ports\mimxrt10xx\supervisor\serial.c
Right below the comment I added an if:
// TODO: Switch this to using DEBUG_UART.
#if defined(USE_DEBUG_PORT_CODE)
// static LPUART_Type *uart_instance = LPUART1; // evk
static LPUART_Type *uart_instance = LPUART4; // feather 1011
// static LPUART_Type *uart_instance = LPUART2; // feather ...
Enable support for extended HID usage page and usage. Related to Support HID Usage Pages and Usages >255 #5529.
Also added suppression for array-bounds warning to enable mpy-cross to build on Mac.
I think I created the pull request correctly (see above https://github.com/adafruit/circuitpython/pull/6239). Let me know if I need to try again :-)
Thanks!
I thought I fixed the issue of handling zero bytes returned from the stream, though. What is an example of code that is doing the wrong thing?
Fixes #6237.
Between pico-sdk 1.2.0 and 1.3.0, the RP2040 RT UART timeout interrupt was enabled as part of uart_set_irq_enables(). See https://github.com/raspberrypi/pico-sdk/issues/500 and https://github.com/raspberrypi/pico-sdk/pull/504. Our code did not know this interrupt was now enabled, and did not clear it in the interrupt service routine. Random noise on the RX line could cause this interrupt to be triggered, and once triggered, it was not cleared if the data was not read, and...
Card library for Circuit Python
Advancing the cache ID fixes the espressif build issues, so merging this first to get that fix in.
Build failures are CI - not related to PR.
CircuitPython version
Adafruit CircuitPython 7.3.0-beta.0-2-g87e59a444-dirty on 2022-04-04; Teensy 4.1 with IMXRT1062DVJ6A
Code/REPL
import time
import board
import busio
import supervisor
from digitalio import DigitalInOut, Direction, Pull
led = DigitalInOut(board.LED)
led.direction = Direction.OUTPUT
check_pin = DigitalInOut(board.D2)
check_pin.direction = Direction.INPUT
check_pin.pull = Pull.DOWN
uart1 = None
last_check_value = check_pi...
This is a duplication of my post in the Adafruit forum,
maybe it is better located here...
I am almost ready with a product containing a ItsyBitsy nrf52840.
It is a braille keyboard for blind users to connect to IOS devices.
We initially want to build a small production run.
Regardless of the number of products brought to the market we need a CE certificate in Europe.
(Similar to FCC in the US.)
For CE RED and EMV testing, the laboratory tells us that we need to bring the nRF52840 ...
This looks good! I will make the one change noted and then re-run.
This was fixed in #6231 so we can take this back out.
I fixed a minor build problem to make sure this works for all builds including espressif. Will merge when done.
Made draft pending #6223 resolution.
Merging this to get it in. Will revisit if necessary.
@gamblor21 is this self-contained as it is? Should we go ahead and merge this to get part of the functionality?
If you could make an issue (or edit an existing one) with a task list (use [ ] in a list to allow checking off done tasks), that would be great.
Would be great to have the Teensy Micromod working on this as well.
Will play with it some,
but not sure what PID/VID to use?
I noticed that the Teensy 4 and 4.1 have an Adafruit VID...
Let me know what you think
We used to give out PID's, but stopped because either the manufacturer or pid.codes are the best sources for non-Adafruit boards.
@onyx hinge I labelled four PR's with 7.2.x milestones. I think they are all we want for bug fixes for 7.2.5, so once they are approved and merged, I can make another release, and you can finish the 7.2.x -> main build. I could make another beta at that time.
Good morning. I'll look
Thanks! If this tests out OK it seems like the simplest and therefore relatively safe fix.
@tulip sleet I can mash 'merge' on those PRs if you like, they were very simple and to the point.
Sure, thanks! go ahead, I did test them both. There is a big backlog of builds now
I will be out for a while early afternoon, will try to do releases after that, after things have caught up.
should we cancel some of the older 7.2.x branch builds?
you mean the merge builds? We now have auto-cancel, which cancels and restarts if there is a new push.
it's great! Thanks to microdev for that
I thought you closed it by accident. No matter.
I think I accidentally force-pushed the branch until it was even with master, which caused github to close it.
ports/atmel-samd/mpconfigport.mk:ifeq ($(TRANSLATION), ko)
``` interesting, I just noticed that the code to exclude the fonts for these translations is port-specific
the "ja" translation has 454 distinct glyphs but tilegrids have only 256 distinct tiles so it can't be displayed even if the font fits in ROM
(well, for some specific build it has 454 glyphs, it probably varies according to features)
Due to #6149 a tilegrid can only display 256 distinct tiles. However, the ja translation has many more. For instance, the adafruit_feather_rp2040 build ends up with 454 distinct tiles. As far as I can guess, this means that the displayio terminal will show those values above 256 incorrectly as one of the first 256 shapes.
That's not to say we shouldn't improve tilegrid in the future!
@guighub can you please post complete code to reproduce the problem?
@tulip sleet curious what the lock is guarding against here. ```void common_hal_keypad_keymatrix_reset(keypad_keymatrix_obj_t *self) {
const size_t key_count = common_hal_keypad_keymatrix_get_key_count(self);
supervisor_acquire_lock(&keypad_scanners_linked_list_lock);
memset(self->previously_pressed, false, key_count);
memset(self->currently_pressed, false, key_count);
supervisor_release_lock(&keypad_scanners_linked_list_lock);
doesn't scan happen via background task? or is it via irq/timer?
it was against another keypad scanner being added to the list while a scan was in process. Maybe it is not necessary.
i might have written it thinking that something might be done at interrupt level
there were many versions of the code
or maybe removed from the list
.reset() doesn't clear the event queue too?
@ladyada @dhalbert - Actually Adafruit does sell Teensy boards ;) Although maybe not the Micromod version.
what is not completely clear to me, is the relationship of the PID/VID while running CircuitPython versus running something different, specifically with a Teensy.
For example I looked up a different MicroMod board, From their Arduino boards.txt
micromod_samd51.name=SparkFun SAMD51 MicroMod
micromod_samd51.vid.0=0x1B4F
micromod_samd51.pid.0=0x0020
micromod_samd51.vid.1...
Yes, we sell Teensy's :slightly_smiling_face:, but we refer people to PJRC sources for other than simple support.
We use separate PID's for the bootloader, for a running Arduino program, and for CircuitPython, to make it easier to identify what the board is running. Arduino cares about this, and some other programs do too. We used it to help Mu identify boards for a while, but now we identify based on the USB device interface names.
we require unique VID/PID for bootloader vs running circuitpy vs other runtimes. we used to not require it but had windows OS lockups.
the manufacturer (SFE) has a VID, you can ask them for a PID - they have approx 65000. or PJRC can provide one as it is a licensed device. that way it will pop up as a SFE or PJRC device, not an Adafruit device (since we do not manufacture or design or license the Teensy)
The CI jobs vary about which versions of typer and click they are loading, which is causing failures. The most current versions should be fine.
weird, how is that happening? is pypi not serving up the same versions everywhere?!
wow the versions are WILDLY different. ```['adafruit-circuitpython-busdevice-5.1.1', 'awscli-1.22.38', 'botocore-1.23.38', 'charset-normalizer-2.0.9', 'cryptography-36.0.1', 'jmespath-0.10.0', 'pyOpenSSL-21.0.0', 'pyftdi-0.53.3', 's3transfer-0.5.0', 'tomli-2.0.0', 'typer-0.4.0', 'urllib3-1.26.7']
['adafruit-circuitpython-busdevice-5.1.8', 'awscli-1.22.88', 'botocore-1.24.33', 'charset-normalizer-2.0.12', 'cryptography-36.0.2', 'jmespath-1.0.0', 'pyOpenSSL-22.0.0', 'pyftdi-0.54.0', 's3transfer-0.5.2', 'tomli-2.0.1', 'typer-0.4.1', 'urllib3-1.26.9']
i am baffled. I thought it was GitHub at first, but it seems like pypi is going a bit crazy
pyOpenSSL-22.0.0 was released January 29, so some database seems to be serving up months-old versions instead of new ones. does pypi have a status page?
https://status.python.org/ yeah something's going wrong
Welcome to Python Infrastructure's home for real-time and historical data on system performance.
Monitoring - Applications are coming back online and we are monitoring for stability.
Apr 5, 15:41 UTC
Identified - Core failed service has been identified and is coming back online. Next we'll bring up the ancillary services. Once all our automation services are online we can begin to bring the applications back.
Apr 5, 15:38 UTC
Investigating - All backend services for PyPI are down due to a cascading failure in our deployment tooling. We are investigating and working on restoring service.
Apr 5, 15:25 UTC
yeah bad news
I will do merges when things finish, but I won't start release builds until this is fixed
Oof.
@idle owl I have created a new (currently hidden) page in the sharing a library guide and compiled together all of the notes and other typing related things that I know about: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/typing-information It's not quite done yet. The two things I know for sure that I still intend to add are an example of the typing import with the try/except that we use, and a section that explains Union, Optional and similar other typing helpers that get used sometimes.
When you have a moment if you'll take a look at what I have so far and let me know if you have any feedback.
There is likely some copy editing that could be done to improve things but I want to make sure everything so far is headed in the right direction and see if there is anything else specific you can think of that would be good to add to it.
Thanks so much! I'll take a look once I finish what I'm working on right now 🙂
Actually a 3rd thing that I plan on adding comes to mind now as well: A section that talks about how to find the correct types. I will explain the process of looking in the code and examples or other usages for clues about what the proper type is and also show how to use type() in REPL or in modified library code to check on actual types being used.
This all sounds great
I suppose I should test this code I'm working on, next. simplifies and drops 600 bytes of code (in a non-LTO build) from keypad. but of course maybe it's so much smaller because I deleted something and didn't put it back 🙂
I don't know if i have the full code anymore, but if i can find it I'll post it here.
Issue #6148. Since the re-doing of Espressif GPIO resets done as part of PR #5892 the voltage monitoring done on the MagTag by pin GPIO4 has been always returning high values. This fix avoids resetting that pin on the MagTag and allows correct readings of the voltage.
Approving in advance.
I'm happy if this fixes a problem .. but .. it would also be interesting to know what's different about ADC on a pin that has been 'reset', because if we understood that maybe we'd get better ADC behavior on all pins.
greps log files
@dhalbert -- no sign of the problem with the 7.3.0-alpha.0-63-g372306411-dirty build
Thanks
Configuring this in boot.py definitely makes sense. As far as I can tell, what is missing is just a python API for setting/overriding USB_VID, USB_PID, USB_PRODUCT, USB_MANUFACTURER; probably in the supervisor module.
It's interesting that usb_build_device_descriptor already has parameters for setting USB_VID and USB_PID at runtime, but it is only ever called once (and with static arguments).
These values could be non-const variables that can be updated (in RAM only) w...
@tulip sleet When you're available, I'd appreciate a final review of this code: https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/2135 (No functional changes, only variable name changes.)
This adds supervisor.set_usb_descriptor_overrides(manufacturer: Optional[str] = None, product: Optional[str] = None, vid: Optional[int] = None, pid: Optional[int] = None) -> None:
This function can be called to override the build-type settings for USB_VID, USB_PID, USB_MANUFACTURER_NAME, USB_PRODUCT_NAME for the next boot process from boot.py.
Closes #4404
Once that PR is merged, the next step is to add it to a board guide and fill it in. I'll have you review it for accuracy before Anne and Limor.
@lone axle If one wanted to load a Community library onto a Pi for use with Blinka, how would one go about doing that? Do a pip from within the library directory or something? I have someone on the forums asking about it. If you know, do you mind replying?
I at least assume that's what this person is trying to do.
I doubt they're using bare metal.
Mostly because most folks are using Blinka.
There are a few possible ways, but pip install is probably the easiest if they already have pip set up on their pi (which they should if the followed the setup guide for Blinka/Pi)
and yep link me and I can respond.
They do apparently.
Thanks so much! @lone axle https://forums.adafruit.com/viewtopic.php?f=60&t=189997
you have to look at the library to see if it is on pip to begin with
They tried pip, couldn't find it.
@onyx hinge As everyone else is gone or idle, I'm pinging you with this one. nRF board question. On reset, begins by flashing yellow to allow for entering safe mode, then blue to allow for entering pairing mode, before fully booting into CircuitPython. Press reset during blue, what should be happening here? The LEDs flash again, but there's a moment of solid blue that time, and then in a VERY short period of time, it goes back to running CircuitPython code. That doesn't seem right. Updated to 7.2.4, and tried on CPB and CLUE, same behavior.
I feel like I remember pairing mode lasting a lot longer than that. As in... long enough to actually pair and remain paired.
it's on for good once you reboot in pairing mode
No... it's not. Not right now, anyway.
well it should be
It almost immediately bounces back to running code.
yes but the pairing is on
Ok.... I'll try again.
I'm glad neradoc is answering because I don't know
or it should be
Ok, it paired properly that time. I think.
The app isn't seeing it now, but that's a separate issue.
OK, thanks @jaunty juniper. I guess it was a me issue. That's what I get for not assuming that this time, like I usually do.
I guess we need to document that somewhere unless we did and I missed it. Which is probably the case. Because that is confusing.
To me anyway.
it might be flaky, it's bluetooth after all 🤔
Also valid.
I guess I was expecting it to keep flashing blue or be solid blue until it paired. That was my mistake.
the LED codes probably are all different since the last time you did it, and guess who gets to make sure the guides are clear !?
if you had a mirror you'd be looking at her
it might be clearer if booting in pairing mode made it wait until you connect to it with an app, while (!Serial) style
Also doesn't help if I can't figure out what is actually happening. Can't update a guide without the right info.
I actually know what you're referring to!
like doing the reset dance is an intentional action at a point in time, you then know to connect to it, while putting it in pairing mode is a mode that is otherwise invisible afterwards (outside of scanning with the app when BLE is in a good mood)
I'm certain Scott has Opinions about this, and its current behavior is probably what he wants.
ValueError: IO44 in use
Hmmm I wonder why this happens. Maybe it's because I made a debug build, and this is one of those 'shared with jtag' pins? That's my current theory.
rebuilds circuitpython
yup that was it
This saves 444 bytes on the pygamer build (both commits taken together)
testing performed:
- pygamer (samd51) with ShiftRegisterKeys
- macropad (rp2040) with Keys
- UM feather s2 (esp32-s2) with KeyMatrix
Result:
- all ports still worked nicely
- keys held down at start always registered (>2 trials all boards, >100 trials esp32-s2)
- keys held down are immediately registered after reset() (>100 trials esp32-s2)
- double .reset() is OK, accessing .events throws (only tested...
@lone axle Wow this page is beefy! The only suggestions I have are nitpicky formatting things. I think when referring to Python, it should be capitalised at all times. As well, I think it's ok in this case to use the Heading 1 for the ones you have a Heading 2 on currently, and Heading 2 for all the current Heading 3s. That will make all headings linkable, which I think might come in handy. Otherwise, other than me not knowing accuracy because I don't know typing information all that well, it looks great to me!
Thank you! Appreciate the feedback I'll incorporate that stuff when I get back to it.
Sounds good!
CircuitPython version
Adafruit CircuitPython 7.2.0
Code/REPL
import digitalio
import busio
import board
from adafruit_epd.epd import Adafruit_EPD
from adafruit_epd.il0373 import Adafruit_IL0373
# create the spi device and pins we will need
spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)
ecs = digitalio.DigitalInOut(board.D12)
dc = digitalio.DigitalInOut(board.D11)
srcs = digitalio.DigitalInOut(board.D10) # can be None to use inter...
I think it is that the resets now set the pin to be an output with a pull-up, instead of an input. @tannewt did that in Perhaps the change should instead be that we make sure to undo the pull-up when setting up AnalogIn. https://github.com/adafruit/circuitpython/pull/6057. @DavePutz, I think maybe that is the better fix.
@idle owl @jaunty juniper The point of the blue delay was not to enter pairing mode, it was to erase the pairing info. You can also do that by _bleio.adapter.erase_bonding(). I will double-check to see if anything has changed about this. It is explained in this diagram, from here: https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#circuitpython-7-dot-0-0-and-later-2978455-21
"Pressing reset during the BLUE blinks will clear Bluetooth information and start the device in discoverable mode" so kinda both?
This is for use with PyLeap, no one is going to add _bleio code to make it work with PyLeap. Defeats the purpose.
that is the most correct, the lack of bonding info makes the host say, "do you want to connet with this"
Hmm ok.
oh wait, you can connect at any time with the App once it's bonded, even if you power cycle it ?
anyway, sounds like timing is messed up
some connections require bonding, like HID mouse and keyboard
i have not used PyLeap enough to know, but I think so too, so you can use it in a classroom
I've been resetting it with the button, and it remains known to PyLeap, but that's not power cycling.
It pops up a "Do you want to connect to CIRCUITPYfoo1" that you have to say yes to when first using it
I'm not sure it is. I think it might be ok. I think the whole thing might have been a me-issue. Not understanding what was going on.
But maybe I'm now simply used to what it actually is doing, so I don't take issue with the timing. Because I had to make it work.
so blue reset makes it discoverable, which is required to pair it with pyleap, but it also erases all bonding, including bonding made through python ?
yes, it erases all bonding info
Which is awkward with PyLeap, because there's still an issue where you have to manually go in and "Forget" the device if you have to repair it at any time, or it won't connect. They're working on trying to fix it, but it might be an iOS thing.
this is in supervisor/shared/bluetooth/bluetooth.c
I'm not suggesting changing the behavior, simply relaying semirelevant info.
there is a yellow blink for safe mode and a faster blue blink for "clear bonding and get into discovery mode". After you click reset during blue, the next time around (because it's a reset), I think it does not wait and show 1sec of blue
It shows some period of solid blue before code runs.
the first time or after pressing reset?
Following pressing reset during flashing blue.
yes, it takes a bit of time to do the discovery
So flash blue, hit reset, starts up, some period of solid blue after whatever, and then code runs
But if you're not looking for it, it's easy to miss, I think.
yes, that's what I see, but only after reading the code. Perhaps there needs to be a fuller explanation somewhere
Probably something like that.
I'm not sure how things like this will be explained in PyLeap.
There's a mini tutorial if it can't find your board, which could include this.
They're updating it soon. So I will make a suggestion now.
Once I find out where to leave suggestions. Since they're not bugs. 😄
https://docs.micropython.org/en/latest/library/micropython.html#micropython.opt_level do we specify any optimization level with mpy-cross? I was looking into whether it is possible to have mpy-cross eliminate if typing.TYPE_CHECKING: ... blocks but that involves changing the compiler so it can (A) assume TYPE_CHECKING is false and (B) enabling at least optimization level 1, which also deletes asserts. Going up to optimization level 3, which removes line number information, could be a memory savings to consider taking on samd21 builds with frozen files.
(part "A" is a big TODO too)
I can confirm the code now passes without error with #6233
For instance, with a change to adafruit_requests (an example more complex than most! and not on the most memory-constrained builds) it decreases the mpy file size from 9196 bytes to 7878 bytes.
diff --git a/adafruit_requests.py b/adafruit_requests.py
index 4c046ad..74a9a22 100644
--- a/adafruit_requests.py
+++ b/adafruit_requests.py
@@ -33,20 +33,16 @@ license='MIT'
"""
+from __future__ import annotations
+
__version__ = "0.0.0-auto.0"
__repo__ = "https://githu...
If user code uses the TYPE_CHECKING identifier for any other purpose, it would change the meaning of the code. However, like True/False/None, this is not likely to occur on purpose. Unlike True/False/None (being converted to non-identifier tokens) the problem would pass without notice, except that TYPE_CHECKING would always be treated as False.
does that include adding a typing library ?
there's a "postmortem" of the pypi outage. https://status.python.org/incidents/mxgkk3xxr9v7
@jaunty juniper yes it adds a typing module with the only member TYPE_CHECKING and the value False
that reminds me, is supporting blinka on Micropython a goal ?
I was under the impression that it worked, though I don't know to what extent.
like, currently when I tried to install the files on a pico, there was not enough free space on the drive
@onyx hinge I am confused about your TYPE_CHECKING PR, could I ask you some q's?
@tulip sleet it can wait, we're going to start making dinner in a second
sure
I don't blame you for being confused, my ideas come out of left field sometimes
the original goal of Blinka was to support MicroPython! (if I remember right). That quickly morphed into SBC's, and MicroPython fell by the wayside.
It's still a goal, but a minor one
and for example are we actually using __future__ now in libraries, which is not in MP ? and typing is not on MP either
from __future__ import typing is not a thing in CPython. I am not sure we should do it this way.
We want the code to be compatible with CPython
I added from __future__ import annotations because that is a thing
for the drive space issue, I was wondering if yould be relevant to some CI make a micropython release of blinka, with most boards definition files pruned (or if it could be installed like that with upip)
yes I mean from __future__ import annotations, it's not in MP
(but the new PR is from __future__ import typing)
from typing import TYPE_CHECKING
yes, a pruned version of blinka makes sense, but we have not done such pruning yet. We talked about doing it for some frozen libraries (like the CP library), but didn't come up with a satisfactory solution yet
I think there may be a simpler way of doing this, without needing to add new features
try:
from typing import TYPE_CHECKING
except ImportError:
TYPE_CHECKING = False
# ...
if TYPE_CHECKING:
# guarded import code
The if TYPE_CHECKING: should then be optimized at compiled time.
from __future__ import typing does not exist in CPython. I don't think we should add such an incompatibility.
The module is named __future, but the doc says it is typing.
please try very latest version of cpy, in case something got fixed recently
This is normal if it happens on reload. The SPI is retained by displayio when you setup a display, so that it can be used to show the REPL when the code ends or reloads. You need to execute this before initing the SPI line.
displayio.release_displays()
See example here:
https://learn.adafruit.com/adafruit-2-9-eink-display-breakouts-and-featherwings/circuitpython-usage#grayscale-display-usage-3102538-29
(A better place for support issues is [the forums](https://forums.adafrui...
I am working on a different fix with the same effect.
yes, should have been `from future import annotations
@Neradoc i dont think this is the displayio driver, its the framebuf one
Closing this up, as
try:
from typing import TYPE_CHECKING
except:
typing = const(0)
does nearly as well for reducing size as this patch.
note that const(False) isn't permitted.
sorry for making you waste brain cycles on that Dan, except that obviously I wasn't going to come up with the try/except variation myself
np, I get bad ideas when my blood sugar is low too 🙂
i think it was a good bad idea
the motivation is excellent
Hi! I have a question about pylint CI. I just submitted a PR on this library and it's complaining about Module 'struct' has no 'unpack' & Module 'struct' has no 'pack' on code I did not touch. https://github.com/adafruit/Adafruit_CircuitPython_BLE_Apple_Notification_Center
I don't see that; I just see that it failed black formatting. Have you been using pre-commit? https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/check-your-code
I just ran into this TileGrid limitation yesterday as well and looked into the code and came to the same conclusion about the 255 limit. Thank you for adding some mention of it to the docs.
It might be worth documenting this limit on the __setitem__ docstring down here as well: https://github.com/adafruit/circuitpython/blob/359d8e57730a8c9a68fd5429691f5825bdc3cf61/shared-bindings/displayio/TileGrid.c#L389
yep
I was hoping there was something wrong with my pylint setup and CI would be different
I used to get that locally until I uninstalled an older version
make sure black is up to date, should be 22.3.0 or so
I am at 22.3.0 yes
older version of pylint? @devout jolt how about version of pylint?
but why is it failing in CI then too?
because your pre-commit formatted it with the old black?
and that's what you comitted?
maybe pre-commit autoupdate ?
would fix things
I do not understand. shouldn't it be checking the files with its own version of black? And it's failing on code I did not touch. And it's saying "pack()" is not a member of "struct"
that (the pre-commit cache thing) was for your fail on struct, CI doesn't fail on struct
I cannot tell why CI failed, can you? https://github.com/adafruit/Adafruit_CircuitPython_BLE_Apple_Notification_Center/runs/5842541346?check_suite_focus=true
yes what is the failure?
yes but why?
because the files were not formatted to its liking
because your pre-commit is running an old version of black, per Neradoc
so you formatted it the old way, and it wants it the new way
sigh okay. lemme try again. Is it standard practice to always have to pre-commit autoupdate before pre-commit run --all-files to catch whatever the formatting-du-jour is? I don't have a good feel for the standard dev cycle here
black hasn't changed its mind in a long time. This is new.
i agree with you that pre-commit could do a better job. They have some philosophical issue
about versions
I notice in the commit log for that library there were some black updates in the pre-commit-config.yaml but I assumed that would be taken into account by pre-commit
the way pre-commit works is a mystery to me, it looks like it runs its own installs of the tools it uses with the appropriate version from some cache, but the details are a mystery
did you get your version up to date so your .pre-commit-config.yaml was the same? I don't know whether that helps
yeah it was a fresh checkout
anyway, did it reformat now after pre-commit autoupdate or removing the cache?
okay after doing the following:
rm -rf ~/.cache
pip3 install pylint --upgrade
pip3 install pre-commit --upgrade
brew upgrade black
pre-commit autoupdate
pre-commit run --all-files
I get:
does that mean it worked? it doesn't match CI
oh I have unstaged commits now. wow I guess I never focussed on the fact it REWRITES my files
let me force a re-run of the CI, in case it was the pypi issue
hold on
yeah, usually you do git commit, and it prevents that if something is wrong
I must say, I very much dislike how black reformats some things but this isn't my house 🙂
we don't like it sometimes too, but consistency is better. pylint is lot more of a nuisance
Agreed. Thank you all for the help. Sorry if I was cranky
well, it was very much not jiving with your expectations
whelp, it passed CI so looks like my offerings were accepted
I have learned how to force black to leave my lists one item per line even when they are small (ending comma), so I feel like I have the power now
Automated website update for release 7.2.5 by Blinka.
I added a PR for an auto-deploy feature for Piku if anyone is interested in testing or reviewing that would be welcome.
I think there are two problems here:
- The default pull-up on the pin pulls the voltage to the wrong value.
- The impedance of the voltage divider that's checking the voltage is very high. It's two 1Mohm resistors, with a capacitor across one. So once the pin is set up for ADC, it takes a while for it to get to the right value.
Here is a test program running on CircuitPython 7.2.3, with no fixes. Notice the voltage is wrong to begin with, moves down, and then stabilizes. But it takes a...
@danh, I was wondering if pins other than the GPIO4 used for the voltage monitor would have similar issues when used for ADC readings. If so, then disabling the pullup in the AnalogIn constructor might be the only solution. Also, would boards other than the Espressif boards have the same problem?
[btw @ danh on GitHub is someone else, not me; I am @dhalbert]
I was wondering if pins other than the GPIO4 used for the voltage monitor would have similar issues when used for ADC readings. If so, then disabling the pullup in the AnalogIn constructor might be the only solution.
I tested other AnalogIn pins, just floating, and I don't see this problem. Even without disabling the pull-up, their values are near zero. I think maybe the cap on the voltage divider is a big culprit here....
@gamblor21 is this self-contained as it is? Should we go ahead and merge this to get part of the functionality?
Yes this should be fully self-contained. Worse case if I missed something CIRCUITPY_ZLIB=0 will quickly turn it off.
If you could make an issue (or edit an existing one) with a task list (use
[ ]in a list to allow checking off done tasks), that would be great.
Will do in the next day or so.
The display shifting bug I observed above has a similar behavior as that described here: https://github.com/espressif/esp-idf/issues/8381
Keep an eye out for when the updates get back ported into the 4.4 version, see this issue to track it: https://github.com/espressif/esp-idf/issues/8620
Awesome! Thank you Dan for resolving the issues to get this merged. Your efforts made it easy for me to contribute to this project.
As the title suggest this adds support for or 4MByte flash versions.
Working on WIO Terminal eRPC support, and I've found that busio.UART doesn't implement RTS/CTS yet. Anyone know if this is just a to-do thing or if there was a deeper reason? Based on the SAMD datasheets it seems like RTS/CTS flow control should be implementable as there's hardware support for it in the onboard USART.
The atmel-samd port implementation of busio.UART does not currently implement hardware flow control with RTS/CTS. This capability exists at the hardware level (see the SAMD datasheet section on Sercom USART), so I think it should be possible to add support to the port.
I think there was simply no need for it, so nobody worked on it.
So I guess I've found a need (the WIO Terminal's SAMD51 uses a UART to talk to the RTL8720D co-processor and includes hardware flow control to help ensure that eRPC messaging works as needed) and may need to work on it 😉
I finally got around to testing this. It works fine.
Test program:
import adafruit_pioasm
import rp2pio
import array
program = adafruit_pioasm.Program("""
set x, 31
in x, 32
.wrap_target
jmp x--, f
f:
in x, 32
.wrap
set x, 3
in x, 32
""", build_debuginfo=True)
program.print_c_program("test")
b = array.array('L', [0]*6)
sm = rp2pio.StateMachine(program.assemble...
Thanks for this nice refactoring, and fixing the initial state getting.
Been working on adding pan to AudioMixer/MixerVoice. So far it is functional though the algorithm is very basic and may have room for improvement. I've only tested with stereo 16-bit audio on an RP2040 Pico so far. I may just put a conditional in there to only allow this functionality if the self->channel_count == 2 since I assume all channels are in a continuous alternating stream of 16-bit values packed into the 32-bit buffer which I haven't accounted for. Any thoughts on this? I'll be working on some deeper audio processing additions to CircuitPython for personal use, but figured this could be generally more useful in case there's a potential pull request here. https://github.com/dcooperdalrymple/circuitpython/commit/01c8bd673a0675b155645350d7aa131347cba40c
If that's important to you, it's OK and I won't stand in the way.
I merged main and pushed it into your branch. This should resolve the espressif build failures, with luck.
Thanks for taking on this work! A number of people have asked for it.
I made some detailed comments. I would also note that we may want to get this to fit on the SADM21 builds, which are very tight on code space for right now. If that's not possible, we need to make this optional to save the code space.
supervisor is an OK place for this. We are just introducing a usb module for USB host capabilities. Right now it is very host-oriented, but it's possible that this eventually might be in usb.<something> instead of supervisor in the long run.
I am thinking of a name like supervisor.set_usb_identification(), with the same arguments.
Note that vid and pid can't actually take None as an argument. You would get an error if you tried that. So the annotation could be `vid: int ...
Use mp_get_buffer_raise() here to check for Union[str, bytes, ReadableBuffer], instead of checking for str or bytes. For examples, see shared-bindings/wifi/Radio.c. That will take care of the type checking. Validate the length using mp_arg_validate_length_range(), in py/argcheck.c Search for examples of its use. Then you don't need to introduce new error message strings. We try not to include new strings unless we have to.
As you probably know, the descriptor strings are actu...
These take significant RAM and it would be better to allocate them dynamically, rather than use up 256 bytes of memory all the time here. The values are needed after the boot.py VM finishes. There is some trickiness right now about passing dynamically-sized objects across VM's for USB purposes. See main.c; I forget the exact details, but the values needed are basically hoisted up into main.c and saved on the stack temporarily.
There are a bunch of open issues about audiomixer: https://github.com/adafruit/circuitpython/issues?q=is%3Aissue+is%3Aopen+mixer. I was thinking particularly about https://github.com/adafruit/circuitpython/issues/3210 w/r/t what you are doing, but there may be others of interest to you.
https://github.com/adafruit/circuitpython/issues/5136 has some long-term thoughts about audio. Audio support is in general very complicated and timing-error prone, and we think eventually it might be reworked and cleaned up, both internally and in the API.
Thanks for doing the detective work! Opening a PR next would give a good basis for further discussion. Tannewt is out for a few weeks, so we'll probably end up making a decision without him. Most likely, disabling this (with an easy way to re-enable it) is the way to go. Marking the UART as "in use" (so that it can't be constructed via busio.UART or board.UART) when the debug UART is enabled would also be good, because at least you'd get an exception instead of just something that doesn't wo...
Closing in favor of #6241 which has better information. Note that it's always possible to edit the title & initial message of an issue to reflect changing understanding of the problem; doing that or creating a fresh issue are both OK.
@onyx hinge gm - trying to think about #6246. The fix does work, in a slightly accidental way. The alternative is to disable the pullup in the AnalogIn constructor, and document that you should wait at least one second before reading board.BATTERY
I think the pullup should almost certainly be disabled in AnalogIn
measuring across a resistive divider is very common, and the pull-up changes the ratio -- markedly, in this case
the time constant on this particular divider is so long, do you think we should keep the never reset thing also. It works because the pin is not reset with a pull-up elsewhere
someone with a ppk2 could determine the power impact of disabling just that one pull-up
surely it's pretty small
EMC Testmode for nRF52840
this is a duplication of my post in the Adafruit forum,
and in the issues of CircuitPython in Github,
maybe it is better located here...
I am almost ready with a project / product containing a ItsyBitsy nrf52840.
It is a braille keyboard for blind users to connect to IOS devices.
We initially want to build a small production run.
Regardless of the number of products brought to the market we need a CE certificate in Europe.
(Similar to FCC in the US.)
For CE RED and EMV testing, the laboratory tells us that we need to bring the nRF52840 into an EMC-Testmode
In the Nordic nRF52840 SDK documentation I found this:
https://infocenter.nordicsemi.com/index ... erial.html
Here are my questions:
Is anyone here aware of this mode?
Can this mode be "activated" from CircuitPython? (currently, I assume not!)
In an ideal world, I would like to see a library with a function settestmode(mode) that would activate the different modes.
After this call the nRF Chip would be probably unusable for CP until the next boot...
Can anybody help with creating such a library?
Or where would be the correct place to put such a function into the nRF52840 builds.
I think this would be "a pice of cake" for someone knows how to talk to the SoftDevice of this chip.
could you paste the "infocenter" link again? It is truncated
for this testing, does it need to be running CircuitPython at all? If it's just an EMF test, then could you write a small Arduino program or similar and load it with that?
does it have to be part of the shipping device firmware? exactly what Dan is thinking..
the on-board module itself is CE-certified, so does the whole system need to be re-certified?
No it does not!
Also a "firmware" which just does the test mode would be fine...
The lab tells me, that I need to bring a product which goes into "EMC Testmode Center Frequency unmodulated"
nRF5_SDK_17.1.0 has an examples/dtm folder. It has hex files built for various of their devkits, but perhaps switching that around for the module on the itsybitsy is .. feasible.
are they aware of the pre-certified module?
perhaps Nordic has a standard firmware load already built that can be loaded onto it with SWD. But then the rest of the device would not function
maybe that is OK
The Nordic sales engineering team may be able to help you with this
lots of hits here: https://devzone.nordicsemi.com/search?q=ce certification firmware#serp=2
@domdfcoding you pushed 319ca85 after our discussions of making divisor read-only, etc. What are your current thoughts?
Yes the module is certified, which takes away most of the problems.
But the integration onto a PCB and into a housing needs to be tested.
And yes I do have the certification documents of the module and the
Lab is aware of this.
We do not use the nRF SDK, so linking in the DTM module to CircuitPython would be a major undertaking. A standalone SDK program makes more sense, I think.
(the SDK is not the SoftDevice, I think you know that)
Thank you for the link, and I understand what you say.
since we overwrite the standard bootloader, you may need to restore that to run some other firmware, that is the main nuisance I see
CircuitPython version
Adafruit CircuitPython 7.3.0-beta.0 on 2022-04-01; ESP32-S3-DevKitC-1-N8R2 with ESP32S3
Code/REPL
>>> import board, busio
>>> uart1 = board.UART()
>>> uart1.deinit()
>>> uart1 = busio.UART(board.TX, board.RX, baudrate=38400)
>>> uart2 = busio.UART(board.IO17, board.IO18, baudrate=38400)
>>> uart1.write(b'abcdefghijklmnopqrstuvwxyz')
26
>>> uart2.write(b'abcdefghijklmnopqrstuvwxyz')
26
>>>
Behavior
Wrong data output,...
I talked with @jepler about this, and we decided to disable the pull-up( I added 99dc402), and we'll also keep your no-reset change, so that one need not wait to read the battery voltage. We can change this in the future, but for now, this is the easiest for the end user. Thanks for your work on this.
OK, let's merge what we have and I'll describe it as "preliminary" and/or "experimental". Thanks!
Can confirm quirky behavior on ESP32-S3. I've been running this on two separate N8R8 devices (one transmitting, one receiving) for several weeks:
uart = busio.UART(board.IO6, board.IO7, baudrate=921600, parity=busio.UART.Parity.ODD, stop=1, receiver_buffer_size=8192)
Data chunk sizes are variable, but typically several hundred bytes. It will work properly for long stretches, then gets erroneous bytes typically at the beginning of each data chunk (resulting in erroneous CRC). Resetting the...
Yes, I will need to compile with the SDK a "special" firmware and somehow get this firmware onto the ItsyBitsy.
For this, I will need to use a Segger J-Link programmer and connect to the pads on the back of the ItsyBitsy.
This alone will be "tricky" as the ItsyBitsy is soldered onto a keyboard PCB....
Because of this, I had hoped to be able to activate the Test-Mode from a CP or even Arduione configuration.
perhaps you can extract the DTM lib into an Arduino program
@gamblor21 I re-read @tannewt's comments, and it sounds like he would like it all wrapped up in gzip, instead of exposing zlib? Do I understand correctly. Did you have further conversations with him in Discord (say), or elsewhere? I approved and then re-read, and now I'm a bit unsure.
@onyx hinge I think I will make a 7.3.0-beta.1 after #6426 and #6226 are merged and the translation updates are merged. Anything you want to get in before that? Still open questions on several other PR's
it will take all afternoon for all the merges to complete anyway
Not particularly, but I'll do a scan of PRs a bit later today. Is 6226 the pio wrap one?
filesystem stub
oh, I can do the PIO wrap one too, missed that
absolutely fine
I want to get the 7.2.5 fixes in a beta, that's a high prio for making a new one
ok, will do
I started on release notes already
I'd be ok if they were split into two modules.
@dhalbert My understanding based on t Scott's comment from 2/3 (quoted) was that it was okay to split the zlib portion into it's own thing since it already matches the existing CPython API. I understood the later posts to mean that for the DecompIO / stream related APIs when those are made to match CPython since they don't today that they would become the gzip module.
It's possible that my interpretation is incorrect though. I know it...
Got it, thanks, I was not following it that closely. I'll go ahead, since this is useful functionality, and gzip will end up using zlib anyway.
Thanks for the PR @gamblor21!
It looks like the uzlib API isn't grounded in the real zlib API. The CPython API doesn't have an IO wrapper class at all. The decompress object doesn't really have the stream API.
However, gzip has a GzipFile class and a gzip.decompress() function. I think that's the best approach for making this CPython compatible. Rename to gzip and rework the API to match. https://docs.python.org/3/library/gzip.html
import digitalio
import busio
import board
from adafruit_epd.epd import Adafruit_EPD
from adafruit_epd.il0373 import Adafruit_IL0373
# create the spi device and pins we will need
spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)
ecs = digitalio.DigitalInOut(board.D12)
dc = digitalio.DigitalInOut(board.D11)
srcs = digitalio.DigitalInOut(board.D10) # can be None to use internal memory
rst = digitalio.DigitalInOut(board.D9) # can ...
ok @makermelissa can try to replicate
So far it does not look like anyone is interested, so will closet this one out.
@KurtE why don't you submit a PR for it since ya think it would be cool to have? do you have the hardware?
Sorry @dhalbert, I thought I had replied.
@jepler's suggestion to "count every quadrature transition" was the missing piece. By always configuring the second PCNT channel and counting every transition the code becomes much simpler, and allows the divisor attribute to be changed on the fly. The position is then just the internal transition count divided by the divisor.
The same approach could be used with the other ports, which would mean position would update immediately when `divi...
Thanks for the reply. Does it still make sense to pass the initial divisor in? I think that makes sense, because then you don't have to worry about the order of the calls.
With the current code the constructor doesn't need to know the divisor anymore, so the order is back how it was before this PR.
I think it depends what you think should happen when the divisor is changed.
Given that I don't know the real world reason for dynamically changing the encoder divisor, I don't feel confident stating how it should work.
I see three possibilities:
- document that the position may change arbitrarily when changing divisor, the code can reset position to 0 if it wants
- make new movement relative to the old position, applying any pending sub-counts according to the new divisor
- multi...
If this passes your testing with divisors of 1 and 4, it's good enough for me. I didn't do any testing on HW myself.
CircuitPython version
Adafruit CircuitPython 7.3.0-beta.0 on 2022-04-01; ESP32-S3-DevKitC-1-N8 with ESP32S3
Board ID:espressif_esp32s3_devkitc_1_n8
Code/REPL
# SPDX-FileCopyrightText: 2017 Limor Fried for Adafruit Industries
# SPDX-FileCopyrightText: 2017 Limor Fried for Adafruit Industries
#
# SPDX-License-Identifier: MIT
"""CircuitPython I2C Device Address Scan"""
# If you run this and it seems to hang, try manually unlocking
# your I2C bus from ...
- Getting started with pin mapping.
CircuitPython version
Adafruit CircuitPython 7.3.0-alpha.0-38-g862210b3f-dirty on 2022-03-24; Adafruit Feather M4 Express with samd51j19
Board ID:feather_m4_express
Code/REPL
import microcontroller
import sys
print(str(len(microcontroller.nvm)), " bytes of nvm available.")
Behavior
Traceback (most recent call last):
File "code.py", line 12, in
TypeError: object of type 'NoneType' has no len()
Description
According ...
Possibly a build error... can you try the beta?```py
Adafruit CircuitPython 7.3.0-beta.0 on 2022-04-01; Adafruit Feather M4 Express with samd51j19
import microcontroller
len(microcontroller.nvm)
8192
That's good to hear. I'll keep what I'm working on as a private build or eventually move over to C++. I definitely see major opportunities to ramp up the capabilities of the CircuitPython audio engine, but that may be outside of the scope of the project.
Your version is7.3.0-alpha.0-38-g862210b3f-dirty, which is a base of a ways back (though nothing about nvm was changed that I know of, so see if you move up, if it helps, and also check your own mpconfigboard.*, etc.
CircuitPython version
Adafruit CiruitPython 7.2.3, 7.2.4, 7.2.5, 7.2.1 for Circuit Playground Bluefruit
Code/REPL
All examples supported by PyLeap were exhibiting the same behavior.
Behavior
The intended behavior in PyLeap is that you pair the device (CPB or CLUE only at the moment), you choose an example, you download it (the first time only), you transfer the code to the device (in this case, CPB), and it automatically reloads and begins runnin...
@TrevKnows I wanted to tag you here so you can follow it, if you like. I will keep you posted regardless.
Note - the original issue was filed on PyLeap: https://github.com/adafruit/PyLeap-iOS/issues/18
The watchdog module has two modes, RAISE and RESET. RAISE is to raise a WatchDogTimeout exception when the timer expires, while RESET causes a hard reset of the board.
Currently on RP2040, RAISE mode is not implemented. Additionally, because RESET is the only ava...
@onyx hinge I approved https://github.com/adafruit/Adafruit_CircuitPython_PIOASM/pull/35. Maybe this should finally be 1.0.0 ?
Oh is it still pre-1.0? It should be 1.0 at least.
CircuitPython version
NA
Code/REPL
export CFLAGS=-march=native
make BOARD=xxxx
Behavior
arm-none-eabi-gcc: error: unrecognized -march target: native
arm-none-eabi-gcc: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8-m.base armv8-m.main armv8-r ...
This is dependent on the compiler you are using. What version are you using? I'm not sure why you're doing this -- what's your use case? We wouldn't want to ignore the flag, we'd want to report the error.
If you would like to change build options, that's best done in the appropriate Makefile or .mk file.
When I build from the updated git sources, it still comes out
Adafruit CircuitPython 7.3.0-alpha.0-38-g862210b3f-dirty on 2022-04-07; Adafruit Feather M4 Express with samd51j19
Board ID:feather_m4_express
N.B. I was able to bull the bundle OK, but pulling circuitpython I get tons of Could not access submodule.
How do I build the beta?
More:
-march=native is for the architecture the compiler is running on, but we are specifically using arm-none-eabi-gcc as a cross-compiler. If you want to make a native build, check out the ports/unix tree.
Are you following the instructions in https://learn.adafruit.com/building-circuitpython ? You need to do make fetch-submodules at the top level.
This kind of build help is best done in our discord, https://adafru.it/discord, in the #circuitpython-dev channel.
OK, I have managed to get a crash, running NINA-FW 7.1.1, after 1766 seconds doing simple fetches from a local webserver, using the example above: https://github.com/adafruit/circuitpython/issues/6205#issuecomment-1079777657.
763 Fetch start Retrieving data...Fetch end
1764 Fetch start Retrieving data...Fetch end
1765 Fetch start Retrieving data...Fetch end
1766 Fetch start Retrieving data...Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "c6205.py",...
OK, I have managed to get an exception on MatrixPortal, using CIrcuitPython 7.2.5 and running NINA-FW 7.1.1, after 1766 seconds doing simple fetches from a local webserver, using the example above: #6205 (comment).
763 Fetch start Retrieving data...Fetch end 1764 Fetch start Retrieving data...Fetch end 1765 Fetch start Retrieving data...Fetch end 1766 Fetch start Retrieving data...Traceba...
As mentioned in issue #6241 the commit to setup port hooks is now
causing all input/output that are to go to the Mu window to also
go to the LpUart that is defined the port serial.c
and in this case it goes to lpuart4, which on Teensy 4, 4.1 is
used on Arduino Serial2. With this new code this port no longer
works properly.
This is one way to solve it, in that there is a #if defined() that
if not set, all of the code in this file is ignored and the ...
The issue I'm reporting is that it hangs - there's no exception raised.
I upgraded to 1.74, and I am also now seeing hangs, sometimes after a couple of minutes sometimes much longer. No panel is attached to the MatrixPortal, so that's not a factor. So it's disappointing the upgrade is not helping, but I have some leads.
anyone consider adding %timeit to the REPL?
that's an iPython thing, not in the regular REPL in CPython either. But there is the timeit module, which could be adapted to CircuitPython
timeit module looks pretty portable, just have to replicate the itertools.repeat function, which is pretty straightforward
Automated website update for release 7.3.0-beta.1 by Blinka.
@gamblor21 I re-read @tannewt's comments, and it sounds like he would like it all wrapped up in
gzip, instead of exposingzlib? Do I understand correctly. Did you have further conversations with him in Discord (say), or elsewhere? I approved and then re-read, and now I'm a bit unsure.
Hi, as @FoamyGuy said we did discuss it during in the weeds a few weeks ago. I looked and gzip for CPython is implemented in pure python so I'm thinking if zlib can be expanded a little bit more the...
Dodika00 you solve your probleme.Can you help me
i did not solve it yet
For anyone that works with requests, here's a PR to allow for multiple cookies in the hrader. This seems to be in compliance with CPython but figured others might have thoughts or at least more knowledge. https://github.com/adafruit/Adafruit_CircuitPython_Requests/pull/108
My thoughts were that if the library is often frozen in, this would be a better strategy than implanting the cookies property or CookieJar class
As a follow up believe it related to a clock stretching issue with the BNO080: https://github.com/adafruit/Adafruit_CircuitPython_BNO08x/issues/33
Will try a i2c1 = bitbangio.I2C(board.I2C_SCL1, board.I2C_SDA1, timeout = 500)
next time I have it set up
I need to go through a round of testing on this, but we decided to go ahead with this limited functionality in CircuitPython. Most users will probably want to use Arduino for more advanced stuff (or just the gw-compatible firmware), and that's OK.
After I re-test mfm floppy reading on hardware, I'll set this as ready for review.
FYI -- I just updated my BlackPill to 7.3.0-beta.1 and this issue is still present.
What is usb host?
the thing you connect usb devices to — usually your computer
supporting USB host allows connecting keyboards and other generic USB peripherals to a Circuitpython board
I believe AT Makers has a case of an accessibility device that uses a proprietary type of HID, that they want to convert into a generic compatible HID device, that's an interesting use
@tulip sleet Can you take one more look at this PR? I'm blocked on it at this point for one of my tasks. If you're ok with it, please approve. If not, lmk what I can do. Thanks! https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/2135
I'm looking for someone to build me (then help me build) a "custom" CP image for RP2040 (Nano). It's really the same as, say, 7.2.4 but just with unused modules removed to help save heap space. Will pay of course. Thanks!
Folks here will almost certainly help you build a custom CircuitPython image. However, we, as a community, don't typically accept pay to do this type of thing.
do built-in modules take up heap space?
looks like github actions is sad again today. such a variety of failures ... https://github.com/adafruit/circuitpython/actions/runs/2109289862
Uff.
have you already looked at https://learn.adafruit.com/building-circuitpython/build-circuitpython ?
githubstatus is green, so they haven't noticed. https://www.githubstatus.com/
Welcome to GitHub's home for real-time and historical data on system performance.
generally speaking, disabling a module frees up flash but doesn't affect heap much.
I have and that would be the next logical step. Just trying to save myself some time. I find I sometimes spend more time setting up then actually doing.
That does make sense becuase it's not loaded.
what is the problem you are trying to solve?
Might be a fools errand, but looking at trying to save heap space. We're right on the edge. It may be that it does little to nothing because the modules are not loaded anyways.
@bitter marsh I would look into precompiling as much as you can into .mpy files, that will save some memory
Of our code, I presume you mean? Yea, all of the libs we use are .mpy files and yea, we'd need to look at our own. also I presume converting fonts to binary will save a decent amount too.
Somehow I missed your response, sorry. Approved.
Ah ok. Thank you!
@tulip sleet I re-requested review on the .gitignore PR as well.
@tulip sleet Hey... question. What should I call the asyncio template in a board guide? "asyncio"? something else? It goes under the "CircuitPython Essentials" header, so it doesn't need "CircuitPython" in it. But I'm not sure if you have a better idea for a page title, or if you think asyncio is fine.
i was calling things "Cooperative multitasking", but that's a mouthful, and asyncio is the mechanism to do it and the shorthand, so go with asyncio
This issue looks to be with time.sleep() and not related at all to neopixels. Reducing the test script to:
`
import time
def wait_cycle(wait):
for j in range(255):
time.sleep(wait)
last_time = 0
try:
while True:
wait_cycle(0.01)
now = time.monotonic()
print(now - last_time)
last_time = now
except:
pass
Gets the following results:
1371.69
3.78174
3.39111
3.5542
3.21875
3.66504
3.15234
3.11377
3.09277
3.07617
...
Odd -- I get very different timing on mine. @DavePutz What board are you using?
Adafruit CircuitPython 7.3.0-beta.1 on 2022-04-07; stm32f411ce-blackpill-with-flash with STM32F411CE
>>> import hang
35.892
10.832
10.109
12.774
12.267
9.03198
16.355
6.34702
with a minor change -- the timing is better -- but still has the odd slowdowns
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
673.351
2.48999
2.49097
2.49023
2.48999
2.48999
4.2168
2.48999
2.49121
3.61401
2.48999
4.39185
9.47217
2.48999
2.49097
2.48999
2.48999
using
def wait_cycle(wait):
for j in range(25):
time.sleep(wait)
last_time = 0
try:
while True:
wai...
I'm getting some output when I use the correct pins( see https://learn.adafruit.com/adafruit-2-9-eink-display-breakouts-and-featherwings/pinouts) with this script:
import time
import digitalio
import busio
import board
from adafruit_epd.epd import Adafruit_EPD
from adafruit_epd.il0373 import Adafruit_IL0373
# create the spi device and pins we will need
spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)
ecs = digitalio.DigitalInOut(board.D9)
dc = digitalio.DigitalInO...
Oof, I don't know why I thought you were using grayscale. Let me try with a tri-color...
@jerryneedell - I have a stm32f411ce-blackpill with STM32F411CE (i.e. not the flash version). I'm running a local build from the current main branch.
Ok, tri-color is sorta working. I'll try messing with it a bit and get back to you.
@jerryneedell - I have a stm32f411ce-blackpill with STM32F411CE (i.e. not the flash version). I'm running a local build from the current main branch.
odd -- I wonder why mine (with flash) is running the .01 sleep loop so much more slowly....
Ok, the width and height were reversed in your example too. Try this:
import time
import digitalio
import board
from adafruit_epd.epd import Adafruit_EPD
from adafruit_epd.il0373 import Adafruit_IL0373
# create the spi device and pins we will need
spi = board.SPI()
ecs = digitalio.DigitalInOut(board.D9)
dc = digitalio.DigitalInOut(board.D10)
srcs = digitalio.DigitalInOut(board.D6) # can be None to use internal memory
rst = None # can be None to not use this pin
busy =...
Regardless, clearly something is broken in time.sleep().
Thanks for borrowing this down -- I will modify the issue title to remove the neopixel slander ;-)
Here's a version that draws it all at once and I put back in the board.SCK:
import time
import digitalio
import busio
import board
from adafruit_epd.epd import Adafruit_EPD
from adafruit_epd.il0373 import Adafruit_IL0373
# create the spi device and pins we will need
spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)
ecs = digitalio.DigitalInOut(board.D9)
dc = digitalio.DigitalInOut(board.D10)
srcs = digitalio.DigitalInOut(board.D6) # can be None to use internal ...
I used CircuitPython 7.2.5 and the original issue appears to be fixed.
hey @tulip sleet - i'm using the keypad library and trying to see if there's a simple way to detect a double-click. currently trying with time.monotonic() and states but wondering if i'm missing something with the event queue maybe that would be easier?
hi - there is a timestamp in each event: event.timestamp. There is a library for doing arithmetic on these, to handle wraparound. let me find it
I went ahead and reopened this as Sparkfun did come through with a VID/PID:
VID: 0x1B4F
PID: 0x002E
@mjs513 and myself now have a at least partially working version of it.
I just pushed up one of the last pieces need to build. Still have formatting issues will work on that later
It looks like the clang... used for previous PRs on other projects is not meet the same coding requirements.
My Python skills are not that great, but having fun to do pin check sketch that shows you all...
ah cool, thank you!!
courtesy jepler; he added the timestamps
@tulip sleet Alright, the asyncio template is ready for your review. I'm not sure if you're able to edit templates or not. If you edit the guide page, there will be a link at the top to the template (like on mirrored pages). You would click that to go to the template editor, if you have access. Otherwise, I guess we can discuss your suggestions in realtime here, or we can open an issue on the Learn repo, if you'd rather. Up to you. https://learn.adafruit.com/adafruit-esp32-s2-feather/asyncio?preview_token=vJ_qAZ3jfU7F3eDEmDKYUA
Oh, you're not expected to copyedit (but you can if you want), it's more reviewing it for accuracy and so on.
A lot of it is from your guide, so it's probably ok, but you might have better ways to explain some things that I didn't get from your guide.
I see "This page is templated, You may only edit content in the marked sections."
You don't have this at the top of the page?
No.
OK, then you don't have template access. Which makes sense, only 4 people do I think.
so I don't have the privs
Is the actual name of the page "asyncio", or that's the name of the template?
Both. I can change the template name to be clearer if you think it would be helpful
I think "Multitasking with asyncio" is probably less cryptic. "Cooperative multitasking with asyncio" is maybe too long?
Ok, that sounds good. You choose the page title when you add the template, so the template name doesn't matter.
Title updated.
Maybe put colons after the "one" and "two:
NeoPixel ring one data in (DIN) to microcontroller A1
NeoPixel ring one ground to microcontroller GND
NeoPixel ring one V+ to microcontroller 3V
NeoPixel ring two data in (DIN) to microcontroller A2
NeoPixel ring two ground to microcontroller GND
NeoPixel ring two V+ to microcontroller 3V
Hmm. We don't usually do that. You think it might be clearer that way?
"highlighted in [color] the wiring diagram" -> "on the writing diagram"
I thought it was "one data in" I parsed it wrong the first time I read it.
it's "NeoPixel ring one: data in ..."
Fair enough. Ok. Fixing template now, then will fix guide page.
Fixed.
Fixed the text for the button too
Ya I knew what you meant. Ya, used in 🙂
"You should have at least the following file in / of the CIRCUITPY drive:", maybe say "top level". Novices may not know what "/" means
Ooh, that's a Learn-wide thing, there. You're right though. I'll do that from now on. Fixing now.
Fixed
The "at least" wording is because of the sometimes superfluous adafruit_bus_device or pixelbuf.mpy that are included with some libs, even when not needed because the screenshot generator isn't smart enough to know when they are not needed.
If you download the project bundle, your lib will match the screenshot.
asyncio doesn't work on boards that would require adafruit_pixelbuf.mpy so it works here.
"Following set up, you create a class called AnimationControls. This class enables you to include ways to control the animations for use with asyncio." => "... This class provides ways to control the animations ..." or "This class provides the ways the animation can be controlled ..."
I think you could says something like "Notice that the controls object provides the animation direction (controls.reverse), the delay between steps of the animation (controls.delay), and the delay between complete animations (controls.wait). That would go below def rainbow_cycle or maybe def blink.
.delay vs .wait is a little confusing, one is intra-animation, the other is inter-animation (inside vs between)
Hm. I can see that.
e.g. this uses the word "wait":
You fill all the NeoPixel LEDs blue, wait for a specified amount of time, then turn all of the LEDs off, and wait for the same specified amount of time.
waiting in this case for .delay time
you could say "delay for a specified..."
"The blink() block twice includes the following line of code which utilises the delay variable from the AnimationsControl class above." => "the blink() block includes the following line of code twice, which uses [or utilises] the .delay attribute of the AnimationsControl object." Similarly in next sentence, refer to the `.wait' attribute in the object. I like being precise about object vs class.
I do too, but I'm fuzzy on it, so I don't get it right.
and the technical name is attribute, rather than variable, because it's an attribute of the object. i.e. not a plain old variable
Right that makes sense.
"or the task function finished", can leave out the "or"
"If you want to ensure the task executes forever, have a loop that never ends in the function" => "If you want to ensure the task executes forever, have a loop that never ends in the task function"
need to update the second instance of variable.
Also good call
There I think I got both of the places you meant.
async def loop():
while True:
print("I'm looping!")
await asyncio.sleep(0)
I would call this task() instead of loop, or never_ending_task(), or something to emphasize it's an example of a task.
"a loop in your task function"
that's it; thanks for your patience
Thank you so much! This was all great.
I think it's a very clear example, and well laid out. yw
Thank you! 😊
"Both functions end with the following line of code which utilises the .wait attribute of the AnimationsControl class." class => object
ok, made a second pass, looks great!
I can hand it off to Anne and Limor with more confidence. Thanks so much for all of your input
you're very welcome!
OK, I have managed to get an exception on MatrixPortal, using CIrcuitPython 7.2.5 and running NINA-FW 1.7.1, after 1766 seconds doing simple fetches from a local webserver, using the example above: #6205 (comment).
763 Fetch start Retrieving data...Fetch end 1764 Fetch start Retrieving data...Fetch end 1765 Fetch start Retrieving data...Fetch end 1766 Fetch start Retrieving data.....
@gilded cradle Hello! Are you around for a couple of questions? They're about the WebSerial ESPTool URL changes you made that came up last night in the meeting.
Sure Kattni
@gilded cradle OK. First question is the changes were made in the "Web Serial ESPTool" pages, as well as the "Factory Reset" template/pages, correct? Or are there more instances of it to look for?
@gilded cradle The second question is, are you going to set up https://adafruit.github.io/Adafruit_WebSerial_ESPTool/ with instructions to go to the other URL, or as a redirect, or something? Or will it simply remain as is.
As far as I know I changed all the relevant ones. If you find any they should be updated.
Ok, I'll do a bit of digging to make sure, but sounds good.
We can set it up to redirect
Might be worth it. I have it bookmarked, and that's what I was using to get to it.
I have to wait for a PR to get merged because Github doesn't like you having forks at 2 different locations.
Ah fair enough. I've dealt with similar before.
🙂
Thanks!
CircuitPython 7.2.5: tested on FeatherS2 and Adafruit Feather ESP32-S2. Also true as far back as 6.3.0 (did not test further back).
Using the PCA9685 driver, there is at minimum an almost 10ms gap between any two I2C transactions. This causes stepper motor rotations to be very slow, etc. This slowness was first noticed by a user here: https://forums.adafruit.com/viewtopic.php?f=60&t=190046.
I see a similar 10ms gap in some case in the SHT4x library, so I think it is generic to I2C.
@tulip sleet maybe you can explain the philosophy & practicality of using #if FOO instead of #if defined(FOO) on this PR? I'm not sure I'd get the explanation right, because I'm comfortable with both ways of doing things and I'm not sure I'd get it right. (and maybe it should be a CIRCUITPY_ identifier too?) https://github.com/adafruit/circuitpython/pull/6261
Sure.
@proven garnet I figured out a way to generate a patch file for Adabot that only applies to Adafruit CircuitPython TestRepo, for the purpose of being able to test the process without actually trying to apply a patch across all the libs. This means I have a way to walk you through it to find out if you can do it without the pressure of actual patch contents. I think sometime next week will be best as I've got obligations the rest of this week to attend to.
Congrats to @proven garnet for submitting the 350th CircuitPython library! Between the Adafruit CircuitPython libraries and the Community Bundle, we've reached 350!
@gilded cradle Found one. https://learn.adafruit.com/admin/guides/3358/editor/23525 Can you update the screenshot? I already updated the URL, but realised the image didn't match anymore.
Sure
Otherwise, it looks like you caught everything!
I updated like 3-4, so I think I got the process down.
There's one more guide returning on the URL search, but I can't find a reference to it in the guide. Justin is checking.
I'm not editing, you can take over. I closed the tab.
Ok, cool
@gilded cradle Justin found it. https://learn.adafruit.com/upgrading-esp32-firmware/upgrade-rp2040-airlift-firmware#flash-airlift-using-web-serial-esptool-3086368-18 <-- also needs to be updated.
@idle owl Ok, that one's a bit different and will need new screenshots.
Yeah, that's what it looked like. Anyway. That is definitively the last instance of it. 🙂
Thanks
Ok, Kaluga one is done.
Thanks!
yw
That sounds great! I'd love to go over it then!



Excellent. We'll sort it out next week!
anybody has a Feather ESP32S2 TFT with latest CP ?
CircuitPython version
Adafruit CircuitPython 7.3.0-beta
Adafruit CircuitPython 7.2.0
Adafruit CircuitPython 7.2.4
Adafruit CircuitPython 7.2.5
Code/REPL
import digitalio
import board
import time
# Turn on I2C power pin
i2c_power = digitalio.DigitalInOut(board.I2C_TFT_POWER)
time.sleep(0.1)
i2c_power.switch_to_output()
time.sleep(0.1)
i2c_power.value = False
time.sleep(1)
i2c_power.value = True
Behavior
TFT should by default and ech...
Oof, I don't know why I thought you were using grayscale. Let me try with a tri-color...
You thought right, I was using greyscale! Wasn't sure how to adapt the code to my device.
Ok, the width and height were reversed in your example too. Try this:
import time import digitalio import board from adafruit_epd.epd import Adafruit_EPD from adafruit_epd.il0373 import Adafruit_IL0373 # create the spi device and pins we will need spi = board.SPI() ecs = digitalio.DigitalInOut(board.D9) dc = digitalio.DigitalInOut(board.D10) srcs = digitalio.DigitalInOut(board.D6) # can be None to use internal memory rst = None # can be ...
Thanks so much for your help, works great now!
I have one
I have one as well, just finished doing a fresh build/flash, have some time this evening if you need someone to test something @jaunty juniper
Question - I am new at circuit python so I am not very good at it and might be asking stupid questions.
The CAN library does not seem very good. It has all blocking calls instead of callbacks while stuff happens in the background
Can I create a library in C, use the microcontrollers built in CAN functions, and then create an interface for MP/CP?
Same for if I went a offbord CAN solution with SPI and DMA
The goal is 2 things: make an arduino interface and a circuit python interface (hopefully saving having to rewrite code), and to have higher performance CAN code that does not block
It was changed from I2C_TFT_POWER to TFT_I2C_POWER in #6045 to match the other TFT pins.
I check pin name in REPL on each rev before running TFT code to turn TFT on and change code to match. In REPL run “import board” then “dir(board)” to get pin name.