#circuitpython-dev
1 messages · Page 371 of 1
I think it's around that #help-with-circuitpython message
@mental nexus have you heard anything from the sigrok folks?
Thanks -- it would be great if someone would move the ticks stuff forward since I don't seem able to.
@slender iron I've integrated Open Street Maps using leaflet.js before and found it pretty nice to work with if you are in JS land maybe give it a look.
I'm not doing a ton in JS land atm. Most of what I've been doing is integrating more tags into the tiles so we can style based on broadband info
I worked on integrating layers to OSM as well. I used to work for a wireless company here in CR, so we made an SVG layer for mapping the AP with the channels, TX power, how wide the antenna is, etc.
the eternal sleep PR? sounds ominous
nice! I'm actually trying to annotate the OSM features rather than overlaying geometry
so marking a building or road as having fiber
(or not)
@onyx hinge internal. lol
revamped the guts of light sleep
@onyx hinge will we enable it for any of the higher end ones? Seems like it might be nice for highly specialized C modules
Nice to see that byte order thing fixed in findimports thanks for working on that Jeff!
@ionic elk I don't know for sure.
Or quirky junk that does hacky stuff that wouldn't be appropriate to merge upstream
well .. as it stands, you couldn't receive a pin object in a natmod and do anything with it. For instance. Because you can't call (say) common_hal_mcu_pin_is_free
so you can't use it to implement a novel HW driver
adding any function to the available functions potentially the compatibility of mpy files too
we could add that to a list for natmod linking or something right?
Can you still you use HAL stuff even? Or they don't have any HAL access at all, just C algorithms?
No news yet. Posted on the mailing list also, but no responses so far.
I think their IRC might be the most active. let me check...
Natmod was a pretty popular request in the past two years of Circuitpython202x blogs so it seems like people had need for it, but if it can't even use the hardware that's... real limited
you can use the functions and objects in py/nativeglue.h
Re this thread: https://forums.adafruit.com/viewtopic.php?f=19&t=164655 And my testing: Adafruit CircuitPython 5.3.0 on 2020-04-29; Adafruit Metro M0 Express with samd21g18 >>...
Could we just add the whole common hal to that file?
or does that bork our code size too much
yes probably (I did add one)
I mean for big boards, code size isn't a big deal.
Do you mean making the affected libraries into packages, so only the needed functionality is imported?
Yes, they were talking about tree-shaking
org_displayio_cartesian would not be better than displayio_cartesian yeah
Thanks everyone!
Thanks y’all!👋
Thank you
Thank you all, have a good week.
Thanks
Thanks everyone.
Thanks everyone. Have a wonderful week!
Always good to test your backups, @idle owl
I wasn't super specific about when I'm gone, but I'm here all week, and will be back around starting on the 25th
Enjoy your trip 🙂
Great conversation -- thanks!
@onyx hinge @lone axle can the file listing image generator create alt text too? That way the pics would be accessible
I think it could, we would just need to settle on what it should contain, and how to store it (unless there is some way to attach it to the image file that I am unaware of).
I think it does have to be done separately. Dan suggested trying to make the images html and CSS completely instead
that'd also make them accessible
I actually started down that road first, so if we end up wanting that I can maybe re-use some of the code from that first attempt I made. I do think we could generate an HTML file with contained CSS instead of an image. But I don't know if learn guide can embed an HTML page like that? If so that might be a better approach.
justin would be the person to ask
I think it's worth thinking about accessibility of it as dan pointed out internally
wasn't it mentioned that there's a text version under the picture ? I remember that coming up
@idle owl this is from one of my last pr. CI..
Collecting Sphinx Downloading Sphinx-4.0.0-py3-none-any.whl (2.8 MB)
often times there is a text listing (bullet points in my experience) that has all of the libraries listed as text. But I don't know about other required files like images / fonts / sounds etc.. Those are usually mentioned somewhere on the guide but maybe not right alongside the rest of the files that have to get copied to the device.
Cheers. Guess we find out soon if it breaks things.
hmmmm right
I wonder what the most accessible way is to show files hierarchies, how a screen reader would pick up on a file being indented to show it's in a directory
or it would be done by grouping in the html structure
it's a good question. I'm not sure of the best approach
mic = audiobusio.PDMIn(board.TX, board.D12, sample_rate=16000, bit_depth=16)
samples = array.array('H', [0] * 160)
while True:
mic.record(samples, len(samples))
magnitude = normalized_rms(samples)
print((magnitude,))
time.sleep(0.1)
I have trouble understanding. The sampling rate is 16000 i.e. 16000 samples in 1 sec. We create an array of 160 samples only. Can we make the samples array of length 16000 rather than 160? If no, then what's the point of the sampling rate?
Looks good to me. Thank you!
I'm at a loss. You're an org member with write access. I guess let me know if the issue persists and we'll dig deeper.
The 700ms safe mode window is hard to hit. My reaction time is not that good, and I have resorted to explaining this as a "slow" double-click, since I can't wait for yellow and then click again. Maybe just lengthening it slightly would be helpful. I would love an easier way to get into safe mode.
I'm totally open to increasing the time. It only occurs on power up so it's ok to make it longer. It's actually a hair under 700ms because it's 700 ticks which are just under a ms each.
...
usually admin level is needed to override a broken CI or lack of approval
It was approved.
She had access to approve it.
Everything was green for me when I clicked merge.
hrm
Yeah.
looks at branch protection settings
I'm getting a github unicorn when trying to load the branch settings....
👍
Merge gremlins
I think there is a separate list for the branch
Fair enough.
I didn't dig deep into that setting because I didn't want to bork something.
the master settings did load and they say the user must have the maintain role
main is failing for me though
I have main up.
nice!
It's a restricted list, and/or users with maintain role.
kk, so you can add stargirl either to the list or the role
I'll add stargirl to the list.
@ivory yew You should be good to go now.
As long as it saves. Fail.
Not good yet.
GitHub be havin' issues.
Oop, already added. So it saved and failed.
RIP GitHub...
Thanks for the fixes! I'm going to merge to get them in. Isn't a word usually 32 bits and 16 bits are halfwords or nibbles? May want to change that in the future. Fine for now though. Thanks!
@still zephyr How does this look? https://github.com/adafruit/cookiecutter-adafruit-circuitpython/issues/134
@slender iron I see you deployed the CI changes to cookiecutter, yes?
@still zephyr I can include some more prompts about info to include, since we're doing it. If you think that would be useful.
I will add.. If your PR cpmerms dcumentation, please build verify the documentation localy following steps in the guide
Ah fair enough.
yes? I think so. my brain has been thrashed by the merge
@slender iron There's a "help-text" or some such file in the workflow, that's it?
yes
I others points We will added to the design guide and that will be our refrence, what do you thnik?
Right on ok thanks
I don't understand.
if we have some others points in the future, we could add them to the designduife, to cover it there and have just one information source
Ah. As long as it fits in the design guide, yes. I don't want to bloat it with info simply to not have to add a link to the template.
@still zephyr I updated it, refresh and let me know what you think.
I see, no problem. I do not think there is more information to add besides the Named Tuples discussion That I saw last week
Kind of want short URLs for the guide links.
I like it
thank you @idle owl
is this rst or md?
we coudl create the links depending on the format to show just the link
It's neither. It's text.
ohhh
It's the same as anything you put into a PR.
That's why I'm requesting https://adafru.it/ urls for the guide links at least.
Adafruit Industries, Unique & fun DIY electronics and kits : - Tools Gift Certificates Arduino Cables Sensors LEDs Books Breakout Boards Power EL Wire/Tape/Panel Components & Parts LCDs & Displays Wearables Prototyping Raspberry Pi Wireless Young Engineers 3D printing NeoPixels Kits & Projects Robotics & CNC Accessories Cosplay/Costuming Hallow...
I think the design guide link should stay as-is because it's not necessarily an Adafruit link.
I see yes. Good point.
Ok short URLs requested. I'll update the comment when they're created. I added one more line about removing the text and including a list/explanation of changes. I'll ping once it's finalised.
Ok the short URLs aren't live yet, but I realised this isn't going to be live before they are. So I updated it. @still zephyr Can you take one more look?
Yes 🙂
It is good, besides the two links, that points to adafruit.com, it sees good to me 🙂
Yeah the links will be updated soon. I won't make it live until the links are live.
Good, Thank you Kattni
Links are live.
Thanks! We want to get it live ASAP, so it needed to be done quickly.
@onyx hinge Do you have a mo? I have two text files I need compared. I used your git ls-files magic to generate them but I don't know how to diff them.
I added the LED pin based on your list, but realised that was generated 2 months ago, and should probably be verified again.
@idle owl you need to compare them locally or in github?
Locally. They're two text files I generated locally.
you could use Pycharm
How?
Wait a sec I will take a screenshot
with XCode you might have FileMerge installed
This is excellent.
can you run opendiff in the command line ?
No idea 🙂
(for me it launches FileMerge comparing the files given on the command line)
Right click on the file, and the select the other file
2021-05-10 16:47:59.313 opendiff[23526:21640657] too few arguments
2021-05-10 16:47:59.319 opendiff[23526:21640657] usage: opendiff file1 file2 [-ancestor ancestorFile] [-merge mergeFile]```
Yep I found it! Thanks!
This should be the rest of the Adafruit boards that did not previously have an LED pin for the D13 built-in red LED.
No new boards with a little LED have been added without an LED pin in the last two months apparently.
Thanks @still zephyr and @jaunty juniper for the tips!
Thanks, but yeah we sorted it.
@lone axle Hmm. If I add a PR template to cookiecutter it will be included with all PRs to all libraries, including Community Bundle libs generated using cookiecutter. There's a way to specify custom templates, but I don't know how it plays into whether or not it would show up, and I don't know if we can utilise it to specify a different template for Community libs. https://docs.github.com/en/github/managing-your-work-on-github/about-automation-for-issues-and-pull-requests-with-query-parameters
You can use query parameters to share URLs with customized information.
Anyway it needs to go in, so I'm going to add it, but I'll add it with the intention of adding another one for community libraries so we can try to make that work.
Update images to the latest board revision and also update the description and product URLs. Capitalize the name.
Ty!
You're welcome!
So, recently something broke all the Python symlinks on my mac and I'm still trying to figure out what it was. But I was disturbed to find that if you update your python installation, apparently any virtualenvs you have will all break? And it's not trivial to fix them either, you have to manually go in and edit them all, or you lose your module list, which is kind of the whole point of having them
Is this actually true or have I done something horribly wrong?
How did you install Python? And what are you using for virtual envs?
I don't specifically recall. I have a python3 in /usr/local/bin/python3 which is what which python returns.
that looks like homebrew I think ?
I use Pyenv which I think avoids all that nonsense. There's some major issues with Homebrew's Python.
I think so too, lemme look up how to figure out how to make homebrew print the location of a package real quick
I read a post about it recently. Might be exactly what you ran into, I don't remember specifically.
Oh, the post talks about how if you upgrade any of the dependent packages, Python will be updated also. And it deletes all previous versions every 30 days.
I don't know about pyenv, I will check it out
but I would expect that you need to keep the older version for the venv to keep working, at least by middle version number ?
Homebrew I mean.
Yeah, check out pyenv.
There are other options, I'm sure. But having the lack of control that Homebrew offers is probably not good for a stable environment.
So this whole brew updates python and screws up all your VMs is just kinda a known issue, then?
reinstalling the venv with the newest version should be possible with some smart command
Appears so.
But like Neradoc said, there might be workarounds for your envs.
If the previous version of Python is deleted, maybe not.
Depends on what Homebrew considers "previous" I guess.
@jaunty juniper there wasn't one that I could find on google, just a bunch of stuff that said to find ~/.virtualenvs/my-virtual-env/ -type l -delete, which deletes all your modules so it's basically just "delete all your virtual environments and start over"
maybe something like you recreate the venv but you can reinstall everything by piping some requirements file or something from the old venv into the the new venv's pip install, which can all be automated in a script
that's harsh
I was thinking something like mv venv oldvenv python3 -m venv venv blabla/active cat or find or something ./venv/something/moduleslist | pip install
@ionic elk Not going to lie, I recently started over because my virtual envs weren't working properly and were all pretty much borked. And it was somehow installing everything outside the env as well. I now use mkvirualenv to create one and workon to open an existing one. I think that's Pyenv. But I had help, so I'm, uncertain.
but I don't know
I'll check out pyenv and see if that helps. If not I will try to spin up a script as @jaunty juniper suggests. But I'm weirded out by my googling, it makes it seem like this is an isolated problem, not something that happens to everybody
Otherwise I feel like I'd find more official tooling. Right now I'm seeing a bunch of hacks in my search returns
so I still feel like there's something I'm doing that's wrong
Anyway TY for help
Good luck. Hopefully it's not as awful as it sounds.
I'm just in the classic "is it broken or did I break it" phase
Yeah I get it. I always assume it's a me problem for WAY longer than I probably should.
And Python environments are a special little flower to begin with.
Normally I'd be happy to blame the system but "python updates break all virtualenvs" seems like if it was happening to everybody, it'd be a bigger deal than google is suggesting to me
From the post I referred to "The web is littered with frustrated reports about this problem and replete with hacked-together Bash scripts that purport to repair damaged Python virtual environments. And all because of one core misunderstanding."
Stumbled on it because it's on the blog of the guy who maintains the Pelican website generator software. https://justinmayer.com/posts/homebrew-python-is-not-for-you/
Justin Mayer is a software designer & developer, open-source maintainer, and conference speaker.
I did find it unclear with brew if or how to keep older versions of python
oh god now my git says there's stuff on my own PR that I put there but somehow don't have locally
and yeah brew updated me to python 3.9 from 3.8 when installing a different thing once
Ghost in the machine.
@idle owl ok that post makes me feel more secure about it
Good, that's what I was hoping for.
somebody had a ghost I2C address in help-with-project too (turns out it's an undocumented but expected thing)
In this case I think it's actually just that I merged on github weeks ago and forgot about it
whoops.
Sounds good to me. Even if it defaults to using the Template for PRs and it's the same one as Adafruit bundle I think that is okay for now. The user could always modify or remove it after they generate their project. Personally I'd probably just leave it for projects I create. I think having that template is helpful for folks creating PRs. A separate template for community bundle would be cool if we can get it to work but not a deal breaker in my mind even if not.
This also removes the need to pin share because we don't use the
status LED while user code is running.
The status flashes fallback to the HW_STATUS LED if no RGB LED is
present. Each status has a unique blink pattern as well.
One caveat is the REPL state. In order to not pin share, we set the
RGB color once. PWM and single color will be shutoff immediately but
DotStars and NeoPixels will hold the color until the user overrides
it.
Fixes #4133
PR for 7.x mpy builds: https://github.com/adafruit/circuitpython-build-tools/pull/71
I think changing all the relevant ifs to add github.ref == 'refs/heads/main' would work to limit pushes without interfering with releases (on 6.x branches for example), but I don't know how to test it:
if: (github.event_name == 'push' && github.ref == 'refs/heads/main') || (github.event_name == 'release' && (github.event.action == 'published' || github.event.action == 'rerequested'))
I followed the doc example of a push action that is limited to the main branch:
https://docs.github.c...
Is the only cross-screen way to change the background color of a display to use the adafruit_shapes library?
You could use displayio, do you want a full bckground color?
I'm just a bit lost in the intersection of all these libraries. I'm setting the background on a sharp memory display - adafruit_shapes works fine, but it seems hacky, so I was hoping to learn the right way if there is one
I'm using framebufferio, though, and I don't quite understand totally how that overlaps displayio
and I don't see any specific references to background color in the displayio docs anyway
Yes, kind of the same.
Agree, what normally you do is you create a bitmap of the size of your screen and the color that you want added to a tilegrid and then add append it
the display stuff is kind of getting over my head at this point
:), you know alarm.c gets over my head, displays stuff is easy 🙂
I will ook for an easy example give me a sec
I guess my central question is, are there competing systems for display?
The portal graphics library uses the background bitmap pixel to set the whole thing if you want a reference
because I keep trying examples that seem similar, but they don't overlap
so, we are trying to unify all in displayio
more recently in displayio_layout
but is a work in progress
almost there
Cool - I don't mean to sound critical at all! I'm just trying to keep up 🙂
no it is good,there are different tools, displayio_widget was created to facilitate and integrate all that and avoid having all these graphics libraries everywhere
when you say graphics libraries, do you mean things like framebufferio, terminalio, sharpedisplay, that kind of thing?
there are some displays that works with displayio and other with frambefferio. and sharpedisplay,
when I said graphics I am talking here about the different widgets like the progress bar, the annotation widget, the button, animated button, the text label
ok, so you mean higher level libraries
is it?
I have not try it myself
sorry if that's a dumb question, what does "difficult" mean? All my example code for testing the 1306 is still displayio
Main program
mic = audiobusio.PDMIn(board.TX, board.D12, sample_rate=16000, bit_depth=16)
samples = array.array('H', [0] * 160)
while True:
mic.record(samples, len(samples))
magnitude = normalized_rms(samples)
print((magnitude,))
time.sleep(0.1)
I don't understand. The sampling rate is 16000 but we store only 160 samples what happens to the rest. If I increase the number of samples, I don't see a rapid change on the serial plotter plotting the rms value. Plea...
I do not tell anyone, but lately we are trying to use VEctorio, more and more 🙂
Looking at my old code, I think you have to float the old pins too (set as input). I've included some relevant parts below. Please try this and let me know if you still encounter an error. I can clean up what I have (was messily written during a hackathon) and just post the whole thing as a demo. I'd also suggest blowing on the sensor as a means to test it, I found it was the lowest effort method to produce a lot of apparent noise (turbulence).
from adafruit_pybadger import ...
difficult is because I have not try it 🙂
Ok I clearly just need to read the doc pages for all these modules and make a diagram or something
I use the display shape library
try to understand what does what.
I think they are just API for differents thinks made by different people, that is my best guess
for faster animations and meory efficiency, low level I recommend vectorio
comes with the core
if you want the API go displayio
But displayio_layout worth a look
IT will depend on what you are trying to do I guess
Last thing the documentation is excellent in DisplayIO_layout so I recommend read the docs there, but happy to try to answer any question let me now 🙂
- extmod/uzlib: Update uzlib to v2.9.2.
- extmod/moduzlib: Update for uzlib 2.9.2.
- py: Remove calls to file reader functions when these are disabled.
- docs/machine: Change sleep to lightsleep and add timeout arguments.
- stm32: Implement machine.lightsleep().
- extmod/modussl_mbedtls: Remove deprecated mbedtls/net.h header include.
- unix/mpthreadport: Add thread deinit code to stop threads on exit.
- unix/mpthreadport: Cleanup used memory on thread exit.
- unix/mpthreadport: Remove busy w...
This removes examples/natmod/features0 again. Either I'd prefer to keep example/natmod/features0, or remove the associated test that has a hard-coded copy of this object code.
Also a nit about FALLTHROUGH but it can be addressed separately if you prefer.
More stragglers in "bitops", for some reason (it was my fault)
tannewt/merge_1.14:shared-module/bitops/init.c: FALLTHROUGH;
OK, this is direct from upstream. I might have written it differently.
yay, just ran across this bug
Tested on the Feather S2. I expected that trying to use more endpoints than available results in reset to safe mode. Here are a few boot.py that cause issues. (Manual safe mode recovers).
import usb_cdc
usb_cdc.enable(console=True, data=True)
- reset loop (status LED alternates purple and black)
import usb_hid
usb_hid.disable()
import usb_cdc
usb_cdc.enable(console=True, data=True)
- code.py runs
- device connected seen on USB (ioreg) but no drive, no seri...
@slender iron do you remember why you made this change in huffman? https://github.com/tannewt/huffman/commit/27b1bba76198a0b343f694a6d680b5293d1c56aa I notice we're also installing huffman in requirements-dev.txt, but .. not using it?
@slender iron did you pull-request your ulab fixes upstream?
ah great, you did
@onyx hinge no I don't remember
Love the generator - I forked it thinking I'd add the strokes as an option, but I see it's already in there as an option. Slightly different approach (current code divides R/G/B by 2 for the stroke - I converted it to HSV and cut the V in half), but it's imperceptible. Yay - I didn't have to fork it 🙂
Truly imperceptible @idle owl
I tested: the green blink after the code ends, red on exception and yellow when reset to safe mode.
- works as expected on a QT PY 2040
- works on the Feather NRF52840 Express after uncommenting
MICROPY_HW_NEOPIXEL
On a Feather M4 and Feather M0 Express, the LED stays either black or lit. It comes back to life when doing things like opening the drive in the Finder or activating and sending data to CDC2.
Looking for the seesaw rotary encoder library and example
@gloomy socket that's a good question, I don't see one either.
the demo shown in the product page was probably made with arduino
I am sure it will be added soon, but if getting your project going is urgent I think you may need to use arduino. https://github.com/adafruit/Adafruit_Seesaw/blob/ed2dbf6a8c73236846ec054100975e2216cec202/examples/encoder/encoder_basic/encoder_basic.ino
Arduino driver for seesaw multi-use chip. Contribute to adafruit/Adafruit_Seesaw development by creating an account on GitHub.
Nice find! I hadn't seen the arduino example
Could you update the image sizes so they are a 10:13 ratio?
See https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/preparing-the-images
Also, please keep the features list limited to the items on this page:
https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/adding-to-blinka. That's used to create the search filters.
You can just move them down to the description area if you'd like.
Thanks
@slender iron how would you feel about putting ESP-NOW on the radar, since Micropython has a PR up for it?
Greetings from the language summit @slender iron
@supple stag what hardware + python stuff are you doing? is it related to nmigen?
I work on the HDL magma and the surrounding eco system
I'm not sure why we'd do it. do we have an issue to discuss it?
@slender iron we have one up
You don't feel it's useful? It's a low level adhoc network, lets you use wireless without a router - I dunno, there's a ton of stuff I see enabled by that
I'm busy this morning so I can't discuss it now
np, just mentioning it since people brought up the new Micropython and Pycom support in Github
I'll go through my email later today
@supple stag I've dreamed of merging hardware def with python driver code like we have in circuitpython
I created it in a way that allows for more to be added. We'll see what we can do.
Ill be honest I am not super familiar with circuitpython. I saw the blurb for your(?) talk so was looking at it a little the other day.
it's a version of python for microcontrollers
Bonus!
(for CP folks, there may be folks from the python language summit dropping by)
For anyone who is interested in this module - what kinds of projects would you use it for? And what do you feel the biggest draws of it are, compared to other similar options?
@supple stag we have a lot of C code that talks to internal peripherals and lots of python drivers that talk to logic over i2c
Interesting, definitely intersting in chatting after the session
I'm in seattle so I think we're in the same timezone
yeah, I am in the bay area
k cool. I'll be around all day
well, most of the day. gotta get groceries and make dinner 🙂
I would LOVE this - the biggest use cases would be in-vehicle networks - specifically boats and RV's where I don't run a router - also in the shop for things like dust collection automation. Basically anything that doesn't need WiFi connectivity to the internet or to a server resource.
@jaunty juniper I added the LED pin to the remaining Adafruit boards. So everything we support is in line with the change to the code on that page. It's only in main right now though, so until we do a 6.2.x release, we don't have a CP release with those updates in it.
@thorny jay I just tried your mlx90640 code with a feather rf2040 on a keyboard feather wing. I am using CP 7.0 and had to make a few changes to the ulab calls -- after that it works great -- Thanks you! Do you want a copy of the code with the changes I had to make?
Yes please, share the code. I know ulab has change a bit in CP7 but did not try yet.
@thorny jay minor changes -- use ulab.numpy and remove .numerical ....
Thank you for sharing the code. I'll be trying it withe matrix-portal later.
Thanks, @makermelissa ! I totally missed the purpose of the features list, my apologies. And I have changed the image ratios to 13:1 as indicated on the link you provided. Originally, I only saw the 700x, 300x, and original size references. They weren't far off from 13:1, and now they should match exactly with a tiny bit of cropping.
Thanks again!
@thorny jay I made another simple change -- from ulab import numpy then replace all ulab.numpy with just numpy -- a bit cleaner.
I think you can test on your own fork with its branches. The S3 upload steps will be attempted but fail (I think.) We can also just do best guess and check to see how it changes for this repo.
Removed with the MicroPython 1.12 merge:
https://github.com/adafruit/circuitpython/pull/4693
But something like it is super useful for debugging, especially for intermittent exceptions.
I've been trying the latest builds and I'm still seeing the original problem. Is there anything I can do to help diagnose the root cause to help get this fixed?
Here is the notes document for Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1KY5czjOS8X8uZRGZpW3zT8RYCaMnOEZyUEC5GdTpzdw/edit
CircuitPython Weekly for 10 May 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to participate, add ...
hey weblate folks, how should we handle changes like: https://github.com/adafruit/circuitpython/pull/4747/files ?
ideally we wouldn't lose the existing translations
You are correct, it should not miss any strings. Not idea how that was done via weblate...
Do the meeting notes get wiped and overwritten each time, or is there an archive?
there is a new Google doc each time, and they get archived in github: https://github.com/adafruit/adafruit-circuitpython-weekly-meeting
weblate is doing the update after I merged a commit. I wonder if we should have changes like that hand edit the .po files to keep them linked
@idle owl are you around?
Eating dinner. I'll be around tomorrow.
Thanks 🙂
C python relies on sys.exec_info() and a traceback class missing from Circuitpython I believe, which is why I was worried a C python compatible version for traceback.print_exception would take more space and be more complicated to use. But I might just worry for nothing.
I personally would prefer we implement format_exception()/format_exc() or similar since getting the traceback as a list of strings is more generic and allows for easier piping into logging, uploading to a server,...
Ok, update @jepler. Hopefully fixed the docs too. Did an amend since I revived some files.
Thanks! This matches the changes I'd made at https://github.com/tannewt/circuitpython/pull/12 except that you revived the glossary and put an include in a different spot.
I don't know if weblate can or can't do this, but it would be nice if it kept the prior translations, and could match them up, even if mostly, regardless of case. It would then have a "original string casing changed. Translation still good?".
Probably require a bit of research on the Weblate project system
I looked through the files as usual and didn't spot anything. One comment that does not block approval.
Since these are MP_ARG_REQUIRED, the defaults are not necessary, and perhaps misleading. I can't find this in micropython, so maybe we added it.
This fixes a compiler warning about an uninitialized field.
It does appear to have a translation memory feature, which powers the automatic translation
https://docs.weblate.org/en/latest/user/translating.html#automatic-translation
@tulip sleet I have an old laptop under 10.12 (!!) it does that thing where the CDC interface name is not in the hierarchy of the serial port, though it has the original pyserial issue that identifying them by locationID is not enough since CDC 1 and 2 have the same locationID, so I can restore that scan function from pyserial as a fallback and maybe find a way to make it differentiate ports
we can also fall back to identifying by VID or VID/PID. I will see whether they really want it to run on High Sierra or whether later is OK.
VID/PID does not automatically recognize the right port, but you can always try them both if necessary from the dropdown in the lower right
of the Mu window
hmmm there is a bInterfaceNumber that uniquely identifies each port in addition to the common locationID, that should work
bInterfaceNumber is unique to the total USB device, yes, but is not unique across multiple physical devices (I think you know that. So bInterfaceNumber will not distinguish the data from the repl/console port, but it could help you distinguish the dual ports
like that:
+-o CircuitPython CDC data@1 <class IOUSBHostInterface...>
| | {
| | "locationID" = 68157440
| | "bInterfaceNumber" = 1
| | }
+-o CircuitPython CDC2 data@3 <class IOUSBHostInterface...>
| | {
| | "locationID" = 68157440
| | "bInterfaceNumber" = 3
| | }
On a Feather M4 and Feather M0 Express, the LED stays either black or lit. It comes back to life when doing things like opening the drive in the Finder or activating and sending data to CDC2.
Thanks for finding this! I'm able to reproduce it but can't find the issue. Will have to get the debugger out tomorrow.
@slender iron Can I just say a big thank you to you and the team for the upstream MPy merges?
of course! happy to hear it
we do "hug reports" every monday meeting. feel free to drop a note there whenever you have thank yous
(link to the notes doc in the pinned messages)
Will do!
I also may have spotted you on reddit mechkeyboards trying to use IO expanders for a keyboard
about 4 years ago
ya, I used a shift register for one end of it
What was the poll times like?
I'm looking at moving away from the pico to a teensy 4.1
I never measured it because I didn't notice an issue
really?
hmmm
I have the SPI MCP23 chips
and they're slower
my I2C ones are ~10ms a poll vs 16ms
the shift register was used to "bubble" the low value through
and the SPI bus is at 10MHz
yeah I haven't gotten my shift register boards in yet
this is all on the MCP23 chips
why do you think that's too slow?
I'm aiming for sub 1ms though
why?
your monitor likely updates at 60hz and you won't see the intermediate key state
humans can barely perceive 60hz
- To see if I can do it
- Because commercial boards claim to be able to do it so I'd love to make something that actually does do it and you can verify it
- I like to set a high bar to see what is possible
I also have 144Hz panels
USB is 1000hz I think
my only 60Hz panel looks slow to me these days, even just dragging the mouse around
I know it can't actually provide reports faster than 1ms
a logic analyzer may help optimize the code
since that'd let you see all of the bus traffic
errrr iirc, its that setting the row pin low takes too much time
because its all on the MCP23
so the 24MHz serial shift register should make that non-existant
but I think the teensy will be better since I don't have to deal with IO expanders at all and just some level shifters for the dotstar "SPI"
21 cols, 7 rows
I literally cannot fit it on the board
I could do it with the shifter register but I'd have no pins for the dotstars or screen
how many total keys?
112 iirc
do you have a logic analyzer?
nah, haven't gotten around to it yet, but I may need that tool
it could help ensure you are doing minimal transactions
they are super handy for optimization
USB HID max is 1000Hz, but most devices are 125-250Hz. I do have a mouse that's 500Hz though
iirc, I found someone else doing the same thing and I tested their poll code on my set up and they were ~20ms on my I2C chips vs my 10ms
I set the row pin then see if any of the interrupt pins are high, if the interrupt pin is high I ask the chip for that bank's interrupt flag register output then register the key press if the IO register in the MCP23 for that MCP23 pin being high then I report that key via the keymap and reset the flag for that bank to return the interrupt pin to low, then move onto the next row
I have a logitech G700s mouse that says it does 1000Hz reporting
I think my ducky keyboards also claim a 1000Hz report rate too iirc
Are you looking to build your own gaming keyboard/pad?
Yeah, I was wanting the pico mostly for the novelty plus the 2nd core would be good for LED animations and screen updates. The screen is for the numpad "layers", so you can what the numpad is mapped to, to be used as an optional macropad.
Also because the name Pyco (python and pico) for a full size board is like calling a guy who is 7 foot tall "tiny"
Sounds cool. If you're not playing a lot of FPS stuff tho, might not need to worry about polling rates
Haha, my favourite games are FPS :)
Kinda important then XD
Yeah, doesn't help that I'm a huge mechanical keyboard nerd too and that I plan to sell kits at some point, so I not only want it to be good to use for myself but something that I can have other people use too. I'm open sourcing all the hardware and firmware but the kit option is there for people who don't want to get boards fab'd and don't have the tools to do it themselves.
Fixes #2999 for now.
I didn't find anything of concern, except that some run-tests.py changes in the actions yml files were missed. All tests passed locally.
after the 1.15 merge, we will have about 7000 insertions+deletions of difference from micropython, when it comes to the language core files in py/ and excluding files with "circuitpy" in their names. That's a fair bit closer than 6.2.0 to its related micropython release (1.9.4), about 13000 insertions+deletions of difference.
```jepler@babs:~/src/circuitpython$ git diff --shortstat v1.9.4 6.2.0 -- git ls-files 6.2.0 -- py | grep -v circuitpy
184 files changed, 8835 insertions(+), 4282 deletions(-)
jepler@babs:~/src/circuitpython$ git diff --shortstat v1.15 tannewt/merge_1.15 -- git ls-files tannewt/merge_1.15 -- py | grep -v circuitpy
187 files changed, 5106 insertions(+), 1923 deletions(-)
across all common files, ```shell
$ f () { A=$1; B=$2; shift; shift; git diff --shortstat $A $B -- $(comm -12 <(git ls-tree -r $A -- "${@-.}" | awk '{print $4}' | sort) <(git ls-tree -r $B -- "${@-.}" | awk '{print $4}' | sort)); }
$ f v1.9.4 6.2.0
789 files changed, 16395 insertions(+), 10686 deletions(-)
$ f v1.15 tannewt/merge_1.15
526 files changed, 8191 insertions(+), 6036 deletions(-)
LGTM modulo the run-tests vs run-tests.py
LGTM. I checked the pin assignments for I2C and UART.
thankx btw i cant seem to build on windwos from main latest
$ make -C mpy-cross
make: Entering directory '/c/Users/ladyada/Dropbox/micropython/circuitpython/mpy-cross'
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
Traceback (most recent call last):
File "../py/makeqstrdata.py", line 744, in <module>
encoding_table = compute_huffman_coding(translations, args.compression_filename)
File "../py/makeqstrdata.py", line...
oh wait it cant find gcc anymore. wtheck
try a clean build too; QSTR errors can occur when a build failed early and is redone
aah i ifgured it out - i recently updated msys. i have to use 32-bit compatibility mode for gcc (!?)
now something else, probably some windows default encoding thingy
$ make BOARD="adafruit_qt2040_trinkey" -j 32
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
{'sku': ['W25Q64JVxQ']}
text data bss dec hex filename
244 0 0 244 f4 build-adafruit_qt2040_trinkey/boot2.elf
QSTR updated
Traceback (most recent call last):
File "../../tools/gen_display_resources.py", line 43, in <module>...
@onyx hinge I chatted w/damien and jim. we agreed it'd be neat to share the py folder
@slender iron these numbers back up the idea it's possible!
a modest amount of work trimmed thousands of lines of differences away
yup! I think we'll be under 100 commits difference
@ladyada this is a stab in the dark at your build problems reported in #4750.
@tulip sleet that works on Sierra (thanks to my mom's old laptop) if you want to test it, it falls back to searching the separate AppleUSBDevice/IOUSBDevice that are not in the hierarchy, by locationID + interface number https://gist.github.com/Neradoc/e718ee1db78549e510dfd03da2eed7d9#file-pyserial_list_ports_osx_sierra-py
Here is a quick CircuitPython example (no button) - https://gist.github.com/jfurcean/be1c34366dbaf44d0d5904c8a54501fb
I've bought a Feather STM32F405 Express and was expecting I could get it to act as a USB keyboard, but turns out USB_HID (and quite a lot of other features) aren't implemented for STM32 chips yet.
Is there any effort being made to implement USB_HID support?
@tulip sleet looking at that issue just above, it seems that HID and MIDI are disabled on stm32f405 due to lack of endpoint descriptors (there are 4 in+out pairs). With 7.0, can we enable it but .. I guess the user would have to disable CDC or MSC before turning on HID or MIDI? Maybe you'd like to comment, or maybe @ionic elk can say more about the HW limitations.
The OTG_HS in peripheral mode has 6 in+out pairs, but I guess it's the OTG_FS peripheral that CP uses.
I was just responding to that as you wrote. I'm not sure whether there are 4 or 5 available endpoint pairs. I need to double-check that. I have a provision for leaving HID, MIDI, etc, disabled by default, but if there is room one of them could be enabled.
so we could compile them in, but you might need to turn off CDC to HID, etc.
The OTG_FS interface main features in peripheral-mode are the following:
- 1 bidirectional control endpoint0
- 3 IN endpoints (EPs) configurable to support Bulk, Interrupt or Isochronous transfers
- 3 OUT endpoints configurable to support Bulk, Interrupt or Isochronous transfers
so one pair for MSC and 1.5 pair is needed for CDC REPL
and then they are all used up
I will query the user about this; not having REPL is a nuisance, but is possible
I think the OTG_HS does not have a PHY
ok, yes, it does have a PHY, but it's not wired up
yes, the OTG_HS has a FS-capable PHY; but it's not connected on the feather
i think it's not connected on the pyboard either
i'm not sure why we chose the FS instead of the HS. I think TinyUSB does support HS, but maybe there was some other reason
really old discussion: https://github.com/micropython/micropython/issues/260#issuecomment-34263530
huh I wonder what this weird unicode is doing in the middle of autogen_usb_descriptor.c (in 6.2) ...
// "Љ" : <class 'adafruit_usb_descriptor.standard.StringDescriptor'>
const uint16_t language_id[] = {
0x0304, 0x0409,
I guess that character is 0x409
yes, I forget the exact interpretation of 0x0409 as a language ID; I think it might mean "no language specified"
USB HID (and MIDI) are theoretically available, but they are not turned on. The problem is that the USB physical interface (PHY) that is connected to the USB connector only has 4 endpoint pairs. One pair is reserved for control purposes, one pair is used for mass storage (CIRCUITPY), and two pairs (well, 1.5), are used for the CDC serial (REPL connection). So that leaves none for anything else.
There is another USB PHY on the chip, a HS-capable one with more endpoints, but it is not connec...
since that script is all gone in master I won't worry about fixing the weird character.
The context for me is that non-ASCII characters in comments caused problems in some other source file when building on Windows
$ make BOARD="adafruit_qt2040_trinkey" -j 32
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
QSTR not updated
648392 bytes used, 396088 bytes free in flash firmware space out of 1044480 bytes (1020.0kB).
14884 bytes used, 247260 bytes free in ram for stack and heap out of 262144 bytes (256.0kB).
Converting to uf2, output size: 1292800, start address: 0x10000000
Wrote 1292800 bytes to build-adafruit_qt2040_trinkey/firmware.u...
@tulip sleet did you test that ? ☝️
I'm around!
not yet, you mean on high sierra?
Hello Kattni, could I pm you? it is nothing bad 🙂
yes
if you have some time to check it finds the interface names
Sure.
@slender iron looks like the 7.x bundle is not using the intended version of mpy-cross, or something. ```jepler@eric:/tmp/adafruit-circuitpython-bundle-7.x-mpy-20210512/lib$ od -tx1z simpleio.mpy | head
0000000 4d 03 02 1f 82 0f 06 02 00 00 00 00 27 37 00 21 >M...........'7.!<
0000020 01 61 20 80 08 28 28 28 28 48 43 30 4b 48 23 5d >.a ..((((HC0KH#]<
Is there documentation on how to disable the REPL?
Or better yet, route it to the serial port so I can just hook up a separate adapter to get to it.
build logs say: Building mpy-cross for circuitpython 7.0.0-alpha.1 which is older than we want. does it need to be changed in a different place too?
https://github.com/adafruit/circuitpython-build-tools/compare/1.8.4...master we need to release in circuitpython-build-tools
I made a release, but I guess we have to wait for the next bundle build 😕
It is working on High Sierra!
$ python3 pyserial_list_ports_osx_sierra.py
/dev/cu.Bluetooth-Incoming-Port: n/a [n/a]
/dev/cu.usbmodem621: Metro M0 Express - CircuitPython CDC data [USB VID:PID=239A:8014 SER=E50DEC9948314D5020312E36222216FF LOCATION=6-2]
/dev/cu.usbmodem623: Metro M0 Express - CircuitPython CDC2 data [USB VID:PID=239A:8014 SER=E50DEC9948314D5020312E36222216FF LOCATION=6-2]
do you need it tested on non-M1 big sur again? I can pass it to someone else to test on big sur m1
I tested it on Big Sur, I'm only missing the M1 for tests, though I don't expect any change since all the changed code should only be reached when no interface name is found
(but you know, software)
yes, that's what I think. I am awaiting some feedback from the Mu folks about corner cases, but if you update the PR to adafruit-board-toolkit to include the essence of this code, then I'll make a release, and also make a PR to Mu to require at least that version. thanks for your MacOS skills on this
This is all really, really new, and we're still getting the edges smoothed off, but we will think about enabling the possibility of HID while at the same time leaving it off at runtime by default on the STM32F4 boards. See the usb_hid and usb_cdc doc here: https://circuitpython.readthedocs.io/en/latest/shared-bindings/index.html.
Hi, I've just noticed an issue with garbled data in ulab. It looks likely to be related to taking a slice of a returned array (which is a view) but not storing that unsliced array anywhere. I'm just going to go rummaging in github issues...
Another community member added rotary encoder support in seesaw. It will be available the next time the bundle is updated, or you can grab the files direct. https://github.com/adafruit/Adafruit_CircuitPython_seesaw/pull/61
there is so much redundant info in that embed :/
oh well, someone worked hard on it!
@onyx hinge We avoid using get and set in CircuitPython libs. I might submit a PR to change the property names.
sorry if I was too quick to approve something unsatisfactory
No worries.
It's good, and I'm not sure how else to name at least one of them.
seesaw is older.
IIRC.
I figure if we're going to approve new code, we might as well try to stick with newer decisions, regardless of the current code.
anybody here use docker?
https://forums.adafruit.com/viewtopic.php?f=60&t=178954
@idle owl sems like the base seesaw class has its own smell, but then there are other classes that behave normally, like digitalio
I'm making a few simple changes. You can decline to accept them if you don't think they're appropriate.
@idle owl OK, we may be working at cross purposes
How's that?
Oh you're refactoring it anyway?
I'm creating the wrapper class. it sounds like you're interested in revising the main seesaw class. We could do both, nothing wrong with that
If the wrapper is going to be what is directly used, I don't care about what seesaw looks like. My concern is with the user-facing end of things.
But my changes aren't serious. Like I spell out position because there's no reason not to be clearer.
So I guess we can do both. I should PR first though.
I haven't tested it yet, but I am set up to do so.
OK, I will let you PR first
I noticed this on CircuitPython 6.2.0 on a CLUE (nRF52840):
Adafruit CircuitPython 6.2.0 on 2021-04-05; Adafruit CLUE nRF52840 Express with nRF52840
>>> import ulab
>>> import ulab.numerical
>>> import ulab.filter
>>> data = ulab.ones(10000)
>>> fir_taps = ulab.array([0.15, 0.2, 0.3, 0.2, 0.15])
>>> filtered_data = ulab.filter.convolve(data, fir_taps)[6:-6]
>>> ulab.numerical.sum(filtered_data)
9992.0
>>> len(filtered_data)
9992
>>> a = [] ### append to an array to write a...
Ugh. Memory error.
I had based my additions on the other parts of seesaw.py and the Arduino library, but I agree with both on the changes and the wrapper class. Will there be a wrapper class just for the individual i2c qt rotary encoder that includes the neopixel and button?
I was testing on clue fwiw
@gloomy shuttle what I was writing was strictly for the encoder position
I had to use mpy-cross to test on QT PY m0
Thats's what I'm about to do.
I was on clue so no troubles here
@gloomy shuttle really appreciate your contribution, thank you!
Should the seesaw library also test the seesaw version to make sure it is compatible with the device -- the Arduino code does this. For example the encoder build should be 4991
It is checked in the Arduino example, not in the library https://github.com/adafruit/Adafruit_Seesaw/blob/master/examples/encoder/encoder_basic/encoder_basic.ino#L36
TIL I have an old white macbook running 10.6.4
@onyx hinge Ok tested the changes. I'll put in a PR now.
hmm didn't we decide examples shouldn't use f""-strings? print(f"Position: {position}")
Oh. Yes we did.
(not that you introduced this with your change @idle owl )
do you mind?
Nope.
I didn't notice it either until I was reviewing. yay, the process works
Should be this, right? print("Position: {}".format(position))
I mean it works
but I want to verify anyway
@ionic elk I am trying to using a J-Link with the Feather 405. Should I expect it to work? The J-Link says it can't connect. I am using the SWDIO and SWCLK pads on the bottom (not the box connector), and have RST and GND and Vin connected
I can try the ST-LINK also. I have an ST-LINK Mini
I think that style works everywhere @idle owl
@tulip sleet the Jlink should work with the FeatherF405, yeah - I actually find the F405 is more reliable about staying connected and cooperating with it than any of the other chips I've used...
tnx, I will keep working on this, then, maybe just a wiring error
JLinkGDBServer -if SWD -device STM32F405RG is the command I use. It needs the power plugged in with USB.
I am using the same args, so hmm
STLink is fine too but I always have to catch myself up on openocd
@tulip sleet I additionally have -speed 4000 in my commandline but it could be suspicion
J-Link is connected.
Firmware: J-Link V10 compiled Apr 27 2021 16:35:48
Hardware: V10.10
S/N: 50104963
Feature(s): GDB
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...
ERROR: Could not connect to target.
Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...
Shutting down...
Could not connect to target.
Yeah I feel like that might be a wiring error. I only use the box connector so I don't know how reliable the pads are
tnx, trying a few things, no success yet
I may go ahead and solder the box connector, but my success rate is only about 70% the first time
meaning it's tricky to solder on the pads? I think I might have used a heat gun
yeah, I don't have one yet
Sorry! I personally asked about this before, but old habits die hard.
i use flux and check the continuity carefully
Ping me directly if needed. Attending the Education Summit until 4pET.
@onyx hinge Did you see my comment on the PR? It isn't working for me. Am I missing something?
@idle owl argh
I pulled it down locally and the example is failing.
I don't see get_product() or whatever it was in seesaw.py
yeah I messed it with some search & replace
Ok
@idle owl updated
Testing
you're awesome, I appreciate it
There it is!
I do. I just replied on the thread, and can hopefully help out.
@onyx hinge Merged. Do you want to do another release?
@idle owl it would be a very good idea, before people start writing code to the current module!
I meant will you please do the release 😄
Cheers!
Now I can document it as well.
That rotary encoder snapped onto the breakout so tightly, I didn't even bother to solder it. Works fine. Wouldn't recommend that to other folks, but it worked this time.
Is anyone successfully running pyenv-virtualenvwrapper alongside pyenv? I'm getting all kinds of errors that aren't covered in the setup
I had virtualenvwrapper installed already, so I'm worried that's messing it up
@ionic elk My partner might know, but she's in a meeting at the moment. I can ask when she's free.
I'd rather not just use pyenv virtualenv if I can help it, I like the simplicity of workon
@idle owl ty!
@ionic elk I have all three installed. But she'll be the one who knows how I'm using them. She is the one who helped me set it up. So I'll let you know what I find out.
Anyone have one of these STEMMA rotary encoders and a Raspberry Pi set up?
@idle owl I think I figured it out, I needed to install more packages on the local pyenv I was using, and the errors were making that seem more complicated than it was
Ah nice!
thanks for checking though!
No worries!
@idle owl by the way, do you know if pyenv global persists past a restart? Or do I need to add it to my bash profile?
@ionic elk I don't have anything that says global in my bash profile. But I don't know for sure. Again, Rose would know. But she's still in a meeting 😄
That's fine, if your bash doesn't have global it probably stays persistent. It carries into new shell sessions. Just figured I'd check if you happened to know.
thanks for cluing me into pyenv in the first place, it's going to save me a lot of headache
@fossil gorge cool. thanks!
little bit of initial setup but a lot of long term payoff
Great! Glad I could help. That's the feeling I got, so that's why I shared.
I woulda been doing all those hacky shell scripts around brew like your article mentioned
Yeah 😕
lol 😆 🤮
@ionic elk She said pyenv global is persistent.
Fixes #4746.
- Endpoint count checking was off by one.
CIRCUITPY_USB_{HID,MIDI,MSC}_ENABLED_DEFAULTdefault values were not set conditionally.- Clean up
print_safe_mode_message()to simplify logic, reduce size, and divide up safe-mode reasons more accuractly. - Redo logic of printing startup messages in
run_code_py()to not print safe-mode message twice, clean up newlines, and be more consistent about whitespace. - Shortened and rephrased some messages slightly.
It appears ...
@tulip sleet fyi, thought this might be of interest re what i have done to start to get tasko running CP on nRF. https://github.com/WarriorOfWire/tasko/issues/2
I didn't test it on a Raspberry Pi, but I did test it with Adafruit_Blinka and the u2if for the Pi Pico
I'll take it!
I think we could patch builds instead of rebuilding to do this. (Have a variable to check for safe mode and use the map file to know where it is in the binary and then change it.) It'd still double the number of artifacts but not the build time.
I like this idea - if it works, it achieves all the objectives in this thread, without the CI drawback.
@v923z may be interested in this.
@still zephyr I mentioned in our internal meeting that you're going to be looking into the PRs, and we're on board. I'll do what I can to provide you the support you need, and once you've sorted out what you need, we'll get you hardware.
Thanks Kattni 🙂
Thank you so much for offering to do this! It really needs to be done but it keeps getting bumped by other things.
No problem glad to help.
that's what I missed I think. should work going forwards
I think the seesaw library was done by the same person who did the arduino one
LGTM modulo the run-tests vs run-tests.py
Assuming it passes CI and there was nothing new besides the run-tests.py change, LGTM
Sorry for the delay in reviewing this.
frozen/Adafruit_CircuitPython_HID and Adafruit_CircuitPython_SimpleMath should not be changing. They are probably behind the current versions. You might want to merge from upstream and then recheck these. You may need to pull them ahead by hand; make them match what is in main.
Do a make translate after you merge from upstream as well.
Thanks for all the commenting.
I did not test this on hardware, but I know you've done that extensivel...
Safer to put in parens due to possible operator precedence issues.
#define STM_ALARM_FLAG (RTC->BKP0R)
You could make these part of a typedef enum and then change its type where they're used.
It did not fix #4746 in my tests, both cases with issues now do a reset loop.
sorry didn't have notifications turned on, but do now. will try and keep up with this channel 🙂
Really looking forward to CirPy 7.0!
It did not fix #4746 in my tests, both cases with issues now do a reset loop.
Thanks, because of debugging issues I was testing with an STM board, but will try with an ESP32-S2.
Looks OK, no testing performed.
@Neradoc It turns out the ESP32-S2 endpoint situation is idiosyncratic. From the datasheet:
- Endpoint number 0 always present (bi-directional, consisting of EP0 IN and EP0 OUT)
- Six additional endpoints (endpoint numbers 1 to 6), configurable as IN or OUT
- Maximum of five IN endpoints concurrently active at any time (including EP0 IN)
All the other chips have symmetric pairs of IN/OUT endpoints, but the ESP32-S2 does not. I am confused why we can support HID at all, because t...
Note edit in previous comment.
This covers the 16mb and 4mb versions of the PicoLipo board. The former should be launching this week, so if we would get this merged soon, that would be greatly appreciated!
@tulip sleet How far out are we from a 6.2.x or 6.3.0, and/or a 7.0.0alpha release now that uPy is merged?
There's a lot of guide stuff that is tenuously relying on things only in main, and that's not great. 😄
I am trying to fix a particular dynamic USB bug, but it's not a showstopper. I could make an alpha. There are many problems, but we can get to them. @slender iron how do you feel about doing an alpha release.
what do we really need in 6.x? New boards?
Alphas are supposed to be buggy.
frozen/Adafruit_CircuitPython_HIDandAdafruit_CircuitPython_SimpleMathshould not be changing. They are probably behind the current versions. You might want to merge from upstream and then recheck these.
Yes, the eternal "I forgot to update submodules after merging" problem, that I will never not forget to do. I should figure out how to tack on a shell script or something to auto-run it or post a warning or something after a git merge
New boards and updated pin definitions.
I don't know that much else needs to go into a 6.x release.
do you have a preference for 6.3 vs 7.0.0?
@tulip sleet ty for review!
6.3 is safer
If 7 stable was around the corner, I'd say no worries on a 6.x version, but it's not. So yeah.
Thanks for submitting. Could you please resize the photos according to this guide: https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/preparing-the-images? Otherwise it looks good.
We need a stable that is a little more up to date, in my opinion.
But in the end it's up to you.
I will discuss timing with Scott. maybe do a 6.3.0 early next week. I could do a 6.3.0-rc.0 sooner, maybe, but not sure it's necessary.
I don't think an RC is necessary.
I think another stable release would be fine.
But yeah, discuss.
we are trying to avoid doing stable releases toward the end of the week so we don't have support probs over the weekend.
That's fair. I wasn't thinking about what day it is. Another few days isn't going to make or break anything on my end.
@tulip sleet I'm open to a 6.3 and a 7 alpha
dynamic USB has some bugs but so do a lot of other things
I will do some backporting of new boards, etc. and see how fast I can do it.
for 6.3.0
Thank you!
alphas have bugs too 🙂 thanks!
yay the testsuite parallelization change was taken by micropython
nice!
well, it was approved but is not merged yet. close enough
Changes look good! Thanks - we'll merge now and you can then proceed on the API cleanup, etc.
@jaunty juniper if you go ahead and push the Sierra support to https://github.com/adafruit/Adafruit_Board_Toolkit/pull/4, i will merge it and make a release so it can easily be tested on M1 by pip3 install .... Except for Mu beta, there are no downstream users of this, and it works at least as well as the previous release. We just need to re-confirm it works on M1 before I push a new version requirement to Mu. Thanks!
oh, you did, never mind! I was looking at an old list of commits.
😉 👍
Hi. Could you elaborate? We've prepared pictures exactly as described on the github page, and ran them through the recommended webpage to compress them.
Provide 3 images. An original high-quality image. A smaller image (300 px width), and a larger image (700 px width) in each respective directory (assets/images/boards/{small large original}) and process them in something like https://squoosh.app/ to reduce file size. If you only have one image, place it in the 'original' folder.
This ...
This works well enough to do a framebuffer demo but only with specific pins, and it tends to crash after a soft reset.
Looks like today's 7.x bundle has the right magic number in it, so using it with main branch builds should be working!
HEllo @idle owl are you avalaible?
For a few minutes. Then I'm unavailable for 2 hours. What's up?
Nothing I will sent you a link, I do not think we need anything just letting you know 🙂
Ok!
There is another USB PHY on the chip, a HS-capable one with more endpoints, but it is not connected to anything. It is not connected on the PyBoard either. I'm not sure why, but I think there was some reason.
Most of the STM chips have HS peripherals but no HS PHY. They require a separate UTMI chip for the HS PHY. That's why they aren't used very often.
Oh yeah, fair enough. I just checked the other images (same dimensions) and they look fine. Maybe the image sizing is a bit more resilient than I thought. :)
@Neradoc would you mind posting an example of handling an exception in CPython that we could make work in CircuitPython? (I've never done it in CPython.) Thanks!
Looks fine to me. It might be good to try an update the translations so that the ones aren't lost about button presses.
Thanks @makermelissa! I'm curious now what the issue was that made you flag this. That guide does mention different dimensions to what this repo says, so perhaps ones needs to be updated?
There actually don't seem to be that many changes in the core language syntax. 7.0 will have expression-assignment ((x := f())), variable type annotations (x:int = 1), and matrix multiplication operator (A = L @ U). That's about all I saw reading through the top blurbs of the related micropython releases..
it'd be nice to have variable type annotations for use in libraries, but we'd only start using it when we no longer make 6.x bundles. Well, the same for any of these features really.
@kevinjwalters
That would be inappropriate as the slice is a view onto that data as I understand it.
This is correct, but perhaps the first question is, whether this has anything to do with ulab, and convolve. I believe, especially, if this is a problem with the garbage collection, we should strip this to the most trivial example that produces such behaviour. Something like this:
import math
_data = [1.0] * 10000
data = _data[6:-6]
sum(data)
a = []
for idx i...
First part:
Adafruit CircuitPython 6.2.0 on 2021-04-05; Adafruit CLUE nRF52840 Express with nRF52840
>>>
>>> import math
>>> _data = [1.0] * 10000
>>> data = _data[6:-6]
>>> sum(data)
9988.0
>>> a = []
>>> for idx in range(1_000_000):
... a.append("AYMABTU")
...
...
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
MemoryError: memory allocation failed, allocating 131072 bytes
>>> del a
>>> sum(data)
9988.0
Although perhaps this...
@still zephyr Ok, so with your list. Where it says "ok" you need the hardware to test it? Am I reading that properly?
No, No need I already have it or it does not need
It will be the YES
Ah, ok. So very few!
Meaning the MCP and servos as I do not have any of that
Ok yeah I see that now.
yes, very few, for the moment, there are some that it will depends on the development on path of the PR
I have a lot of sensors, including the three that you made 🙂
😊 That's excellent though.
Thank you for waiting on the LED Animation PRs by the way. I'm thinking of creating a new Advanced_Animations or Community_Animations library because it's already too big for some boards.
Agrre let me know if you need help
A couple the outstanding ones are mine so if they get moved about just let me know I can help
Yes! That is where I would start with it. I'll let you know when I get a chance to do it.
Then you can PR your animations to it. They'll need to require the main lib instead of direct inheritance, or whatever the terminology is.
I can do a similar list for the issue if you like,
Are there specific issues you're interested in doing but don't have the hardware for?
Not really, I do not like displays nor leds 🙂 so we don have a lot, but there are some sensors in there
Ok, then don't worry about putting together a list unless you specifically want to get something to work on an issue 🙂
Will do thanks
have you tested this? It'd be great if we could ignore them
@still zephyr When you're confident that you have a list of all the hardware needed to work on PRs that you're interested in testing, please let me know and I'll get you set up with an order. I want to try to consolidate as much as possible to one order, so if there's something you think you might need, and it's reasonable, please include it in the list.
Yes. for the moment I think we do not need anything, but I will as you proposed if the times comes
Ok that works.
thanks
new fancy warning: ```
../../devices/ble_hci/common-hal/_bleio/Adapter.c: In function 'bleio_adapter_gc_collect':
../../devices/ble_hci/common-hal/_bleio/Adapter.c:917:75: error: expression does not compute the number of elements in this array; element type is 'bleio_connection_internal_t', not 'size_t' {aka 'unsigned int'} [-Werror=sizeof-array-div]
917 | gc_collect_root((void **)bleio_connections, sizeof(bleio_connections) / sizeof(size_t));
(with gcc 11.1)
Many cherry picks from main to add new boards, correct pin errors, and fix a few useful bugs.
Artisense RD00 board #4512. Thanks @m-byte.
Correct pins for UM TinyS2. #4534. Thanks @UnexpectedMaker.
HunterCat NFC board. #4545. Thanks @sabas1080
BDMicro VINA-D51 updates. #4561. Thanks @bd34n.
QT Py RP2040 D3 pin correction. #4581. Thanks @dhalbert.
STM32F4 Black Pill add flash chip. #4582. Thanks @kevinlutzer.
Remove robots.txt from ReadTheDocs. #4584. Thanks @hdalbert.
Adafruit NeoKe...
@onyx hinge Jeff, if I patch up the code now, would it still make it into 6.3?
@lapis hemlock Probably. 6.3 will be using legacy branch, 7 is using your master branch. Please let @tulip sleet know if you have updates that should go in.
i did not merge any ulab fixes into 6.3
I'll be around discord much less starting on sunday
@tulip sleet the fix isn't written yet, I don't think
This is about #4753, in case you're missing context
Oh, it's recommended to have the images at a 13:10 ratio (like the other images on the site), but yours are 4:3. It looks fine either way.
6.x is still legacy ulab, right?
6.3 is primarily just new boards and pin fixes for old boards
@tulip sleet I think so. But the question is, whether you want to include the fix for https://github.com/adafruit/circuitpython/issues/4753.
i only included some very small code fixes
@lapis hemlock thank you for jumping right in on this
@tulip sleet you get to make the call about whether it's an impactful enough bug that you want a fix for 6.3
there are numerous other (non ulab) bugs in 6.3; i would encourage people to move to 7.0.0 if they want to use ulab due to the API changes
whether it ends up in 7.0 only, thank you @lapis hemlock for jumping right in to work on it!
@balmy plover Not at all!
in other words I don't think you need to fix it on the legacy branch
it's a serious bug, but it affects only a certain class of user
@tulip sleet OK, then I will just work on master.
Want to put in the run reason fix? #4708
@lapis hemlock I only glanced at your proposed fix, and I think it is just about as right as you can make it. There may still be problems interacting with memoryview() but I don't know that you can fix them purely in ulab. that's the related issue https://github.com/micropython/micropython/issues/7261
I have the feeling that a change in the core is needed, such as adding an "origin pointer" (to use your terminology) within the mp_buffer_info_t structure
@balmy plover Thanks for following up on this. https://github.com/v923z/micropython-ulab/pull/388 fixes the first issue, but the one with the memoryview still stays.
On standard Python 3.7,
>>> hex(memoryview(b'\1\2\3\4\5\6\7\8')[2:6].cast('i')[0])
'0x6050403'
while on circuitpython,
Adafruit CircuitPython 6.2.0-rc.0-47-gd6c924449-dirty on 2021-04-03; Adafruit CLUE nRF52840 Express with nRF52840
hex(memoryview(b'\1\2\3\4\5\6\7\8')[2:6].cast('i')[0])
'0x4030201'
@onyx hinge You have just opened a nasty can of worms, I think. 🪱
the .cast() one is my fault, micropython doesn't have cast().
don't go looking for trouble, you'll find it
ah note to self, the examples need to be listed in the docs .. https://github.com/adafruit/Adafruit_CircuitPython_seesaw/pull/66/files
@onyx hinge what does hex(memoryview(b'\1\2\3\4\5\6\7\8')[2:6].cast('i')[0]) mean -- trying to understand what it should be.
not enough 😉 -- I'll do some reading , but it sure is not intuitive.
>>> b[2:6]
b'\x03\x04\x05\x06'
``` Slicing the bytes object works like so
>>> hex(val)
'0x6050403'
``` If you turn those 4 bytes back into an integer they are the number 0x6050403
ah -- got it -- now I see - I was confused because [2] had to be 0x03 -- now it makes sense -- Thanks!
memoryview & cast are another way to do the same "switching" between viewing the data as bytes and viewing it as a 32-bit integer
and yeah there's the whole "little vs big endian" thing that can get in the way of understanding
it is a bit "dense", what I wrote.
So am I , at times 😉
nobody's saying that but you 🙂
Thanks for explaining it. I'll be able to sleep tonight...
I'd request #4691 to be in too, if possible.
this is good to know
@tulip sleet , @onyx hinge https://github.com/v923z/micropython-ulab/releases/tag/1.7.8 contains the fix, in case you want to include this in 6.3.
@lapis hemlock 1.78 is a little behind the test fixes; should I advance to the tip of legacy?
or are those fixes irrelevant to circuitpython?
@tulip sleet Sorry, I messed up one of the test files, and that is why the tests fell through. I have updated the release tag, it should be good to go.
thanks!
@kevinjwalters Thanks for bringing up the issue; it has been fixed in https://github.com/v923z/micropython-ulab/pull/388, and the fix backported to the legacy branch: https://github.com/v923z/micropython-ulab/releases/tag/1.7.8.
@jepler Thanks for digging to the root of the problem!
@onyx hinge do you have time to do a PR to main for the ulab fix for #4753?
anyone ever seen tar ext :2331 in gdb just chew up memory and never complete?
GCC has an annotation for marking a function as malloc-like: https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Common-Function-Attributes.html#index-malloc-function-attribute We should mark gc_alloc with it.
You also give it a deallocator. In MP we have gc_free and gc_sweep. We'd need to call free from sweep for this to work I think.
Looks fine to me. It might be good to try an update the translations so that the ones aren't lost about button presses.
@onyx hinge You said something about ESP32-S2 debug build being too big, but now I cannot find that. I just encountered this (actually saw the issue in the debug UART log). DId you just turn off one or more big modules?
I will just turn off ulab, I guess
i searched for what you posted, but could not find it 🤷 ; it must be there somewhere 🙂 thanks
Tested using CircuitPython 6.2.0 on the FunHouse.
test = {"a": "A", "b": "B", "c": "C"}
>>> test
{'c': 'C', 'a': 'A', 'b': 'B'}
Here it is in CPython:
>>> test = {"a": "A", "b": "B", "c": "C"}
>>> test
{'a': 'A', 'b': 'B', 'c': 'C'}
The CPython result is what I would expect for both.
Remove robots.txt from ReadTheDocs. #4584. Thanks @\hdalbert
I think that was a typo, as @\hdalbert appears to have nothing to do with CP!
Remove robots.txt from ReadTheDocs. #4584. Thanks @\hdalbert
I think that was a typo, as @\hdalbert appears to have nothing to do with CP!
Sometimes I have trouble typing my own name :slightly_smiling_face:
@tannewt anything you want to add to this?
Is it a bug or an enhancement ?
Dict order was not guaranteed until python 3.6 and Micropython was based on 3.4 I believe.
You would do something like that (if you use the dict notation you'll lose the order).
from collection import OrderedDict
OrderedDict([("a","A"),("b","B"),("c","C")])
It's not in MicroPython (yet or ever): https://github.com/micropython/micropython/issues/6170
Got AdaBox? ✅
Added:
- Count in and out endpoints and check against provided limits. ESP32-S2 allows only 5 IN endpoints, so this enforces that limit.
- Turn on MIDI and HID on some low-endpoint boards, but have them disabled. The user could disable something else (like the REPL) to add them.
- Add more information to documentation.
make translate seems to have fixed up some of the messages that would otherwise have been lost due to rewriting. I will check after merging and address missing ones fr...
Sorry I'd stopped juggling this since we'd resigned to including pull-up resistors on Keybow 2040 for i2c, but I believe it will still be required.
We'll be shipping some Breakout Garden products which - unlike Pico Explorer - do not include onboard pull-up resistors (or, indeed, any components other than headers) which might rely on this change.
Our in-house breakouts should be fine since they include onboard pull-up resistors, but since we've shipped Qw/St adapters there may be cases ...
@dhalbert thanks, calling usb_cdc.disable() in boot.py makes usb_hid work.
The cherry on top would be access to the REPL via the dedicated serial pins, is there any way to do that?
so, with MICROPY_EPOCH_IS_1970 set to 0, there's a few codes that need to be changed to set the date and time based on external timestamps (like NTP servers)
you'll have to subtract 946684800 (2000-1970 in seconds) from the matching unix timestamp
that's not C pythony though
well actually it is defined to be platform dependent
Provide support for accessing the REPL over UART. There are some compile switches for this, but I don't know how complete it is on the inside. There was support long ago because of the ESP8266. The BLE-only workflow would use a similar internal path.
One request: https://github.com/adafruit/circuitpython/issues/4752#issuecomment-841111515
Related to #721.
When the Epoch is set to 2000 instead of 1970 (MICROPY_EPOCH_IS_1970 set to 0), rejecting values lower than TIMEUTILS_SECONDS_1970_TO_2000in time.localtime() results in rejecting dates before 2030.
Should a conversion routine maybe be added to lib/timeutils that does this check, to isolate epoch checking in one place? I don't think lib/timeutils should necessarily throw an exception, but it could return success/failure on the conversion.
Oh, ok. I guess this is an enhancement then.
This detects an overflowed flash partition, such as
1452105 bytes used, -10313 bytes free in flash firmware space out of 1441792 bytes (1408.0kB).
444428 bytes used, 1652724 bytes free in ram for stack and heap out of 2097152 bytes (2048.0kB).
on a metro esp32-s2 built with debugging.
Looks like this is wrong for non-PSRAM builds, at least that's my first guess. I'll take a look locally, soon
Our in-house breakouts should be fine since they include onboard pull-up resistors, but since we've shipped Qw/St adapters there may be cases where our pullupless boards might be combined with pullupless sensors and I'd like to have an answer when that inevitably happens.
Adafruit also puts pull ups on the breakouts. It comes up occasionally but most folks can handle adding pull ups themselves or getting a better breakout. I wouldn't worry about it. Though, if you do want to add it, we'd...
Yup, I may rethink this with the BLE work. It may involve giving UARTs a lifetime similar to displays.
There is collections.OrderedDict but its look ups are linear and therefore slower.
These changes clairfy the flow nicely - thanks! I did not test but you did. The build failures are due to GitHub cache failures. You could merge from upstream and re-run, because the cache key has already been changed.
@tannewt anything you want to add to this?
Not that I can think of. I don't really remember anything prior to the merge. :-)
@dhalbert
Many cherry picks from main to add new boards, correct pin errors, and fix a few useful bugs.
Out of curiosity, what is a useful bug?
Rotaryio Trinkey pins were from an older rev board.
Tested with a mounted encoder. .position increases clockwise with IncrementalEncoder(board.ROTA, board.ROTB), as expected. Also tested board.SWITCH and board.TOUCH.
Needs cherry-pick from #4765.
I wanted to build a port of CircuitPython port for Zephyr RTOS like this https://github.com/micropython/micropython/tree/master/ports/zephyr. I assume it is written in C. Can someone please guide me with writing it. It will be beneficial for the community as it would be possible to be used with Zephyr RTOS like MicroPython.
We have looked into this and spoken to folks at Zephyr about it. But there are some fundamental issues about dynamic pin allocation which are a stumbling block. See https://github.com/zephyrproject-rtos/zephyr/issues/11918
are pin alarms on MagTag/CP6.2 still limited to 2 total LOW ones?
Is github down?
loads for me
hmm
are you getting the unicorn or something else?
They have been working on the pinctl API
ping works ... must be time to give up for the day...
I Think so. It’s a hardware thing.
thanks. that's what i remember. just been a while.
so no way to deep sleep, wake on any of the 4 buttons and then determine which one?
I could be misremembering but I thought you could tell which pin triggered it, but only at most monitor a couple pins
right. max 2. at least that's what i ran into last time.
was hoping maybe some worked some magic to get around the hardware limit 🙂
It seems that there was a copy-paste from another board that was not updated.
Hi, I'm having this same error with this fuel gauge. I'm not a developer so I can't quite tackle this, but I have the Feather nRF52840 Express and this fuel gauge. I'n getting this same error:
Traceback (most recent call last):
File "code.py", line 454, in <module>
File "adafruit_lc709203f.py", line 122, in cell_percent
File "adafruit_lc709203f.py", line 188, in _read_word
RuntimeError: CRC failure on reading word
when I try and use this sensor with the code:
im...
I'd be in favour of adding this.
It's confusing moving from the Pimoroni Micropython firmware which doesn't need resistors to CircuitPython which does. I'm using the Pimoroni Scroll Pack which just plugs into the RP2040 Pico. Bodging two resistors when switching to CircuitPython feels kludgy.
@Gadgetoid Was this added by Pimoroni to their firmware or is it part of Micropython?
Adafruit Rotary Trinkey. #4594. Thanks @ladyada. from above... Rotary Trinkey is #4449, but it looks like that should be in 6.2.0 except that downloading it from circuitpython.org gets a NoSuchKey XML error.
It's not fixed, I have both error cases above do a reset loop on latest on ESP32-S2.
I tested on the ESP32-S2 with your examples and did not get a reset loop, hmm.
@anecdata This will add the missing boards to 6.3.0. I'm not sure why they are listed in the boards file for 6.2.0; that is an error, obviously.
Oh it works when I erase_flash and install with the Circuitpython bin, but not if I install the UF2 bootloader first.
I only tested with the .bin. I just re-tested and it goes into safe mode with USB devices need more endpoints than are available. as I expected with a boot.py:
import usb_cdc
usb_cdc.enable(console=True, data=True)
If boot.py is empty and you use the UF2 version does it work?
Could you compare the initial prompt with the version number between the .bin. and the .uf2 version to make sure they are the same build? Thanks.
There isn't anything in my USB impl that should c...
I tried with the artifacts, with the the latest S3, I fixed my toolchain to be able to build locally, same result every time. I tried the bin from the same local build, goes to safe mode. Empty boot.py, no boot.py, or the boot.py listed above to work do work as expected.
TinyUF2 uses USB, could it leave it a state where there's some endpoints cleanup needed ?
it should do a rather thorough reset after tinyuf2 starts and then starts Cpy
i'm testing with uf2 now
it re-enumerates so it should not be a problem, but...
Will CP7 support usb-midi on esp32-s2?
yes!
sweet!
but you will need to turn off HID or REPL to make room in terms of USB endpoints
it's a tradeoff in terms of endpoints
A trade I'm willing to make.
tell me if you can repro, I tested right now with the latest tinyUF2 release
@microDev1 do you use the UF2 bootloader ? It seems to be what makes the difference.
I get the same result as you when I rease_flash and install Circuitpython from the bin.
@jaunty juniperI did see the reset loop with the UF2. But I think this is a safe mode issue with tinyuf2. I remove boot.py, loaded the uf2 version, and then did this in the REPL:
>>> import microcontroller
>>> microcontroller.on_next_reset(microcontroller.RunMode.SAFE_MODE)
>>> microcontroller.reset()
That crashed my Linux box 🙂 😦
but the board did reset, and when I was able to connect again (it did not re-reset), it was NOT in safe mode. So that would explain the reset loop. It is not going into safe mode successfully with the UF2 version
it just keeps running boot.py over and over, which causes the reset loop
this safe mode issue sounds familiar, maybe there is already an issue for it
ah
welll, the opposite: https://github.com/adafruit/circuitpython/issues/3988
in any case, needs to be investigated. I will write an issue
i never use the UF2 because it's too easy to mess up and then you need esptool anyway
yeah I remembered that, I thought it might be the difference 😉
i will try that again to verify and hopefully I will not crash Linux again
verified, it did not go into safe mode
and fortunately it did not crash this time. Linux has some kind of problem about not liking the CDC connection being terminated abruptly
yep I can confirm it doesn't go to safe mode
It seems to be what makes the difference.
Yup! I get WATCHDOG with UF2 and the expected SOFTWARE with non-UF2 build.
7.0.0 latest, with TinyUF2 in use only.
ESP32-S2 does not go into safe mode when requested to do so on a reset.
>>> import microcontroller
>>> microcontroller.on_next_reset(microcontroller.RunMode.SAFE_MODE)
>>> microcontroller.reset()
On reconnect, CircuitPython does not report it's in safe mode.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython...
Led does not turn on
was tested on
Adafruit CircuitPython 7.0.0-alpha.2-573-g49bad0797 on 2021-05-14; Adafruit Feather M4 CAN with same51j19a
Neopixel only turns green on bootoader mode.
See #4766 for problem diagnosis.
Just a message for an admin the meeting notes for next Monday meeting pinned are not the correct ones
This is ready for re-review. The single build failure was a GitHub Actions problem.
Fixed by #4689 and previous PR's.
Saw this string for translation; The 'microcontroller' module was used to boot into safe mode. Press reset to exit safe mode..
This would be a problem for people using the RPi Pico, as it does not have a reset button?
I updated the pinned message, thanks
I thought about this, and propose adding a simple new native-C module interval. Its implementation will be very small so it can fit on the smallest boards, which don't have longints. Because it only uses short ints and is not a class, it generates no garbage, and is fast. Pseudo-code is below:
"""Time intervals < 2**30 milliseconds (about 298 hours)."""
MAX_MS = 2**30 - 1
"""Maximum available interval: about 298 hours."""
def now_ms() -> int:
"""Return th...
@dhalbert I think that's fine, it has a slightly smaller "surface" than mine but is a bit "more different" from the micropython implementation.
To allow implementing micropython's ticks_diff and ticks_add with a minimum of fuss, consider making the wrap occur 229 rather than 230 (and do put the wrap value in the public API):
the TICKS_PERIOD of 2**29 is chosen to simplify the backwards-compatibility implementation of ticks_add and ticks_diff on platforms without long ints; we can ...
I worked interval out from scratch while not being able to sleep, without reference to the MicroPython utime routines. The first thing I thought of was has_elapsed_ms(), and added diff_ms() later. I didn't realize how close it was to utime. My diff_ms() does not return negative values (it always assumes there might be a wrap) and does not depend on utimes TIME_PERIOD/2 constraint. I think that it is a little less confusing.
When documenting class parameters. In some cases the documented parameter could have two different types.
This include reference in the design guide in how to achieve this.
For reference see this two pull requests:
It is enabled by defaul heret, so it doesn't need to be listed explicitly. Same for MIDI:
https://github.com/adafruit/circuitpython/blob/25a44cb77ff53ade15fdfac09e74d59b4b4b375e/py/circuitpy_mpconfig.mk#L334
And it is not turned off for small SAMD21 builds:
https://github.com/adafruit/circuitpython/blob/25a44cb77ff53ade15fdfac09e74d59b4b4b375e/ports/atmel-samd/mpconfigport.mk#L31-L61
I wrote interval up without fully re-reading the original comments -- sorry. I'd be OK with adding some kind of add function too, and including the possibility of negative diff. But I do like the idea of putting this in its own module. Adding a done or has_elapsed function is also convenient. The main thing is that it should be quite small, so it still fits on low-flash-size boards.
I haven't used it in C Python, my concern is how to implement code like that (6.2.0).
import adafruit_logging as logging
import io
import sys
logger = logging.getLogger(__name__)
try:
do_some_stuff()
except NameError as ex:
# just print exception without raising (debugging)
sys.print_exception(ex)
# log exception with a logger (stdout or file)
with io.StringIO() as sio:
sys.print_exception(ex, sio)
logger.error(sio.getvalue())
...
Current modules list from https://circuitpython.readthedocs.io/en/latest/shared-bindings/support_matrix.html (built after this PR merged)


Is there a way to create an operation similar to findall using the re module? My re experience isn't great, I could do something to whittle down my string with each match but maybe there's a better way?
well, I guess cutting the string isn't so bad, actually, pretty concise.
standard python lets you specify a start position for the match and search methods of regular expression objects: ```python
re.compile("x.").match("xaxbxc", 2).group(0)
'xb' # standard python3
this is optional in CP/MP but looks like we enable it whenever we enable re. (except not in the "unix" build which is what I initially tested)
@onyx hinge ok, so instead of cutting the string, I'd just change the match start? That'd work too
Hi everyone I'm trying to port the SAML21, but I can't find the saml21_cpu.s, where is it obtained from?
https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/supervisor/samd21_cpu.s
@steel granite the asf4 submodule has files from microchip. one step of adding saml21 would be obtaining the files and adding them to a fork of https://github.com/adafruit/asf4.git
as far as I know you have to go through some process on a microchip website to get the files, it's a bit of a pain and done so seldom it's not documented
er no, I'm giving inaccurate info
I bet the content of samd21_cpu.s would work just fine as saml21_cpu.s
samd51/e51/e54 are all identical for example
haaa ok, I have the next error
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = ${RAM_SIZE} (in boards/common.template.ld) I suspect RAM_SIZE (defined in mpconfigport.h) may be wrong or not defined
#define RAM_SIZE HMCRAMC0_SIZE
``` if you copied this block, make sure it's the right define for saml
if I change it to #define RAM_SIZE THIS_IS_WRONG that's the error I see
I'm going to check
you can also look at the content of the file build-$BOARD/common.ld to see what it is expanding to, it should be a number (possibly a hex number)
ok, i have my error SAML21 is HSRAM_SIZE and SAMD21 is HMCRAMC0_SIZE
I have changed it
now I have an error on the convert uf2, saml21 is in the families 🤔
I get that error if I provide a 0-byte input .bin file for uf2conv
maybe an earlier problem has caused your .bin file to be empty
note how it says "0 bytes used" in flash firmware. Some problem has caused your output to be empty.
I'm going to check, thanks @onyx hinge 
I'm sure you'll trace it back to the cause
It seems to me that a "DEBUG=1" build of clue doesn't boot.
I'm confident it used to work but not exactly when
Adafruit CircuitPython 7.0.0-alpha.2-584-g25a44cb77-dirty on 2021-05-15; Adafruit CLUE nRF52840 Express with nRF52840
>>> import features0
>>> features0.factorial(16)
2004189184
``` however, once I turn off DEBUG (and turn on CIRCUITPY_ENABLE_MPY_NATIVE) the "features0" natmod example works. nice!
(the factorial number itself is "wrong" because the calculation is done in 32 bit integers, ignore that for now)
I built at 7.0.0-alpha.2-584-g25a44cb77 with DEBUG=1, and got a red light and no CIRCUITPY drive. With DEBUG=0 or the binary from s3, it works. This makes me think that DEBUG=1 is broken at least for clue and possible for other nRF52s.
and by the way enabling this is +24kB flash used, so it really doesn't pave the way to "unbundling" core code on flash-constrained samd21 builds
Works like a charm: https://hackaday.io/project/179496-chocolad-keyboard-hacking/log/192866-dynamic-usb-descriptors
Based on the above, I have been trying to improve my mouse jiggler to make the presence of CircuitPython stealth.
But I fail with two error: https://gist.github.com/dglaude/aad3d9e19858b062306b2a514434fd6b
No sure exactly what I did wrong (more than one thing likely)... I tried my best to upgrade my CPX to the latest CP, upgrade all the mpy and run this code as code.py....
From my understanding, that slide position check and the disabling of USB descriptors needs to be in boot.py after you re-plug the board in.
I could not find the cause my .bin file is zero, any way i can go?
@steel granite normally the linker is told it must include all symbols in the special section called ".vectors", and every other function which is required (such as main()) is found, directly or indirectly, from those functions. I would guess that ".vectors" does not have right contents (any contents) for some reason.
boards/common.template.ld: KEEP(*(.vectors)) /* isr vector table */
For samd21, this is the startup_samd21.c file in the asf4 files for samd21: ```c
samd21/gcc/gcc/startup_samd21.c:attribute((section(".vectors"), used)) const DeviceVectors exception_table = {
so I'd make sure `startup_saml21.c` is included in the list of source files and has the appropriate content.
```make
Makefile: gcc/gcc/startup_$(CHIP_FAMILY).c
yes, i have added chip_family saml21 and startup file https://github.com/ElectronicCats/circuitpython/blob/addSAML21/ports/atmel-samd/Makefile#L95
ok, I have uf2 file thanks @onyx hinge
Greetings!
Short background:
I've spent a fair amount of time attempting to understand how my Raspberry Pi Pico works.... I've barely scratched the surface. Thus far I've been able to get some "neopixels" running some basic algorithms, such as a walk from (x1,y1,z1) to (x2,y2,z2) these can be pre-determined coordinates or randomly generated to create really fun color effects. One of my implementations uses a typical Raspberry Pi running a python daemon consuming Firebase events and updati...
From my understanding, that slide position check and the disabling of USB descriptors needs to be in
boot.pyafter you re-plug the board in.
So indeed boot.py is needed, and I was confused because the output of boot.py are in boot_out.txt.
It is very hard to troubleshoot and understand what is happening... but I also need to convince Windows 10 that the filesystem is clean. Any ejection when CIRCUITPY is visible make this trick stop to work for me and the drive keep reappering. ...
That code looks correct. You should be able to get a clean unmount in Windows by doing an "Eject" from the USB icon in the taskbar. But that should not affect whether this code runs.
boot.py only runs after a hard reset (power-cycle, reset button press, or similar). It does not run after auto-reload due to editing code.py or another file, or if you type ctrl-D in the REPL.
This missive is interesting: https://www.devever.net/~hl/usbnkro.
The 6KRO limit is if the device is recognized as a boot keyboard only. So there are a couple of ways to achieve NKRO: one is to use a >6-key report descriptor, and another is to simulate multiple keyboards.
TinyUSB allocates the number of separate HID interfaces at compile time (also true for other devices, such as CDC). Currently we allocate only one. I will make this at least two to be able to support boot keyboards. Bu...
For anyone who is interested in this module - what kinds of projects would you use it for? And what do you feel the biggest draws of it are, compared to other similar options?
I would use it for accessories connecting to a central unit. The biggest drawback for me is the requirement that the central and the accessory knows each other’s MAC address. When selling accessories I cannot know this in advance. The MAC must be shared on another channel first such as Bluetooth. Another drawback i...
It would actually be very handy to have a way to assign a 6KRO for the first USB descriptor then another descriptor as an NKRO to allow for NKRO when inside an OS but to also allow for boot time control.
Actually that bit at the bottom of that post is exactly what we should try to get as it solves the issue of buggy BIOS implementations and silently allows for NKRO if the host supports it, which is perfect since nothing extra has to be handled by any HID use-case to "handle" HID interaction.
It would actually be very handy to have a way to assign a 6KRO for the first USB descriptor then another descriptor as an NKRO to allow for NKRO when inside an OS but to also allow for boot time control.
This will be possible. You will be able designate a keyboard (or mouse) descriptor as "boot", and it will mark it as a boot device. You could have a completely different keyboard report descriptor as the actual report descriptor (which would would be ignored in boot mode). So you could us...
I thought that the host is supposed to tell the device whether it expects a boot keyboard or not when the plug is connected?
I thought that the host is supposed to tell the device whether it expects a boot keyboard or not when the plug is connected?
The host sends a "Set_Protocol" command to switch to the boot protocol and the standard, implied descriptor. So I think you could still have an NKRO-style report descriptor, but also will need to support the standard descriptor if it's Set_Protocol to boot mode. I think this is implied by the spec and by the last few paragraphs in https://www.devever.net/~hl/usbn...
Hasn't been done in a while. Gamepad has been removed from HID, for instance.
Hi,
this code:
`
import usb_cdc
import storage
import digitalio
import microcontroller
buttona = digitalio.DigitalInOut(microcontroller.pin.GPIO15)
buttona.direction = digitalio.Direction.INPUT
buttona.pull = digitalio.Pull.UP
thisstat = not buttona.value
buttona.deinit()
if thisstat:
print("disable_usb_drive")
storage.disable_usb_drive()
print("usb_cdc.enable(console=False, data=True)")
usb_cdc.enable(console=False, data=True)
else:
print("nothin...
Do usb_hid.disable(). I think that will get you the extra endpoint pair you need.
The safe mode problem has an issue at #4766.
(If you put your entire code in a pair of triple-backquotes it will be marked as a single block of code.)
Some very rough preliminary numbers for deep sleep, with all upgrades in (battery life for 1000mAh battery):
ESP32-S2: 2.2mA, 454h
NRF52: 3.6mA, 272h
STM32: 0.78mA, 876h
RP2040: 2.68mA, 320h
I think I can get the pico lower
Probably impacted by dev board leakage current too, not sure how to account for that 🤔
So, this has been already solved? should this issue be closed?
I just noticed ulab missing on STM32 based KittenBot Meowbit. Was that an oversight? I tacked the question on the end of: Adafruit Forums: Is memory set correctly for KittenBot Meowbit?
.
See commit 70e978f48b587620bb1407d9717f0a8fc3d4cf26 -- I think this board has limited flash space.
I somehow broke the boot.py file which makes the file system read-only.
Adafruit CircuitPython 7.0.0-alpha.2-584-g25a44cb77 on 2021-05-15; Raspberry Pi Pico with rp2040
boot.py output:
OSError: [Errno 5] Input-/Output error
I think it should be the other way round: If something is wrong with boot.py, the filesystem should be always writeable so you are able to fix the error.
Renaming boot.py via REPL didn't work but formating the drive resets it completly.
I think it should be the other way round: If something is wrong with boot.py, the filesystem should be always writeable so you are able to fix the error.
If the filesystem is corrupted, then the metadata is probably damaged (e.g., the directory entries). It can't be recovered, so we or the host computer make it read-only so no worse damage will happen.
Read about the best way to edit files and avoid corruption here:
https://learn.adafruit.com/welcome-to-circuitpython/creating-and-ed...
@jepler I think it's 512kB with its STM32F401RET6, same as SAMD51?
Ok, because the error got written to boot_out.txt it looked liked an internal behaviour of circuitpython.
Is there an updated sample boot.py from your first post?
Is there an updated sample boot.py from your first post?
What is your boot.py? That would be the easiest. Also see the documentation: https://circuitpython.readthedocs.io/en/latest/shared-bindings/index.html.
I will be writing a Learn Guide shortly. This is all very new. I am working on boot HID devices at the moment.
The sole build failure here is some kind of GitHub Actions problem, so this should be considered a successful run.
I managed to get it to compile and CircuitPython works with analog support. I've been using 5.x build though. Anyone having similar problems can use: