#circuitpython-dev
1 messages ยท Page 390 of 1
Yeah that is true, and those need to go.
But that's another story.
I'll put Dylan on it.
Thank you for catching this.
For future reference, my suggestion would be to merge a failing PR, and notify me about the issue so we can make a decision without desyncing library config files.
You should have the ability to merge a failing PR.
yep. i considered that.
I noticed that I could merge the PR even with the failure but wasn't sure if that was a good idea or not.
In 99 percent of cases, it is a terrible idea.
In this particular case, where something remote has changed and it's nothing to do with us or your PR, I'm ok with merging and then dealing with the problem. But this is a rare case.
@blissful pollen yah. maybe you could do that with the PR you're dealing with? otherwise you're just repeating my no-no. ๐
@blissful pollen @tidal kiln Repeat the no-no this time. Because we're about to do it globally.
And Adabot knows how to skip things.
The author did change it already - just haven't merged it yet they have to (last I looked still fix the examples) and the change to this PR has to sync with the equivalent busdevice core change
okei doke. thanks. @idle owl for future ref - OK to ping you for any CI thing? or is it just a subset?
I'm great to start with, and I usually know who to direct to if it's not for me.
So ping me.
excellent. thanks!
Thank you for catching it!
Just mistyped "origin" as "origina" and now I want an Orangina.
Read through the code. Looks like more efficient and clearer use of the i2s peripheral (and espโs library) to give more flexibility and also add 16 bit parallel LCD.
Good reuse of code for older _construct function.
Did not test on hardware.
@onyx hinge looked through ParallelBus code and looks good to me with what I can see by a quick look at the code. With no hardware handy right now, I did not test. Since I didnโt do testing, I was hesitant to โapproveโ but let me know if you want me to.
@blissful pollen do you think you'd have a chance to do any testing?
@mental nexus appreciatae you taking the time!
I have not, I may have missed the PR going through which one is it?
https://github.com/adafruit/circuitpython/pull/5378#pullrequestreview-762377697 I just requested your review
okay thanks i'll try to take a look at it later today or tomorrow
@microdev1 @gamblor21 I've pulled from upstream and can see the IDF cache key fix is in my fork now, so it should be safe to rerun the build prior to review / merge.
Any CircuitPython Librarians up for approving a few PRs? I have four outstanding ones I'd like to get merged. I can link if anyone is up for it.
Thank you @tulip sleet!
It would be useful to have a few sentences, and/or a link to more details for each bullet point on CircuitPython release announcements.
I do not have any idea what some of these features are/do (some of the feature names use jargon, and I don't frequent this Discord).
I'd like to have a brief explanation right there in the announcement text that would inform me as to whether I should investigate a new or updated feature further.
I think the best we can do is consider adding a link to the relevant PR. The releases and their associated notes already take a significant amount of time and effort (multiple hours). Perhaps the PR and its discussion would at least be somewhat helpful to you. @tulip sleet
Yep, I get that it's a lot of work, and I'm grateful. Of course it's not just me that probably would benefit from this suggestion, but rather your entire target audience.
The PR usually has some kind of details. Since... we need to know what we're merging, etc.
We'll consider what we can do. Thank you for the suggestion!
@lone axle Thank you so much for the git help yesterday. It worked perfectly. Though I realised as I was typing this, I did not do the other search I needed to do. So I only half completed the job. Oops, I guess it's another opportunity to get the commands into my head.
I searched for wheel(), I did not search for instances of _pixelbuf imports. Fingers crossed I didn't add any, but I bet I did.
Hooray, you're welcome. I still don't have it fully commited to memory yet. Pycharm saves terminal histories seperately and I know I've run that in the bundle repo before so I go there and up arrow through my history to find it ๐
Yeah, I use iTerm and have some bash magic going on where I can type the beginning of something and up arrow and it goes through all the commands that start with what I typed.
SO convenient.
I'd be lost without it.
Or hitting a lot of up arrows to go through everything. ๐
I didn't know that about PyCharm though.
as a heads up the ; true part of that command may not be necessary with all commands. It's needed because git grep returns an error code if it doesn't find anythign which prevents the foreach loop from continuing. So commands that don't behave that way shouldn't need it. Though I don't think there would be any harm in having it even when not strictly neccessary.
history | grep 'git' is a good "what was that command again?" trick too
Oh good to know.
Thanks.
Man, populating the bundle takes ages.
I delete it every time so I'm not having it all sitting there.
nice! thanks for the tip. That seems to show history from all terminal sessions as well which is cool if I'm in one that has it's own history.
Oof, yep, I did miss some.
Luckily not any of the same libs I already did. That would have been embarrassing. ๐
I think* only of past closed sessions unless you've got a 'share the history' setting enabled. So if you've got two terminals, type a command in one, I don't think it show's up with history | grep "keyword". But I don't know how the history thing works sooo milage may vary?
I'm not sure if there is some setting for it. I've never changed anything that I can recall but the terminals inside of PyCharm all remember things that I've run inside of each project and terminal instance specifically and don't "up arrow" through commands that were run elsewhere.
ah, running history | grep whatever inside those does seem limited to only stuff that I've run inside of it as well. I must have run that foreach inside of a "normal" terminal at some point because I found it when I first ran that after you mentioned it.
Ok, that makes a lot of sense. I was really confused at how much shared history there was, but I don't run terminals in IDEs so it's a major grey area to me
Thank goodness for working primarily on a laptop.
just flickered but came back super fast and battery kept everything in place.
oof that's fortunate that the power is back and the battery kept things for disappearing. Time for a round of "Save save save" sprints
It's been raining here for 48 hours straight. Had power flickers last night.
Wind died down today which was likely the cause.
I need to get some trees down a couple years ago after an early ice storm my lights kept dimming and I could see branches banging into my power lines
Yeah we have a giant tree in the back yard we keep an eye on. We wouldn't take the whole thing down if it came to it, unless it died. In which case it's a hazard to the house as well as the power lines.
Turns out you have to push if you want your changes to show up on GitHub ๐คฆ๐ปโโ๏ธ
i have a couple trees that died as result of some sort of insects I think. Some tree service is going to make a nice amount
Oi, that's true.
Hey folks, I have two PRs that could use a review. https://github.com/adafruit/Adafruit_CircuitPython_NeoKey/pull/3 and https://github.com/adafruit/Adafruit_CircuitPython_LED_Animation/pull/82
Thank you!
Oops I didn't notice it but the checks failed on the LED animation
Ah have some things to fix on that one.
Yeah I just saw that.
No worries.
Sphinx biting me.
My git knowledge is lacking for PR #5383 it now has to be merged after microdevs change for the ESP IDF key. Does anything have to be done to do that? I tried to re-run the workflow and it still failed
you have to push a nothing commit to get it to redo the pr against the tip
the PR is set to the commit that existed when you did the PR, until you do another commit on the PR
Okay thanks I'll let the author know
@microDev1 @gamblor21 I've pulled from upstream and can see the IDF cache key fix is in my fork now, so it should be safe to rerun the build prior to review / merge.
You will have to push a nothing commit to the PR and then it should build correctly against the latest merged code.
I can merge it anyway with the failures
I thought it needed re-testing, but it's fine except for the bad builds, right?
Yup I hadn't given it an approval yet waiting on that, and it has to go alongside the python busdevice library too. Both do look good now
It's a change to the adafruit_busdevice module. So it is being changed both in the core and in the library that is used for the smaller builds
did you cancel the bad build?
Yes I did
Thanks!
i will keep an eye on the merge action to make sure it works: https://github.com/adafruit/circuitpython/actions
@michthom Thanks for all your work working through this and the library build. And congrats on your first PR! ๐
@gamblor21 Team effort - I certainly needed your support.
@blissful pollen Merge actions almost done. Looks fine. The espressif builds were all fine.
Awesome. Thanks for helping on that
np
Still playing around with heavily-modified example code that does management frames only, single-channel or channel-hopping, parses frame headers, and does a coarse parse and dump of the fixed and variable components of the frame body. The test environment has a relatively limited set of devices in range. Let it run a few hours last night, and do get interspersed errors from the callback:
- Not enough memory for promiscuous packet (esp-idf heap stats when this occurs is typically something...
Tested on an UnexpectedMaker TinyS2 with the Adafruit 480x320 TFT breakout. Could only test non-sequential pins as I did not have 8 pins together, but no issues. Tried a few different display frequencies with no issues. Looked over the code and I saw no issues there.
hah, I forgot I hadn't acually tested non-consecutive pins :rofl: so thanks for that @gamblor21
ok well true deep sleep and fake deep sleep is working in this commit: https://github.com/maholli/circuitpython/commit/f030a522353b60e535d756d63fcc2d93d5c8d91e
fake sleep is a little janky. I haven't been able to get a CMP flag to trigger while the vm is running, so for now it just checks port_get_raw_ticks while looping in fake sleep.
Is there anything specific to do to get my board into the 7.0.0 release? I expected to see to the PyKey60 download page to have 7.0.0 available. Did the merge just missed the release by a couple of hours or is there something else I am missing?
Is REPL over hardware UART possible?
There are some compile flags to turn it on. It's only implemented for certain boards.
// in mpconfigboard.h
#define DEBUG_UART_TX
#define DEBUG_UART_RX
are you referring to this? ๐
I saw this in microbit_v2
yes, I thought there was something else, but I looked and I can't find it.
Yes, it was merged after rc.3. We expect to do a 7.1.0 or something like that relatively soon, but there's no schedule. The "Absolute Newest" should be fine.
@tulip sleet I can't get REPL over UART with those defines on espressif.
I don't think it would be that hard to add. There's a CIRCUITPY_SERIAL_BLE, and the logic for UART would be similar. There was multiterminal but we don't use it for anything. It was for ESP8266, I think.
I added a CIRCUITPY_CONSOLE_UART but it doesn't do anything.
The name of that maybe should be changed, or the name of CIRCUITPY_SERIAL_BLE should be changed. I don't remember now.
thanks dan, I'll take a look at how CIRCUITPY_SERIAL_BLE is implemented, I need the repl over uart thing for esp32c3
Scott may have a mental plan about this
Does esp32s2 common-hal code need to feed the WDT, or yield in some way sooner than some interval?
@slender iron if I request 0x6d44_4333 id... then will the following be the entries in the board config?
CIRCUITPY_CREATOR_ID = 0x6d44
CIRCUITPY_CREATION_ID = 0x4333
I believe both creator and creation are 4 bytes long, if you request the creator ID 0x1337_BEEF, you use that as the creator ID, and whatever 32 bit value as the creation ID
yup, what neradoc said. you just need to request the creator ID and then decide on your own creation id
okay so...
CIRCUITPY_CREATOR_ID = 0x6d444333
CIRCUITPY_CREATION_ID = any random 32 bit value
@idle owl were we doing something global about this f-string check? It's affecting some PR run: https://github.com/adafruit/Adafruit_CircuitPython_GPS/pull/67/checks?check_run_id=3702332800
@onyx hinge yah. stuff is happening for that. kattni would know current state of progress though.
Yes. If the author is comfortable, they can do it in their PR. Is it otherwise ready to merge?
Might make more sense to simply merge it failing before we run the script, really.
it was marked as being a new contributor PR so I would probably not ask for it
Is it ready to merge now?
if enabled, could push changes to their pr
The script will be run today.
That's why I'm saying we can merge it now failing.
Or it may have conflicts once the script is run.
I don't know enough about GPS, I think it's a safe-ish change though
ah. got it. don't even worry about the change. it'll happen automagically later.
that's fine then
Yep.
@tidal kiln @onyx hinge The script has been run, so all the libraries should have that update now.
y'all are great, thanks!
cool. thanks. the CI dragons have been put back to sleep...for now.
For now, indeed.
and on a friday ๐
Welp. ๐คท๐ปโโ๏ธ It needed to be done.
@gilded cradle Did the 2.9" Eink Displays guide get updated or is it new? The info on the bottom of the guide is inconsistent.
@idle owl kind of in between. It's a new guide that drew from existing pages. Which info are you referring to?
@gilded cradle The "This guide was first published on $date" and then the "This guide was last edited on $date" - the published date as 22 September, the last edited date was 16 September ๐คท๐ปโโ๏ธ
@onyx hinge As long as you're up for helping, I have code that mostly does what I need, except for one thing, and the only way I know how to deal with that is a simple state machine, and I think it's a terrible kludge that I keep perpetuating when I shouldn't be.
I need it to only send spacebar once, and not again until you've backed off and gotten closer again.
Right now, it repeatedly sends spacebar as if you're holding it down, which will make you fail the game.
Oh yeah @idle owl, not sure why. Maybe because I used the copy feature from another guide.
Ah ok.
@idle owl always losing at the game isn't great ๐
I'll have to send another PR to the newsletter to get it in there, I thought it was old. Thanks @gilded cradle
@onyx hinge Ok, that's fixed. So... how to only send it once.
Without using my "debounce" state machine code.
Here is what I'm referring to, written for the Circuit Playground library: py button_a_pressed = False while True: if cpb.button_a and not button_a_pressed: # If button A pressed... print("Button A pressed.") [...] # The code you want to execute on the button pressed event. button_a_pressed = True # Set to True. time.sleep(0.05) # Debounce. if not cpb.button_a and button_a_pressed: # On button release... button_a_pressed = False # Set to False. time.sleep(0.05) # Debounce.
Kludgy. ๐
Or is that acceptable?
I tried both press and send.
Neither one only sends once.
it's probably fine?
Hmm fair enough
I'm surprised press sends again, or rather, that press again does the equivalent of release+press
(it's not what the source says to me, but if you tested it then anything I thought I knew is suspect)
Hmm.
I'll try again.
It might be my code.
Making it keep sending.
Do you want to see the code? It's probably my code being wrong.
if you want to share it in its current state
"Want" is a strong word. ๐
initial_proximity = apds.proximity
while True:
print(apds.proximity)
current_proximity = apds.proximity
if current_proximity > initial_proximity and current_proximity > 127:
pixels.fill((255, 0, 0))
keyboard.press(Keycode.SPACE)
initial_proximity = current_proximity
elif current_proximity < initial_proximity and current_proximity < 127:
pixels.fill(0)
keyboard.release_all()
initial_proximity = current_proximity
time.sleep(0.2)```
That doesn't include setup obvs.
That if is true more than it should be, I think.
so your pixels are filled like you want, but the virtual keyboard isn't doing what you want?
Well, the pixels aren't a good example because if they keep "filling", I wouldn't notice.
Because they're already on
but it's red when the hand is close and unlit when the hand is removed
it doesn't look like it would release unprompted, so it should hold the space bar down
They do turn on appropriately, but the space is initially sent appropriately too
I don't think I quite follow.
Should it release inside the if ?
it should hold the space bar until you back away
That's what it's doing. That's not what I want it to do.
So you're correct on what it's currently doing
do you want it to act like it taps space just once when you first move your hand down?
I think so?
If you hold space down playing this game, you die quickly ๐
So you need to only send it once when you want to
then yes you'll need to use a state machine
or debounce or whatever you like to call it
and use send
yes and use send
Ah ok. I guess I always thought I was doing it wrong because I wrote that code really early on in my learning process.
And a lot of that code I wrote early on is... not great.
there are a million different ways to phrase it but yours works
was_pressed = False
while True:
pressed = read sensor or whatever to get a True or False value
if pressed and not was_pressed:
do the actions for newly pressing a key
was_pressed = pressed
I tend to write something like that, personally
Problem here is, the proximity sensor is not a True/False situation.
I guess I need to make it one.
maybe pressed = current_proximity > initial_proximity and current_proximity > 127 ?
(I think there's something weird about the double comparison but that's a separate thing)
OH!
it looks like you used current_proximity > initial_proximity as a way to do the debouncing, but it wouldn't work since it would still trigger when moving away (or in)
Yes that.
I just figured that out.
I was trying to use that to make sure it only triggered when you were moving the right direction.
Maybe it doesn't matter.
I would remove that comparison
Still sending repeated spaces. sigh.
(since it will always be true when the other condition becomes true, but also some other times)
or is the direction you move important for the game ?
Adafruit CircuitPython 7.0.0-78-gb8aa2b9cc-dirty on 2021-09-25; MicroDev microC3 with ESP32C3
Board ID:microdev_micro_c3
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Hello World!
Code done running.
Press any key to enter the REPL. Use CTRL-D to reload.
finally REPL on esp32c3 ๐ฅณ
Congrats! Nicely done!
@tulip sleet follow-up from our previous conversation... REPL over hardware UART not working was espressif specific... common_hal_uart_never_reset() wasn't implemented properly.
I'll PR with a fix soon.
glad this was not generic, and glad you got it working. If you think the switching on/off should be cleaned up, that could be another thing to do, but you're probably on a particular path
@idle owl I don't have a prox trinkey so I can't exactly follow along with you ... so instead I wrote a program using the encoder button of the macropad. ```python
import time
from adafruit_macropad import *
macropad = MacroPad()
old_pressed = False
while True:
pressed = macropad.encoder_switch
if pressed and not old_pressed:
macropad.keyboard_layout.write(' ')
old_pressed = pressed
time.sleep(.001) # I found that .2 was too long
what is the game btw ?
@idle owl my goal is to try to separate the logic about "when to send a space" given a nice clear button press from "how to turn the distance sensor into a nice clear button press" and figure out which one is the problem
@jaunty juniper chrome://dino/ in google chrome / chromium browser
just enter that in the address bar to start the game
oh that's what the hiibot came pre-installed with
yay!
it is a cause for rejoicing!
But it's not saving and reloading
I had to manually reload within the serial console to get it to update
wait that's weird
does it do it still now that it knows you're watching?
are you on 7.0.0?
does it persist after you use the reset button?
Don't know, haven't tried yet
we're getting v. close to "you get to file an issue now" ๐
understood
Now it's reloading.
Sigh.
Not worth filing an issue, imo. But wow that was annoying.
I'm not sure I've ever run into that before.
i thought I saw something like this yesterday, and was really confused. But I could not reproduce it.
I think I was getting a USB error really early.
I'm not great at this game, but I am worse with this input method. ๐
I need to ๐ฎ . BBIAB.
@idle owl do try decreasing the sleep time, 1/5 of a second is an eternity in this game
by the way you can use a predicate with adafruit_debouncer, I think it would work:
distance = Debouncer(lambda: apds.proximity > 127)
while True:
distance.update()
if distance.rose:
keyboard.send(Keycode.SPACE)
pixels.fill((255, 0, 0))
if distance.fell:
pixels.fill(0)
Hmm. Fair enough.
This is easier for me to explain ๐
And actually, not sure debouncer would fit.
This one is tight.
oh right trinkey
ya
too bad, I liked the idea of rose/fell having a double meaning ๐
Agreed! And it would have worked! Except for me explaining lambda ๐
It's destined for a guide, as is probably obvious.
up-vote for native code on the second processor, I have a project that requires 4 rotary-encoders and presents a HID interface.
- in my experience, reading encoders is helped by a little physics (momentum) modeling. A bit too complicated for PIO, but C code is working great on the second processor.
- for HID handling, circuitpython shines there, contrasted with getting HID to work via the C-sdk, not easy.
Possibly this is an example of an app that needs dual-cores: circuitpython on Pr...
@nmorse did you try circuitpython as is? 4 rotary encoders and HID is not processor intensive.
I will try that, (on this project) up till now I had been doing all 'C-sdk', thanks
I realized what happened. I wrote that page on the 16th, but because I had to write drivers for the UC8151D eInk display, it didn't go live for almost a week and so the dates are correct.
Ok! It's alright. It went into this week's newsletter, I don't think it was in last week's. So it all works out.
Awesome
Thanks @FoamyGuy I have a PR up against our fork of the circuitpython-org repo, and once we make an official PR here, I'll circle back and make an official PR against your main repo.
The common_hal_busio_uart_never_reset() function wasn't implemented in espressif port.
This caused serial over uart to not function properly as busio is reset at multiple occasions after serial_early_init().
Should common_hal_busio_uart_deinit reset the mask?
Nope as never_reset is meant for things that should be kept alive across multiple VM and REPL runs.
These things should only be reset on reboot of the mcu.
As described in the title. The first commit had an error connected to the UART pins. This fixes it.
I checked the corrections against here, but why is there a D1, which is not on the silk nor the diagram?

WiFi and BLE both seek to discover a relatively fixed list of devices in range, and those devices are explicitly sending frequent beacons and advertisements in order to be discovered within a fixed length of time. Advertisements from a connected BLE device are conceptually infinite, but I believe the typical use case makes occasional scanning for new data a practical approach.
WiFi monitor mode, on the other hand, is conceptually an infinite process with no clear end point. Occasional scan...
Good call. It's a remnant from arduino boards where the uart pins were referred to as d0 and d1 when used as gpio pins. I will update the pin diagrams to reflect this, for all our boards.
@tulip sleet report_ids = (0,) doesn't seem to be accepted
Sounds good, I thought I had seen it reset the never_reset for displayio if you release the display. The rest looks good to me.
CircuitPython version
Adafruit CircuitPython 7.0.0 on 2021-09-20; Seeeduino XIAO with samd21g18
Code/REPL
import displayio
from digitalio import DigitalInOut, Direction
import board
import time
import adafruit_displayio_ssd1306
import busio
led = DigitalInOut(board.D13)
led.direction = Direction.OUTPUT
displayio.release_displays()
spi = busio.SPI(board.SCL, board.SDA)
tft_cs = board.D2
tft_dc = board.D1
tft_reset = board.D0
display_bus ...
displayio is does not fit on the xiao, you can try to use framebuf version
https://learn.adafruit.com/micropython-hardware-ssd1306-oled-display/circuitpython
https://github.com/adafruit/Adafruit_CircuitPython_SSD1306/blob/main/examples/ssd1306_simpletest.py
JFYI. I've tried example above and getting the follow error:
Traceback (most recent call last):
File "code.py", line 6, in <module>
File "adafruit_ssd1306.py", line 268, in <module>
MemoryError: memory allocation failed, allocating 296 bytes
It seems using CircuitPython with ssd1306 is impossible ๐ข
It's not impossible, I use it for example on this device: https://hackaday.io/project/180309-pewpew-oled
But I did have to compile my own version of the firmware, and enable displayio in it.
usb_hid.Device report_ids validation did not allow report_id=(0,).
@jepler Thanks for finding this. Could you test with your report-id-less report descriptor. I did not test except to see that it compiles.
For a personal project I'm working on, I'd like to use CircuitPython as Python is much easier to program in (and I'm much more familiar with CP as well - it worked phenomenally when I upgraded a previous project to use CP!). However, my specific board for this project, the TinyZero, doesn't show CircuitPython support on the website. I would prefer to use this board as it's smaller than a U.S. Quarter, which enables it to fit inside a mini custom enclosure! I believe it's specs are indeed suff...
See this guide for information about how to add a new board to CircuitPython:
https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython
We're happy to get a pull request.
Thank you so very much for your quick reply and for adding this as a long-term update! Have a great day! ๐
The link for the Community Bundle pointed to the Circuitpython Organisation Bundle (which should probably get a link too some day).
Added board support for our new Challenger board with an LTE modem.
Current compiled downloads are unusable because MICROPY_QSPI_CS is defined as the wrong pin
@analog bridge how stable is your ESP32-C3 port? Iโve got one of the Engineering samples from early this year and kind of want to try it out.
I haven't done a lot of testing as currently only REPL interaction is possible over hardware UART but please feel free to give it a shot... most things should work.
One more thing, I am doing all the testing using the latest revision 3 of esp32c3, you might have to tweak the sdk config a little to specify the revision of your chip.
It appears when you interact with the chip using esptool.
I figured as much. Thanks for the work youโre doing in the C3 port
Iโve wanted to do more with the C3 but Iโve been waiting for the BLE port ๐
๐ ... ble is the hardest part.
I think following in board's sdkconfig should do
# CONFIG_ESP32C3_REV_MIN_0 is not set
# CONFIG_ESP32C3_REV_MIN_1 is not set
CONFIG_ESP32C3_REV_MIN_2=y
# CONFIG_ESP32C3_REV_MIN_3 is not set
CONFIG_ESP32C3_REV_MIN=2
cool, i'll pull down your repo and build it and try it out
use this branch instead of the PR one... I have got board files in this one
https://github.com/microDev1/circuitpython/tree/microdev-micro-c3
will i flash it the same way i would the bin for say an s2 using esptool?
yes, its the same... there were some changes with esptool config flags, they have been taken care of in the Makefile
okay, so just sh esptool.py --port /dev/cu.usbxxx --after=no_reset write_flash 0x0 firmware.bin
or you can use make BOARD=... flash
oh didn't know you could do that lol
I prefer the make one as it takes care of all the flags.
doing that, do i need to specify the com port target?
oh yeah, I forgot that... make BOARD=... PORT=... flash
ah perfect
the default is /dev/tty.SLAB_USBtoUART
CircuitPython version
CircuitPython 6.3 but also observed in version 7.0
Code/REPL
import board
import time
#LEDs-----
import digitalio
redLED = digitalio.DigitalInOut(board.RED_LED)
blueLED = digitalio.DigitalInOut(board.BLUE_LED)
redLED.direction = digitalio.Direction.OUTPUT
blueLED.direction = digitalio.Direction.OUTPUT
blueLED.value = True #LED is turned on
redLED.value = True #LED is turned on
time.sleep(2) #to give m...
Looks good to me based on the pin diagram here: https://wiki.makerdiary.com/nrf52840-mdk/images/nrf52840-mdk-pinout.jpg
Don't have one of these devices to test with though.
I am on a steep learning curve on CircuitPython and now I need to understand how to get async/await to work. First obstacle is I get: no module named 'asyncio'.
I am on 6.3.0. Any hints to where I can read up on this?
@ErlendFj asyncio is not yet available, though we are looking at event and concurrency support in more depth for 8.0.0. However, async/await is turned on for most boards, and there are several libraries already available. See this forum post: https://forums.adafruit.com/viewtopic.php?f=60&t=183355
dang... crosstool-ng no longer supports macOS
A versatile (cross) toolchain generator
That post is 3 years old ๐
Thanks for the swift answer. I'll try with yield or asynccp and see if I
can sort it out.
On Sun, 26 Sep 2021, 21:28 Dan Halbert, @.***> wrote:
@ErlendFj https://github.com/ErlendFj asyncio is not yet available,
though we are looking at event and concurrency support in more depth for
8.0.0. However, async/await is turned on for most boards, and there are
several libraries already available. See this forum post:
https://forums.adafruit.com/viewtopic.php?f=60&t=183355โ
...
I know, just sad
I keep running into issues building
Ok I am WAY LATE to the party here, sorry @maholli, but here is a summary of the existing ways the different ports handle fake sleep. Hopefully some of this will be helpful - I'm still not totally grokking the way the ASF4 is handling these interrupts.
- STM32: These chips are pretty straightforward, because the RTC alarm feature, which compares the current RTC time to a calendar date by default, will generate interrupts successfully regardless of whether the MCU is in "run" or "sleep"...
@maholli your current method seems fine, tbh, close to the STM32 implementation. Fake deep sleep needs sleep performance the least out of any mode, because the assumption is that you'll only ever use it when debugging and connected to a PC. But if we want to do light sleep (where RAM isn't dropped), it would be good to figure out how to get that CMP to work.
Are you currently able to detect, after waking from true deep sleep, whether it woke up from sleep or just started for the first time...
Which board are you unable to build?
Iโm trying to test out the ESP32-C3 stuff microDev is working on but I need to add the riscv tool chain and Iโm following the esp idf instructions for mac install but Iโm just running into build issues with crosstool-ng
Hmm.. Iโve not had issues recently esp32s2 on my Mac. Itโs be a few weeks since I tried it and wonโt be able to check until tomorrow morning. Iโll try it then. I have not tried the C3 at all, but can you build the S2?
Yeah, as far as I can tell
@ornate breach I can provide you with .bin for REV-2.
@ornate breach I see that the C3 may need a different set of tools from the S2 -- I can build the S2 OK on my Mac, but have not tried C3.
But if I run ./install.sh esp32c3 in the esp-idf folder, it does not complain.....I tried downloading pr 5394, but I don't see a C3 board in the boards folder to try building. I I must have missed something and since I don't have the hardware I think I'll leave this to you to sort out. Sorry I could not be of more help.
@solar whale use this branch instead of the PR one... I have got board files in this one
https://github.com/microDev1/circuitpython/tree/microdev-micro-c3
hmm -- that seemed to be building OK on my Mac, but failed near the end with /Users/jerryneedell/.espressif/tools/riscv32-esp-elf/esp-2021r1-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: build-microdev_micro_c3/supervisor/shared/serial.o: in function `serial_early_init': /Users/jerryneedell/projects/circuitpython_microdev/ports/espressif/../../supervisor/shared/serial.c:72: undefined reference to `common_hal_busio_uart_never_reset' collect2: error: ld returned 1 exit status make: *** [build-microdev_micro_c3/firmware.elf] Error 1
a pull from adafruit:main should fix this
how do I do that?
have you cloned my fork?
I cloned your fork and checkout the microdev-micro-c3 branch
okay then following should do
git remote add adafruit https://github.com/adafruit/circuitpython.git
git fetch adafruit
git pull adafruit main
yay! that worked ```
1280672 bytes used, 161120 bytes free in flash firmware space out of 1441792 bytes (1408.0kB).
0 bytes used, 8192 bytes free in 'RTC Fast Memory' out of 8192 bytes (8.0kB).
16 bytes used, 8176 bytes free in 'RTC Slow Memory' out of 8192 bytes (8.0kB).
0 bytes used, 32768 bytes free in 'Internal SRAM 0' out of 32768 bytes (32.0kB).
0 bytes used, 294912 bytes free in 'Internal SRAM 1' out of 294912 bytes (288.0kB).
So it does appear to be possible on a Mac!
Building the C3 board in circuitpython gave me a compiler/asm error for not being able to find the risc-v esp g++/gcc and asm compilers
Might be a linking issue, not sure ๐คทโโ๏ธ
no idea -- mine did not complain....
This PR adds DisplayIO bringup to the Pimoroni PicoSystem.
This is raised as a draft with a line in mpconfigboard stubbed out (so checks will hopefully pass), pending the addition of a PicoSystem "stage" and "ugame" to https://github.com/python-ugame/circuitpython-stage/ and a bump to the submodule.
Looks like circuitpython-stage submodule is currently tracking master, so there shouldn't be any implications in bumping it?
cc @deshipu pretty sure we dont want to use gamepad or gamepad shift anymore, replaced with keypad
https://learn.adafruit.com/key-pad-matrix-scanning-in-circuitpython
@idle owl I think the scripts to make issues for missing types across all libraries are all set and ready to go any time. Wanted to give a heads up here because whenever I run it there will be a big wave of them created and they @mention both of us now.
I think "gamepad" is used by ugame- but I'm not quite sure how this all hangs together and what the dependencies are.
It looks like "gamepad shift" is not needed though, as it deals with shift-register based inputs which PicoSystem doesn't have! I'll rebase that out.
LGTM! Thanks @Fe7n for the PR and @FoamyGuy for the review.
Try disabling serial as well. Add these lines to your boot.py:
import usb_cdc
usb_cdc.disable()
Our Windows Drivers installer does not yet support the Pi Pico, and that may have something to do with this.
Also try Uwe Seiber's USB Device Cleanup tool, which may remove some bad state: https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#device-errors-or-problems-on-windows-3094694-15
I see that. ๐ Thanks for the heads up! RIP my inbox. Can you run it on a subset initially to verify that it's working properly before setting it free on the entire bundle? Or is that a huge pain to do?
Or did you do that already?
I have not done that yet. I can give it a try. I think it's possible by cloning a local copy of the bundle and removing all but a few of the submodules from the local copy.
If it's too much of an issue, don't worry about it. I'm sure it's fine. It's something I always ask of Dylan when running entirely new scripts on the libs, so I figured I'd ask you as well.
I'll try it out and if it starts looking too crazy I'll skip it.
Perfect.
@tulip sleet You around for a question regarding guide feedback I received? It's regarding the Windows 7 CP drivers.
I think the answer is delete and move on, but I wanted to give it a fair go.
AFK at the moment but will get back to you
Ok thanks!
?serverinfo
31k ๐
CircuitPython Weekly meeting happening in about 1 hour 45 minutes. Everyone is welcome to attend! If you're interested in participating either by attending or providing updates, please add your Hug Reports and Status Updates to the notes document before the meeting. Hope to chat with everyone soon! https://docs.google.com/document/d/1rS5p7xF_UUpumitnW2mV-B3IL7vB6e7V2HIAkk7Zo9E/edit# <@&356864093652516868>
CircuitPython Weekly for September 27th, 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canโt make the meeting and would still like to partici...
@idle owl Point me to the guide feedback and I'll take a look.
Oh! That's even easier. Hold on, getting link.
DM'd.
Like I said, pretty sure it's a delete and move on, but I figured I would at least check with you.
Alright, I ran it on 4 libraries, one package and one single file module for each of helpers and drivers type libraries. Looking over the issues it created now. As long as everything looks good with them I'll run it on the rest of the list.
@idle owl the 4 that it created look good to me. I'm going to try to figure out if there is a relevant rate limit for creating the issues and maybe add some delays to the process if so. But should be running it on the larger list starting shortly.
Great! Thanks for running the test.
I'll ignore email for a bit here ๐
okay, it's running now. If I'm understanding the rate limit endpoint correctly it's showing 0 used of all types so it seems maybe creating issues with the gh CLI tool does not use anything that is limited. It's taking about 3 seconds per library, and stops for manual intervention on ones where the adafruit repo was forked from a different user to ask me which user it should use. I'm keeping an eye on it and doing that as needed. Should be done in 5-10 minutes I think if the pace holds.
Ah fair enough. Sounds good.
Ah, nope it started failing with GraphQL error: was submitted too quickly
I will save the output from what it's done so far and start up the remaining ones in a little while.
Yikes -- maybe I should do a "reply-all" to each of those e-mails from @lone axle ๐
Generally deinit should undo never_reset. Never reset is only meant to protect against bulk reset. Deiniting a specific instance should still work.
What is the NB after Challenger for? I'm wondering how it is different from the existing wifi board.
I think the permissions for this repo might be different from the majority of them: https://github.com/adafruit/Adafruit_CircuitPython_PCF8563 creating issue failed with GraphQL error: You don't have permission to add labels in this repository.
Thanks. I'll take a look.
@lone axle Fixed. The CPLibians team wasn't there.
The team is there now.
Oi. Wonder how long that's been the case - Adabot doesn't work without that.
I'll circle back and run it on that one at the end.
Thank you!
That makes sense... never_reset should protect from things like reset_port and not from an explicit deinit call.
At a lot of places I find that the never_reset mask isn't being reset on a deinit call, this shouldn't create any issues with the functionality of things but should be fixed in the long term. I'll open an issue for this.
@idle owl another one with the permission error here: https://github.com/adafruit/Adafruit_CircuitPython_Ducky
That's a recent one. Need to remember to mention it to Dylan too.
Fixed!
another newer one with the same issue: https://github.com/adafruit/Adafruit_CircuitPython_Pixelbuf
Fixed!
Alright. We've made it through the whole list now. There are a few that it skipped or didn't render properly. I'll go through and get them all squared away later on this afternoon after the meeting.
Excellent!
Internal meeting just ended. BRB!
Hmm. Audio not right.
uh oh
Work in progress. Sound-reactive blinky thing. Werewolf for scale. #CircuitPython #ulab https://t.co/fVTTxag1lo
The Apple IIe uses a custom microcontroller and ROM chip to put ASCII values into the computerโs memory. How hard could it be to replace that dual-chip setup with a microcontroller to emulate another kind of keyboard? Bald Engineer tries using an Arduino Mega 2560, Teensy 4.0, and a Pi Pico to replace a vintage ROM chip. See what works AND what ...
The NB stands for No Battery and is a spin off from the standard feather format. It adds 4 GPIO pins and deletes the battery connector.
@onyx hinge Yep. The main benefit that I use to checkout a PR branch:
gh pr checkout [PR #]
But I've also learned recently that you can leave reviews as well
gh pr review --approve -b "Tested successfully on PyPortal. Looks good to me"
It finds the active branch to know which PR to make it on.
wow neat!
I won't fight you for it ๐
As I understand it, the difference is the community bundle is meant for libraries supported by individual's whereas the circuitpython org bundle is for libraries supported by multiple folks.
it's "Circuitpython Organisation" Bundle not ".org" as in github organisation, aka https://github.com/circuitpython
the name is confusing because of "org" vs ".org"
One thing we do still need in the CircuitPython organization bundle is to get adabot (or some other tool) making the automated releases whenever one of the submodules has a new version. Right now the releases for CircuitPython organisation bundle are manual.
@idle owl I wonder if Jerry should go before Melissa since the topics are related
but we need the intro first so everyone's on the same page
okay
@gilded cradle do you have a link to show the sorts of issues you're concerned about? what do the errors look like, etc.
Let me check... It was a little while ago
(I'm just a user, is there a link to when these "calls" happen? It's very interesting)
You need to be part of the <@&356864093652516868> I believe to join
Sorry for the ping ๐
Ping.
they are mondays at 11am pacific 2 pm eastern
@heady island we meet most mondays at 2PM Eastern (US) time, you can ask to join @ circuitpythonistas to get notifications or to speak in the meeting, or check out our online calendar https://github.com/adafruit/adafruit-circuitpython-weekly-meeting
@solar whale it adds about 30 bytes to an mpy file
past meetings are available on youtube too: https://www.youtube.com/playlist?list=PLjF7R1fz_OOUvw7tMv45xjWp0ht8yNgg0
irrespective of the quantity of type annotations, those are removed
You can put the group name in backticks so it doesn't ping people.
thanks ๐
If a function says def f() -> int: ... the -> int part is just ignored by circuitpython, so if it refers to typing.List then it doesn't matter that this doesn't exist
@onyx hinge it was back and April and it looks like the GitHub Actions results have been discarded since then.
Here's the PR though: https://github.com/adafruit/Adafruit_Blinka_Displayio/pull/58
jerryn said "if you add a comment, you need to run the regression test" ๐คฃ
"should" ๐
we'll give you a "should"er to cry on
When I complete the annotations for a library this week I'll test on Blinka and microcontroller various scenarios to see if I can find out what if any possible issues may arise.
as a new user - a few blogs pointing me to this discord mentioned the PIO channel
If there was a msg to go to "new channel" it would be fine
@heady island would you like me to add you to circuitpythonistas?
Thanks
@slender iron sure! ty
Thanks all, hope everyone has a nice week! ๐
@slender iron The audio is borked on the video. My audio is fine, everyone else is consistently intermittent. Sigh. OBS did not indicate there were any problems.
argh
@slender iron Do I post it with messed up audio (it's pretty bad to listen to), or do we skip this week?
@idle owl I'll still listen to it ... but happy to test it and tell you if its unlistenable
Sure, thanks.
I think post it still with the first sentence of the description acknowledging the problem
They can at least listen to Kattni's excellent intro audio and bail out when the others start talking.
The others are inaudible \ unable to be understood.
Fair enough. I'll make it public and submit another PR to the newsletter.
It turns out that SimpleMath and ProgressBar libraries both already have type information for everything in them. So those are our first two completed libraries ๐ . I'll do some testing on Blinka and a Microcontroller this week with these two in addition to another library that I'll fill in the types for, maybe a display driver to validate Blinka_Displayio environment.
That's perfect. Thank you so much for looking into this and getting all of the issues made.
Not sure if this is the right channel but you all know the audio on CircuitPython Weekly for September 27th, 2021 video on YouTube is messed up, right?
This is the right channel, and yep. There was an issue with the recording this week. There is a discussion up a little ways in this channel.
There are text notes available here: https://github.com/adafruit/adafruit-circuitpython-weekly-meeting/blob/main/2021/2021-09-27.md if you're interested in seeing everything that was discussed on the audio.
Thanks
I will try to start making backup recordings again starting with next weeks. I was recording them for a little while but I got tripped up one week by having an extra discord window open and fell out of the habit after that.
There's a note on the video, and in the notes document regarding the audio. Apologies. The recording software did not indicate any issues, so there was no way to know until the recording had been completed.
@idle owl hey. any idea why no CP lib for this?
https://www.adafruit.com/product/1746
guessing because disco?
No idea! Probably? No idea when it was disco'd. Might have been pre-CP.
I never got one, looks like.
is opening an issue in bundle repo still how to request?
Um.... hmm. I thought it was opening an issue on the core. Let me take a look. Hold on.
@tidal kiln Open an issue on the core and label it "library".
That's where we have other driver requests.
ok. thanks. will do.
good to have to at least document, even if decide not to write
i'm not seeing any old issues requesting it?
core or bundle
Thanks for your insight @hierophect! Yes, I'm able to detect whether wake-up is from POR, BACKUP, etc...
I've continued to wrestle with getting CMP to fire an interrupt, but have been unsuccessful. I'm convinced there's some micropython/circuitpython interrupt handler I can't find that's quietly clearing the flag.
@tannewt are there any interrupt handlers or MP/CP things I could be missing that'd impact an RTC interrupt during fake sleep like this? Below is a print-out of relevant RTC r...
Bumps nokogiri from 1.11.5 to 1.12.5.
Release notes
Sourced from nokogiri's releases.
1.12.5 / 2021-09-27
Security
[JRuby] Address CVE-2021-41098 (GHSA-2rr5-8q37-2w7h).
In Nokogiri v1.12.4 and earlier, on JRuby only, the SAX parsers resolve external entities (XXE) by default. This fix turns off entity-resolution-by-default in the JRuby SAX parsers to match the CRuby SAX parsers' behavior.
CRuby users are not affected by this CVE.
Fixed
[CRuby] D...
CircuitPython version
Well, im doing what im told:
I run CP 7.0.0
all libraries are up to date
the content of my CP (Matrix portal M4)
Found device at /Volumes/CIRCUITPY, running CircuitPython 7.0.0.
adafruit_fakerequests==None
neopixel==None
adafruit_requests==None
adafruit_bitmap_font==1.5.1
adafruit_display_shapes==2.3.0
adafruit_display_text==2.21.0
adafruit_esp32spi==3.5.11
adafruit_io==5.5.0
adafruit_matrixportal==3.0.1
adafruit_portalbase==1.9.2
note tha...
In situations where types come from existing modules within circuitpython but those modules are not used for anything other than typing would it make sense to do imports like this:
try:
from typing import List
import digitalio
import busio
except ImportError:
pass
presumably digitalio and busio would not raise an error. But importing them could take up memory right? So doing the typing import first and catching the exception will prevent digitalio and busio from being imported when the program runs on a microcontroller?
That makes sense but I would add a comment like # Used only for typing. before the imports to make this clear.
Thank you
At a lot of places the never_reset mask isn't being updated on a deinit call, this shouldn't create any issues with the functionality of things but should be fixed in the long term. This issue was previously discussed in this conversation.
https://github.com/micropython/micropython/pull/6882 tries not to write too many bytes at once. See if we need to do this too.
Corresponding code for us is now in https://github.com/adafruit/circuitpython/blob/aa52d726de268562f7353264e88a45f8a235bd18/supervisor/shared/serial.c#L205-L215
This branch adds support for the STM32L4 family, specifically the STM32L4R5-based Swan board. The board found at ports/stm/boards/swan_r5
The changes are almost entirely compile time conditional and so should have minimal impact on other STM boards in the port.
I made an attempt at implementing WebUSB by factoring in the tinyUSB examples and working the Vendor class descriptor into the dynamic set of USB descriptors. It's not presently working as far as I can see, but also does no ha...
Looks good! Thank you!
How do you know it isn't getting into RTC_Handler? https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/supervisor/port.c#L477
How do you know it isn't getting into RTC_Handler? https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/supervisor/port.c#L477
@tannewt I've checked by added printf statements to RTC_Handler to check for COMP0 and COMP1. Only time I get something is when COMP0 fires for a sleep (for example).
Two other things to check would be GP2EN in CTRLB and also the errata. It's possible it's broken.
Is there any way to prevent lookup for a uf2 firmware file in CI for non-uf2 mcu's like esp32c3? Currently CI fails with the following error:
Cannot find file ../ports/espressif/build-microdev_micro_c3/firmware.uf2
Error: Process completed with exit code 1.
I'm not sure if it's there or if the information is duplicated somewhere else
I added the board in extension_by_board... doing a test now.
That worked! Thanks @jaunty juniper.
Add esp32c3 based MicroDev microC3 development board.
I seem to have forgotten (or broken) something... after having an esp-idf binary on an esp32s2, I'm unable to flash CircuitPython. Anything I try just gets the BOOT drive back on reset. Is there a canonical set of esptool parameters in use these days?
You may want to try erasing the flash before loading CP
yes, thanks, that did it
Great -- I've run into that a few times.
I'm guessing it would have also worked if I had installed TinyUF2
I'm featuring CircuitPython on the esp32s2 on the Hak5 YouTube channel and was pleased to see this is being worked on. Just wanted to mention I'd be happy to feature this on Hak5 with a shout-out and $100 gift card to whoever manages to pull it off, thank you all for your work!
does anyone know what's up with current main esp32s2 build errors related to undefined reference to 'port_i2s_reset_instance'? ...something to do with paralleldisplay
hmm, not here. just did a compile with no errors .
maybe due to CIRCUITPY_AUDIOBUSIO_I2SOUT ?= 0 to make space for DEBUG=1? I'll try a new scheme for space
yes, that makes sense
when there's a module dependency like that, is it typical for turning off a module to cause build errors, or is it more manual to keep track of those things? (I don't see a new flag for parallel display)
hm, re-enabling CIRCUITPY_AUDIOBUSIO_I2SOUT didn't do it, I'll just comment out the three lines of relevant calls for now
I think it needs CIRCUITPY_AUDIOBUSIO
ah, there they are, thanks!
but not sure it should be called in any case. i leave that to someone who better understands what they have done with I2S
I don't think they are called, but build gets unhappy
its called in the deinit i think.
oh, like from a hard reset?
ugh, so I infer that it's manual to know which modules depend on others when turning off modules (for space)
i guess, freeing up the i2s instance that was created for parallelbus.
thanks for your help, back in business ๐
๐
hihi please run pre-commit or fix up formattin' so we can pass CI
https://github.com/adafruit/circuitpython/pull/5403/checks?check_run_id=3737657712
Should be good now. :-) 2 commits were needed - for some reason running the pre-commit hook locally didn't fixup all the problems. I made commit fbf8159 by running the formatter directly on the files affected.
There's a very rough and rudimentary POC here, basically the Espressif sniffer example, shoehorned into CP and tweaked to parse the more interesting RX_CTRL header and frame header fields and split up the frame body into its fixed and variable (Information Element) components, just enough to extract an SSID if available. Management frame type only at the moment, any subtype. Channel changes after each frame. CircuitPython code just s...
is it possible to see the resulting html files from the sphinx docs build from a PR branch before the PR is merged? or is that only visible once it gets merged and is then shown on the readthedocs pages?
๐ค I would build them locally
The thing is, I think I'm seeing different results locally compared to what is getting generated by actions. I'm trying to determine specifically what the ones generated by actions will look like because I suspect that mine locally are different and not correct.
Now I'm seeing different results than I was getting the other day even though I don't believe anything int he environment or code should be different ๐
oof
@lone axle I don't think the doc artifacts from github builds go anywhere, but that doesn't really matter as what is shown on readthedocs doesn't come from there either
.. it comes from readthedocs own process
I was having this strange difference between Sphinx running in actions vs. running locally. Actions completed successfully, but locally failed.
The user that made that PR also saw the same error locally that I was seeing.
But actions completed successfully. And now if I go back and run the build on the same code locally it's succeeding. I don't know what could have changed ๐
That looks like a problem with a mocked module. If that doesn't mean much to you I can say more..
I agree, and the error does make sense to me. And I was able to get passed one of the errors by adding microcontroller to the mock list. But it's not there in the actual repo. So I don't understand how it didn't have the same error when it ran inside of actions.
the fake version of a module provided in this way works in some respects, but not all. So for the error you linked to,
"/home/timc/repos/circuitpython/Adafruit_CircuitPython_BLE_Radio/adafruit_ble_radio.py", line 51, in _RadioAdvertisement
match_prefixes = (struct.pack("<BH", 0xFF, _ADAFRUIT_COMPANY_ID),)
I am guessing that _ADAFRUIT_COMPANY_ID is a mocked object, and that simply can't stand in for the kind of object that struct.pack requires.
it's not listed in conf.py though: https://github.com/adafruit/Adafruit_CircuitPython_BLE_Radio/blob/2bd9f0ddc2206a3e1c16ed383a4e0f68915e1d8a/docs/conf.py#L28 is there somewhere else that those can come from when it runs in actions?
from micropython import const ... _ADAFRUIT_COMPANY_ID = const(0x0822)
so if from micropython import const fails, then const is a mocked function, and its return value is a mocked object. That mocked object, whatever it is, doesn't work with struct.pack. from micropython import const should come from adafruit blinka, I suppose?
it did seem related to const() to me. I noticed that when I was getting that error locally if I removed the const() call wrapping the value that it was not having the error any more.
requirements.txt lists Adafruit-Blinka so from micropython import const seems like it should work
I do think blinka contains a placeholder for that. I believe that my local environment had the same version of Blinka installed as the actions did though. But I'm also not getting the error now when I run it on the same library
hmm maybe I was wrong about it being installed at the time I guess. If I uninstall it now I can force the same errors to appear
okay. It specifically needs to have adafruit-blinka installed and not to have microcontroller in the mock list
what's odd to me is, conf.py doesn't specify to mock the micropython module, so it should have made the import an error instead. Or maybe a mocked module is mocked as a first resort instead of a last resort.
the docs are not super clear on this point
Maybe I started without blinka installed, added microcontroller to the mock list. Then installed blinka but at that point still ended up with argument is not an integer I needed to go back and remove microcontroller from the mock list.
It's probably an entirely different issue. But this is the other thing that came up tonight that made me believe that the actions sphinx run can result in different outcomes / files than the local one. For this display driver the current file in readthedocs shows the correct arguments for the class:
But when I run the sphinx build locally against main I end up without the bus argument:
Maybe the deal is that readthedocs process differs slightly from Sphinx.
do you have adafruit-blinka-displayio installed?
I ask because the only thing that "smells like a mock" is the fact that ILI9341 subclasses displayio.Display
I do
I wonder if this configuration https://github.com/adafruit/Adafruit_CircuitPython_ILI9341/blob/9a3e9c3adeb5949567271cd99de349a08db9e47b/.readthedocs.yml#L6 is causing the docs to get built with python 3.0 inside of readthedocs.
I'm not sure if I'm understanding the documentation for that correctly, but I see something are listing a specific version like 3.5 or 3.7
maybe it installs python3 and ends up with whichever version happens to be marked as stable inside of it's VM which I guess would depend on the specific OS it's using.
Anyway I appreciate you taking a look and offering up some ideas. With your help I think I've understood what happened to me the other day with the BLE_Radio library, which was definitely more concerning to me since it was error vs. no error. This difference is relatively minor in comparison.
Locally, I have to remove displayio from autodoc_mock_imports to get the correct signature.
Ah! nice find. same here.
but in actions it would fail since it wouldn't have adafruit-blinka-displayio maybe
it's listed in requirements.txt so it should
oh, actually that is in requirements, yep
It makes me wonder how the copy that is currently in readthedocs came out correctly. But I can probably put that curiosity out of mind. I have a PR for typing open in that driver, I'll try removing the mock for displayio from conf and see if it remains happy.
readthedocs says projects created a long time ago use an old sphinx version
Downloading Sphinx-1.8.5-py2.py3-none-any.whl (3.1 MB)``` and in fact
which could easily make its behavior different than what you see locally.
Oh wow, I don't know what their release pace is like but that does seem quite old. That is very likely it
I wonder if projects created before that can specify to use a newer one.
and we're currently at 4.2.0
I have to assume so, but I don't seem to have the privileges to look or change it for this particular repo
https://github.com/readthedocs/readthedocs.org/issues/6296 maybe including sphinx with a version in requirements.txt
You have solved so many mysteries for me, I have suspected differences on a few other occasions but never chased down the specifics this far. Thank you so much for taking the time! I really appreciate it.
I have a RTD project registered in 2017 but I don't see a setting for sphinx version in the admin pages
okay, goodnight
it sounds like you should be able to put an explicit sphinx requrement and have it honored, yeah
I was quite surprised that the same encoder increments once per "dent" in Arduino, but once per 3-4 "dents" if connected to Pico running CircuitPython
Is there a progress on correcting this? Can I just alter some C code to get Arduino-like behaviour ie higher resolution?
@teal condor you can get more help in #help-with-circuitpython channel... this channel is primarily used for circuitpython development work. ๐
Thanks! I'll ask my question there itself, won't clutter here ๐
CircuitPython version
Adafruit CircuitPython v 7.0.0
Code/REPL
import _bleio
adp = _bleio.adapter
msg = bytes('abcde', 'utf-8')
adp.start_advertising(data=msg, # msg is of bytes type
connectable=True,
anonymous=True,
timeout=30,
interval=0.1,
tx_power=4)
Behavior
Traceback (most recent call last):
File "", line 5, in
...
Hi
I am really loving my Raspberry pi pico, but currently i need to switch to the US keyboard(or other languages, US is just my default when i do this), so when i want to show scripts to my friends they need to change the keyboard language on their pc, which just really ruins the "magic" of it.
I would be more than happy to make the new setting, but i have never tried to do it before, so i dont really know how to, never the less i will try.
-Sรธren
I believe what you want is to look here for international layouts:
https://github.com/Neradoc/Circuitpython_Keyboard_Layouts
Thx so much for the help, i wouldnโt have been able to find this if it werenโt for you, again thx
Fra: @.>
Sendt: 29. september 2021 14:24
Til: @.>
Cc: @.>; @.>
Emne: Re: [adafruit/circuitpython] Danish Keyboard (#5406)
I believe what you want is to look here for international layouts:
https://github.com/Neradoc/Circuitpython_Keyboard_Layouts
โ
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https:...
@dmikhalsky We don't see skipped increments on RP2040 in general. The MacroPad has an on-board encoder, and the "MacroKeys" program, which uses rotaryio, is changing things once per detent. How fast are you spinning the encoder, and is it a regular encoder like the one in our store?
PS: If you could also help me resolve the
_bleio.BluetoothError: Unknown system firmware error: 0009, that would be great! I tried sending a blank string payload, it worked, but it is not working if I send any other string. What should I do?
The data you're trying to send is an ill-formed advertisement. An advertisement contains chunks of data in a specific format, with type and length bytes, etc. If you use the https://github.com/adafruit/Adafruit_CircuitPython_BLE library, it will he...
@dhalbert
Yes, the encoder is vanilla "aliexpress-type" one. I am just starting with CircuitPython and Pico and tried examples from https://learn.adafruit.com/rotary-encoder/circuitpython
In both examples the encoder behaves the same. In the HID one, it took me 4-5 full rotations to go from zero volume to full volume.
Serial debug shows the same. I rotate the encoder very slowly and it increments every 3-4 dents.
I am pretty sure the decoder is OK as I just recently used it in another Ar...
@dmikhalsky I would not expect those results, so it might be a wiring issue. Could you take this to https://forums.adafruit.com/viewforum.php?f=60 ? Post your code and a picture of your wiring. We try not to do support in GitHub: it's for bug and feature tracking, and I don't think this is a pervasive bug.
Native method implementations that use mp_arg_parse_all() should be able to accept positional args that are labeled with keywords, but they are not.
Here is an example showing the issue with busio.SPI.
Constructor signature:
busio.SPI(clock: microcontroller.Pin, MOSI: Optional[microcontroller.Pin] = None, MISO: Optional[microcontroller.Pin] = None)
Method signature:
write(self, buffer: _typing.ReadableBuffer, *, start: int = 0, end: Optional[int] = None) โ None
...
A list of modules that need to be modified to work on esp32c3:
- [ ] ALARM
- [ ] ANALOGIO
- [ ] AUDIOBUSIO
- [ ] COUNTIO
- [ ] FREQUENCYIO
- [ ] IMAGECAPTURE
- [ ] PARALLELDISPLAY
- [ ] RGBMATRIX
- [ ] ROTARYIO
@idle owl I wrote a library https://github.com/adafruit/Adafruit_CircuitPython_Radial_Controller which I expect to use in a Learn Guide, showing the code. But maybe I should just put the code in the Learn repor? Do we have guides that point to code in libraries, not just in the Learn repo? I have a sample boot.py and a sample code.py to show, but they are in examples/ in the library (and are named differently.
There are guides that point to library repos instead of specifically the Learn System repo. Most of the "Primary Guides" for specific hardware devices that I've run across embed example code from the driver library repo instead of the Learn System repo. For example, this page: https://learn.adafruit.com/adafruit-128x64-oled-featherwing/circuitpython embeds from: https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_SH1107/blob/main/examples/displayio_sh1107_simpletest.py
Thanks! I was looking for an existence proof, and that is exactly what I need.
@tulip sleet and once the library is in the bundle, within 24h you should have a folder-image for the examples at https://adafruit.github.io/Adafruit_CircuitPython_Bundle/
I think it happens each time the bundle is released
Sounds like you're good to go?
Yes, thanks!
Great.
TimeAlarm and PinAlarm are now both working on https://github.com/maholli/circuitpython/commit/d536be7228eac78b95e0b838110997434bcdad7a.
But there are caveats!
- PinAlarm uses only the
TAMPERpins for deep sleep. PinAlarm is also working with light sleep, but that's achieving the same power consumption astime.sleep()so we may want to remove it. - There are only a couple
TAMPERpins:
<img width="500" src="https://user-images.githubusercontent.com/29153441/135322362-07a43f23...
Here is the notes document for Mondayโs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youโll be attending the meeting - itโs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weโll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1_ZwlimMfNiDPSwWszVzGFMKQzGXSjmb5TzzhQ97kiOY/edit
CircuitPython Weekly for 4 October 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canโt make the meeting and would still like to participate, ...
@tulip sleet Are you going to submit your lib to the bundle?
yes, i'm just trying to get readthedocs set up. it's not showing up as a subproject to add yet
Did you add adabot as a maintainer? So I can take a look.
not yet, but I was looking at the HID library as an example, and it doesn't have adabot as a maintainer either, which is weird
Yes it does?
No, on Read the Docs itself.
Is where you add maintainers to docs.
Did you set up your lib on RTD?
(brb)
oh, yes, I was looking in Subprojects by mistake
Back.
ok, i added the project, added the webhook, and added it as a subproject
Excellent. Did you add adabot as a maintainer on RTD?
I'm logged in as adabot, not me, I always do that
it's one less step
Yep.
do i need a discord webhook too?
No.
I think I'm all set then, I'll make a PR to add it to the bundle. A little weird the code is not reviewed, but that's always true when I create a new lib
We'll find out if there's bugs once folks are using it ๐
yeah ๐
Complaint driven development.
lol
@tulip sleet Merged your bundle PR. Thanks for submitting it!
thanks! onward
anyone know if it's possible to restart a CI run that's like 15 months old and the logs are gone?
Link?
it will still run against the old commit it's trying to merge to, you'd have to push a new commit to get it try against the latest
Yeah that would work. Push an empty commit should force it.
not my pr though. don't worry about this if not quick/easy answer. it's not a CP thing.
would like to see all the output from the CI run on their last commit
if they allow maintainer pushes, you could clone their repo and still push an empty commit. or just edit in GitHub and add a period to the end of sentence or something like that
oh yah. that trick. i'll try that. thanks.
Yeah looks like simply doing the restart from GitHub won't work. Edit a file would work.
dan's trick worked. thanks!
yah, looked all around for a "restart" option. did not find.
Same.
thanks for looking!
You're welcome!
Sigh. I have a Feather M4 that isn't showing CIRCUITPY.
Unplug and replug fixed it. Ugh.
@tidal kiln OK, I'm tagging you in. How do I pull a GPIO pin low in CircuitPython? e.g. simulate it being tied to gnd. (This is for that encoder again.)
I think I did it right. But the encoder isn't being read.
The buttons work, but the rotary encoder is doing nothing.
Double checked the pins.
Similar code worked for JP. Except he tied the pins to GND directly.
And my center button is intermittent which is even weirder to me.
Maybe this hack isn't possible on CP. Arduino sets the pins to output, pulled low. Can't do output and low in CP.
I'll check in again in the morning.
@dhalbert @hathach do either of you have something to say about whether this is right or better done in another way? I'm not familiar with webusb so I don't understand what is going on here.
I think all new sites of allocate_memory need to be accounted for in the macro CIRCUITPY_SUPERVISOR_IMMOVABLE_ALLOC_COUNT or CIRCUITPY_SUPERVISOR_MOVABLE_ALLOC_COUNT in supervisor/shared/memory.c
Tested with AI Thinker board.
The USB Vendor stuff was added by a contributor for 6.x. I did not attempt to redo this for 7, and I assumed it needed to be reworked.
WebUSB is more complicated than WebSerial, and I'd recommend trying to use that if possible.
@bsatrom Did you test webUSB? Are you using it?
Hi,
Would it be possible to add the i2cperipheral module to RP2040-based boards like the Pico? It looks like the Pico SDK has an i2c_set_slave_mode function so set one of the i2c ports into slave mode. Presumably that could be used as the basis of an implementation?
It is certainly possible to add i2cperipheral on RP2040 now that the pico-sdk has support for it.
CircuitPython version
Adafruit CircuitPython 5.4.0 LoC BeR M4 base board with samd51g19
Code/REPL
import time
time.monotonic()
# in code and the command line, the fraction of seconds was always .0
Behavior
I did observe this behavior last night on a device that was running for many days.
Note: that also after breaking the code with ctrl-c and importing time
and entering time.monotonic() in the command line, the fraction of seconds was always...
@idle owl guessing its something else, and probably something simple? should be doable. just your basic
pin.direction = digitalio.Direction.OUTPUT
pin.value = False
@tulip sleet hey. there was a "CIRCUITPY not showing up on win 10" thing in #help-with-circuitpython last night. i think maybe it ended up being a known scenario? looks like they got it working eventually.
This is a known problem with time.monotonic(), because of the low precision of floats (5-6 digits). We recommend you use time.monotonic_ns(), if you board supports it (must have longints). Or, if it works for you, you can use supervisor.ticks_ms(), which wrap but keep their precision.
See https://github.com/adafruit/circuitpython/issues/342#issuecomment-337228427 for some background on the precision issue.
Ok, thank you taking a look at this so quickly and for the explanation.
It would be helpful if is this information would be available at:
https://circuitpython.readthedocs.io/en/latest/shared-bindings/time/
Also a possibility to programmatically reset to time.monotonic "0" would be helpful, as this situation can be detected quite easily, now that I know how,
Could have been a badly corrupted CIRCUITPY, or Windows seeing too many errors on the USB port and then refusing to see the device. It does look like Uwe Sieber's Device Cleanup fixed it
yah. probably the latter.
As suggested by @ThomasAtBBTF in #5411.
Hello all,

I am having nearly 10 - SCD_30 Sensors for measuring CO2 Value, Temperature, and Humidity for an project.
I was recording succesfully all the values without any problems making simple circuit with rapsberrypi:
Vcc,grnd, SDA, SCL and SEL.
Suddenly i am getting value of 0.0 for CO2 alone. i am not sure why its happening. But works fine with different sensor with ...
Certain functions (e.g. enable_autoreload(), disable_autoreload() etc.) could benefit from set and get methods when implemented as a property, this would reduce the number of individual functions.
Modules (as opposed to class instances) can't in general have properties, so we'd need a singleton of some kind to hold the properties. For instance, microprocessor.cpu is a singleton instance of Processor, and it holds properties like temperature.
@tulip sleet sry for asking yet again, but what is latest approach for flash erase? (when REPL access not possible) still here?
https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#old-way-for-the-circuit-playground-express-feather-m0-express-and-metro-m0-express-2978458-30
That is the only way if REPL access is not possible. You might be able to enter safe mode by the "slow" double-click method. So, "old" was only with respect to reformatting a corrupted filesystem. It's still the only way when there's absolutely no way to get to the REPL.
oh. yah. safe mode.
for the other approach, if there isn't a UF2 eraser for target board, then what?
im 0 for 10 trying to get into safemode
I usually only get there by mistake
In CPy 7, click reset, and then click again in about half a second, while the RGB is yellow. You can't wait for the yellow, our reaction times are too slow.
The other way is to build one of my CIRCUITPY-ERASER-DANGER uf2's, which involves changing one boolean. I can make you one or tell you how.
if they are starting with an older firmware version, could they update ok? they still won't get CIRCUITPY, but firmware will update to 7? (to make getting into safe mode easier)
board is qt py m0
sure
Running in safe mode! Not running saved code.
You are in safe mode because:
You pressed the reset button during boot. Press again to exit safe mode.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 7.0.0 on 2021-09-20; Adafruit QT Py M0 with samd21e18
>>>
ok, yah, that was easier with 7
we lengthened it from 700ms to 1sec
To create a CircuitPython that reformats the filesystem every time it starts, in circuitpython/main.c, change the false to true and rebuild:
// Create a new filesystem only if we're not in a safe mode.
// A power brownout here could make it appear as if there's
// no SPI flash filesystem, and we might erase the existing one.
filesystem_init(safe_mode == NO_SAFE_MODE, false);
any chance that could get added to the ci so one gets built for all boards?
we had a long discussion about this: https://github.com/adafruit/circuitpython/pull/4722 and ultimately didn't do it
make clean doesn't delete "index.rst" files, does it ? is there a way to remove them after a make html ?
@tulip sleet I'm hitting the HardFault_Handler when developing samd fake deep sleep. But only on some boards. What's the easiest way to debug this? Do I need to dust off GDB?
That is the easiest way. Set a breakpoint on HardFault_Handler or, better reset_into_safe_mode(), and you'll see what led to the hard fault.
yah, it really should. I think right now they are .gitignore'd.
yep, specifically /shared-bindings/*/**/*.rst is ignored
@onyx hinge The generated screenshot images for project bundles: where are they committed? I see the form of the github.io URL, but I can't actually find where they are pushed to, despite reading images.yml in the Bundle repo.
@tulip sleet the github.io page is showing https://github.com/adafruit/Adafruit_CircuitPython_Bundle/tree/folder-images
OH, a separate branch
if git commit -m"update images"; then git push -f origin HEAD:folder-images; fi the name of the branch is hidden in this git command where nobody will ever find it
yes, I never found it ๐
github pages likes to serve everything from a particular branch of a repo, usually not the main one
Maybe I will add that to the README, not sure it's documented anywhere
agreed, it needs to be documented. and maybe rolled out to the other bundles.
thanks!
you're welcome
Hi there @dhalbert! We have not yet done thorough testing, but I have seen the device accessible from the browser - I plan to circle back on this over the coming days.
Because it is conditional code, I thought it would be ok including it so others can build on what is done here, but I'm happy to remove those changes if they are blocking approval of the PR. They are not needed for this board at present.
Has anyone had any trouble looping an MP3 in 7.0? I pulled out an old project (HallowWing M4) and even with loop=True it stops playing after one loop
It's possible we missed testing that. Could you file an issue with a simple example? Thanks.
Will do, just wanted to check first, haven't had much of a chance to look into it further
CircuitPython version
Adafruit CircuitPython 7.0.0 on 2021-09-20; Adafruit Hallowing M4 Express with samd51j19
Code/REPL
import board
import digitalio
from audiomp3 import MP3Decoder
from audioio import AudioOut
speaker_enable = digitalio.DigitalInOut(board.SPEAKER_ENABLE)
speaker_enable.direction = digitalio.Direction.OUTPUT
speaker_enable.value = True
audio = AudioOut(board.SPEAKER)
mp3 = open("laugh.mp3", "rb")
decoder = MP3Decoder(mp3)
a...
๐ That was it!!!!! Thank you so much. Went around in so many circles with that. The solution is so obvious but was nowhere on my radar.
Now to figure out how to make the pixel move with the encoder.......
cool. np.
ping me if you want if you run into other oddness
is that the only wiring connection you plan to show in the guide?
That was the plan yeah. Limor said it was fine when I checked in to verify.
I guess I could show it "wired up" typically as well. But I'll have to test it. <grump>
i'd suggest mentioning the general nature of the hack, like "doing this just so it can be plopped down on a bread board next to a feather"
otherwise it will be interpreted as the required way to wire it up
Valid point.
put in the text. put it in a call out box. make it bold. make it blink. make it scroll.
Call show().
@tidal kiln Don't suppose you want to help me with the pixel code? I'm trying to port an Arduino sketch and I'm not quite getting it. I have it lighting up a pixel as it moves around, but either it's not turning off the other pixels after it lights them up, or it turns them off but only flashes the pixel as it moves.
sure. same ard code from yesterday?
Yes.
Here's what I have in CP so far: py while True: position = encoder.position if last_position is None or position != last_position: print("Position: {}".format(position)) last_position = position pixels[position % len(pixels)] = (0, 150, 0) pixels.show()
This lights them up but does not turn them off behind it.
If I add an else: pixels.fill(0) after that, it only flashes it as it moves.
(with show())
is position generally working? like if you just print that value and spin dial - changes as expected?
Yep, it is now, thank you for help with that.
I think it's a good start. Ready for another review?
ah. just add a pixels.fill(0) in there.
pixels.fill(0)
pixels[position % len(pixels)] = (0, 150, 0)
pixels.show()
Now nothing lights up.
Oh
hold on
Magic!
I was so close!
Thank you ๐
I think I can figure out the rest. I'll ping you if I run into another wall.
that's the equiv of the pixels.clear(); line in the ard sketch
Ohhhhhh
Are you actively working on adding BLE workflow support? I'm a bit worried we're going to start getting a support burden of people trying to use C3 boards over USB.
Tricksy
I'd like to wait a bit while we resolve #5404.
and the arduino sketch is only using that conditional for the serial prints
We should probably add a support note about the C3 to the README too.
if (curr_rotary != last_rotary) {
Serial.print("Encoder value: ");
Serial.print(curr_rotary);
Serial.print(" direction: ");
Serial.println((int)direction);
}
everything else happens outside the conditional in the loop
I'm not sure I know what you mean by conditional.
your check here if last_position is None or position != last_position:
the pixel updating can be outside that
Not sure I need auto_write=False to begin with.
Which would clean up the show()s.
I took it out for the encoder pixel, and it seems to be working ok?
get position and button info
clear all the pixels
set pixel(s) based on position/buttons
show
repeat
i would. i'd turn auto_write off and call show at the end.
I think it's a good start. Ready for another review?
Not quite. I'll ping you when I get things cleaned up. Do you want that to be a PR?
Wait, what?
you do several pixels sets - for the dial and then for each button?
Yeah. But the button code is different. Because I created them in a list.
for i in range(len(buttons)):
if not buttons[i].value:
if i == 0:
print("enter")
pixels.fill((100, 100, 100))
# pixels.show()
if i == 1:
print("up")
pixels[0] = (150, 0, 0)
# pixels.show()
if i == 2:
print("left")
if i == 3:
print("down")
if i == 4:
print("right")
else:
pixels.fill(0)```
Haven't set them all yet
And was trying with show() at the end
it does not function as expected.
With that code, with a show() after it at the same indent as the for, it simply turns off the LEDs when I press a button.
did you enable pull ups on the inputs?
Yep
button_pins = (SW1, SW2, SW3, SW4, SW5)
buttons = []
for button_pin in button_pins:
pin = digitalio.DigitalInOut(button_pin)
pin.switch_to_input(digitalio.Pull.UP)
buttons.append(pin)```
They work. It prints the right thing when I press a button.
So I crash into HardFault_Handler on a pycubed board on builds WITHOUT DEBUG=1 but it runs fine on builds with DEBUG=1. Have you encountered this?
@idle owl wanna move to #help-with-circuitpython ?
Sure. Or we could move to a thread. Up to you.
#help-with-circuitpython doesn't seem busy. We can do that.
We should probably add a support note about the C3 to the README too.
Sure, I'll add it in a separate PR.
Are you actively working on adding BLE workflow support?
Yup! I have started working on it and have got the basic stuff ported to esp from nRF implementation.
I started with the smaller things like UUID, Descriptor, Service etc. and am incrementally moving to the larger things.
hmm. let's try thread. need more experience using those.
Oh, sure, many times ๐ . There are two common reasons I've encountered for DEBUG/no-DEBUG crash differences. One is that the bug is a second-order bug: something was smashed a long time ago, so reordering code, storage, etc., changes the bug. The other is that something that should be volatile is not volatile in the no-DEBUG build, but is accidentally volatile in the DEBUG build due to optimization differences.
You could try doing a -ggdb3 build with the regular optimization; it may already be set to do that. Can you get a backtrace? You can get a less-informative backtrace without debug symbols in the no-DEBUG case.
Thanks for that. I'll add to the enum. I won't push until we have a clearer idea of what we're doing with the WebUSB support, since the CI build is quite expensive. :-)
ooo I'm going to look into possibly missing a volatile. In the meantime, how do I snag a backtrace from a no-DEBUG build? I'm using AS7 (which just learned they renamed to microchip studio haha)
i have no idea how to do it in AS7. I always use gdb.
Maybe you can still set a breakpoint.
tried but it couldn't find the function. I'll thrash a bit and let you know
I have got nothing functional with BLE yet and things will probably remain in this state for a while.
My concern is that CI is not being run for esp32c3 at present due to no boards.
I think we can have an esp32c3 board with a big note in README for the time being. :-)
I'd like to wait a bit while we resolve #5404.
Sounds good. Will look at some other stuff until then .
Big note in README is fine with me. Thanks!
Updates readme to include esp32c3 related documentation.
@tidal kiln Bold and info-y enough?
yah. hopefully.
maybe slightly different text
the more "normal" way would be tie COMA/B to GND
Updated.
The wiring shown here ties COMA/B to digital outputs set LOW instead of GND to allow for the direct-to-Feather connection.
?
Hmm yeah.
I wonder if it would be good to add a warning that this trick is not good for devices that take more power, because the gpio pins can only sink so much current.
I don't follow. What devices that take more power?
like, you couldn't use this trick for the GND of a neopixel strip
I mean, it's going in a guide for this specific device.
We show wiring diagrams in guides for other devices.
So I don't think it's necessary to extrapolate here.
I guess if it comes up, we deal with it. But I think it's fine here.
I think it would still be nice to explain when it's safe to repeat such technique, people are going to pick up this trick and try to use it in their own devices
I think this is actually a nice learning opportunity here, since there is a neopixel strip being used in the same project, so it could be mentioned that its gnd has to go to true gnd
CircuitPython version
Adafruit CircuitPython 7.0.0 on 2021-09-20; Raspberry Pi Pico with rp2040
Code/REPL
import time
from math import sin
import board
import displayio
import rgbmatrix
import framebufferio
import adafruit_imageload
import terminalio
from adafruit_display_text.label import Label
displayio.release_displays()
matrix = rgbmatrix.RGBMatrix(
width=64, bit_depth=6,
rgb_pins=[board.D6, board.D5, board.D9, board.D11, board.D10...
Hmm fair enough.
@tidal kiln Tagged you on this as well as Limor, since you seemed familiar enough with it. https://github.com/adafruit/ci-arduino/pull/107
@tidal kiln Do you know how long it takes for updates to that file to propagate? Is it instant because it pulls from the latest version? Or is there latency on that. (Submitting code to Learn soon that will need this update.)
unless it's cached, i'd expect instant
OK that's what I was thinking too.
Thanks - I'd say leave it in, maybe with a comment caveat that it's not fully tested, since we only turn this on for one other board right now.
the ring buffer is hurting my brain... each element is limited to two bytes?
yes, and the two-byte is hacked on. We got it from MicroPython
it could use a rework, but it's small
do we have a queue-like structure that can handle arbitrary number of elements and types?
or is that an exercise left for the reader ๐
I'm wrestling with either queueing up blobs of bytes that Python can dissect, or queueing up distinct fields that can be directly accessed
If parsing in c is significantly faster then in python which I believe it is then this can be left for the user to decide from python side.
the event queue (like keypad) is ideal conceptually, but my events have relatively large amounts of data
unless maybe the queue contains mini-pointers to pointers to chunks of memory with the data
I am thinking of something like these formatting settings wifi.Packet.RAW, wifi.Packet.SSID, wifi.Packet.RSSI.
haha, implementing anything like that is many levels above my current (not much) skill ๐
I'll take a look at your implementation today and see if I can help out with something. ๐
thanks, but I haven't pushed the current work. The existing stuff is really raw and naive (nothing passed up, just serial dump)... what I've been doing today is trying to adapt keypad into a separate module, which was going OK until I got to the ringbuf
That's okay... I will be looking mostly at the forward api.
i'll push what I have, it's a separate branch 'monitor_queue`
I may also look at how BLE or wifi do scanning, but I've come to think that will give results that are too "chunky"
(bursts of frames followed by intervals of missed frames)
ya packets are much heavier than that
(if you look, I just put a couple of fields in to see if it could work and how that would ripple through the code, but that would get unwieldy with a bunch of fields)
I did shared-bindings first, should have started in common-hal
Was following the learning guide https://learn.adafruit.com/building-circuitpython/build-circuitpython
But encounter the following error:
$ make V=2 BOARD=circuitplayground_express
GEN build-circuitplayground_express/genhdr/mpversion.h
python3 ../../py/makeversionhdr.py build-circuitplayground_express/genhdr/mpversion.h
make: *** No rule to make target 'freetouch/adafruit_ptc.c', needed by 'build-circuitplayground_express/genhdr/qstr.split'. Stop.
Any advice ?
@misty storm forgot to do the git submodule update --init?
Checked and confirm I have done that. I was able to make mpy-cross.
invoke make with the -d flag reveals more hints as below:
Trying implicit prerequisite 'freetouch/SCCS/s.adafruit_ptc.w'.
Trying pattern rule with stem 'adafruit_ptc'.
Rejecting impossible implicit prerequisite 'freetouch/adafruit_ptc.w'.
No implicit rule found for 'freetouch/adafruit_ptc.c'.
Finished prerequisites of target file 'freetouch/adafruit_ptc.c'.
Must remake target 'freetouch/adafruit_ptc.c'.
make: *** No rule to make target 'freetouch/adafruit_ptc.c', needed by 'build-circuitplayground_express/genhdr/qstr.split'. Stop.
So it is saying it needs to create this file adafruit_ptc.c in folder freetouch, which consists of only one file .git
SAM D5x/E5x family datasheet says that there's a watchdog timer peripheral available. Add support for this to the existing CircuitPython watchdog module.
samd21 also has a watchdog timer, but it's less likely that there's room for an implementation on those older/smaller chips.
Thanks for the hint. I did carry out this step but always encounter error when trying to clone the esp-idf sub folder. I think this may cause the repo clone to be incomplete and hence the build error.
But then my question is how to tackle this GnuTLS recv error (-24) ?
Cloning into '/mnt/c/Users/kevin/Documents/mcb2/circuitpython/ports/espressif/esp-idf'...
error: RPC failed; curl 56 GnuTLS recv error (-24): Decryption has failed.
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
fatal: clone of 'https://github.com/espressif/esp-idf.git' into submodule path '/mnt/c/Users/kevin/Documents/mcb2/circuitpython/ports/espressif/esp-idf' failed
Failed to clone 'ports/espressif/esp-idf' a second time, aborting
@misty storm I use this alias:
alias gitsubupdate='git submodule sync --quiet --recursive && git submodule update --init'
so you are using WSL? It looks like you are trying to share storage with your Windows filesystem.
You may also have symbolic-link issues if you try to use /mnt/c
@crimson ferry ports/nrf/common-hal/nrf/_bleio/PacketBuffer.* uses a length header when storing variable-length stuff using ringbuf.
you could also consider using Python lists if you are storing python bojects
@misty storm I think I've seen someone complaining recently about a certificate error with esp-idf somewhere
what is the overall thing you are trying to implement?
looks like one of their certs expired
one possible workaround would be to temporarily disable ssl verification with git config --global http.sslVerify false โ just remember to switch it back to true afterwards
@tulip sleet thanks, Iโll look at that. Iโm trying to get wifi frames up to pythonโฆ variable-length bytes if raw, and/or a collection of various types of data if parsed in common-hal
suppose you create a bytes with the data and then just push it on a list
itโs a continuous process, so the queue is essential
๐ the first one is, but the "collection of various types of data", that's broken up into objects, is it?
yes, either way, itโs a continuous firehouse of frames
that is kind of what PacketBuffer is doing
iโll dig into _bleio, thanks
@crimson ferry you could also consider leveraging the code for collections.deque. This would let you work with fully-formed CircuitPython objects rather than low-level C structures. There's not actually a C API for deque objects but we could either (A) expose one internally or (B) your code can go via mp_call_function family functions to call the methods
(I didn't read the full discussion so please forgive if this is irrelevant advice given the full context)
Thanks, that may well be helpful though most of the stuff between python and simple things in common-hal is still pretty murky to me, so I don't know what a good design looks like. keypad looked really nice to handle continuous events, maybe _bleio.PacketBuffer is a way to extend that to larger / more complex data. There's already a queue at the common-hal level, triggered by an event-handler, but the goal is to get those queued elements containing many bytes (and / or mixed-type data parsed from those bytes) up to Python in a dynamic, more continuous fashion (not like ble or wifi scanning, with a fixed iterable).
I was thinking of using collections.Deque for keypad events, but it's not included in any builds right now, and I needed to make the code as small as possible, so I went with ringbuf (which is not the greatest piece of code).
I might have also used plain lists, but I needed to make some list operations be public that were static, and I would have had to convert back and forth between Python integers and C integers.
Hi,
I am trying out the asynccp sheduler, but I cannot figure out how to exchange values with the running tasks. I would be grateful for any hints.
`
#=================================================================
Asynccp functions
#=================================================================
class App:
def init(self):
self.text_ID = '' #result from task
self.now_audio = 'Hei.wav' #input to task How to make these 'global'
...
sorry - the insert code did not work as wanted
I corrected the code embed. However, a better place to seek help using CircuitPython is our Discord in #help-with-circuitpython or the Adafruit Forum. Since you're using a third party library (asynccp) you may also wish to inquire in whatever support forum they suggest.
https://github.com/tiangolo/typer/releases/tag/0.4.0 Typer 0.4.0 supports Click 7 and 8 now!
it looks like cascadetoml and circup don't have a fight anymore, when you install them both. yay!
the new typer came out a month ago but it's the first I noticed.
hooray!
@lone axle Maybe I missed this, but I was curious if you had a topic planned for your Deep Dive guest host appearance today
Don't think I mentioned it before so you didn't miss. Plan right now is to try to wire up the chip / LED matrix to test out our first type annotation that has been contributed with this most recent wave of issues: https://github.com/adafruit/Adafruit_CircuitPython_MAX7219/pull/35
Depending on how long that takes (never wired one up before) I may get into some RasPi BlinkaDisplayio testing afterward.
@lone axle Awesome! I'm very curious to see the type annotations, I have not used that much\at all.
That is an excellent emoji ๐
Same. And I will work on my code as I watch/listen.
I'm still very new to typing in python as well
My friend worked on Microsoft Mixer and when they shut it down, he setup his own discord with all the art from theirs ๐
(Where the emoji came from)
I have now tested this with a keyboard report descriptor without a Report ID, and gave report_ids=(0,). No errors are reported and the report descriptor works.
@jepler are you able to review?
@tulip sleet I've been unsuccessful troubleshooting my fake-sleep HardFault_Handler crashes via GDB. It has something to do with GCC optimization but I can't find it even stepping through the entire stack.
what can I try/add to HardFault_Handler to figure out what's causing the issue??
could you set a breakpoint at all on reset_into_safe_mode or on HardFault_Handler
I can't find it in the disassembly and it doesn't occur when built with DEBUG=1.
(PS it always happens on the 4th iteration of a fake-sleep routine... doesn't occur if I supervisor.reset() that many times, though... and isn't related to the duration of fake sleep)
you should still be able to set a breakpoint even without DEBUG=1, I think. It still knows the name of global routines.
it can't seem to find it. Is there something I can add to reset_into_safe_mode to prevent it from being optimized out? Maybe a volatile ?
you want to make it not inline-able
put an MP_NOINLINE in front of the definition
that is a MicroPython macro that has the magic words to make it non-inline
Gotcha! trying this now
@tulip sleet I'm working with a feather m4 (D51). Should I be setting up this "micro trace buffer"?
I think that's only SAMD21
@tulip sleet finally got it to break on reset_into_safe_mode. What sort of things can I query to determine my issue?
jsut do a bt (backtrace) to see what was happening when it hit that
This is all I get. Should I investigate mp_load_method_maybe?
(gdb) bt
#0 0x00044cde in reset_into_safe_mode ()
#1 0x000053c4 in HardFault_Handler ()
#2 <signal handler called>
#3 0x0002c92a in mp_load_method_maybe ()
#4 0x2001e0e0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
ugh, could be better
so damaged stack already. you could populate the code around where you think things are going bad with mp_printf(&mp_plat_print, ..)s and do some divide and conquering to narrow where it might be going wrong
setting a breakpoint on mp_load_method_maybe() is not going to help because it's called too often
I've been using printf to hunt for things but at this point I'm all out of stuff I can try.
I do know it's always the 4th fake-sleep cycle during a call to alarm.exit_and_deep_sleep_until_alarms(time_alarm). My Gut is that it's something to do with this portion of main.c
#if CIRCUITPY_ALARM
if (result.return_code & PYEXEC_DEEP_SLEEP) {
// Make sure we have been awake long enough for USB to connect (enumeration delay).
int64_t connecting_delay_ticks = CIRCUITPY_USB_CONNECTED_SLEEP_DELAY * 1024 - port_get_raw_ticks(NULL);
// Until it's safe to decide whether we're real/fake sleeping
if (fake_sleeping) {
// This waits until a pretend deep sleep alarm occurs. They are set
// during common_hal_alarm_set_deep_sleep_alarms. On some platforms
// it may also return due to another interrupt, that's why we check
// for deep sleep alarms above. If it wasn't a deep sleep alarm,
// then we'll idle here again.
common_hal_alarm_pretending_deep_sleep();
} else if
so if you just print something before every statement there and see when one doesn't show up?
I've drilled down to exactly when it happens. But I'll try and dig deeper.
managed to get a little bit farther? Should I look into a gc issue?
#0 0x00044d06 in reset_into_safe_mode ()
#1 0x000053c4 in HardFault_Handler ()
#2 <signal handler called>
#3 0x2001d720 in ?? ()
#4 0x00022830 in gc_collect_end ()
#5 0x200015e0 in _mscd_itf ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
it's probably worth checking the code to make sure that any objects you have stashed away are being marked in gc. If you made a static that contains an object, it will need to be made part of gc.
Hey, was @lone axle streaming today?
starting right now
he is going to, see discussion in #live-broadcast-chat
I didn't create any new static functions (beyond what TimeAlarm already has in most ports), but I did REMOVE a static ( timer_callback ) and just made it a void timer_callback(void).
Where is this list of special gc objects? I'm combing through /py/gc.h now
Not functions, but variables. We are talking about the root pointers and the variables gcโd in the various *_gc_collect routines
I see! Ok I'll investigate and learn more. thank you!!
I'd suggest you should separate your app data from your app actions. Something like this:
class AppState:
def __init__(self):
self.now_audio = 'Hei.wav'
self.now_colour = BLACK
async def scan_NFC():
# This is an unfortunate expression. Is there not a start_read_passive_target() and is_read_passive_target_done()? Because then you could actually read from this and not block for up to 100 milliseconds like you're doing here.
uid = pn532.read_passive_...
Thank you. I moved to build on another Ubuntu (not Ubuntu on WSL) and the build completes successfully!
I try to test the firmware but found that the "version" as printed on the REPL is "2025d0c", which happens to be the beginning digits of the commit as reported on the circuitpython github (the commit number ??)
https://github.com/adafruit/circuitpython/commit/2025d0c0605c4c0b21f58e1337e35546e011668b
Now when I try to update the libraries with circup, it seems confused by this "version" number and comes back with a "there was a problem". How can one controls the version as I should have put it as 7.0 ?
skip the cicrup and move the libs manually. I still bump into this
Adafruit CircuitPython 2025d0c on 2021-10-02; MakerDiary nRF52840 MDK USB Dongle with nRF52840
from adafruit_ble import BLERadio
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_ble/init.py", line 17, in <module>
ImportError: This release is not compatible with CircuitPython 4.x; use library release 1.x.xAny advice ?
Contains a bunch of minor updates for microS2.
Nice cleanup: these look fine and I'm sure you tested the flash parameter changes.
Have you update circup recently? I didn't see this problem when I used circup recently on a build with such a version
Aha, it looks like you are building off master instead of main?
@jepler, @WarriorOfWire, thanks for your help. I shall go to discord, but since asynccp is not part of basic circuitpython I thought i'd risk a question here. I struggle to get my head around class/objects - in this instance I don't understand how the state variables work. I have got the code up and running through, and the different functions 'communicate' with each other by means og global variables. I'm sure that is the bad way to do it, but so far as I do not understand better, that is th...
Yes. May I ask how to build from main ? I just follow your learning guide literally.๐
if you type git status, what does it say?
But if I put circuitpython 7.0 back, then things work as before as it should.