#circuitpython-dev
1 messages · Page 17 of 1
I just diagnosed an off-by-one bug, where something started numbering at zero, but was expected to start at 1. Then I went to the kitchen to make lunch and started measuring four half-cups of water into the rice cooker, saying to myself "zero, one, two, three". Around "two" I realized what I was doing. 😆
The testing is appreciated!
This is not intended to be a 100% replacement for the adafruit_led_animation.helper.PixelMap class. You've identified a number of things that are not implemented (pretty thoroughly actually!)
I chose not to implement everything as a way to keep the code size smaller. I'd prefer if only the part that benefits the most from speed is in C and as much as possible is in Python.
So, for instance, those class methods would just shift to being non-class function...
👋
danh and microdev1 noticed that this ignore pattern was over-broad and caused added sdkconfig files in boards/ (which should be committed) to be ignored and not proposed for addition by common tools like git status, git gui, etc.
This pattern anchors the search so that it only matches in the ports/espressif directory, so ports/espressif/sdkconfig is ignored but ports/espressif/boards/example/sdkconfig is not ignored anymore
This was noticed over in #7198 and also probably contributed to...
Ljinux raspberry_pi_pico_w 0.3.6-dev 01/01/2020 00:00:07 circuitpython Ljinux
[board@ljinux| ~]> modprobe driver_wifi as network
API: 12.2
Data: RaspberryPi.PicoW
Compiler: 1.29.4
ClmImport: 1.47.1
Customization: v5 22/06/24
Creation: 2022-06-24 06:55:08
[board@ljinux| ~]> iwctl --passphrase "[REDACTED]" station wifi connect Pi400
[board@ljinux| ~]> ping feline.gr
PING feline.gr (95.216.7.161) data.
ping: send 95.216.7.161
ping: recv 95.216.7.161 81 ms
PING from feline.gr:...
<@&356864093652516868> We'll have our weekly meeting in about 90 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/1_pM6rZNwdHXKLP69lmqDRBxVVnlMj-TsIRuRjjSCyEU/edit?usp=sharing -- I look forward to everyone's updates!
Google Docs
CircuitPython Weekly Meeting for November 14th, 2022 Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll...
Now it doesn't build without debug..
R U back?
yup! today is my first day back. just starting to get through everything
Just select-all/delete for your inbox and it will make things easier
Zero inbox policy... 🙂
I make pretty good use of filters to prioritize things
so I'll mostly skim and mark as read stuff
Fixes #7040.
stm_peripherals_timer_get_source_freq()was off by one in its TIMx numbering assumption, causing incorrect lookups of some timer frequencies.- In
PulseIn.c, timer clock reset was being done with an integer instead of a bitmask. Noticed this while looking for other manifestations of the previous bug. - Added some logic to
stm_peripherals_timer_get_source_freq()to handle other variants of STM chips. Not tested, but would have been wrong otherwise. - Reworked timer a...
Looks good to me, viewed locally from this branch. Thanks for the improvements @makermelissa!
Was browsing across the repo but wanted to review..
r, g, b, are of type uint8_t within your struct, not int. Is this conversion from uint8_t to int intentional?
Looks good to me. Tested successfully by running locally and trying the new search terms for picow.
It's great to be able to fine tune the search results with tags for specific devices like this.
Thanks for adding this functionality @makermelissa
I'm seeing weirdness only on the prototype 'scorpio' board with usb .. sometimes tio will log that it is disconnected but almost immediately reconnected:
93.2fps
93.8fps
[tio 12:46:08] Disconnected
[tio 12:46:09] Connected
93.8fps
93.7fps
kernel logs:
[1630122.269598] cdc_acm 3-2.4.3:1.0: ttyACM1: USB ACM device
[1630200.247678] usb 3-2.4.3: reset full-speed USB device number 110 using xhci_hcd
[1630200.509619] cdc_acm 3-2.4.3:1.0: ttyACM1: USB ACM device
the only thing interesting is that the circuitpython code is making heavy use of background pio writes. It looks like only usb-cdc is affected by this, not the CIRCUITPY mass storage device which is also weird. Compared to my usual setup I also have a USB hub in the mix so it could be related to that. Right now, just scratching my head over it...
I'd probably use a beagle to sniff the traces
yeah, I don't have one 😕 I can do a software-only trace with wireshark but that may not be super useful
and of course when I start looking for it, it stops triggering
for a while I felt like it was 'worse' with higher LED current, like it was a supply droop or ground bounce or something, but just now I cranked the brightness up and that didn't make it happen more. The LED power supply is separate from a 5v/2a dedicated supply, not from the scorpio. still not enough to drive 240 neopixels at full white!
😂
At Arduino we like to experiment with new technologies to figure out if we can use them to improve the tools we make for our users. We’ve recently been experimenting with the Python language as a possible extension for our programming platforms, considering how it has become the number one language for many types of […]
Anaconda
Earlier this year we unveiled PyScript to enable users to create Python applications in the browser. In order for PyScript to succeed, we at Anaconda must make strategic investments in both the project itself and its core technology dependencies, such as WebAssembly (Wasm) and the fantastic Pyodide…
Melbourne MicroPython Meetup October 2022
Damien gives an overview and demonstration of PyScript, running MicroPython in a browser.
I believe ntoll is doing the pyscript work for anaconda
CO2 Meter
What about Mastodon posting...
We had our first Mastodon article this week
Yes, email the link to Mastodon please
We're working on getting a CircuitPython user up and running. Once it's solid, you can tag that user as well. Email is best though, especially for now.
Slightly harder to find folks on Mastodon.
We'll continually look to adjust to the social media environment
mastodon enecourages hashtags and the latest version allows following hashtags: use #circuitpython as appropriate
I’m on Mastodon too (@tammymakesthings@techhub.social) but I never really got the hang of Twitter so I’m still figuring out how to use it. But feel free to connect with me.
I just added my Mastodon to my discord profile (@mototimo@fosstodon.org)
👏
i did the draft annotation by hand, but made an issue to automate it
💯
❤️
we need a blinka with a heart emoji
I have an image I made that's basically that. But I'll get our graphics person to do something better.
Wondering if we have ulab fast copy to pixelbuf, like we have fast copy to displayio bitmap. ("pixelbuf" I hope the right name for the source of Neopixel colour).
@errant grail not sure you can change the palette "LIVE" you have to re-apply for update of the screen.
Yes, that may be a challenge. Understanding the overall architecture of displayio's C code is somewhat beyond my skillset.
Mostly unscathed - some minor house issues, lost utilities for 12 hours and broadband for a day
@onyx hinge (briefly got on now) Curious to see how you fixed the NeoPxl8. I didn't get very far beyond wanting to learning more about how the PIO part was working. If you have something to test let me know.
👶
Will you be putting the bangle.js 2 into the CP repo? Look forward to trying it.
👀 Oh it's got a heartrate monitor too, that's pretty neat
Not working yet is the fun part of open projects
the pyocd maintainer flit is open to it but can't do it themselves since they work for arm
I started it but didn't get too far
this is my repo playing around with jtag and riscv debug: https://github.com/tannewt/jtag
(not well documented)
maybe I can try to get kraj interested lol
looks like I didn't push my changes but can
there is a slack pyocd with a channel for making it arch agnostic
(or arch plugin)
(the openocd forks drive a spike into my brain)
I do think setting the property as opposed to calling show() makes it more clear that it's intended to be called once (or whenever you want to change the full display to a different entire group.) Lots of existing code will need updated ultimately if the show() method is removed, but could be worthwhile if it adds clarity.
Openembedded Workshop (Feb 6, 2023) <= Is that in Brussels like FOSDEM???
Now is the time to mark show() deprecated and make root_group assignable
Better idea, multiple people post them. 🙂
@errant grail Thank you for the Pygamer-Thermal Camera upgrade-- it works great!
Wait, where, what?
@stuck elbow I couldn't find the issue, did you say you made it already?
You're welcome! I use mine quite a bit.
CFP for OpenEmbedded workshop will be at https://pretalx.com/openembedded-workshop-2023/cfp
Schedule, talks and talk submissions for OpenEmbedded Workshop 2023
Scorpio is calling.
Location will be https://goo.gl/maps/VZk8zfYBM8bHhTSB8
So now I need two Scorpio, one to output to NeoPixel and one to read signal...
The code was updated for v8.0.0 and frame rate was improved by 20%.
Pretty much all the Display.show() does is setting the root group for the display. However, some users are confused about how this works, and call in a loop on every refresh, or expect it to do something else. Now that we have the Display.root_group property, we could replace that method with just a direct assignment to that property. Hopefully, it would make it a little bit clearer how it works.
This would be an API change, so it would require changes in the documentation, example cod...
Need to head out. Later, folks!
I didn't, I did just now: https://github.com/adafruit/circuitpython/issues/7213
We can do this upwardly compatible in 8.0.0 and then drop .show() in 9.0.0, so, as @tannewt mentioned in discord, let's do this by 8.0.0 final.
Oh, that is for the 8x8 sensor I don't have because I focussed on the MLX 24x32 sensor.
+1 for plugin
pico sigrok: https://github.com/sigrokproject/libsigrok/pull/181
@hoary moat I am from Belgium... I have been to most FOSDEM...
Cheers all!
oh, we might have met and never realized
(at least I never realized, I'm bad with people)
(maybe we did) I did watch one of your presentation, I am not sure if I came to talk to you and if you would have make the link... I might be bad at first contact. 🙂
and in a place that has good beer too
Not sure if I will be at FOSDEM in person or not just yet... isn't really a work excuse, but I might just go work remote for a couple weeks and enjoy Brussels.
It would be interesting to see how would the code looks like before and after this change... with one simple example. At least it will help me better understand, and maybe discover that I have done things wrong all this time.
@random junco did you create the notes document we used today? Do you know if you might have missed the step of check the box for “Share it with the same people”? I changed the document sharing mode so that it was "view only" but that also affected me. which isn't actually a problem that prevents me working, but it's not supposed to go like that. (it should have been directly shared with me as editor via 'share with the same people' but seems not to be)
Yes, I created it. More than likely did it wrong, and I apologize. I'll make sure to get it right next time
Thanks, sorry to bug you!
no need to apologize, I appreciate you letting me know, can't fix it if I don't know. 🙂
@dglaude My understanding is the difference would look like this:
import board
import displayio
display = board.DISPLAY
# Setup the file as the bitmap data source
bitmap = displayio.OnDiskBitmap("/purple.bmp")
# Create a TileGrid to hold the bitmap
tile_grid = displayio.TileGrid(bitmap, pixel_shader=bitmap.pixel_shader)
# Create a Group to hold the TileGrid
group = displayio.Group()
# Add the TileGrid to the Group
group.append(tile_grid)
# Add the Group to the D...
Alternatively, you don't even need the group variable:
import board
import displayio
display = board.DISPLAY
# Setup the file as the bitmap data source
bitmap = displayio.OnDiskBitmap("/purple.bmp")
# Create a TileGrid to hold the bitmap
tile_grid = displayio.TileGrid(bitmap, pixel_shader=bitmap.pixel_shader)
# Create a Group to hold the TileGrid
display.root_group = displayio.Group()
# Add the TileGrid to the Group
display.root_group.append(tile_grid)
# L...
I made a branch here: https://github.com/FoamyGuy/circuitpython/tree/set_root_group that allows setting the root_group property on the display. It will certainly still need some work, this is the bare minimum to allow setting. The most basic case of making a group and showing on the display seems to be working as intended but only minimal testing so far.
what would be the consequences of adding functions to shared-bindings/<module>/<something>.c without adding the matching definition inside of shared-bindings/<module>/<something>.h?
I would have assumed it would either not build, or not work properly if it did build. However I realized that I forgot to add anything to the .h and my new code does work surprisingly.
If a function is global (definition looks like int f(int arg) { ... }) then it should even be an error if there's not a previous declaration like int f(int arg); or extern int f(int arg); the declaration SHOULD be in a .h file, though the check doesn't actually require it to be.
If it's a per-file function (one of the meanings of static in C), like static int f(int arg) or STATIC int f(int arg) then it is not usable from another file, even if you know the name, and so having a separate declaration in a header file would be nonsense.
Looks like this field is not reset on deinit, so e.g. behaviour of PWMOut currently depends whether there was a DigitalInOut before.
# Pi Pico with 220R between GP0 and GND
import board, digitalio, pwmio
p = pwmio.PWMOut(board.GP0, frequency=1000, duty_cycle=0xffff)
# 2.69V
p.deinit()
p = digitalio.DigitalInOut(board.GP0)
p.switch_to_o...
I thought ./ was top-level. Thanks for correcting this.
Do we want max drive strength for everything? Would it be done like in DigitalInOut?
Yes, that should be fine. Do it like https://github.com/adafruit/circuitpython/blob/8f414eb4ee4db6489c0f9eca1e441200ff3e852a/ports/raspberrypi/common-hal/busio/UART.c#L133-L136
PIO looks complicated. Actually, if it's for everything, might it be better to set it for all the relevant pins on startup and then leave it alone in the individual IO libs?
How would it work with show(None) which normally resets the display to show the terminal ? Would display.root_group = None set the root group to the terminal ? Isn't it weird that setting a property to None yields a different value ?
has this behavior changed with CP revs?
https://learn.adafruit.com/adafruit-pyportal/pyportal-hardware-faq#faq-3023990
Yes display.root_group = None will show the terminal.
It agree is a bit strange that setting to None has some effect other than "show nothing", but it's the same in the current API calling show(None) results in the terminal showing.
Perhaps there could be something like displayio.TERMINAL_GROUP or similar as a constant that is either an alias for None, or a new constant value that is used to indicate you want to show the terminal instead of other displayio objects, something li...
iirc the status LED was made optional. I think if you use the pyportal library you can enable it to output those colors about status (or perhaps it's enabled, by default, I'm not certain). If you don't use that library I think the status light won't do anything automatically unless user code specifically sets it up and sets it.
This is the one I am thinking of: https://github.com/adafruit/Adafruit_CircuitPython_PyPortal/blob/main/adafruit_pyportal/network.py#L78 looks like it defaults to None so off unless you enable it with init argument.
That is my understanding. I should've said "is optional" really. I don't have specific recollection of it ever happening by default, but perhaps it did before I started using that device as much.
thanks. i think you're correct. looking at lib code.
confusing FAQ. should probably be more explicit about it being with the pyportal lib and with feature enabled.
Perhaps there could be something like displayio.TERMINAL_GROUP or similar as a constant that is either an alias for None, or a new constant value that is used to indicate you want to show the terminal instead of other displayio objects, something like that would make the resulting code more readable and better describe what it does.
It could be the actual terminal group, since it is kept in memory anyways.
if we deprecate show() the amount of example code out there to be updated is mindblowing. all learn guides, examples, etc.. that's a major major change. i do agree with it because deshipu is right. getting a handle on what show() does is confusing for beginners and almost counter-intuitive nomenclature. once you know what something does the name actually becomes kind of irrelevant though, it just becomes the trigger to do something you need. so the inverse argument to keep it would be that if new users are being confused by it then that's a failing of documentation and learn guides.
We have made major changes before, not as extensive as this. A lot of the code for the Learn Guides can be changed at once in the repo (and then the text of the Learn Guide has to be checked to see if show() is mentioned. It's tedious, but doable. Since we are doing it in a staged way, we have months to do it.
it will also break all display driven code prior to 8.0. that could be a good thing as it will force all code to be updated, like that might be a good thing in some respects. however it could also be a bad thing as it would make any display project non-backwards compatible. this is a big decision.
it will not break it until 9.0.0
ah ok, plenty of time to get things ramped up and prepped for the change. good early early warning if it's going to happen. thank you for the clarification.
root_group was more of an "advanced" feature, I wonder if it should not be just root for simplicity
we try very hard to have a release that includes the new way but still includes the (deprecated) old way. We don't do that only when it's unavoidable due to code space or something. @jaunty juniper -- could suggest that in the issue.
brings up another point about starting to introduce deprecation warnings into the core. it'll take up space but could be a lifesaver to someone working with old code that doesn't know any better.
we don't want to print deprecation warnings, it clutters up output. There are deprecation warnings in readthedocs and the release notes
(that's even more breaking though)
also people not connected via serial don't see them anyway
yeah, CP needs to be too slim and trim and for that. np.
deprecation warnings break serial communication
do you mean root and root_group are aliases of each other?
oof
like if you rely on exchanging serial data with your board and can't use usb_cdc.data (on ESP for example)
yeah i'm still on usb and serial, still haven't been able to update my network for wifi workflow 😦
what do you need to update on your network?
firewall blocking mdns from traversing vlans
well I meant changing the name which would be bad, but we can alias until CP9, though I don't think there is any code out there that uses root_group out of really advanced stuff and kmatch
and i want to do that after i wire ethernet in the attic so it's a whole ordeal.
right, same thing, can do both ways until CP9, so if we're making one change, we can do the other. Not sure if root or root_group is clearer -- we can discuss in the issue
does web workflow use if you put in the ip?
on the question of warnings, I vaguely remember Micropython having a debug level setting, though I think that was for showing the ESP debug to the REPL
not sure i tried it twice and failed to get it working, will set aside some time to take another look
that was about 2 months ago i think
I used prefab long cables from Monoprice in the attic and got double-ended wall-plate sockets, so no punchdown-ing necessary. Also I am color-blind so that was going to be an issue.
still had to drill in the attic, which is very unpleasant place to work (joists and fiberglass insulation)
yeah i punchdown my own, i used to be an installer, that's not the problem. the problem is i'm now 280lbs and the attic in this house is about 3ft tall. :/
ack, I understand
ours is taller but I still often wear a bike helmet when I'm up there
not a bad idea, never thought of that. attics in fl can get up to about 130F in peak summer. dying of heat stroke is a very real and biggest concern.
yeah I only do that work in the winter or at night after it cools down
which is why i waited for fall/winter around here, the time is now and i'm still procrastinating. gained weight and for the first time in my life actually concerned about falling through the ceiling too.
this is far off from -dev, sorry
np
We share the language core with MicroPython, but the board-specific parts of implementations can be rather different. Some code could probably be adapted. Modbus is not a feature we plan to add any time soon; if a community member wanted it, we'd certainly entertain PR's.
also, unrelated but it would be nice to clarify and stabilize the rules of the terminal group and related stuff, maybe have an API to access it, since there are regular demands to hide the blinka logo for example. Also change the font size.
We already added a way to disable the status bar, we could have an API for the logo and configuring the REPL. There also is supervisor.reset_terminal() which always leaves space for the status bar I believe so it might need changes.
Or maybe we could just make sure that the rules are clear (what is in root_group and in what order for example) and have a helper library for advanced uses (hide parts/resize REPL/change the content of the status bar/etc.) so as not to add more things in the core.
the other way to go is expose the serial stream out of CP into the VM so the user can do anything they want with it
(including making their own Terminal instance)
there are demands for redirecting stdout to a file
that's crossed my mind too when I hit bugs on the bangle.js 2
Given that this is an external module, what's the likelihood that it would "just work" vs. needing updates to handle different core APIs?
Is there C native code for Modbus in https://github.com/brainelectronics/micropython-modbus? I see the Python module. Its network code may need to be adapted. But it could be made into a CircuitPython library.
It's intentional, but I may be wrong.
On 32-bit arm micros, arithmetic on narrow types can actually be less efficient than arithmetic on wider types. Canonical example [https://godbolt.org/z/Kr41o9sMd]:
#include <stdint.h>
uint8_t add8(uint8_t a, uint8_t b) {
return a+b;
}
uint32_t add32(uint32_t a, uint32_t b) {
return a+b;
}
assembles to:
add8:
adds r0, r0, r1
uxtb r0, r0
bx lr
add32:
adds r0, r0, r1
...
I have retested, and this is ready to go.
This pr was meant to be a 5 minute thing just so that I can continue on the ap..
But here we are.
The lwip_src stuff should stay for now..
Some other stuff is using ping.c and without ping.h some stuff are acting sus on actions
(but not on local somehow even though I make clean).
Not willing to pursue removing them in this pr. I may try it at another time.
For now, this is considered solved, as ping_time is residing within ping.h and works as expected.
either black or pylint caught a couple errors in my time function. that's pretty cool.
I bet pylint
black is comfortable juggling ljinux code without fail
And I do plenty of sussy trickery
What kind of help do you need w/testing?
Just general testing, as the earlier occasion when we tried to enable WFI for light sleeping problems cropped up that the original submitter didn't find right away. I tried to test a number of scenarios that would "cover" normal usage but one always misses something...
@tannewt want to review this as a way to stick your toes in the pico w waters?
Thank you for the insightful response, seriously! Learned a lot.
On rp2040, which is cortex-m0plus with -O2 optimization, the "int" version is smaller by 8 bytes. On adafruit_proxlight_trinkey_m0 which is cortex-m0plus with -Os optimization, the "uint8_t" version is smaller by 24 bytes.
Would you be able to #ifdef these types depending on architecture?
PIO looks complicated. Actually, if it's for everything, might it be better to set it for all the relevant pins on startup and then leave it alone in the individual IO libs?
That makes sense. Are you interested in doing a PR?
This might be due to escape-code handling. @Neradoc notes here: https://github.com/mu-editor/mu/issues/1505#issuecomment-830061810 that
serial_port = "/dev/cu.usbmodem144443131"
import serial
VT100_RIGHT = b"\x1B[C"
channel = serial.Serial(serial_port)
channel.write(VT100_RIGHT*50)
channel.close()
causes the issue.
Do you have other Espressif boards you can test with? The BLE implementation on Espressif is limited due to some existing limitatations of the underlying nimble library, so we stopped working on Espressif BLE for a while. There may be remaining bugs.
I just saw adafruit is about to offer a NeoPixel BFF for the qt-py form factor. I'm hopeful that as a result, this problem will get more attention. I look forward to synchronizing NeoPixels over wifi!
I don't think it has to do with escape codes. After pasting "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" to my terminal program, ctrl-c doesn't work either. I suspect an internal serial buffer fills and that prevents ctrl-c from being received..
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1bxU_XogCgdpbxVPRA01tDc_tqLY0VFVUkpX6JQzwtd8/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for November 21, 2022 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to pa...
perhaps but I'll leave it for now as "not worth it". It's important to us to size-optimize for the samd21 boards much more than anything else.
@hathach can you comment here? We are using tud_cdc_set_wanted_char(CHAR_CTRL_C); and depending that we'll see a call from tud_cdc_rx_wanted_cb. However, when a lot of characters have gone un-read, the wanted CB is no longer called. Is this a TinyUSB bug or do we need to change what we do in CircuitPython (for instance, to do something to drain the un-read characters even if the Python code isn't reading anything)?
want to do 8.0 triage tomorrow before meetings?
sure
time for me to up my github email filtering game
can do
Give me a bit more time before I touch LWIP stuff. (So I'll pass.)
I have one note, maybe an added comment would be helpful.
Not sure what's going on with github, I don't have the usual approve/request changes/just comment buttons to select the 'result' of my review.
this doesn't actually modify any of the registers, so won't the pwm peripheral keep doing whatever it was doing before reset()? Are we depending on some other way of stopping the physical output on the pin, like setting the pin's function to gpio or disabled? This might merit a comment.
oh, because the PR had already been merged, that's why.
Thanks. I am still not 100% confident about the way ping_time is used across two source files (Radio.c and ping.c), whether they need to be the same or whether they need to be different; but your logs seem to show that it "works now".
A note for the future: Because I don't know a single thing about your "ljinux" environment -- and the majority of reviewers won't either -- it is more difficult for me to analyze and understand what I am seeing, compared to just seeing Python code. If in th...
@onyx hinge do we have an issue for pico w web workflow?
looks like no
kk, will add one
or if we do it's not marked rp2
I'm looking in web workflow and don't see it there either
The WiFi module is a relative of the one on the Pico W. However, it is connected through SDIO rather than PIO. The module code is also specifically licensed for use with an RP2040. https://github.com/georgerobotics/cyw43-driver
I believe /code/ is served by code.circuitpython.org and will need an update.
I wonder if these are actually bit flips in the SSD1322. I believe CP should only be updating the changing region and basically leaving the left half alone.
Does the panel lose the old memory between updates? We could write it after the update with the "new" data so that the next update has a reference.
It's hard to troubleshoot because it takes at least 2 days to reproduce. I switched from a label to a bitmap_label and so far it hasn't happened but unfortunately I have to switch back to label because the bitmap_label has too much flicker upon updates.
Performing a supervisor.reload() every night at midnight prevents the problem.
I have 4 QT PY ESP32-S2's and 4 of these SSD1322 displays. Any troubleshoot suggestions to narrow down the cause?
Ah, good catch. It's in https://github.com/adafruit/circuitpython-org/blob/main/_layouts/download.html and should be a pretty simple fix.
I recently add board to CPY.org and I would like to ask, if download for stable & beta version of CPY should show up right away or I have to wait until some new release? I saw that there was some bug with building files, but I do not know if that is related. Also I added board to tinyUF2 repo, so do I have to "connect" it to my board at CPY.org or it will show up eventually by it self (like for example for magtag board)? Thanks for clarification 🙂
for the builds to appear, there needs to be a board definition in the cirtcuitpython repository when a release is made
we may want to use :inherited-members: in autodoc for the portal classes
so docs for classes like MatrixPortal include stuff from PortalBase
@stuck elbow thank you 🙂
merged PR are automatically built and send to S3, change the board name with the board ID of the board you are looking for https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/crcibernetica-ideaboard/
also speaking of "crcibernetica-ideaboard", didn't we settle on underscores for board ids ?
You'll want to add an entry here to share the USB VID/PID with the other version: https://github.com/adafruit/circuitpython/blob/main/tools/ci_check_duplicate_usb_vid_pid.py#L33
This looks fine to me. I'm happy to test in main. :-)
Thanks for adding this! One minor suggestion.
I'd suggest moving this down below current_area_dirty and omitting the : 1. I'm not sure what size the struct will use but I know that by placing it here, you are unaligning the pointer that follows this and likely leaving a bunch of empty space.
Is this waiting to be copied into the other ports' Makefiles?
Sorry, I do not understand what you mean by 'change the board name with the board ID of the board you are looking for..'? This is not my board and I know that I can download daily build from S3. I was just curious about release versions, but I already have the answer from deshipu
ok cool
@fonix232 Please let us know when this is ready for review.
@LazaroFilm You can help test using "artifacts" from the CI run. See the bottom artifact here: https://github.com/adafruit/circuitpython/actions/runs/3352586595
@fonix232 Please let us know when this is ready. Thanks!
Are you still wanting to work on this or can we close it? (Closed PRs can still be accessed.) I think its all tricky stuff.
Its ok if the PID isn't for CP only. We would like the PID to be unique within CP though.
@dhalbert Still want this in? I'm concerned we'll miss broken but not fixed issues.
Any update @MicroDev1?
@RonnyM82 Please update this PR as requested above when you have a chance. Thanks!
I'd close this if it doesn't match what CPython does.
Perhaps before wifi init we should use getenv to look at see if the user has a valid country code defined in the .env file?
That sounds like a good use for .env! :+1:
I think a CI check for new boards is best. Is there tooling that needs the python identifier property for all boards?
@litui Any chance you want to polish this up so we can include it in 8.0? Thanks!
@hathach Did you ever get back to this?
As long as you don't work for LilyGo, I'm ok granting pid.codes PIDs for open source code (CP) on closed source hardware. https://pid.codes/
@anecdata Do we have 32MB support now an updated version of the IDF? Or will we need IDF 5?
In my git repo for nvm.toml i'm not showing a pull request. can only view the pull request at adafruit/nvm.toml
changes show in my github desktop, file is there in my github folder on my pc. it's weird.
in your own git copy, it'll usually just be a branch
[adafruit/circuitpython] New comment on issue #6223: PWM status LED on C3 causes All channels in use
deiniting a specific PWM should unset never_reset
On second thought, the timers are reset by timers_reset(), so I think this is OK.
@dhalbert Still want this in? I'm concerned we'll miss broken but not fixed issues.
I do not understand this well enough to have an opinion right now.
There is still an open ESP-IDF issue I think is related to this: https://github.com/espressif/esp-idf/issues/8741
@jaunty juniper any chance you have an ai thinker c3 board handy?
I've got a fix for the pwm status led
yup
I guess I'll need your board def though...
my changes are here: https://github.com/tannewt/circuitpython/commit/93ee54a2fb52bf20c49e9dfc846e03f400322ec5
reinstalled WSL and come to find out you don't need to setup the virtual machine in the bios or do any of the hardware vm stuff. it doesn't even use it.
Sorry I'm very behind on this review. I'm just getting back from paternity leave and am reviewing new APIs. My main question is, why is the buffer provided in the constructor? I'd expect it to be provided to read() similar SPI's readinto(). That would make what read modifies clearer. You could also return the captured sample count to match UART's readinto.
Hi! I think this is really neat but needs a bit more polish. Where should I put my feedback? Here or a new issue?
resolves: #7213
This change allows display.root_group to be set to a group to be shown on the display rather than calling display.show(my_group).
There is example code in the linked issue that illustrates the difference in API.
Currently this change is not breaking, the display.show() function still exists and works the same as current main.
This also introduces displayio.SERIAL_GROUP which returns the Group object that contains the blinka icon and serial output text scr...
@deshipu nice, that is perfect.
I've updated my branch to have displayio.SERIAL_GROUP that returns the internal circuitpython_splash group. I made a draft PR for it as well. I think it might make a few builds too large, will need to see how the actions shake out. Also possible it needs more changes still, I've done only the bare minimum to make it work I think.
How about CONSOLE_GROUP or CONSOLE ? I associate that term more with a display showing the output of the program.
(We use the term console in usb_cdc too for the REPL serial port).
I guess we don't have an official lexicon to make all the terms cohesive.
I am open to CONSOLE_GROUP or dropping group and using just CONSOLE. I've edited my original post with that and a few other remaining questions that I forgot to mention when I wrote it initially.
Thank you. Changed that in the latest commit.
Just tried it with a couple QT Py ESP32-C3 boards, not seeing the issue on either, so seems to be specific to the XIAO.
This adds support for a prototype version of the Adafruit Feather ESP32-S3 Reverse TFT and Adafruit Feather ESP32-S2 Reverse TFT boards. At least one revision is anticipated before manufacture, so creating a draft PR.
Works (both):
- CIrcuitPython starts
- TFT
- WIFI
- neopixel
- D13 LED
- bme280 works with normal I2C pins:
b = board.I2C()
Works (esp32-s2):
- max17048 works with reversed I2C pins (known board bug)
b = busio.I2C(board.D3, board.D4)
Broen (esp32-s3)...
well after trying to use the wrong build for 30 minutes, and being distracted by other things, it seems to work fine, the same code that triggered the error with main now doesn't
@ladyada see above for the results of my testing these modules
@tannewt unfortunately not yet, I have switched to other esp32/rp2040 works. Will back to this later when possible.
Fixes #7105.
On SAMD21, port_disable_tick() did not finish the job of disabling the _tick_event_channel.
Also added a check to avoid doing anything if _tick_event_channel was already disabled.
Before this change, editing a file and causing an autoreload would use up a bunch of event channels:
(this is from some temporary logging I added:
[code.py edited here]
Code stopped by auto-reload. Reloading soon.
>port_disable_tick, _tick_event_channel: 0
port_disable_tick, _ti...
@tannewt Can you elaborate on "we'll miss broken but not fixed issues".
Where should I put my feedback? Here or a new issue?
An issue should be fine.
noice! dont forget, will have PSRAM and possibly different amt of flash in final version (the PSRAM modules werent in stock)
In what box 😭... the story of my electronic hobby. I almost started a list of items currently lost.
Right now the box with StemmaQT sensor is lost, together with the QTPy S2.
I was thinking about form factor sorting: Feather size, Micro:bit size, QTPy size, I2C sensor without StemmaQT, Adabox full product (PyPortal, PyGamer, MagTag, ...).
@tannewt Can you elaborate on "we'll miss broken but not fixed issues".
If commit A is run and fails on boards 1 and 2 then commit B is added to fix 2 (but not 1), then the CI view will show green even though 1 is still broken. I think you need to run tests based on all changes since the main branch.
We should probably update this internal API to match the new way.
Open questions:
- Does anything else need to be done for the
display.root_groupsetter? It seems to work as-is but I've only added minimal code to make it work, perhaps there is something I overlooked that still needs done.
I think it's ok as-is. We may want to make None mean nothing is displayed rather than showing the CP terminal.
- Open to discussion on the name of
displayio.SERIAL_GROUPI proposeddisplayio.TERMINAL_GROUPin the issue initially, but accidentally c...
If commit A is run and fails on boards 1 and 2 then commit B is added to fix 2 (but not 1), then the CI view will show green even though 1 is still broken. I think you need to run tests based on all changes since the main branch.
This won't be the case as failed jobs from the most recent workflow run of the PR are also scheduled.
Is this waiting to be copied into the other ports' Makefiles?
I think so.
I guess we don't have an official lexicon to make all the terms cohesive.
The design guide is a good place to document terminology. design guide source
Do you have any other displays you can run the code with? I'm curious if they'd end up with the random pixels too.
I have a few: SSD1309 (128x64 mono), SSD1351 (128×128 color), ST7355 (128x160 color) & ST7565 (128x64 mono)
None of them are grayscale like the SSD1322 or have a 256x64 resolution. I guess the SSD1309 would be the closest.
I'll try to set up a lab this weekend with multiple configurations.
updated the bee motion s3 to add some addition information
added Bee s3 board relevant information/docs.
Hi, looks like you're using a feature value that's different than our search filters. If it has battery charging, you can use "Battery Charging", otherwise it's probably best to remove it.
Hi, looks like you're using a feature value that's different than our search filters. If it has battery charging, you can use "Battery Charging", otherwise it's probably best to remove it.
sorry about that. it should be removed now.
@onyx hinge I was thinking your elf loader class could make top level attributes available for global variables for a running program
you mean like smooshing it together with something like the register library? that would be neat
kinda except you could do it all dynamically
for scalars, probably. but structures?
I'm thinking __getattr__
for instance, for the keyboard project I was thinking I wanted a ring buffer in the shared memory area, but that's got structure to it
also I'm not sure if I know the size of symbols or just their address
elf supports many debug sets such as dwarf that can have type info
I am frightened of parsing dwarf, I think it's complicated
ya, I think thats fair
I was thinking we could do a similar //| trick in the file to generate a python stub
elf is simple because simple loaders are good .. debuggers are never simple, but debug information size has been a very real problem for big C++ projects especially
that's a super cute idea and I'm into it!
so that'd be a special register style class that could do the final "link" to find the symbols address
if we're providing a build system we can also do more of the 'extractive' stuff on the host computer with full pyelftools
those can parse out dwarf structure information for sure
they'd need to be marked volatile then too though
true
(my stemma g0 boards are out for delivery)
ooh
I was thinking we could use SVD to create "driver" classes for peripherals too
just checked and an elf SymbolTableEntry does have a size in bytes, but not even a type tag. you have to go to the dwarf or stabs debug info for that
but if there was another section which said "oh, the struct parser for ringbuf is "<HHH"" you're starting to get somewhere. i.e., you just started homebrewing your debug information
I think we should build on #6902 and refine the APIs to be more generic. I've been thinking about coprocessor and memory APIs within a few contexts that this API can apply to:
- An FPGA world where peripherals are dynamic and a "raw" memory API is needed to write drivers for them.
- An FPGA world where you can instantiate as many CPU cores as you like. Probably RISC-V ones. Controlling them would likely be done through the debug spec.
- [A St...
I have been kicking around the idea of Register classes that use a standard memory access API under the hood
Like here for RISC-V debug registers: https://github.com/tannewt/jtag/blob/main/riscv_debug_module.py#L97
and here for FPGA defined registers: https://github.com/systemonachip/systemonachip/blob/main/systemonachip/peripheral/timer.py
Darn the easier to support debugging info format is not available for riscv targets cc1: error: target system does not support the 'stabs' debug format
At a high level I was thinking it makes sense to put this in one place, but I don't really have any idea where it would go or how you decide which pins are eligible.
#7218 is discussing a coprocessor API that could apply to the broadcom port.
We've got #7218 going to discuss a coprocessor API that would apply to running native code on the second core (not Python on the second core.)
@Rybec you may be interested in synthio. Though it needs to be changed to take in real-time midi messages too.
Where should I put my feedback? Here or a new issue?
An issue would be fine.
Ok, I've opened #7218
We believe this was closed by #7140.
@onyx hinge @tulip sleet ready when you are
Join us in "Amelia"!
one minute; eating ice cream
It doesn't need never reset because the status LED is only active when user code isn't.
This also fixes PWM never reset on espressif so that deinit will undo it.
CFG_TUD_CDC_RX_BUFSIZE
@tannewt @dhalbert and I discussed this and we feel that there's no way we can make ctrl-c work -- if we potentially throw away characters from the buffer, it will break things that rely on reliable buffers like file uploads in mu and thonny. But if we don't throw away characters, the "ctrl-c" method can't work, because the ctrl-c character never leaves the host computer.
We might be able to add an alternative out of band interrupt signal such as using DTR or BREAK, which would then have t...
as another alternative, maybe we could discard any pending characters when USB CDC disconnects.
MIght be an sdkconfig issue; I'll take a look later.
This would be a lot of work - deferring past 8.0.0.
It looks like simply setting it to =1 doesn't work...
-- Build files have been written to: /home/jepler/src/circuitpython/ports/espressif/build-adafruit_feather_esp32_v2/esp-idf
ninja: Entering directory `build-adafruit_feather_esp32_v2/esp-idf'
ninja: error: unknown target 'esp-idf/bt/libbt.a'
Actions: look at ESP-IDF issues. Test with Pico W as well.
@guighub We reviewed this issue today. Did you find the full code?
We think this may be a duplicate of https://github.com/adafruit/circuitpython/issues/6005 which does have a full program.
As I've played with this more, adding audiomixer definitely causes more problems.
and btw, WAV file used in my video above is at https://github.com/todbot/circuitpython-tricks/blob/main/larger-tricks/wav/drumsacuff_22k_s16.wav
Ah, ok. Neat! I'm ok merging this in now.
haha, no where near the top of my list
so many toys, so little time
just got my stemma g0 board
what does it do?
nothing atm. its an STM32G0 micro on a stemma qt board
thinking of having basic io expander and adc read examples
x0 or x1?
x0
STM32G030F6P6TR from STMicroelectronics - Microcontroller Units (MCUs/MPUs/SOCs) is available for JLCPCB assembly, check the stock, pricing and datasheet, and let JLCPCB helps you assemble the part STM32G030F6P6TR for free.
so basically samd21, but from stm?
ya, similar. https://github.com/tannewt/StemmaG0
got on my radar for CP because the top end has 144k ram
the stemma qt one only has 8k though
I like that they are going in the direction of minimal additional components
ya, super nice! just a 3v reg and a single decoupling cap
that's one cap less than the samd21
and many fewer than rp2040
got it working with half the recommended caps ;-)
nice!
I wonder if something like vusb would work...
why do you need usb?
I'm not thinking this would run circuitpython
it would be a coprocessor running native code
but you said?
true. that'd be a different board with a x1 device
makes sense
(maybe a gemma and trinket would have the high ram version)
so this is more like samd9 in the seesaw
right
with a rom i2c bootloader
The STM32G0B0KE is a value line version with 144k ram and usb
32 pin lqfp
trinkeys with more ram for animations and HID and other stuff would be nice, though they need more flash too
ah that's good
ain't gonna be so cheap
right, the chips for missiles have priority
it's a bit weird introducing a new series of chips in the middle of a shortage
its their first 90nm mcu afaik
(F0s are 180)
so you may be able to have the new stuff more available due to demand for a specific node
RP2040 is 40nm iirc
and AVRs are like 5mm ;-)
it's funny how the oldest chips are in the greatest demand, because they are used by everyone, and they are actually harder to make with the old processes
probably smaller wafers too
(I discovered asianometry's videos and they are very informative)
nice, I will have to watch those
@slender iron have you looked into tinytapeout, speaking of chip production
ya, I've followed it
kinda think I can help at the peripheral register design and soc definition level
whenever I find cycles
I do think it sounds good to have it under _pixelmap and then having the accompanying python code be adafruit_pixelmap library with the helper functions that is meant for use by user code and other libraries.
If we do want to go that way, I can work this week on cookie cutting a library for it and migrating the existing code from led_animation and making the changes needed to work with new core module.
Two potential issues I found:
- If I have a pixelmap and access outside of the bounds CP crashes
- If I try to get a slice e.g. pixelmap[0:20] I get
TypeError: can't convert slice to int
As to the helper code, I'm not sure if a _pixelmap vs adafruit_pixelmap with helper functions is best. For my 300 grid array it alternates up/down so I had to write a quick function to create the indices in the correct order where the animation library does have some of that in it.
Also I have...
If I have a pixelmap and access outside of the bounds CP crashes
This one should be fixed for sure
If I try to get a slice e.g. pixelmap[0:20] I get TypeError: can't convert slice to int
This one was deliberately not included initially, but now that I used such slices to e.g., quickly scroll in the 5x5 neopixel bff example code I guess it should be added
requests library now has API examples for discord, github, mastodon, twitch, twitter, and youtube.
anyone want to make a request for a basic API example? I'm knocking them out of the park lately.
why aren't my PR updates showing up in the github dev channel feed?
Notable changes required to make this work:
- Patch ESP-IDF:
BT_SOC_SUPPORT_5_0was disabled for esp32. - Enable
CONFIG_FREERTOS_PLACE_FUNCTIONS_INTO_FLASH:
Theiram0_0_segregion overflowed by 3924 bytes. The documentation on optimizing IRAM usage is here. - Partition Scheme:
The firmware overflowed by 11280K. This is a **Breaking Cha...
Presumably I also need to make a PR at https://github.com/adafruit/circuitpython-org for this board variant?
The failed boards include esp32 boards with psram.
Even after disabling all CONFIG_SPIRAM_CACHE_LIB**_IN_IRAM, there is still an overflow of 3828 bytes.
libesp_hw_support.a alone contributes to an increase of 5199 bytes of IRAM usage.
not all the repos feed into that feed
some repos have a webhook to post changes into the feed. The only organization-level webhook is for releases
oh it only shows up for comments on open issues? must have gotten that confused.
do you mean in #adafruit-github-feed , or do you mean in your email?
here in the dev channel, was pretty sure stuff was showing up here :/
only adafruit/circuitpython and adafruit/circuitpython-org show up in this channel
#adafruit-github-feed has more
yeah i looked, must have been mistaken
library changes are not posted in #circuitpython-dev
made a commit to the requests examples as Twitch and added a Mastodon example in there. thought i could do it as 2 separate PR's but it kinda merged them. didn't want it to be confusing to the reviewer.
you can always add another post to the PR if you want to explain something
ah ok thought libraries were included, my mistake
i added CircuitPythonLibrarians as a reviewer. There were no reviewers
is it possible to get a feed for library updates? i'd probably enjoy reading that feed to see what's happening with the libraries.
we would probably add it to the current #adafruit-github-feed
some staff (like me) subscribe to everything in the organization, but that's a LOT of email
would you read #adafruit-github-feeds regularly, is that what you're saying?
I get several hundred emails a day
oh i only look at it while in discord, didn't think of the emails. i don't check my email often either but when i do it's full of updates too yeah :/
yes, hopefully separae it into github-core-feed and github-lib-feed? maybe that will help?
i do enjoy rss feeds
I wish I could somehow unsubscribe from all those gihub e-mails from adafruit repos, they make it really hard to find the few messages that are actually relevant to me
it is a lot
makes me miss comments on my pull requests
are you watching the entire organization? You can turn off notifications on repos you don't care about, or only get notifications on those you do, but it's more trouble to manage
i feel I have to review everything to know what's going on, but I too miss things sometimes
some email filtering and sorting rules could also be helpful
probably forgot that was a thing, i'm still kinda new to working with a group in github, will look into that option
it's kinda why i like the feeds, give a nice curated overview
we'd have to be more careful about setting up webhooks on each library repo; right now we forget a lot. We could also widen the organization webhook
I'm not sure where that would be configured? do I have to go through all the library repositories and unwatch them?
are you watching the organization, or just a lot of library repos?
i think it's done when you submit something like a pr, like there will be a checkbox to subscribe to updates. since i get a lot of emails it's probably checked by default.
how do I check?
that's a good point, dunno 🤷♂️
I think I'm getting all those e-mails because I'm in the librarian group?
you are a member of adafruit org: https://github.com/orgs/adafruit/people/deshipu
oof, that'll do it
yes, you're in the librarian group so you can approve PR's. As a member, you can still control your notifications
yeah i have some set to watched in the top right of the github website on each repo page
I have compiled this and loaded it into my device. The LCD and pins are working, have not tested the IMU yet. The one issue I found is not quite related to this pull request is that the VID an PID of the device are not recognized by VSCode's extension for CircuitPython, thus making it impossible to access the console, though, the console works in Mu Editor.
Digging further I cannot find the PID for this board on this page: https://github.com/raspberrypi/usb-pid
Also, according to this is...
it's because i "followed" adafruit main page
are you getting emails for everything?
no oddly enough but it shows the watched status as following stuff that i'd never follow like cpython
check https://github.com/settings/notifications for various notification settings for yourself
ohhh it only shows if participating or @ mentions by default that's why
info about following organizations: https://docs.github.com/en/get-started/exploring-projects-on-github/following-organizations
ugh i feel noobish
I'm not following adafruit, and I can't see any options about notifications from organizations
are you getting notifications about every repo (e.g. the Arduino ones too)?
no, only circuitpython related
i have nothing to do with that repo but because i'm following adafruit it sets it up automatically and it's honestly a good setting, i'm ok with it now that i realize what it's doing.
I think https://github.com/settings/notifications will tell you why you're getting repo notifications you don't expect
so https://github.com/watching is only non-Adafruit?
how many repos does adafruit have lol, there's no way i'm going through manually setting ignore on the ones i'll never need. hundreds? thousands? lol
both are off for me
about 1700
oof
I think I'm getting subscribed to all the issues because they automatically assign CircuitPythonLibrarians as a reviewer
I would say just check the notification settings in your personal settings, and also what your team member settings are. And pick a repo you are getting unnecessary notifications on and see if you are set to watch it (might have happened automatically).
that's what the log suggests
think i just need to be more diligent in unsubscribing from stuff after i've contributed what i need to as a beta tester, get in and get out. https://github.com/notifications
I think you can control that, but I'm not sure where
thank you for all the explanations dan it was helpful and reassuring.
I don't think I can, other than explicitly ignoring 350 repositories
would you like to be taken off the team and as a member of CircuitPythonLibrarians? We can make you an "outside collaborator".
I'm still hoping I will do more reviewing at some point, so let's leave it is as it is for now, I do filter it on my side somewhat
sure - np - let us know. @idle owl tagging you for interest ^^
I think it's just how github is not really made for hundreds of repositories
There's a talk from GitHub Universe about managing CI across repos and orgs, and I'm wondering how having as many repos as we do will have an impact on what they talk about.
And thanks for reminding me to watch it 
"In this session, Joe Duffy will show you how to standardize the process for deploying GitHub Actions across hundreds or even thousands of repositories, with built-in security, automation, and consistency, thanks to infrastructure-as-code."
sounds like it's right up our alley 🙂
tested:
- board.LED
- neopixel as status LED
- i2c scan finds lis3dh sensor
not tested:
- rgb matrix o_O
- the gpio pins
not final:
- module type (sample is XX0H32, no-psram version)
Introduce new board properties for matrixportal-style boards:
- MTX_COMMON
- MTX_ADDRESS
These are intended to simplify use of the RGBMatrix constructor:
matrix = RGBMatrix(..., addr_pins=MTX_ADDRESS[:3], **MTX_COMMON)
removing the need for sending in the following...
@slender iron hey, just checking your thinking here, it seems like you think maybe this could be firmware related?
https://forums.adafruit.com/viewtopic.php?p=948338#p948338
I don't know what Scott would say but I would have them just get into the REPL and see if it looks OK. Also make sure they are using the right .uf2 file (titano, not regular pyportal)
someone could do a stock check on these, or you could order one
is there one board that still works fine?
yes. this one has been going on for some time.
i have never seen a smeared blurry screen like that. I wonder if Melissa has
maybe here: https://forums.adafruit.com/viewtopic.php?p=306935 really old
if the boards are being tested at a lower clock freq, but CPy is using a higher one, maybe that would explain it. If stock check was done with an Arduino test program
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4-28-ga036c9c38a-dirty on 2022-11-17; Adafruit MatrixPortal ESP32S2 with ESP32S2
Code/REPL
matrix = RGBMatrix(bit_depth=4, width=32, addr_pins=MTX_ADDRESS[:3], **MTX_COMMON)
display = framebufferio.FramebufferDisplay(matrix)
Behavior
Assertion 'height_in_tiles > 1' failed, at file display.c:131
[tio 10:18:23] Disconnected
[tio 10:18:26] Connected
Auto-reload is off.
Running in safe mo...
@tidal kiln I loaded regular PyPortal UF2 onto a Titano: it causes an odd split display, but no blurring. The connection is a parallel bus, not SPI, and there is no frequency specification in the startup code. Have they tried the self-test here: https://learn.adafruit.com/adafruit-pyportal-titano/arduino-test
works on mine
@dhalbert No sorry, I don't think I have it anymore. If I do it's probably saved somewhere along with a bunch of other code, so I'd have to go through every one and test it and I don't know if I have all the hardware I did back then.
Although like jepler said, it might be a duplicate, and looking through the code on issue 6005 it looks familiar to what I was doing at the time.
good idea. was just thinking same.
maybe good to mention that we test everything in stock after production, and the replacement got an extra test beforehand
Is there a reason that info_uf2.txt for all RP2040 boards is RPI-RP2? Is it an implementation limitation?
I cannot get the ap to stop no matter what I do..
This is due to cyw43_wifi_leave being borked and doing nothing.
Looking at the respective micropython code we can see, they haven't implemented it either.
I will continue implementing the AP, without stop_ap.
stop_ap will simply raise an appropriate error. Feel free to suggest error messages.
What I propose is `NotImplementedError: AP cannot be ...
it's in the ROM bootloader on the RP2040 chip
the bootloader is not flashed; it's manufactured in
Ah gotchya. Thanks!
What happens if start_ap() is called a second time, with different parameters such as ssid or password?
Do we have any API to access cyw43_deinit() to shut it all down and start over?
@tidal kiln ya. I just wanted to check that it wasn't a firmware issue. it sounds similar to the tufty 2040 issue too
but it really seems like it is something on their end considering its happened three times
may also be worth checking revision of the board
possible our older versions work ok but something changed with the newer ones
running the arduino test is a good idea
What happens if
start_ap()is called a second time, with different parameters such asssidorpassword?
Stays on original ssid and accepts no connections.
This applies for same ssid, different passwd
different ssid, same passwd
different ssid, different passwd
Do we have any API to access
cyw43_deinit()to shut it all down and start over (short of a CircuitPython reload)?
Aren't some pins controlled from the wifi chip?
It would be pretty problematic resetting.
Pretty...
Presumably I also need to make a PR at https://github.com/adafruit/circuitpython-org for this board variant?
Yes please!
Digging further I cannot find the PID for this board on this page: https://github.com/raspberrypi/usb-pid
Good eye! Looks like it'll need to be requested like other Waveshare boards have.
It is something we want to do. Just not for 8.0.
@onyx hinge does the MP LWIP code allocate on the MP heap internally?
@slender iron I have to admit I don't know.
(be back after lunch)
#define MEM_LIBC_MALLOC 0
Rebased and tested successfully on the 4M version after the fix.
Now, wifi.radio.start_ap, wifi.radio.stop_ap, wifi.radio.connect and wifi.radio.stop_station are ready.
I only now need to do the getters for the ap.
The error messages I added are very much suboptimal. I would very much appreciate some suggestions.
This PR adds a Mastodon #CircuitPython tag link to Social section
Thanks!
Hi @idle owl I am playing with ESP32 board and I find that learn guides are not great at telling how to install CP on it. The definitive guide is this: https://learn.adafruit.com/circuitpython-with-esp32-quick-start/web-serial-esptool but board specific pages do not link there, sometime do not even mention CircuitPython is possible, at best they link to installing CircuitPython guide that talk about UF2 and RP2040. I made a few comment on some learn guide, but the "problem" is a bit general it seems, maybe because of the templating system too.
I think those three board and associated product page are the most important target: https://circuitpython.org/downloads?manufacturers=Adafruit&mcufamilies=esp32
Yeah, that's what I said. 🙂
yeah sorry I misread your link 😉
I believe board guides and product pages do not talk about Circuitpython on ESP32 yet because it's in beta and they don't want to push it yet
Oh, this C3 board is not beta and could be added: https://circuitpython.org/board/adafruit_qtpy_esp32c3/
I meant CP 8 is beta
but yeah the info is missing from cp.org
FYI, if I recall correctly, this action still leaves access to all of the repos. It's a bit odd how removal from the team works. I see @stuck elbow asked to leave it as is for now anyway, so it's not a bridge we need to cross yet.
This is due to most of those guides being created significantly before we added CP support to ESP32. I will make a note to have Eva go back and add in the applicable pages into the relevant ESP32 guides. She's in the middle of another project right now, so it might be a bit. Thank you for pointing this out.
wasn't there talk about where to reference the ESP32 page in the welcome to circuitpython guide ? (which is the "get started" link on cp.org)
ah there's an issue on cp.org: https://github.com/adafruit/circuitpython-org/issues/1034
I have issued a ticket on Waveshare's website requesting for the PID#. We'll see.
TBH, I'm not sure there is significant value top stop the AP during a running program. Changing the AP SSID/password, then restarting the code worked fine when I previously tested. I think there are things that just requires the radio to be hard power cycled. For example, once the AP is started the channel assignment will not change without a hard power cycle.
I looked at the error messages. "cannot be stopped" has the connotation that something is preventing it from stopping. IMO, "...
I have an application (on ESP32-S*) that sets up different SSIDs at different times during a run.
We are (hopefully) trying to have a single consistent wifi API for both espressif and raspberrypi, but unfortunately the raspberrypi underpinnings are less mature / less granular, so we'll have some limitations (for now?)
Hopefully as cyw43 is updated, this stuff will be fixed.
However now we are stuck with what we got.
microcontroller.reset() is still an option.
I'm out. Good night everyone.
night!
In the code for setting PWM duty cycle in the native PWMOut implementation for the RP2040
(https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/pwmio/PWMOut.c)
I found this:
// Wait for wrap so that we know our new cc value has been applied. Clear
// the internal interrupt and then wait for it to be set. Worst case, we
// wait a full cycle.
pwm_hw->intr = 1 <slice;
while ((pwm_hw->en & (1 <slice)) != 0 &&
` (pw...
"Significant Value" was a poor choice of words, on my part. I agree with common api within CP. Since we have to wait for SDK/firmware improvements, I propose we just stick with the current state of the AP development. Cleanup and merge for 8.0.0, and add an open issue or milestone to re-evaluate for future releases.
I'm not really sure. If this is still our branch:
https://github.com/adafruit/esp-idf/tree/circuitpython8
We seem to be on 4.4.1?
igrr says here that support is in 4.4.2.
espressif/esp-idf merged / closed PR 7688 (link above) seems to be where the support is added. Issue 7670 is closed (link above), but oddly issue 8365 is still open (link above).
This was done as part of #5067 -- if it's important for the way PulseOut uses PWM, perhaps the 'wait for duty cycle update' code should be moved accordingly.
https://github.com/adafruit/circuitpython/pull/5067/commits/e87e1d81752605e4ef79e2a89d440c5b2b93ef58
I see the "Update version to 4.4.2" comment there, so in theory it should work. I'm not set up to build and test for a while. Also very baffled about the conflicts... I thought I fixed it at one point (basically copying the then-new patterns), but there are a lot more diffs now that I don't grok at all. If someone else wants to jump in sooner, feel free.
Instead of attempting to add a new chip (S25FL128L 16MB SPI flash) that doesn't have an existing definition in nvm.toml I've decided to go with the W25Q128JVSSIQ https://www.adafruit.com/product/5634 for the custom bluefruit sense build.
At the time I started the project the Adafruit approved chip was unavailable (chip shortage)... which is why I had to try to build my own. Now I can just drop in that chip and test from a breakout board first with bodge wire too. This seems like a smarter way to go now.
So I think i'll be closing this PR https://github.com/adafruit/nvm.toml/pull/9
Is this needed? The rp2040 port auto detects flash size so it should work fine with the 2mb definition
These have been moved to common mpconfigport.mk and can be removed.
@onyx hinge need a PID approval for the UF2 before I can continue with my custom 16MB bluefruit sense modification.
Sounds good!
@analog bridge I’d love to hear your thoughts about the coprocessor issue I wrote up
I just now picked up coproc again. Currently working on PR 7115, will look at your issue comment next.
Thanks! I’m headed to bed now but will reply tomorrow
Should our build directory be build/board instead of build-board?
i.e. move board builds to a sub-directory of build at the root of the port
@jepler Can you run the same code (both ulp and circuitpython) on esp32s2 as well.
I am unable to reproduce this with a simple blink example on esp32s2.
Thanks for the suggestion (I noticed you've worked on audio for CircuitPython a bit, so I thought you might have something to add!), but I'm not trying to do MIDI stuff, and it looks like synthio currently can only do a square wave. I'm looking for something more full featured, where I can basically programmatically craft custom waveforms in real-time. Or rather, I can programmatically craft waveforms already. I just need an API that allows me to play them in real-time, as they are bei...
Bootloader PR has been approved and merged.
Could you refactor the definition of show_board_error and the check into an existing or new .mk file so that it doesn't need to be duplicated in every file?
Any update on this?
@tannewt No updates. The display doesn't work correctly either in the 8bit or ther 16bit mode, and I couldn't get it working with the current libraries. There is some work to be done with the parallelio before this is working, but I don't currently have the cycles to work on it.
Scott, @.***
Welcome Back!
Congrats and hope your child is healthy and well.
I know there is a balance between usability and functionality and Adafruiit
and the Cpy Group truly wants usability for novice users, etc.
I too find the usability factor the main reason to use CPy and not straight
C/C++ code.
Native CPy can read the ADC without the DMA. On the RP2040 the fastest time
(that I was able to achieve)
was about 20 microseconds.
My motivation to develop analogbufio was for a seri...
@tulip sleet is tools directory fine to place show_board_error.mk?
it could go in a py/circuitpy_*.mk
or py/?
right now the check at the top of the Makefiles, but I don't think it has to be
Starting a couple of years ago, git added the concept of partial clones. This adds the --filter option to various commands, git clone , git submodule update, and maybe more. The partiality can be to fetch only the "blobs" (file contents) needed for a particular checkout, or to fetch only the part of a tree.
Rather than repeat some good explanations here, take a look at these writeups:
https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/
https://abou...
I am concerned about something down the line using BOARD parameter in circuitpy_*.mk
so py/show_board_error.mk?
i don't know what you mean by "down theline"
if it is at the top of the circuitpy_something.mk file, is that safe enough?
something using BOARD parameter in circuitpy_*.mk files
it depends on where that gets included
I see, $(BOARD) is used before circuitpy_mpconfig and circuitpy_defns are included
I think we could move this to PWMOut deinit or a private C-only API for PulseOut. It should only need it when setting the duty cycle to 0 and ensuring it happens before deinit. (Otherwise the pin would be left high.)
But I think if you move the check down to the top of circuitpy_mpconfig.mk, it will still do the check, just a little later. From ports/atmel-samd/Makefile:
# Select the board to build for.
ifeq ($(BOARD),)
$(error You must provide a BOARD parameter)
else
ifeq ($(wildcard boards/$(BOARD)/.),)
$(error Invalid BOARD specified)
endif
endif
# If the build directory is not given, make it reflect the board name.
BUILD ?= build-$(BOARD)
include ../../py/mkenv.mk
# Board-specific
include boards/$(BOARD)/mpconfigboard.mk
# Port-specific
include mpconfigport.mk
# CircuitPython-specific
include $(TOP)/py/circuitpy_mpconfig.mk
# qstr definitions (must come before including py.mk)
QSTR_DEFS = qstrdefsport.h
# include py core make definitions
include $(TOP)/py/py.mk
include $(TOP)/supervisor/supervisor.mk
# Include make rules and variables common across CircuitPython builds.
include $(TOP)/py/circuitpy_defns.mk
even if BOARD is used in mpconfigboard.mk or mkenv.mk, the check will still happen?
just a little later. It will fail early enough, I think?
py/mkenv.mk stands out as a good option, it is guaranteed to be at the top as it defines $(TOP)
If you put the define and the ifeq test stuff in circuitpy_mpconfig.mk, I think it would still just work. The advantage of putting in circuitpy_something.mk is that it doesn't need to get merged from upstream (but if they have the same structure, that's a good place too)
py/mkenv is ruled out as mpy-cross.mk uses it and its routine dosen't require a BOARD parameter, I suppose
circuitpy_mpconfig.mk is only used in ports/*/Makefile (besides something reading it for making the support matrix)
how about circuitpy_mkenv to place everything you mentioned above, it seems to be common across all ports
I don't see a circuitpy_mkenv.mk
I mean new file in py/
that sounds good, more stuff could be in there later that is make-related, not port, board or feature-releated
good idea!
As I re-test today I'm getting different results. Of course, I'm also using different boards and different builds of CircuitPython. Notably, these boards are non-PSRAM boards, but at least they're in the feather form factor and have the LED on GPIO13. The build is 8.0.0-beta.4-25-g195ad4e479 which is the same as b8a2d3ffdcbd396a6f551a15abfc8ca7705e8d2e except for the addition of these boards.
Here's a full example with all necessary files:
[coproc-example.zip](https://github.com/adafrui...
Fixes #1104. The page.path variable has the folder, exact filename, and extension, so it really simplifies things.
@prplz Maybe not. I think its ok to have though. Explicit tends to be better.
Know what would be really cool though? Something similar to
audiocore.RawSample, but with a FIFO instead of a static array. If the FIFO had some way of easily checking how many additional samples it has room for, it would be really easy to include a function as part of the program loop that checks the FIFO and generates enough to refill it each loop, before it runs out. Even a 50 to 100 millisecond FIFO buffer would probably be plenty. (Maybe this should be a feature request specifically ...
@slender iron can EXTERNAL_FLASH_DEVICES list devices of different capacities and it will work correctly (select the actual capacity at runtime)? I think existing examples are all same-capacity. EXTERNAL_FLASH_DEVICES = "GD25Q16C, W25Q128JVxQ" and so I bet this was never tested. Thinking about @midnight ember's 16MB modified bluefruit sense https://github.com/pidcodes/pidcodes.github.com/pull/787 -- seems like it SHOULD work though
flash_device->total_size seems to be used consistently
i had the same thought but since it's build just for me i removed the lower capacity and added the bigger one
EXTERNAL_FLASH_DEVICES = "W25Q128JVxQ"
should i leave the lower capacity in there to test that out? can do it if it'll help beta test that np.
I'm not sure on what ports it would work correctly
@midnight ember are you actually making it as a product or are you just hacking one?
mod/hack
I wouldn't bother getting a pid or committing the board def into cp
I know we have a couple haxpress builds but I doubt they are used at all
oh, right duh. guess i felt bad trying to use adafruits vid without permission 😞
was following the guide to the letter... too much.
like the QT PY M0 haxpress ? There are a few in nature (including mine)
I like the general idea that this is trying to portray and agree with the suggested api changes.
This is a vast topic covering multiple platforms and use cases, it would be interesting to see how this evolves.
qt py m0 is a bit different since the flash spot is unpopulated
the nrf sense would require removing the existing flash
Not gonna lie, these little PCBs look like skeleton hands with two fingers up
one of those things they have in stadiums
Actually it’s cartman
foam hands or whatever it's called
Stupidly, they're usually referred to as "foam fingers" when they almost always include a whole hand.
yeah does kinda look like that, just a coincidence of the footprint required for the mod
because the headers are in the way so it has to go past the headers
and because i usually use stacking headers they're pretty tall, once installed it's not coming out
analogbufio is new in 8.0.0. I suggest we make a few tweaks to the API before we stablize 8.0.0.
- [ ] Rename BufferedIn.read to readinto.
- [ ] Provide the buffer to readinto rather than the constructor. The constructor would reserve resources needed besides the output buffer.
- [ ] Have readinto return the number of samples read in case an error causes fewer samples to be captured.
Looking back at the analogbufio code I see that the dma_channel_configure call IS in fact in the read (sigh). I suppose it could have been placed in the constructor (with the start_immediately flag set to False).
I think the constructor should reserve any resources it needs (like the pin and a DMA channel.) Then read (which I'd rename to readinto) would setup and trigger the dma to read into the buffer. The constructor could still do most of the DMA setup, just not the actual buffer set...
rewatching your RP2040 streams from the beginning and they are excellent - quick question - did you ever get anywhere with the "upload code via BLE idea"? or can the pico W do something like this via WLAN?
the BLE stuff is done for nrf basically
and I've just started bringing the web workflow to pico w
Is CDC 0 always repl? Or if repl is disabled, is the non-repl CDC index 0? Asking because I wonder about this ... ``` // Console will always be itf 0.
tud_cdc_set_wanted_char(CHAR_CTRL_C);
@tulip sleet maybe you happen to know/remember?
@amber sundial details are here: https://docs.circuitpython.org/en/latest/docs/workflows.html
looking...
awesome thank you very much!
my pico w web workflow branch is here: https://github.com/tannewt/circuitpython/tree/picow_web_workflow
if you look in shared-module/usb_cdc/Serial.c, you'll see how it picks up the interface number from self->idx. That would be the safest thing to do, to reference usb_cdc_console_obj, which right now is a static in usb_cdc/__init__.c
so maybe you have to make that a global, or add an accessor function or a helper function or something
OK but if it's enabled it'll be idx 0, so the existing code is irght
yes
I may be flashing it wrong this time around, tried a few ways, but I get a boot loop:
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x18 (SPI_FAST_FLASH_BOOT)
Saved PC:0x421099f2
SPIWP:0xee
Octal Flash Mode Enabled
For OPI Flash, Use Default Flash Boot Mode
mode:SLOW_RD, clock div:2
load:0x3fce3808,len:0x68
load:0x403c9700,len:0x980
load:0x403cc700,len:0x25a0
entry 0x403c98a4
huh, tinyusb reports that the duration of the break signal is 65535ms. luckily you can send more characters before a minute is up. Unfortunately, the "break" signal is not sent if the software buffer is full, so this doesn't help.
or at least tio doesn't succeed at sending it, it could be a tio limitation
that seems like a bug?
is it an open issue on tio?
no
I'll write something up
I should also check with current tio, I use debian's which is old
same
When the USB serial buffer is full, the Ctrl-C code to send KeyboardInterrupt can't be sent, which creates a problem if you've pasted code or otherwise filled the buffer and need to recover. A similar problem affects advanced UIs that interact with CircuitPython and may send characters when they're unexpected, such as mu when it tries to move the cursor based on the user clicking on the screen.
The main way forward seems to be to use some kind of message that can still reach CircuitPython ...
@thorny jay I added the CircuitPython install page to the ESP32 Feather V2 guide. Do we have other ESP32 boards that support CircuitPython that don't have install instructions? Or is that the one you were referring to?
I posted the search page, let me try again.
Ok thank you
Ah ha. Ok.
Those need love, maybe you've done 1/3.
Hadn't thought to go that route to find them. Thank you.
Yes, one out of three have CP install instructions.
I assume this one is the same kind: https://circuitpython.org/board/adafruit_qtpy_esp32c3/
Mmm.... I think we have a separate template for ESP32S2. I'll add it to the list for Eva though.
Because it has no native Serial.
S2 is OK, you can do UF2.
Maybe that template would work. Do you have to use the Web Serial installer to get CP onto the C3?
or esptool
We only explain Web Serial on this though.
My only C3 is not supported, but I used the Web Serial...
Fair enough
My Windows PC is not up to date on ESPtool.
How, Adafruit has a great Web Serial page by Melissa, but some guide send to an external page.
This is basically the same thing, but templated to be for a specific board in the board's guide.
I found one thing, then an other, if you start pulling the rope there might be other. 🙂
Your welcome.
I'll see if I can take a look at the audiocore code. I don't think I have enough knowledge of the RP2040, let alone all of the other microcontrollers that might be able to support this, to code it myself. I do know that the RP2040 has some kind of DMA thing that can be used to drive a PWM at a specified sample rate. If 'audiocore` is already using that, I might be able to work out how to set that up with a FIFO for the RP2040. I don't have a ton of free time right now though, so I don't...
The author says "FYI: just made small change in Protomatter for ESP32-S3 to work correctly with PSRAM-equipped Feathers. I’m like 98% sure the change will compile fine w/CircuitPython, but mentioning just in case. This is in the 1.5.2 release on Github."
I touched up the non-UF2 install info at the top of the UF2 page and also at the top of the non-UF2 page
Hmm ok
The non-UF2 apge was very bossac orinted
We have this information spread out something fierce.
just added better pointers and text to STM and Esprssif
Ahh ok
also on the UF2 page, made clearer some boards can't use UF2
i did this only a couple of hours ago
Ok
based on a forum thing
Fair enough
@onyx hinge I know the tio dev had stopped by here and offered to help
@onyx hinge what runs lwip? is it done on cp function call?
code in the sdk
I'm having exec_user_callback queue up the web workflow background task but I'm not sure if the outer lwip code will be run
maybe it'll just work
This is one of those "I may be wrong, because it just worked and I didn't pay much attention to it". There is in socket.c static inline void poll_sockets(void) { but I think it actually happens from an interrupt which is in the sdk
src/rp2_common/pico_cyw43_arch/cyw43_arch_threadsafe_background.c
my curl call failed immediately now instead of hanging 🙂
how do I enable the debug_printf?
I think what I used was ```diff
-#if 0 // print debugging info
-#define DEBUG_printf DEBUG_printf
+#if 1 // print debugging info
+#define DEBUG_printf(...) mp_printf(&mp_plat_print, VA_ARGS)
👍
there are also a bunch of DEBUG macros in lwipopts.h but I'm not sure where their output goes
kk, I'm making progress so far
pico-sdk probably handles that
I did some testing with an ADXL343. I discovered a minor problem in the mode 3 setup on the RP2040 (the clock starts out low), but I have a fix for that and will be PR'ing it.
On the ESP32-S2, I don't have a good analog of your example. I am getting data from the ADXL343 which looks OK, including having bytes with the LSB = 1, but it is not the last byte that is read (which happens to be zero).
There are various Espressif bug reports about mode 3. The most notable one is https://github....
no mdns but everything else looks ok
well, websocket input isn't working...
and now it does
I'd need to go back and test it properly, maybe with python tools, but I have had weird issues with mdns with the app I wrote. I does mdns requests for circuitpython.local and I have been having 2 issues:
- when using a different port than default, the port isn't always reported in the mdns responses, resulting in an inaccessible board, but it's intermittent
- mdns names reported by the boards gain a suffix number that keeps increasing, I believe it might be the board thinking there is a name collision, but there isn't
I saw an issue for the second one and intend on looking at it
ah yes anecdata opened an issue for that I forgot
the first bullet sounds like an idf issue
I'll get my brain in mdns mode next week
though there are two small things to fix in this change first
and next week is a short week
The latest commits make a few changes including
- changing the name of the constant to
displayio.CIRCUITPYTHON_TERMINALand make it return the terminal group that is already in memory. - Change the internal API calls to use set_root_group instead of show all the way down into display_core (made this internal change for 3 types of displays: displayio.Display, displayio.EPaperDisplay, frambufferio.FrameBufferDisplay)
- Added the set root group property to EPaperDisplay (tested successfu...
While testing for #6510, I found a different problem on RP2040. The hw peripheral does not start with SCK high when polarity set to high. This is discussed here:
https://github.com/raspberrypi/pico-sdk/issues/868
https://forums.raspberrypi.com/viewtopic.php?t=336142
Add a workaround, which can be removed when pico-sdk is fixed (scheduled for 1.5.0).
Tested on a Feather RP2040 with a mode 3 sensor, ADXL343.
I tested this with a post-8.0.0-beta.4 build with QT Py ESP32-S2 rev B and rev C boards. I am connecting to a Ubiquiti AP that is about 6 feet away. No problems. Is anyone still seeing this problem?
Tested with a QT Py ESP32-S2, running a while True: loop, and also waiting to open a WiFi connection. In both cases, ctrl-t b in tio caused a KeyboardInterrupt. I didn't encounter any problems using tio in this way. Thanks!
I can attempt this again and see with the latest release candidate and provide as much info as possible myself!
@anecdata I just pushed a commit reverting flash mode back to dio, can you do a re-test.
Still boot looping:
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x18 (SPI_FAST_FLASH_BOOT)
Saved PC:0x42109a36
SPIWP:0xee
Octal Flash Mode Enabled
For OPI Flash, Use Default Flash Boot Mode
mode:SLOW_RD, clock div:2
load:0x3fce3808,len:0x68
load:0x403c9700,len:0x980
load:0x403cc700,len:0x25a0
entry 0x403c98a4
The UART shows up correctly as CP2102N USB to UART Bridge Controller, but oddly the USB shows up as USB JTAG/serial debug unit (macOS)...
Does the n8r8 definition still boot?
The current board definition is basically the same as n8r8 apart from obvious changes to accommodate 32MB flash.
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4-21-g8f414eb4e on QT PY ESP32-S2. Had 4 QT-PY ESP32-S2's running in my office. They all core crashed when I restarted my Wi-Fi router. Simplified my code and reproduced the problem multiple times.
Code/REPL
from secrets import secrets
from time import sleep
import wifi
def connect_to_wifi():
"""Connect to Wi-Fi."""
print(f'Connecting to {secrets["ssid"]}...')
# Test Wi-Fi signal...
The N8R8 .bin artifact also boot loops on the N32R8 board. I've tried two N32R8 boards, just to make sure one wasn't flaky. Something seems to have changed behind the scenes.
When a commit with checks is found, compare it head commit instead of merge ref.
Support psram rgbmatrix on all esp32 variants.
Note: Pending PR: https://github.com/adafruit/Adafruit_Protomatter/pull/55
The Qt Py S2 I was testing with is now a permanent part of my dragon skull project. Ordered another one which should actually be arriving later today. Will look into testing this for you tonight. @dhalbert should I use a nightly build or would you prefer I use the beta 4 release?
Every update you need to write both tables with the old and new data as far as I understand.
I'm assuming this solves some problem, but could you give an example of what it fixes?
We recently added BREAK -> KeyboardInterrupt for USB CDC (#7227). It would be nice if the same were possible with serial adapters. Assuming that the USB-serial chip supports BREAK, we also need to enable it in esp-idf, so that an event is generated when BREAK occurs: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/uart.html#_CPPv4N17uart_event_type_t10UART_BREAKE
The goal is to diff between a PR's latest commit (head commit) and the last commit with a workflow run when available.
The PR's merge ref was being used instead of the PR's latest commit which caused inclusion of changed files from the PR's base branch. The merge ref contains changes in the PR plus the base branch which might have been updated since that last commit.
Suppose two PRs A and B with base branch being main.
PR-B is merged into main prior to PR-A.
Now comparing PR-A's merge...
Thanks for grabbing this.
What testing did you perform? Is this change alone sufficient to make protomatter work on such boards?
In CircuitPython, it looks like we unconditionally define _PM_allocate: shared-module/rgbmatrix/allocator.h:#define _PM_allocate common_hal_rgbmatrix_allocator_impl. I am surprised that does not need to change for this to work.
@tulip sleet @analog bridge I happened to notice the note here https://github.com/adafruit/esp-idf/pull/7 that "MicroDev-1 force-pushed the release/v4.4-circuitpython branch from 778fe92 to dc144aa 2 days ago". The commit message at the tip of v4.4-circuitpython now says "enable BT-5.0 on esp32". Was this intentional or accidental?
[any typos mine, especially in the refs. github would simply NOT let me copy that line of text]
well the enable BT commit was intentional, I wasn't aware of your PR so that was unintentional 😅
@onyx hinge that PR switches the riscv toolchain back to patch3 by accident
danh revereted the riscv toolchain commits
@analog bridge some reason that change didn't go through the pull request process?
so I force push removed them
we should probably make that branch protected against pushes
I wish that those changes had not been undone by force pushing.
i also did some un-PR'd changes in that repo. I was trying to keep the branch fairly clean, because it contained a bunch of confusing unnecessary commits.
the circuitpython8 branch became obsolete, etc. also
yes, because of the force pushing I now have to revise my branch and pull request. That's one reason to NOT force push: it makes any pull request that was in process "include" the commits you wanted to get rid of.
mea culpa and I'll PR changes to that in general. I think this was when no one else was around or something
also it appears that change to that kconfig file did not go through the pull request process, get approval, etc.
I went ahead and created branch protection rules for "release/*" in adafruit's esp-idf fork. They are modeled after the main branch protection of circuitpython. As I write this I'm second-guessing that I did this unilaterally so if consensus differs from my feelings please just go ahead and remove the protection again.
I think that's ok. We can undo the rules in case of emergency.
@onyx hinge apologies for the trouble
while we are on the topic of protection rules, in adafruit/circuitpython, can branch creation by pushing be disabled?
you mean is it technically possible? I don't know. The way branch protection rules are worded, it all sounds like it applies to branches that exist.
Switched to a new branch 'x-test'
jepler@bert:~/src/actions-playground$ git push --set-upstream origin HEAD
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Create a pull request for 'x-test' on GitHub by visiting:
remote: https://github.com/jepler/actions-playground/pull/new/x-test
remote:
To github.com:jepler/actions-playground.git
* [new branch] HEAD -> x-test
Branch 'x-test' set up to track remote branch 'x-test' from 'origin'.
jepler@bert:~/src/actions-playground$ git commit -mx --allow-empty
[x-test 7685da4] x
jepler@bert:~/src/actions-playground$ git push origin HEAD
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 854 bytes | 854.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: GH006: Protected branch update failed for refs/heads/x-test.
remote: error: Cannot change this locked branch
To github.com:jepler/actions-playground.git
! [remote rejected] HEAD -> x-test (protected branch hook declined)
error: failed to push some refs to 'github.com:jepler/actions-playground.git'
so, in my test repo I created a protection rule for "x*" forbidding push. This did not stop the branch being created by push, only updating it via push.
fwiw to protect myself from accidentally pushing to repos/forks I didn't intend, I try to do the following: Set up origin with a https URL, and my fork with a git URL. Since happily all the repos I use daily are public, this means I can fetch them all without authenticating over https; and I can push using my git key for authentication. but when I accidentally push to a remote that is https, I get prompted for a password, which stops me doing that.
all that said, https://stackoverflow.com/questions/61811708/github-new-branch-creation-restriction says there's now a checkbox to prevent the branch creation, let me re-test. I didn't see it to turn it on.
the image shown there doesn't match what I'm seeing at all. hum.
have we had cases of accidental branch creation?
I am responsible for at least 3 instances that I recall
I don't know about in circuitpython specifically, but I know I occasionally push to a different remote than I intended.
$ git push origin HEAD
fatal: 'disabled' does not appear to be a git repository
fatal: Could not read from remote repository.
```you can also set the push url to something invalid as a way to avoid ever pushing to that repo.
I went ahead and disabled bleio on esp32 boards with psram. This can be tracked in an issue.
Also, it would be nice if someone can test this. @Neradoc pinging you for interest.
seems like the workaround that was detailed elsewhere. didn't test.
S3 isn't looking very good.. it's speeds are on single digit kilobytes..
Tested and working with the CH9102F USB converter on Adafruit's Feather ESP32 V2 (& tio as the software on the host computer)
Closes: #7233
Okay, the latest commits add the set root group functionality for FrameBufferDisplay. I tested it successfully on Feather RP2040 with a small Sharp Display breakout, as well as Matrix Portal M4 with an RGB panel. The show() API remains in tact for now, but internally it also uses the new set_root_group stuff.
I think this is ready for further review now.
I noticed that all the boards were being queued for changes specific to a port or a board.
I traced the issue to changed_files being incorrectly set since the switch to tj-actions/changed-files@v34.
Offering a port of the Boardsource Blok on their behalf. Let me know if I missed anything, and I'll try to swiftly resolve it.
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30; Raspberry Pi Pico W with rp2040
Code/REPL
import board
import pwmio
led = pwmio.PWMOut(board.LED, frequency=5000, duty_cycle=0)
Behavior
led = pwmio.PWMOut(pin, frequency=5000, duty_cycle=0)
Traceback (most recent call last):
File "", line 1, in
TypeError: Expected a Pin
Description
No response
Additional information
Using digitalio.DigitalIO(bo...
The LED pin on Pico W is not a regular pin. It is accessed through the CYW43 coprocessor and its firmware, and is not available for PWM use. Real pins like the regular GPIO physical pins can be used with PWMOut. (The LED pin on the regular Pico works as you would expect.)
@jepler I am not sure if there's an improvable error message here or not.
Oh, ok. I was porting some code from the Pico to Pico W. This explains the difference. I'll refactor my code that handles the LED.
Thanks.
switch validate_obj_is_pin to use mp_arg_validate_type and make mp_arg_validate_type print the required type, so that the error is
>>> p = pwmio.PWMOut(board.LED)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: pin must be of type Pin, not CywPin
?
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30; Adafruit QT Py RP2040 with rp2040
Code/REPL
from ulab.scipy.signal import spectrogram
Behavior
ImportError: can't import name spectrogram
Description
Had working example of this tutorial: https://learn.adafruit.com/mini-led-matrix-audio-visualizer
Stopped working after latest update.
Additional information
From the repl >>> help(ulab.scipy.signal)
shows only s...
Adafruit CircuitPython 8.0.0-beta.4-38-g96fc85cd1 on 2022-11-19; Adafruit QT Py ESP32S2 with ESP32S2
Connecting... 192.867.5.309 Disconnecting...
Connecting... 192.867.5.309 Disconnecting...
Connecting... 192.867.5.309 Disconnecting...
Connecting... 192.867.5.309 Disconnecting...
Connecting... 192.867.5.309 Disconnecting...
Connecting... 192.867.5.309 Disconnecting...
Connecting... 192.867.5.309 Disconnecting...
Connecting... 192.867.5.309 Disconnecting...
Connecting...
Good job devs. Bug squashed. Closing issue.
Wifi scanning should be stable across all ESP32-S2's again which is currently at 21 boards according to circuitpython.org If anyone with an S2 has a wifi scanning issue on any version lower than beta 4 please ask them to update to beta 4 or a nightly build if possible.
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30; Waveshare ESP32-S2-Pico with ESP32S2
Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30; DFRobot Beetle ESP32-C3 with ESP32-C3FN4
Code/REPL
# without .env
>>> import wifi
>>> wifi.radio.start_ap("testing", "amogus sus")
>>> wifi.radio.ap_info
>>> wifi.radio.ap_info()
Traceback (most recent call last):
File "", line 1, in
TypeError: 'NoneType' object is not callable
>>> a =...
Oops, turns out ap_info is for info regarding "connected access point". Closing
Actually ap_info is for "the access point we are connected to". So there is nothing more to implement.
Ready for review.
CircuitPython version
error present in:
Adafruit CircuitPython 8.0.0-beta.3, RP2040 Stamp with rp2040
Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30; RP2040 Stamp with rp2040
problem absent in:
Adafruit CircuitPython 8.0.0-beta.1 on 2022-10-01; RP2040 Stamp with rp2040
Code/REPL
import board
from i2ctarget import I2CTarget
i2c_pins = {'scl': board.GP21, 'sda': board.GP20}
i2c = I2CTarget(**i2c_pins, addresses=(0x33,))
while True:
pri...
It seems likely that this was introduced in 8.0.0-beta.2 via PR #6985
The check timeout == 0 and timeout > 0 is intentional: -1 (do not block) is not the same as 0 (block indefinitely).
When timeout is -1 forever should be false.
Partially reverts #6985
Closes #7241
Thanks for finding and fixing this problem!
These branches are multiple years old and probably haven't seen any activity for a long time.
Use build/board instead of build-board, i.e. move boards build to a sub-directory of build in the root of the port.
We might be able to set pre-release releases to show up as latest release instead of the stable one:
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release
Optionally, you can select Set as latest release. If you do not select this option, the latest release label will automatically be assigned based on semantic versioning
[adafruit/circuitpython] New branch created: tannewt\-patch\-1
Thank you for suggesting this. I deleted most of these. Some of these were from micropython, and they are no longer there, so I deleted them here. There were a few named ones by us, and I checked their commits and found the changes had been committed, so I deleted those as well.
I kept all the x.y.z version style branches, because they are of historical interest. I have sometimes gone back to these branches for debugging reasons.
This seems fine to me. But I did a quick search for build- in the tree, and there are number of mentions, including possibly in submodules (adabot), for instance, so we'll need to change places that are assuming the old locations.
The top-level build directory (for documentation) is _build, which I kind of like, which is easy to spot. Maybe _build/<board>?
As you do this, please consider providing
- makefile variables that identify important targets e.g., $(FIRMWARE_ELF) $(FIRMWARE_BIN) $(FIRMWARE_UF2) $(FIRMWARE_MAP)
- phony rules that make them (e.g.,
firmware-elf: $(FIRMWARE_ELF)marked as.PHONY: firmware-elf
For instance right now I have my own additions that include things like
.PHONY: boot
boot: build-$(BOARD)/firmware.uf2
_douf2 "$(MOUNT)" "$<" "$(SERIAL)"
where _douf2 is a script that does the serial tr...
I'd share _douf2 but I don't want to end up supporting it, let alone if folksk wanted to use it on non-linux systems 😕
oh the serial trick with the baudrate ? I didn't think of that !
use discotool, it works on all platforms 😛
how does the serial trick work exactly ?
ah ok just open and close
@idle owl and/or @trim elm are the board.STEMMA_I2C PRs in many libraries waiting on anything further? Or is anything already in the works with them? Is it okay for me to start working through them with review / merge?
Oh yeah I’m just about to work through them all
where is tannewt?
Not around yet, apparently. He's on Pacific Time, so his schedule is later than those of us on Eastern Time.
Gotcha!
@jaunty juniper this is the bit that tickles the device into bootloader mode. uf2 bootloader except on espressif-family where it goes to esptool bootloader. ```python
import sys
import serial
s = serial.serial_for_url(sys.argv[1])
s.baudrate = 1200
s.dtr = False
<@&356864093652516868> We'll have our weekly meeting in about 90 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/1bxU_XogCgdpbxVPRA01tDc_tqLY0VFVUkpX6JQzwtd8/edit#heading=h.gnioqc80bi0b -- I look forward to everyone's updates!
Google Docs
CircuitPython Weekly Meeting for November 21, 2022 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to pa...
Fixes #6891.
Some ESP32-C3 board sdkconfig had unnecessary settings. Removed extra stuff. Tested changes on a QT Py ESP32-C3; seems to act the same before and after, including that bootloader messages did not show up.
so I made that, it seems to work on RP2040 and should be OS independent:
https://github.com/Neradoc/discotool/blob/main/examples/install_uf2.py
just for your curiosity
Awesome!
If that was a discotool entry point we could even start using it in a standard makefile rule
@tannewt I've opened this as a draft due to not having an opportunity to test it thoroughly.
The PID/VID used in this PR is taken from the device as-is, running the factory firmware OOTB. If that's not appropriate (I was hoping it would be), then I'm open to suggestions on how to proceed, as well as to changes to the current code.
Meeting Question: Any word on Circuitpython support for BLE on ESP32Sx yet?
@languid whale work on it will hopefully start next month but no promises
(we're hoping to pay nimble devs to help with it)
I’m running a little behind, but should be there in time to read my notes.
Attached: 1 image
Digging into the task for the day: trying to debug some low-level SPI communication issues in a prototype/eval setup. Somewhat of an odd day as a mechanical engineer when you're breaking out the oscilloscope to debug an inter-chip issue! Thank goodness I can at least control it all in #Python.
Using a Qt Py RP2040 from #Adafr...
💯
(can't wait to find out what this project idea is)
all the improvements lately making led animations super speedy is really cool.
project updates are welcome too. not just dev stuff here
quantization has to be tough, looking forward to reading about that
@tulip sleet it's your turn
liz is reading for you
🙂
Dan do you have anything you want to add to your status update?
nope, all OK, could not hear you because I clicked the headphones icon
stablehorde bot account on mastodon took the bot offline just as i was trying to use it. was going to have it create dragons playing synthesizer art. :/
jeplers stable diffusion art is worth following on mastodon just for that
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30; S2Pico with ESP32S2-S2FN4R2
Code/REPL
supervisor.disable_autoreload()
Behavior
AttributeError: 'module' Objekt hat kein Attribut 'disable_autoreload'
Description
It seems as if supervisor in CP 8.0.0 beta4 doesn't have the disable_autoreload function anymore. Will this be removed in CP8 or is it not yet included?
Docs latest
https://docs.circuitpython.org...
@onyx hinge Plan to do a PS2 to USB keyboard adapter? Or maybe you already did that!
@thorny jay I have not .. I'd be really surprised if there's not one yet
there is ps2io already iirc
It just need glue code...
interestingly ps2io is not on rp2040 so somebody would need to do that
I mean, you could use a different microcontroller -- seems it's on espressif mcus for instance
the 14 segment backpacks are back in stock, i noticed that. they were out of stock when i started my 7 segment project. will be cool to see a 14 segment project.
https://www.morningstar.io/post/sending-midi-nrpn-messages maybe nrpm? or maybe those are two different things
https://github.com/tannewt/circuitpython/tree/picow_web_workflow -- scott's picow web workflow branch -- i have not kicked the tires yet, so you should 🙂
🍎 🥧
Thanks Liz.
Hope everyone has a great week! Thanks for hosting Liz 🎉
Thanks Liz!
Thank you for hosting Liz!
Thanks for hosting, Liz!
Great meeting, thank you for hosting Liz!
later
thanks folks!
The API has changed. Try:
supervisor.runtime.autoreload = False
is there are label in git for a reported issue and then having a dev actually fix the bug. like verified bug fix? just seemed so anti-climactic closing the S2 bug that the devs did a great job of tracking down and fixing.
you can close with a comment like: fixed by #55555 (PR link)
I don't know of a label for it. There is some "resolved by" association that can be made between issues and PRs so that when the PR gets merged it will auto close / complete the issue as well although maybe automatically makes more anticlimactic rather than less without having to push the button.
oh, hmm i don't know the exact commit that fixed it
how would i go about figuring out what to reference as the fix?
Can't reproduce anymore, thanks everyone 🥰
That didn't last long. Also, thanks 😊
Following is the diff of sdkconfig built after this change.
diff --git a/ports/espressif/boards/microdev_micro_c3/sdkconfig b/ports/espressif/boards/microdev_micro_c3/sdkconfig
index 53796af53..75caa2d57 100644
--- a/ports/espressif/boards/microdev_micro_c3/sdkconfig
+++ b/ports/espressif/boards/microdev_micro_c3/sdkconfig
@@ -467,0 +468 @@ CONFIG_ESP_SLEEP_GPIO_RESET_WORKAROUND=y
+CONFIG_RTC_CLOCK_BBPLL_POWER_ON_WITH_USB=y
@@ -544,2 +545,2 @@ CONFIG_ESP_CONSOLE_NONE=y
-CON...
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1teUnR_VtWJ7LLngZ9pD38pyB_qpLpL5NZDVHXbybU1U/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for November 28, 2022 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to pa...
@MicroDev1 Thanks; it hadn't occurred to me to do that comparison. I added your suggestion, and had to add one more line to get it to compile. Now sdkconfig is identical with or without the PR for your C3 board and for QT Py ESP32-C3.
@lone axle twitch api ready for final review, hope you have fun coming up with some cool twitch integrations.
Thanks that did the trick! The documentation is a bit vague here. It really sounds like this is a read-only class.
@onyx hinge is it okay if I work on renaming with leading underscore and try to fix the out of bounds crash from https://github.com/adafruit/circuitpython/pull/7191 ? I think it would good thing to learn from for me, but don't want to duplicate effort if you're into it already.
What do you think about making root_group == NULL not show anything? show() could keep this behavior but root_group would distinguish between None and CIRCUITPYTHON_TERMINAL.
Maybe if I can pull it off for the RP2040, others can use that as a starting point to expand it?
Totally fine to start with one port.
I'd suggest starting with RawSample. The DMA to PWM is already done for RP2040 since CircuitPython has its own rudimentary audio pipeline. Try changing RawSample to queue input samples instead of returning the same buffer over and over again.
The PID/VID used in this PR is taken from the device as-is, running the factory firmware OOTB. If that's not appropriate (I was hoping it would be), then I'm open to suggestions on how to proceed, as well as to changes to the current code.
That PID is marked for the Pico rather than a waveshare board. It looks like they've requested PIDs for other boards so hopefully they will for this one too.
absolutely!
I do like that idea. From person using the API perspective that feels like the expected behavior.
The first way that comes to mind for me to show nothing is to make a new empty Group and show that. This would visually appear like showing nothing, but is perhaps against the spirit of "Nothing" since it's also just a Group that you can then start adding things to.
Is there some better or more proper way? If it is possible would we want to actually remove the old group and just not add a...