#circuitpython-dev
1 messages · Page 368 of 1
i don't know it that well, maybe in the 1pm or in the weeds?
Sure it might be a good in the weeds topic
1pm I don't like to do anything other than lurk since it's so time constrained
re tabs, I would think there would be an uncrustify option to untabify
we can ask jun2sak not to use tabs also
ok I haven't read the uncrustify docs, just the yaml file
me neither
@tulip sleet sure. Do we have a style doc for contributors anywhere?
no, and I think the idea is that uncrustify will just fix it up anyway
though things like naming styles it obviously will not
right, just automate style, and don't sweat what can't be automated
there was something else I wanted to add to uncrustify... what was it...
maybe comment blocks and long function params? I'll read the manual.
we are trying to use the same format as micropython so the merges will be easy
Easi_er_ 😉
I2C.writeto says it expects a ReadableBuffer and takes strings, is a string a ReadableBuffer ?
@jun2sak thanks for cleaning up the internals! Looks good to me. There's just a little bit of formatting stuff to take care of, I can just pull and do it real quick today though. For the future, you can look into using pre-commit, Adafruit has a guide here on how to install and use it (you might also need uncrustify, which you can get with apt, homebrew, etc).
I'll give this another test. Regarding...
@still zephyr Are you still available sometime tomorrow to chat about your work with aggregating the Adafruit and Community libraries?
@ajs256 Thank you for this fix! I may not have time to test it today, but I will tomorrow for sure. I wanted to let you know that it is on my list.
I am looking for the def of ReadableBuffer and having a surprisingly hard time. It's definitely defined _somewhere).
It should not actually take strs. But https://github.com/python/typeshed/blob/4d734e38dde295e93c27efd6ead3bb5c05d03fe5/stdlib/_typeshed/__init__.pyi#L169
it is just for typechecking annotation. It's not just a convention, it can be checked
in MicroPython, string and bytes share a lot of code
and sometimes it's too easy to substitute one for another
I was looking at the OSError: [Errno 19] Unsupported operation error with the SerLCD and at first I seemed to have different behaviours if I called writeto with a string or a bytearray, but that was a fluke, but still I was wondering about that
ideally it should validate the arguments as obeying buffer protocol but not a string
It infinitely hangs unless I pass in
probe=Falseto theI2CDevicecall.
I believe that's because you lock the device with your try_lock() loop.
If you do that, use the I2C object directly.
The role of I2CDevice is to manage the locks. You use it like this:
with dev as bus_device:
bus_device.write(...)
(Note that here bus_device == dev, but I'd call it an implementation detail I think)
Now on the other issue, I do encounter random `OSError: [Errno 19] U...
<@&356864093652516868> We're about 1 hour out from our weekly meeting -- please add your notes to the document! See you in the voice channel shortly. https://docs.google.com/document/d/1IBhFVC1LdW_ptX07F6KpWOSZBpEv2eZWFguEIP4nJio/edit?usp=sharing
CircuitPython Weekly for April 26, 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, ...
Hello yes I am 🙂 I took a look during the weekend to better understand,so yes no problem for tomorrow 🙂
Excellent! Wanted to verify before adding it to my plans.
No problem, let me know around what time and it is all good
Text chat or did you want to do audio/video?
Either is fine, simply trying to plan for it.
I could type pretty fast, but for this I prefer audio
Alright, perfect. I'll figure out a couple of options for you to choose from and we'll figure it out sometime today.
Thanks. let me know, just to run accordingly, I have the day off so no problems there
Excellent! Thank you!
@onyx hinge I have to miss the meeting this week. Sorry no time to add notes.
How about tomorrow 15:00 US EDT (UTC -4h)?
Perfect.. works for me
I think the linkified "this post" in the new version of Mu news item in the meeting doc might be going to the wrong place. Currently it leads to a blank new issue page on github.
Great! Added to my calendar.
brb
same
Special request: can someone change the pinned link for memory saving in the help-with-CircuitPython channel to the new learn guide? https://learn.adafruit.com/Memory-saving-tips-for-CircuitPython. I think it’s a better starting point than the GitHub page.
@mental nexus I think that you can edit your message and the pinned message text will update too
try that first, and let us know if not
Cool. That worked. Easier than I thought.
So with the audio issues I've had, it turns out Discord doesn't support the hardware setup I have at all. So the fact that it even works as well as it has is a total fluke.
Is CedarGrove in this place? What would be his nickname here?
Hello @thorny jay !
We can talk thermal camera later. 🙂
Absolutely!
Hey my "picotouch" PCBs arrived and... it works mostly! Picking up stray touches from cross-board traces and my too chonky fingers, but I'm pretty happy w/ the result so far. Thanks #CircuitPython & #RaspberryPiPico for making this project so easy https://t.co/NUcqa2lEMo https://t.co/EMihBMbzWO
About this
GitHub made it so first time contributors require someone to “approve” the CI to begin running
Do we know if that is on a per-repository basis, or organization?
Could I run the Weblate CI on the core side? I have the ability just checking..
Great job everyone, by the way, on 77 PRs merged. That's just.. 🤯
@still zephyr is there one that is waiting due to that? You can feel free to press the button after you've made the most cursory check for the pull request being "real" (the "unreal" ones modify the github actions yml files)
I've added it to my list for tomorrow, I'll check it out.
@still zephyr I've tried to address the weblate problem by adding the weblate bot as a "contributor"
but didn't see how it turned out yet
Will do, just checking with you folks.. I saw the issue that you put in the weblate side 🙂
@tulip sleet truth
I am lurking (I might have a short question in the "in the weeds")
😊 You're welcome!
Good luck on the vaccine recovery -- use it as an excuse for a bunch of rest, R&R, and hot soup 🙂
Dual espresso scale? ☕?
... an early Clue version. The latest is on a PyPortal.
Whoa cool. Have been thinking of getting a machine but have generally felt overwhelmed by all the info.
🎉
The data files are created in circuitpython-build-tools
FoamyGuy's stream recording mentioned: https://www.youtube.com/watch?v=Mjz0vMw-Jl8&t=6s
and YouTube channel: https://www.youtube.com/user/Zobrombee/
Nice, Thank you Melissa
Oops, I was out of order alphabetically as well. Thank you whoever fixed that.
@onyx hinge Would love to merge the colour of a low-res thermal camera with the image from a normal camera... could be grey scaling the normal camera and some alpha blending of the thermal false colour. 🙂
@thorny jay I had exactly the same thought (well not necessarily about the implementation)
Do you know how the project bundler finds files that are used in the project, but aren't a library? Like in this project: https://learn.adafruit.com/electronic-history-of-the-day-with-pyportal/download-project-files-from-github when you download the project bundle it includes on_this_day_bg.bmp which is used in the project, but isn't from a library.
That's done on the learn guide code. I believe there is some kind of scanning library that finds them.
They are on the github of the learn guide.
Ah, I see. Maybe I can find them by listing files from inside the project folder in the learn guide repo.
possibly
Will do after the meeting, I ll move the conversation to the graphics team
ok Ill move it there
Maybe we could make a "Discussion" Repo that exists just to allow us to talk on issues?
yes
@slender iron John Park encountered this on one of his live streams.
That was discussed in your stream comment I believe.
I kind of like having “conversation” under an issue since they seem to be easier to find/discover. Of course issues “conversations” can head in different off topic directions. Not sure if discussions are as discoverable?
Yeah... John Park!
have to run, i'll catch the rest later
^^ yep. just found same. and only thing that showed up in a recursive grep.
@tulip sleet Thanks for chiming in on github!
I need to drop out a little early
@mental nexus we could discuss later, if you want regarding the mock imports.. on sphinx.
I can help with moving these repos. I've gotten a start on some of the widget ones already, so I've got some experience with it already.
@still zephyr I know hug reports are over but I wanted to give you a huge hug report for all those documentation updates! I've been out for the last week and I'm pretty sure half the emails in my inbox were from your documentation PRs lol. Thank you so much for doing all of that! Documentation is sooooo important especially for new users.
🙂
Cool. Sounds like requirements.txt is the way to go if it can really “verify” the library imports functions really exist. Let me give it a shot on a library and see how it goes. Will using requirements.txt cause failures of “local” docs builds versus on GitHub?
I will try to put some guidance in the design guide after all my work in the documentation related to the sphinx built process in order for folks to understand better this process..
@still zephyr Do you have a little time after this meeting? There's a process we usually follow when updating libraries, which includes merging the PR, and then doing a release. I'd like to have Dylan teach you how to do releases so you can take control of the entire process.
I have yes
No, for local you use mock imports
@still zephyr Great. @trim elm - I'll ping you when this meeting is over and you can work with Jose David. Thanks to both of you!
Ping me after the meeting, if you need help for sure
Thanks everyone!
@onyx hinge Someone was asking about image processing functions, so if you have any suggestions, I am all ears.
The person wanted to have labelling and blob finding.
I think you've already worked with the openmv people, yeah? we may want similar stuff to them.
Thanks
Have a good week everybody! I'm stepping away.
Thanks all!
I don't know yet how Jeff camera work... but does the camera put thing into a "buffer" that can be processed by ulab?
@trim elm The meeting is over. Feel free to work with @still zephyr anytime.
@still zephyr Want to do a vc or whereby? It might be easier to explain stuff that way
I am sure it supports the buffer protocol, so interfacing to ulab should be possible.
yes for sure..
Ok will have to figure out if it goes in both places or only one. On the widgets I noticed that Melissa pulled out the mock imports and then added them to requirements. I don’t have a library right now to push. When I get to the Animation library I’ll give it a try and ping you with lots of questions!
I suggest using one of the Discord voice channels. It will let others sit in if they wanted to.
There's the three "shared" ones.
Ok. Let's go with Amelia Earhart
And then you can also do text chat here.
@lapis hemlock @thorny jay yup, it will work with anything that is a WriteableBuffer, which includes ulab arrays & displayio bitmaps. The "image format" is RGB565 so it is inconvenient to process (or it can be switched to YUV, which at least has the advantage that ever other byte can be treated as a greyscale value)
Thanks!
have the libraries diverged yet for 7.x?
Because if that's a buffer that contain grey scale and I can multiply by a colour from the thermal... then we have the fake colour thing.
No problem 🙂
@slender iron I waved. Like it matters 😄
Let me know when you have a PR into the newsletter.
Seems that I will have to acquire some hardware...
will do, just started the upload
I can wrap up the stuff here: https://github.com/v923z/micropython-ulab/pull/327
@lapis hemlock oh will that help with pixel formats?
if so, excellent. I had not made a connection
@errant grail are you still around? I think you should really have a look at my thermal camera, I generated 64 colours palette in various way, made conversion from temperature to 64 values using ulab, used scaled bitmap for fast display. So some trick can be reused.
@lapis hemlock CircuitPython 7
so not particularly quick
I'm very much in an investigative phase right now
@onyx hinge I have put that PR on the back burner, because there was no response from openmv, so I am not even sure at the moment, whether the implementation would fulfill the requirements. But if you have any comments on the general idea, I would really appreciate it.
@lapis hemlock OK if I have something intelligent to say I'll add it
Thanks!
I am logging off now, but it was great to be around. Hope to do this more frequently.
Yes, still here. I've looked at your code and use of ulab. My initial approach was similar, albeit with a very limited set of temperature values.
I believe palette colour are "free" so 64 or 128 are possible at no cost (once you started).
There as that FancyLED library that had function to generate palette, so at one point I tried that.
@thorny jay In my current implementation, the colors are only limited by 24-bit RGB; no limited palette. Want to jump into a shared voice channel?
Marie Curie?
See you there
@mental nexus I am now free if you want to discuss
@tulip sleet Is there a way to view the frozen libraries from the REPL? Like importing sys or something? I thought for a moment maybe there was, but then realised I didn't know what I was doing.
Thanks for pinging me. But Sorry but I have to run. Let me get to trying to push a library and then that will help it make more sense and I will know the right questions to ask.
No problem 🙂
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/1z62nKbjNNv0j6uPWeUG6Co3aSCw4OQ3wl9VYlRIeTi8/edit?usp=sharing
CircuitPython Weekly for May 3rd, 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, ...
Regarding the Graphics Widgets controls. I transferred the comments here https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_Layout/issues/19 to open the discussion on how we want to handle widgets behavior , if you would like to participate and leave your comments, we are in the process of moving the libraries and implementing the control functions. Any feedback is appreciated, testing, bugs, the normal stuff. Thanks.
Tensorflow Light for Microcontrollers is a subset of Tensorflow Light designed specifically for use with microcontrollers, taking only 16 KB for the core runtime and requiring no system libraries or dynamically allocated memory. Adding these tools would allow for things like person detection, gesture sorting, voice recognition, and other tasks that use trained models.
Tensorflow Light is already implemented for Micropython on the [OpenMV]...
Ugh, ok, I still can't figure out how to find the build assets off of a CircuitPython PR.
I see where they're being built, but.... wait... nevermind.
Artifacts.
🤦
Anyway, hurrah, the fix worked.
Tested successfully on Neo Trinkey (neopixel_trinkey_m0)! Thank you for the fix!
As the others do not exist yet, I cannot test them. If there are issues, we'll catch them at a later date.
@ajs256 GitHub recently changed it so that first-time contributors PRs require approval to run CI. This was put in place to avoid a recent spate of CI abuse. Thank you for your patience with the system.
I think this is ready to come out of draft. I had little idea what I was getting into, and I don't know what I don't know. It needs careful review and test, I'm sure others will find novel ways to exercise the code ;-).
An oddity... there's nothing in the Espressif NETIF or WiFi APIs to get the IP address of connected stations. Maybe I'm missing something obvious. It is possible to get their MAC address and an aid counter, so you could de-auth them (not implemented here). DHCP is behind...
@lone axle @slender iron I added the PyPI global secrets to the CircuitPython org on GitHub for the new circuitpython account.
thanks!
@slender iron For your own awareness, the email address attached to it is a new address (the mailing lists don't support +foo@ for addresses) that goes to circuitpython(at)adafruit.com so it's all the same folks.
👍 thanks for sorting that out
Yep!
Was there one needed for readthedocs too? I'm not sure exactly how all of it gets hooked together.
No, RTD is webhooks. @slender iron Do we want a separate RTD account as well?
ya, I think it'd be good to have a shared RTD account like adabot
On it.
@anecdata I could help with some testing, this is intended to work with the ESP32S2 and Pyportal?
Do you have some simpletest code to share? Or do I use the stubs?
I think this is ready to come out of draft. I had little idea what I was getting into, and I don't know what I don't know. It needs careful review and test, I'm sure others will find novel ways to exercise the code ;-).
I'm happy to merge this quickly. It'll end up in 7.x which will need lots of testing anyway. Getting folks to try it out is the easiest way to find the issues. :-)
@lone axle Ok, so here's how RTD will work. You will generate the documentation on your own account. And then you'll add circuitpython as a "Maintainer" in Settings. That way, we'll all have access to the documentation in the event that we need to. We'll share credentials for that account as needed. This is how we do it for current docs, except with a different account.
jposada202020 Thank you! I have no idea about stubs. I can post some code (I'll edit this comment in a couple of minutes). The API is pretty simple. ESP32-S2-only as the Access Point. Anything can be a wifi station to it.
The first step to testing is to start the AP, then connect some external client to it. That doesn't actually do anthing though, so as a second step I've been running some TCP or UDP stuff over that connection... that's a little more work to set up, but the same as on an...
The code structure looks good to me. One comment about the security enum values. Looks good otherwise.
You may want to split these out like Pull or Direction in digitalio. @jepler did add a way to do enums internally to. That's probably even better. We'll want comments for each entry describing what they mean too.
Isn't the existing shared-bindings limit 65535 because of the 16 bit unsigned int? Want to increase it further?
I have added circuitpython to two of my libraries could you checked if that worked? please:)
Sounds good. I'll try to get that set up on the first few repos that are in the circuitpython org this week.
It did! Thank you!
would the URLs used in the readme need to point to my account? or by virtue of being shared to a maintainer do they work with the circuitpython in the URL?
the badge needs to be modified in the rst file
Here is where the tick times are returned: https://github.com/adafruit/circuitpython/blob/main/shared-module/time/__init__.c This is where I'd subtract the VM start up time from the current time. I don't actually want the internal time to change.
I have not move yet the docs, so in my case I am talking
I think it should point to the shared account. So circuitpython. That way if you, for some reason, can't maintain things anymore, folks can still get to the docs. Does that make sense?
That isn't quite how we do it for the main docs. We have a CircuitPython project, and they're all added a subprojects, so the docs links are all the same.
@tulip sleet do we want a milestone to track what fixes we want in a new 6.x release? most of them are going into main I think
@fossil gorge OK, for the CI approval thing for first-time contributors, it appears to be a per-repository basis.
Was refering the inline documentation in the C code... But posting code will be a breeze.. Thanks :)
@lone axle I added you as a Maintainer also in two repos, if you could verify that.. I could add you to the rest.
@slender iron Maintainers with write access can approve CI runs for first-time contributors. So my assumption is that any role that has write access can approve.
👍
I think for now we see if the group we have keeps up with things. If we're struggling and missing PRs, we could look into adding more folks to the team, or adding folks as collaborators onto popular repos, etc.
Yep, I see these ones under my account now. Thank you!
Great thank you
So you could connect just to do a WEBREPL? (like MP) just kidding..... 😄
@onyx hinge can you please point me to an example or ref on doing enums internally? re: https://github.com/adafruit/circuitpython/pull/4650#discussion_r620667708
@crimson ferry check out shared-bindings/displayio/__init__.c and .h
thanks!
Yes, the limit can be raised to 65535 with the existing API. I'm not sure how long it would be reasonable to make it, though. The two devices I used to test (a DHT11 and an IR receiver) both were fine with a max of 4000 us. I'm not sure what devices might need pulses longer than 32 ms. Also, should an error be raised if the limit is exceeded? The current implementations on boards like atmel-samd seem to silently ignore pulses that are too long.
@onyx hinge I'm still baffled. That doesn't look different to me than what I did. digitalio makes a class, which I've never done but presumably I could figure out. But your method is better than that I'm told, I'm just not getting it.
@crimson ferry yeah the documentation should be better. Can I walk you through it another time though?
OK, is there a good time for you tomorrow?
I'm tied up until maybe mid-morning, then anytime
@tulip sleet You around?
yup
What generates this? https://github.com/adafruit/circuitpython-org/blob/master/_data/files.json I see the it updates automatically with a release with a PR from adafruit_blinka, but I'm unclear on how, specifically, it knows what modules are built into a particular board. Where is it getting that infromation?
Ah so it's in the core.
Ok, would it be possible to use Python code to generate a list of the frozen libraries for a board and include that?
Or some code.
Also, from earlier, is there any way to tell what libraries are frozen into a board from the REPL? other than importing them. As in, is there a way to list them.
Looking.
i don't think there is
Ok
My intention was that the pulse length would saturate at 65535 so it would represent anything longer than that.
unless we can list the fake .frozen directory, let me get a CPX
Thank you
I started to try, but realised I had no idea what I was doing.
Unrelated side note - this is excellent licensing, hadn't considered something like this: # SPDX-FileCopyrightText: 2014 MicroPython & CircuitPython contributors (https://github.com/adafruit/circuitpython/graphs/contributors)
no, you can't list the fake .frozen directory
I'm glad I bailed quickly then.
but the frozen modules are included in help('modules'); you just can't tell which are frozen and which are native
>>> help('modules')
__main__ adafruit_hid/keycode math supervisor
_pixelbuf adafruit_hid/mouse microcontroller sys
adafruit_hid/__init__ array micropython time
adafruit_hid/consumer_control board neopixel touchio
adafruit_hid/consumer_control_code builtins neopixel_write usb_hid
adafruit_hid/gamepad collections os usb_midi
adafruit_hid/keyboard digitalio random
adafruit_hid/keyboard_layout_us gc struct
Plus any modules on the filesystem
this is on a neopixel trinkey
Ah yeah, that's what I have here.
The lack of differentiation is frustrating.
So as a general concept, is it possible to have this https://github.com/adafruit/circuitpython/blob/main/tools/build_board_info.py also include checking for frozen libs and generating a list where applicable? I'm unclear on what would go into that, but I'm sure there's someone else who could sort it out.
we just have to find the frozen modules in mpconfigboard.mk, and add them to the download info
we have to actually look inside the frozen/ directory, because only the repo names are in mpconfigboard.mk. So you'd see Adafruit_CircuitPython_HID, but not adafruit_hid in that file
Ah hmm.
this build_board_info.py script could do it
Ok.
I'll file an issue on circuitpython.org and the core then and link them.
Thank you for your help!
yes, I don't think this would be too hard.
Preliminary testing done in
Adafruit CircuitPython 7.0.0-alpha.1-853-gcbe1aa74f on 2021-04-26; Adafruit Metro ESP32S2 with ESP32S2
Test Code
>>> import wifi
>>> import ipaddress
>>> import socketpool
>>> import time
>>> wifi.radio.enabled = True
>>> wifi.radio.start_ap("Bob", "YourUncle", channel=6, authmode=wifi.radio.WPA2_PSK)
Result
Could connect from a Samsung S9+ Phone

@jposada202020 Looks good, thanks! "without internet" lol, I was wondering how hard it would be to write a router or at least a packet forwarder, or if it's even possible in this environment.
I would be equally useful to get confirmation that these changes didn't break various folks' existing station scan and connect code. If you have existing wifi stuff that still works fine on this version, that would be a good sign :-)
This would be handy in cases where you have a hard UART for debugging, but the REPL isn't working for whatever reason. I'm printing my exceptions to the UART, but don't know how to get the traceback, line, or filename.
Ok, build is passing. I turned off some modules to make it fit. Mostly synthio, msgpack, and asyncio.
Will definitely add the RTD comments, that was an oversight. Will work on the structure of these tomorrow with jepler's help. Did a little reading, sounds like maybe a scoping issue.
in RTD, sometimes there's a "Parameters" header for a function, sometimes there's not. Is there a distinction?
Are you talking about c?
both really, on the RTD website and in the code comments that generate it
classes typically call out parameters, but functions only sometimes have a Parameters header, otherwise they're just listed with a description of what they do, I'll find examples
Works for me! I used the Metro M4 version, edited code.py, and also copied and editing a much larger file, whose contents were fine over reboots.
Maybe it's just variations of style, like code. Return values are similar... sometimes a "Returns" header, sometimes a "Returns" header and a "Return type" header, sometimes the return object is just in the descriptive text. Maybe there's a guide somewhere about this stuff.
I updated the code above to make it a little more interesting. Run it, then try in a browser to go to:
http://192.168.4.1
It's not to spec by far, but it (mostly) works in many browsers. Or any non-HTTP TCP socket client should work.
You may want to split these out like Pull or Direction in digitalio.
I did this while working on WiFi Mesh. The changes are in my mesh branch.
I can create a new PR adding AuthMode and then you can do a merge from upstream.
What have y'all been doing with these NeoTrinkeys? This is an awesome piece of hardware, and I'd love to hear what others are doing with it.
Ok will try. Thanks for the code. :)
@crimson ferry sometimes we omit the parameters list if it is really obvious. If there are multiple parameters, it would probably be better to add an explicit list
Just merged our oldest library PR! Thanks to s-light for sticking with it for so long, including all of the updates necessary to keep the PR in line with the library! 🎉
@still zephyr I created an issue on that repo about the documentation and assigned you.
🙂
The docs appear to be there, but the TOC on the side seems incorrect. Anyway, verify it's an issue, and if not, simply close the issue.
ok, regarding the note, in newwer libraries the note regarding the I2C is not there,
I mean the board.SDA, board SCL,
Ah ok
should I included?
I think consistency is probably ideal.
good will do
😮
What do you mean "they just create the object without the comment"
In the library
(I saw your comment now)
meaning, before this documentation storm, they were already libraries using the board.I2C object, not many but some, and they do not have the note
Ahhhhh ok. I think if we're going to include the note, we should include it everywhere.
Even if it was already in the library without the note.
So, yes, continue as suggested before I said "hold on". 😄
ok, need to go back and verify, but no problem with that just a new PR
another question
Sure
yesterday reviewing the libraries I saw this, do you happend to know where I can get one exactly like this?
😊 Yeah... that's how they are in the shop unless the board has had a new revision. There's 3-4 different boards with my name on them. I designed the PCBs.
It is nice and unique
oh wow
I did not know that, just saw the picture yesterday
Thanks, I will go throught the rest of changes and then go back an do the note, is that ok?
Absolutely! Whatever order works best for you. There's no rush.
There is, summer is comming 🙂
thanks I will start with the ones this morning, thanks again 🙂
You're entirely welcome! Thank you so much!
tl;dr: We need to add functionality to the build_board_info.py tool file to check for and generate a list of frozen libraries for any board builds that have them.
Note: Frozen libraries are CircuitPython libraries that are included in a CircuitPython build for a specific board due to RAM/flash constraints. They are NOT the same as modules which are part of the core CircuitPython.
We added the Project Bundle to the Adafruit Learn System which allows users to download a zip file that in...
Thanks, I'll take a look. I can work from examples like that I think. I'm waiting first to understand what jepler's method is.
Once this is completed, we can deal with rendering it properly on circuitpython.org/downloads/board_name/. This issue has been created to track the next steps.
As in hand-signed?
I mean, I didn't go to HQ with a gold sharpie 😆
🤨 Uh huh
Looks really cool though
I created a bitmap and it was added to the silk library. It's part of the silk 🙂
Exactly 😄
@gilded cradle Before I head down a stupid-hole, is it expected that my FunHouse does not have a UF2 bootloader on it? I'm doing all the things with reset and boot and it's not coming up as HOUSEBOOT.
It was one of the first run of them, I think.
@idle owl it has a bootloader on it. Press reset and then again when the dotstars turn purple.
🤦
@gilded cradle This is why I asked. Thank you. As a tangentially related side note, I can't download the funhouse_tinyuf2_combo.bin file in Chrome or Firefox, it tries to play it as a video.
Oh, I think that's a learndev thing. Want to send them a note?
Sure.
thanks
They just added .bin downloading and must have made it a video type accidentally.
You can right click and choose save link as
Yeah, except change it to .bin
yeah, definitely
@crimson ferry Feel like talking about enumerated values? I have time for more than a 2-sentence answer now.
@onyx hinge Yes, thanks!
@crimson ferry do you want to stick to text or do you prefer voice or video?
text is fine, voice may be more efficient - I haven't done it in Disocrd but should work, I'm not set up for video
OK, let me go to my desktop computer, I'll hear you in a few minutes in the Amelia voice channel.
I think I have to restart Discord, back in 15s
Hi @onyx hinge and @crimson ferry... mind me listening in?
@analog bridge of course not, though I think Anecdata is having technical difficulties so we may switch back to text
@analog bridge no problem, but my audio isn't coming through I think
silly discord
sorry, I'm not sure what's wrong, permissions look ok
that's OK, we can try it some other time
though maybe I'll screen-share in the "voice" channel, if it comes in handy
so.. I assume you're more interested in the "how do I use the enum stuff" than "how does the enum stuff work", right?
at least to start with
This is the area of interest: https://github.com/adafruit/circuitpython/pull/4650#pullrequestreview-645137519
I can follow the PULL-like enum-like class I think, or @analog bridge's mesh, but Scott mentioned another way, but it wasn't clear to me looking at displayio yesterday
OK I'll share my screen as I talk about what I did in displayio
I recently wanted to add color conversion in ColorConverter, and I used this new style of enum to do it
so the first thing is .. you need to include the header "py/enum.h" in the source files that work with the enums
where you get the enum as a parameter it is an MP_ARG_OBJ
and it can have a default value
are you seeing this in the screen share or do you want me to paste the bits of code in here?
stream is visible
OK
I can see it
then when you use it to pass to the shared-module code, you have to use this formula where you call cp_enum_value (to turn a Python object to a C enum value), and cast it ...
it's a bit of a mouthful, but it does a lot of stuff, it checks that the Python object is the right type (so the value is a legal value), and throws an exception if it's not. So no need for explicit error handling
yeah, I knew I had input validation issues
so that I think covers how you'll get the value from a Python function call and into a shared-modules or common-hal function call. make sense? questions?
knowing what to look at is a giant leap 😉
the C enum gets declared in a header file, just like any normal enum
there are also some Python objects: The "type" object, and then in this case a specific one of the enumerated value objects, the one for RGB888.
That one's there because it was used as the default value. You can list them all if you like, or just the ones you need. sometimes you might not need any, but often you need a default one.
next, we get to the most magical part, the use of these C preprocessor macros. MAKE_ENUM_VALUE defines a Python object for a particular C enum value
so that first one defines the object for RGB888. The C name of the object is made up by pasting together the 2nd arg (displayio_colorspace), the 3rd arg (RGB888) and "_obj"
same as we saw in the header file's extern declaration
and then so on for all the other values. These don't have to come in order or anything, but it never hurts to be consistent.
I'll just call attention to the order of things when you put them in the docs -- the line for the documentation of a particular attribute comes right after it.
Next thing is to make the "map" (think Python dict) of the enum values. This is similar to what is done with the module globals, but again hidden behind macros
so you MAKE_ENUM_MAP, giving it that same prefix which is unique to your enum, and then MAKE_ENUM_MAP_ENTRY for each value
and then you have to MP_DEFINE_CONST_DICT and place it in your module globals ...
I skipped over these, but the first one creates the code that is necessary to print the enum objects in Python, and the second one creates the Python type object, the "class ColorSpace" object itself
so .. that's all the parts, I think
questions? comments?
it;'s a lot to digest, I have to spend some time poring it over and trying it out... I was a little slow with my pen, can you point out the very first bit you talked about in the file?
nice! thanks @onyx hinge
I'm not sure which file you mean, there was the MAKE_ENUM_VALUE
let me get you the link to this diff in github view and then you can link me to the lines you mean
oh wow, yeah the diff will show me everything
OK, I think I have the scope of it, need time to digest the details, thank you!
I'm happy to answer any questions and also take suggestions for documenting this for developers. that's absolutely not my strong suit
I think you can follow any of the methods... they all are different ways to achieve the same goal.
i know nothing, I'll do whatever is best
By the way, you can also take a look at the C header for enums https://github.com/adafruit/circuitpython/blob/main/py/enum.h and the implementation https://github.com/adafruit/circuitpython/blob/main/py/enum.c when you want to dive deeper
What I think is nice about this way of doing it (I'm biased, I created it) is that there's not much extra work to do to perform input validation and to print out the enum objects
One aspect I did not cover: if you have a C enum value and you want to return it to Python, you use mp_obj_t cp_enum_find(const mp_obj_type_t *type, int value); to turn it into the Python object...
https://github.com/adafruit/circuitpython/blob/HEAD/shared-bindings/canio/CAN.c#L179 so here we return a "bus state" value into Python from the C enum value
good to know for future
Thanks for your time and help, sorry about the voice, I'll give this a shot.
OK!
anyone know why Discord wants to monitor my keyboard while I'm using other apps?
@idle owl should I use "1.0.0" as the tag for an initial release of a library, or do we start with lower numbers like "0.1.0"?
(trying to narrow down the audio thing)
@crimson ferry It can use "push to talk" where (no matter what app you're in) holding a particular key will unmute your mic
(or to toggle mute)
Depends? Is it a solid library? Or will there be a lot added to it immediately?
@idle owl it's probably mostly done, the main caveat is you need the very latest CP for it to be of any use
😱
Really it's entirely up to you, version numbers are free.
Hmm.
Maybe make it sub 1.0.0 then?
And 1.0.0 it when CP has a release that isn't S3?
should there be a big warning at the top of the docs?
Yes.
Sure
how better to word "unreleased development version"? "absolute latest" is what cp.o says I guess
Put (absolute latest) in parens.
Because I would still think "latest" might mean stable if I was new.
"Absolute newest"
I guess whatever .org says is best
Since that's what should make people want to download it is the wording.
Did we update CircuitPython to do the new things with the status LEDs yet? Or is that still in the works. I don't see a PR for it, but my search fu might be failing.
I don't think it has gone in
@gilded cradle So FunHouse doesn't really have a CircuitPython status LED then? Bootloader and reset, yes, but CP, no. I'm writing broken code and nothing is blinking. I wanted to make sure that was accurate.
Oh, I'm not sure @idle owl. I usually have a serial console open so I didn't pay attention to that.
Trying to make sure the wording I use on this guide page is accurate, is all.
I think I need to remove the word "status" in reference to "LED" in general because not all boards seem to use their LEDs as status.
Let me try adding an error on my other funhouse that's not in sue and see what happens
I was checking to see if it used one like Neo Trinkey, or multiple like others, or none.
I would think a dotstar would light up, but maybe not
Right. That was my thought. But CPX, for example, doesn't do status blinking. So it's not out of the question.
Yeah, my lights don't blink either. Good observation.
Ok, thanks for the sanity check. Appreciate it!
yw
FunHouse uses DOTSTAR_CLOCK and DOTSTAR_DATA for the onboard DotStar pins, which is much clearer than the previous APA102_SCK and APA102_MOSI.
I have added the CLOCK and DATA pin names to all other Adafruit boards using the previous naming convention.
I wonder, why there're hard-coded boundaries in the first place? As for the MAX_PULSE, my wild guess is that there're some dependencies on the buffer type which is uint16_t[], is that correct? But for the MIN_PULSE, why would that be ever needed?
And I think, this should be stated in the API docs, may save a lot of time for someone.
The reason for a minimum pulse time was to ignore 'blips', which seem to be
especially common with the
infrared remote receiver. The maximum pulse time is mostly to give some
idea of when a series of pulses
has ended - otherwise we might sit for long periods of time waiting for a
high pulse to go low when a device
has, in fact, stopped sending pulses. I would prefer a timeout value to
handle that; but there is not currently
a timeout implemented in the PulseIn API.
On Tue, Apr 27, 2021 at 12...
@DavePutz Gotcha, thanks for the clarification!
@onyx hinge FYI -- I just adapted the new gcm4 ov7670 example to run with my 2.4inch TFT (ILI9341). It is running OK now -- with lastest CP build. I had some issues getting it running at first - board would hang but after a few power cycles and reloads, it is running OK.. not sure what the issue was.
nope, I got distracted with merging
@idle owl note that the MagTag does light its top pixels purple for bootloader mode, but not yellow for safe mode (that seems to be common to all ESP32S2) or for errors/REPL. I wish it was more uniform and all boards that can did the purple (on ESP) and yellow light (including CPX) and just omit the rest on power-conscious boards like the MagTag does
I was just noticing earlier that my qtpy m0 doesn't switch its LED on for safe mode (brownout)
@solar whale I see things like that too, and don't understand, haven't been able to find the pattern 😕
Glad it’s not just me 😉
Thanks for the details.
I was mostly making sure that it was that FunHouse didn't do status, not that CP had been updated to do the new status stuff yet.
1.11 is merged
@onyx hinge sometime if you have a minute, could you take a look? I think I doted all the "i"s I knew of, but TypeError: can't convert Authmode to int when I pass one of the new enum values into a function
@crimson ferry I think this needs to be a MP_ARG_OBJ now: { MP_QSTR_authmode, MP_ARG_KW_ONLY | MP_ARG_INT, {.u_int = WIFI_RADIO_AUTHMODE_WPA_WPA2_PSK} },
then you can say wifi_radio_authmode_type authmode = (wifi_radio_authmode_type)mp_enum_value(wifi_radio_authmode, args[ARG_authmode].u_obj or so
I just found and fixing two old displayio refs too o_O
oh? nice.
(cut-paste)
thank you!
no, I meant in mine.. pasted and forgot to edit
and the default in the allowed_args[] probably need to be .u_obj = wifi_radio_authmode_WPA_WPA2_PSK_obj
i had tried that but it was still MP_ARG_INT and the compiler really didn't like that lol
Are we going to change the way we handle I2C, and SPI when MP is merged or it is going to be the same?
@still zephyr Still on for chatting in a few minutes?
yes 🙂
Excellent. I'll ping you in a little bit.
🙂
@still zephyr i2c/spi won't change!
Thanks Jeff
Ok, @still zephyr ready. Audio chat?
yes I am ready
CircuitPython voice channel will work.
WooHoo! Tried out the latest CP with MP1.11 on a feather_rp2040 and gcm4 -- both working well so far. @onyx hinge the ov7670 code still runs!!
I get AttributeError: 'PixelBuf' object has no attribute '_transmit' when trying to use a neopixel in the latest (QT PY M0 Haxpress specifically)
also Saola, seems to be a NeoPixel issue
is there a button in the Github web GUI to un-commit the latest commit?
[DotStar does not appear to be affected. (Relevant because both use pixelbuf.)]
In a PR or a merge? I don't think there is a button to do it. I've done it but had to look up how as I'm far from a git expert
You could just make another commit to undo the last one, not always ideal but may be fastest. I'm not sure if you can roll it back in the UI
the git commands look risky too, I may do what you suggested
If you're stuck on it let me know I can try to look up the commands / test them here.
@tulip sleet Jun2Sak did some cleanup - my testing shows the PR is ready for merge again. Should I encourage him to follow up with more cleanup in different PRs? The code works well, it just has a little bit of preprocessor junk in there that he or I could take care of later.
from main.
@kattni I removed the title, I guess after all these years people stop using this, so now we only have the module name. I have added information, that I would like if possible gets validated, in how to show these informations.
Thanks
@jposada202020 There don't appear to be any changes associated with this PR.
Yes second time in a row that happens to me....
@microDev1 If you're still game, go for it. I'll need some pointers on how to "merge from upstream". I spent most of the day trying to get one of the methods to work (starting with the hardest), I just don't know these abstractions at all at this point.
I see my mistake I did not chekout the other branch. please see Referencing_documentation_other_libraries #4652 for the changes going to close this one
@kattni I removed the title, I guess after all these years people stop using this, so now we only have the module name. I have added information, that I would like if possible gets validated, in how to show this information.
So far, it looks like the general case is that there is no disruption. I've only seen it once. If it happens more, we can characterize it as bug, or intended behavior under specific circumstances (to be documented).
Thank you for adding this!
@jposada202020 You could update this to read "You must also add". It flows a little better.
Thanks, maybe we should discuss this resource to people, at least that people check this guide before create any library to see if any changes have been made, and also a refresh for the Librarians :)
let's get it merged in
One of the documentation PRs that Jose David put in was waiting on the CI run, so apparently permissions are irrelevant if it's your first PR to a repo. Pretty sure Jose David could have approved it, but still, it was a question we were unsure of.
@still zephyr Sorry for delayed review comments. I think that should be it.
Has anyone seen anything like this before? I'm ready to replace it, but I'm not sure what would be causing it, and want to make sure it's not going to end with another replacement. https://forums.adafruit.com/viewtopic.php?f=60&t=178640
Why don't you just clean it up yourself; you should be able to push a commit to his branch. or submit another PR. If you're happy with it, let's merge it.
No problem, I was trying to figure out how to stop the CI 🙂
If anyone has a moment to take a look at this and let me know if it's ringing any bells, I'd appreciate it.
I looked at it, and never seen anything like that before but I'm not that knowledge with bootloader stuff and why it wouldn't hold it after a power reset
Thank you for taking a look.
Creating a draft PR for the CP Sapling Rev B board. Will update to open once I can confirm all changes.
So a small typo change i'm including in my PR is something i've been meaning to fix for a few months but it's completely got buried in the depths of my mind.
I skipped over polling interrupts and ISR details. I am not going to go through the exercise of explaining all of that just to contrast it against async. Which will mostly be a thread model, which was marked as off topic. If you have the right hardware you can build a RTOS in hardware. (I am not aware of that existing.) Conceptually interrupts can be modeled as async however this is technically correct and technically wrong depending on context.
Linux supports kernel modules for a reason. ...
dang, thought i was going to get that fixes to devices.h pushed in that PR but there's a merge conflict on it. next PR it is.
so i've been messing with the wio terminal for a bit trying to get neworking going, and I ran into some troubles that I was hoping I could get some advice on
specifically, the board is missing microcontroller.pins.PB24. I added this into atmel-samd/common-hal/microcontroller/__init__.c, and it shows up now, but when I try and use the pin for a uart, I get a hard fault. I suppose I'm missing some magic wrt adding pins, and was hoping someone could point me in the right direction
@lone axle hay any luck with the pillow haxing
Heya, yes. I have gotten it to generate for all of the projects in learn guide repo!
it revealed some oddities with a few of projects that I am chasing down now actually
I found a few files with UTF BOM in them and findimports raises an exception from it.
UTF BOM??
Early hug report: Would have taken me ages to figure out without Hugo's help!
Here are the screenshots generated by the current iteration of the script: https://github.com/FoamyGuy/CircuitPython_Library_Screenshot_Maker/tree/main/python_generator/generated_images
Still have a few things to clean up with them. But well on our way to getting them all generating nicely.
nice job @fossil gorge
You know what the kids say... BOM me once, shame on you, BOM me twice, then..., you... we won't be BOM'd again
i didn't know they said that, but it makes sense 😉
BBEdit offers the "unicode BOM" and "unicode NO BOM" encodings, I've never seen it mentioned anywhere else
We found that there's a "Remove BOM" in Pycharm. But if you don't know to look for a BOM, that well-hidden option doesn't help
For the record: File -> File Properties -> (several options)
@lone axle looks like its close!
Yep, have some spacing issues on some it seems and need to make sure none of them have unnecessary files included.
PID pending on Pid.Codes --> PID Codes PID PR
hey @tulip sleet if i had to delete my fork and refork, does it then count me as a new contributor?
Or is it the amount of time since my last PR?
are you asking about the PR build being held up?
it's a new feature at GitHub, they haven't tuned it a lot yet. I think everyone is getting held up the first time right now.
ah okay makes sense
approved to run
That PR is mostly just waiting on my PR for PID Codes to get merged. (assuming no one took 4DDF)
well, looks like i have the only PR for PID codes so it doesn't look like i'll have any issues with that.
weird.. ja build for my board failed due to too little flash
This is failing on the Japanese language build. Not sure why it ends up being bigger than the on board flash.. will need to investigate this...
Is this the right channel to ask about library PRs? or is this only for the main CircuitPython repo?
this would be the right place
I did ask in #help-with-circuitpython yesterday but I didn't get a response and I don't know if I am being a bit eager with these changes, haha
if it's an Adafruit library and you want someone to take a look you can ask here
sometimes things get buried by github notification though
Sweet, I'm looking to add some extra chips to the MCP230XX library, I've got a PR here, https://github.com/adafruit/Adafruit_CircuitPython_MCP230xx/pull/41
okay so it looks like you latched circuitpython librarians for a review of it
i would just give it a little time
ok
it can usually take a day or two as they are working on issues across a number of different libraries, mostly circuitpython itself
Thanks!
🙂
@still zephyr @idle owl I'm right here if you'd like to talk about https://github.com/adafruit/Adafruit_CircuitPython_MCP230xx/pull/41
adding parameter documentation explanations
Last few builds are also working fine.
@tyomitch Shall I close the issue for now, unless you want me to test something on the device?
This PR defines DAC* and RTL_* pins in board module of Wio Termianl. Addition of RTL_MOSI (=PB24) is essential, because PB24 is missing in microcontroller.pin. With this PR, the following code works to communicate with RTL8720.
import board
import digitalio as dio
import busio
import time
pwr = dio.DigitalInOut(board.RTL_PWR)
pwr.switch_to_output()
pwr.value = False
time.sleep(0.1)
pwr.value = True
time.sleep(0.1)
u = busio.UART(board.RTL_MOSI, board.RTL_MISO, baudrate =...
@tyomitch Shall I close the issue for now, unless you want me to test something on the device?
Please feel free to close.
Sure. I'll re-open it should it pop up again.
I believe some review comments like this one require attention before this PR is merged.
They got hidden due to large number of comments.
Sure, I'll make a PR shortly. I think commits after c472245 can be cleaned-up?
Thank you. Yes, should be fixed now.
Only four authmodes work for AP in the IDF: OPEN, WPA, WPA2, WPA_WPA2.
By clean-up. I meant removing those commits.
@crimson ferry assuming you are taking about PR #4650... you can remove changes after c472245 by:
git reset --hard c472245
git push -f
@analog bridge The current state should be exactly that. I just did it manually.
suggestion needed regarding wifi authmode property, is it better to have combined enum field like WPA_WPA2_PSK or an array of separate like [WPA,WPA2,PSK].
the latter has the advantage of less QSTR
Adding here the reference on issue https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_Layout/issues/19#issuecomment-828394272
Basic use case is some async event to better respond to user interactions. Could be actions on the reactive screens or other depending on user design.
The Event loop is the main discussion here and how to verify different states of differents graphical components that can be used at the same time producing different results and actions in the code.
Thank you for the PR! It's best to leave discussion of a PR in the conversation thread of the PR. I appreciate your excitement, but as skerr said, it can sometimes take a bit for a merge to happen, especially when it's a more complicated addition that requires testing (versus, say, a documentation fix). I see that there was already follow-up, so I'll leave it to the already-involved folks for now.
@tulip sleet You're the only other person I can think of for whom it's worth taking a look at this: https://forums.adafruit.com/viewtopic.php?f=60&t=178640 Have you seen this behavior before? I'm prepared to replace it, but I don't want it to turn into repeated replacements if it's something within their setup.
Thanks for replying back :)
You're welcome! Thank you for the contribution! Keep us posted in the thread with how testing goes.
Will do
That is bizarre. I would make sure they are trying it with no code.py. A couple of q's: Are the files in CIRCUITPY gone after the reload of the cpy .uf2, or are they stil there? I would suggest reloading, leaving the power on, and doing a storage.erase_filesystem() and see what happens, including after unplug/replug.
If the CIRCUITPY filesystem gets reset on each reload, then there may be something broken about the flash.
Ok, thank you.
i.e. I am wondering if something in code.py is bringing it down
Got it. I'll ask.
@tulip sleet Alright I replied and asked the questions, and asked them to do erase_filesystem(). I'll let you know what comes of it.
I'll subscribe to the topic.
That also works.
🤦 I did an erase_filesystem() to make sure I described the process properly. Then dumped code back on my board, and wondered why it wasn't running. Looked at the serial output on the tiny display and saw it said something about adafruit_dotstar and thought, oh I must have misspelled it, it doesn't look misspelled though.... no, Kattni. There's no libraries on the board anymore because you erased them.
@tulip sleet Wait, have we added the thing that will break the 6.x .mpy lib files to CircuitPython yet?
I'm running the latest of main as of yesterday as Limor requested. Libs are still working, so I guess not?
there are built mpy-cross's in https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/mpy-cross/
we build one on every pr
Oh snap.
Perfection.
Thanks @tulip sleet! I would have fought with building it for no reason 😄
you can add a CFLAGS_INLINE_LIMIT = 35 for japanese too
Consider the following wording:
the following is the prevalent method of documenting parameters
This might sound better as Documenting Parameters.
To include references to CircuitPython modules, cookiecutter creates an entry in the
Thank you for the updates! I have suggested some simple tweaks to the wording below.
any reason the Matrix Portal page doesn't have a UF2 bootloader section?
https://circuitpython.org/board/matrixportal_m4/
@tulip sleet @slender iron I agree, I'd rather just merge it in now. Maybe we can follow up with an issue for the NRF stuff @analog bridge noted was out of place.
@tulip sleet I believe it's just waiting on your review approval/dismissal
Would you mind fixing microcontroller.pin as well? The list is here: https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/common-hal/microcontroller/__init__.c#L268
I agree we should fix this, but let's open a new issue to do that, so this is not blocking the other sleep PR's
@ionic elk have you tested then NRF PR pretty thoroughly, both real and simulated deep and light sleep?
Most notably, let's address this. https://github.com/adafruit/circuitpython/pull/4236#pullrequestreview-615739225
We are merging with this outstanding to unblock some other PR's.
@tulip sleet Yeah, I've tested fake/real light/deep, it all works fine.
The only thing that's weird is that it doesn't keep a timer through real deep sleep, so it does the USB delay every time
Then I will just dismiss my review. I don't want to go through it again. Could you open an issue about that?
Not a huge deal for long deep sleeps, but something to fix later I think
Sure
I'll open issues for anything remaining
@ionic elk can you also look at the "hidden" comments, and check them all and resolve them to make sure they have been addressed? That is necessary to unblock the merge.
@tulip sleet ok. @analog bridge's serial.c issue is not resolved but I'll open an issue for it
@ionic elk #4680 covers that
is that #4680 above I just opened
Oh sorry I missed that
I kinda glaze over the github bot sometimes
I think we're set, if you're able to dismiss now
Sorry for the false comments in my original post, which would be in your email. Instead, look at the comments here.
This is nicely cleaned up. I think TimeAlarm can be simplified to use mp_hal_delay_ms() in light sleep, and to use a prescaled RTC with System ON in deep sleep. Are those things you think would be easily doable, or do you want to pass that on to someone else? If the latter, I think we might disable TimeAlarm for now until it's completely implemented.
Thank you very m...
@ionic elk bang. merged.
@jun2sak we've opted to merge this to unblock the other sleep PRs. Follow up cleanup work is being tracked in #4680
@tulip sleet They replied. Not the response I was hoping for, which is to say, I was kind of hoping it would fail because that's an easier situation than troubleshooting this weirdness.
@tulip sleet Great, thank you! I will clean up the STM32 PR given the new changes, should be done today pending no unexpected disasters
They could try another machine, like a Mac or RPi. The fact that Windows doesn't see it at all when it's plugged back is really weird. Otherwise I'd say just replace, it's cheap, and our time is worth something.
Agreed. I'll ask about another machine, and then replace it regardless. Thanks!
@slender iron ^^
When resuming from light sleep, the code crashes with this error:
Traceback (most recent call last):
File "code.py", line 44, in
File "/lib/adafruit_funhouse/__init__.py", line 122, in enter_light_sleep
AttributeError: 'PixelBuf' object has no attribute '_transmit'
I'm not sure what happened since I had previously tested this, but will fix it as soon as I can figure out what is going on.
@gilded cradle Folks mentioned that _transmit error yesterday on QT Py M0 Haxpress and Saola.
Wrap values from pulsein when the maxlen is exceeded. No error is raised - this in accordance with the PulseIn documentation.
Thanks @idle owl. I noticed it on the FunHouse.
Simply wanted to make sure you knew it wasn't FunHouse-specific.
Yes, that's helpful. I'll make a note on the issue.
According to @kattni, this issue has been reportedly been seen on the Saola and QT Py M0 Haxpress. I observed in on the FunHouse.
I'd do an array or bitmask
combinatoric enum will just get bigger and bigger
This appeared for me after 7.0.0 (Saola, but suspect it isn't port-dependent), never saw it in 6.2.0 on any device.
I didn't touch the init.c, because I suspect that some pins are intentionally left undefined. If it is not the case, I'm happy to add PB2[4-9] to the file. One concerning point: the former fix required 268 bytes of ROM space, and the latter requires another 132 bytes. Is it worth it?
I didn't touch the
__init__.c, because I suspect that some pins are intentionally left undefined. If it is not the case, I'm happy to addPB2[4-9]to the file. One concerning point: the former fix required 268 bytes of ROM space, and the latter requires another 132 bytes. Is it worth it?
I don't think it's intentional. It's just hard to track in the datasheet. Boards that need more space can use the IGNORE_ macros to turn them off.
Ya, I think the space is worth it.
Thanks!
@onyx hinge that was a lot of wires! I now have the ov7670 working on the pico! Thanks for the examples!
🙂 You found me 😆
@onyx hinge when you have a chance I could use your help fixing an re test
@slender iron sure, what's up?
1.12 adds more test cases to ure1.py and one case fails
oops
@idle owl Question, During the weekend I want to go back and revise that we have the note regarding the pins in board.I2C, Do you want me to leave you all the approvals for monday (if any) or do you want me me to auto-approve?
3 tests failed: builtin_override qstr_limit ure1 specifically looking at the ure1 failure?
I tried looking at it but don't know how to fix it
ya, I have a fix for qstr_limit already
Always worth having another set of eyes. Please leave them for me.
I have 6 tests failing. weird you only have 3
will do, by the way this morning I saw that indeed the community_bundle is aleady in there, does not know how.. 🙂 but is ok i guess
did you do make coverage_test?
Right?! I have no idea either. But it's good to have.
Yes, and it was me indeed, so good at least Scott was reviewing those changes at that time
Like I said, we can always revert if necessary. But it worked out!
Yes, thanks Kattni
@slender iron Do you know what Winbond chip ships on the Itsy RP2040? I can't read it and I need the dimensions. I figured you might know with your massive flash collection.
@slender iron is it possible the change to extmod/re1.5/compilecode.c just got lost in the merge? ebf8332104c1
I think it's the XSON package
Right on thank you
no, that breaks it different/worse
right, I think you changed our version in a different way
I'll keep looking into it and let you know.
I was about ready for a concrete diversion anyway
thanks!
@tulip sleet Replacing that person's QT Py RP2040. Here's hoping it resolves the issue.
What do you think of putting additional names for the 40-pin header ?
I filed that after somebody asked about missing pins in the discord, but I don't have the board to check: #4586
The dimensions fit the silk perfectly, so yeah that's correct.
👍
Thank you for the help.
np
@kattni Chnages were done accordingly. Thanks for reviewing.
@jposada202020 Thanks for persisting with the fixes!
@slender iron OK I sent you a pull request but feel free to incorporate into the merge commit
remaining test failure here is 1 tests failed: builtin_override
huh, not here. Is it intermittent or consistent for you?
its very weird
it fails from run-test but the output looks ok when I run it directly
oh that's a skip here
what command are you running?
"./run-tests" in the tests/ directory
I'm running make coverage_test from the unix port dir
yup yup
3 tests failed: builtin_override mpy_native vfs_fat_fileio1
k, that seems like where I'm at
OK, I'm going to step away but I can work on one of them a bit later.
(I have two other failures due to me comparing against 3.9)
the first and third may be related
@slender iron sorry to interrupt, i have a q about using storage_allocations to save the state of some Python objects across VM instantiations. When the heap is torn down (cleanup_after_vm()), immediately after that, would it be safe to assume I can still copy heap objects out to a storage_allocation? (The point of this is approximately to save and restore usb_hid.devices between boot.py and code.py, though it's a tiny bit more complicated than that).
I originally tried to make a storage_allocation of the right size while the heap was alive, but that's not possible. I could always make a large-enough storage_allocation by limiting the number of devices, but if I don't have to do that, it would be preferable.
the q is really just if after the heap it freed then its contents are still viable to copy or not
or if it might immediately get smashed by somethign
ya, I think so. teardown doesn't blank. you just risk allocating something over it
right, but maybe i can do it right away. I'll see if i feel comfortable about that, thanks
👍
Did something just change with MP_OBJ_IS_TYPE?
My builds for NRF and STM32 use it in uppercase, and are suddenly failing... it's not a hard fix, but how did it get past CI on the NRF PR we just merged? I built and tested that just yesterday
I think the MP 1.11 update moved all the macros to lower case. That may have just been merged
So it was... is that just a CI thing? I guess CI ran before that was merged, and then it didn't re-run before we put NRF in
so there's just a little window of time where a PR can actually be failing CI but look like it's ok
the fileio1 issue is related to fast seek but I'm not sure how
ya, some projects do require a latest merge CI pass but our CI is costly
so I think it's better to just fix it when it breaks
yeah that's ok by me just wanted to see if this was a broken thing or just a general risk
that depends on what you are going for 🙂
I think for us, it's just a risk we're ok with
I'm going to hotfix NRF then so it's not broken
kk, thanks
A change to the macros introduced in MP 1.11 snuck past CI on #4236. Fix should un-break the NRF builds.
@slender iron I'm back if you want me to see if I can figure out the fileio1 thing..?
er wait is it passing now?
@ionic elk I will merge as soon as it builds right
after pulling from you I have 2 tests failed: builtin_override mpy_native
debugging mpy_native, it looks like it arrives in mp_native_relocate pointing 1 byte earlier, at b"\x04" # bss, 4 bytes instead of b"\x03\x01\x00" # dummy relocation of rodata, which causes a write through a NULL pointer
@onyx hinge yup, I fixed fileio. I'm taking a break for lunch and a walk so feel free to look at the other two. 🙂
@slender iron fix for mpy_native https://gist.github.com/feb8a0e129ca44937238a11ef9e734f2
builtin_override: Setting builtins __build_class__ back to its initial value is not quite working for some reason
Wheeeeeeeee MpyError: Incompatible .mpy file. Please update all .mpy files. See http://adafru.it/mpy-update for more info.
Wait, what? -bash: ./mpy-cross: Permission denied Since when?
just chmod +x
Do I need to chmod the mpy-cross file? Or am I supposed to be running it as sudo?
Ok thanks
the download does not carry those permission bits
Oi.... I had to give it permission through System Preferences too. MacOS is NOT happy. Heh.
There it goes. Finally. Thanks Dan!
our evil non-verified executables
Pretty much.
At least I'm running into it now, so we know what to tell folks in the near future.
Rainbow!
(It worked.)
is this a small board? Maybe in other cases you can get away with the original .py's
Yeah I thought about that after I went through that whole process. It is the opposite of small. Itsy RP2040. Definitely could have just used the .py. 🙄
But, Limor wants me running latest for everything I do moving forward, so I'll need to mpy-cross things soon enough.
i wonder what the breakpoint is recommending the py source bundles instead of the mpy bundles. mpy is always faster and less fragmentation, at the cost of more complexity
Well when we're making the mpys, there's no reason not to tell folks to use them.
but, we didn't start with RP2040 boards... Yes, I am just thinking about an alternate universe
But when expecting folks to make their own mpys.... good question.
Yeah, exactly.
I mean we had to start somewhere. M0 was it, and we can't simply ignore them now. 😄
As much as there are days I would love to.
@idle owl Question 🙂
Answer!
jajaja
What's up?
Did you validate the standard on how to showcase adafruit products in the libraries?
Probably not. How do you mean?
there are a lot of different ways in the libraries, now that I am going back to verify the board note I would like to do also that
so for example
Ah, right now they're all different is what you're saying.
And you want to know what's best.
* Adafruit `BME280 Temperature, Humidity and Barometric Pressure sensor
<https://www.adafruit.com/product/2652>`_ (Product ID: 2652)
* Adafruit `BME280 Temperature, Humidity and Barometric Pressure sensor
<https://www.adafruit.com/product/2652>`_
* `Adafruit BME280 Temperature, Humidity and Barometric Pressure sensor
<https://www.adafruit.com/product/2652>`_
Adafruit BME280 Temperature, Humidity and Barometric Pressure sensor
<https://www.adafruit.com/product/2652>
Ok, I'm unclear on what the backticks are doing.
All render different
Right ok
the backstick will indicate where the hyperlink will start
The last one, does not have even so only the adress
I know what the asterisk is doing at least.
the underscore will indicate the end of the hyperlink
Ok.
I like the first one, but is not for me to decide
The second one is nice too
I can render all and put a picture here
I think a combination of the first and third one? * `Adafruit BME280 Temperature, Humidity and Barometric Pressure sensor <https://www.adafruit.com/product/2652>`_ (Product ID: 2652)
I think the whole name should be a link, it is a little odd to leave out only the "Adafruit".
That would be great.
Thanks!
Ok, I think leave out the 's at the end of Adafruit, and the : (colon) at the end of the URL. And go with the first one.
Does that make sense?
I will verify, give me 1 minute
Yeah! I think that works. What do you think?
@jposada202020 One PR workflow thing: Each commit you push via the GitHub web interface causes a re-run of all the jobs. Could you do make the changes, or instead use the "Batch suggestions" feature so that all the changes are put together in one commit? Thanks.
@dhalbert no problem. Will do thanks for letting me know
@slender iron https://gist.github.com/82147a70aadf7fcab9ecc938cab9144a another fix for ya
now the first set of tests pass, but the threaded tests just failed...
1 tests failed: thread_exc2
make: *** [Makefile:261: coverage_test] Error 1
aha, that was trivial
thanks @onyx hinge! I'll integrate it shortly
@slender iron do you want PRs or are the gists okay?
Read that as grits.
I didn't find any info on whether the old mpy are compatible with the new versions of circuitpython, I assume they are ? (1.11 switched to version 4 of mpys)
gists are fine. I applied the first one by hand anyway
Not anymore! Latest requires a new version of mpys.
Or at least it did for me just now.
ah ok then
thread_exc2 fix: https://gist.github.com/3f8052071ee3187b6b141fbb3650f065
@slender iron ^
OK now make coverage_test completes successfully
Some info on mpy versions - https://docs.micropython.org/en/latest/reference/mpyfiles.html
@onyx hinge looking at your first patch, you set ASYNC to 0x00
oooops
which will break some of our async stuff
ya, 1.13 has async stuff in it as well
do you mind just manually correcting it?
they do
anyway I pushed but didn't create a pull request from my branch (updated with ASYNC at 0x80): https://github.com/tannewt/circuitpython/compare/merge_1.12...jepler:1.12-more-fixes?expand=1
tests/import/mpy_native.py: b"\x70" # scope_flags: VIPERBSS | VIPERRODATA | VIPERRELOC
tools/mpy_ld.py:MP_SCOPE_FLAG_VIPERBSS = 0x40
``` so 3 times, one in C, one in py, and one implicitly in py
@tulip sleet Gah, I guess I realised that about individual commits to the core, but I wasn't thinking about it. I will be sure to include that in any core reviews I do with multiple change requests. Sorry about that!
NeoPIxel works fine on latest for me. What were folks doing when it was failing with the _transmit error?
@onyx hinge it looks like async_await fails when FLAG_ASYNC is 0x80
I'm looking at why now
It seems nicer if our flag ordering matches theirs
ya
../../py/emitglue.h: mp_uint_t scope_flags : 7; not enough bits
ah
mp_uint_t kind : 3; // of type mp_raw_code_kind_t
mp_uint_t scope_flags : 7;
mp_uint_t n_pos_args : 11;
const void *fun_data;
``` can increase it to 8 , there are currently 11 bits left out of 32
"interesting" that up to 2**11 positional args are supported. why so many.
¯_(ツ)_/¯
thoughts? ```c
uint16_t kind : 3; // of type mp_raw_code_kind_t
uint16_t n_pos_args : 11;
uint16_t reserved : 2;
uint8_t scope_flags;
could make scope flags 16 then too
just the basics, like
import board
import neopixel
pix = neopixel.NeoPixel(board.NEOPIXEL,1)
pix[0] = (0,255,0)
It seems to leave the struct the same size @slender iron so from that viewpoint it's fine
but right now, on QT PY Haxpress, latest (20210428-d4d96bb) gives me CircuitPython core code crashed hard. (fresh from erase_filesystem())
Odd. The only difference in my code is I did not specify a particular pixel.
it'll simplify the loading code too
you could eliminate the bitfields altogether in the same 4 bytes, couldn't you? uint8_t kind; uint8_t scope_flags; uint16_t n_pos_args;
yup
This code makes it red, then green, then blue. I also ran rainbow code. No errors.
oh yeah pix.fill() works on the version I had the _transmit error
(using the .py in both cases)
Ok, specified a pixel, and got the error.
With a .mpy I generated a little bit ago from the .py.
Probably worth mentioning on the issue.
Wait a tick.
I do specify pixels in the rainbow code.
Curiouser and curiouser.
Mining the bitcoins, one MPY at a time!
I'm having trouble totally understanding what's up with the mpy stuff - if I want Neopixel support while testing my branch off current main, how do I do it? Doesn't seem like the library file by itself works either
This is something I've been thinking about for a bit - ever since Jeff E. showed off the "Convert a font to BDF" (I think? or maybe "from BDF") site.... Is something where a user could upload a .py and get a .mpy file something that might be useful? Or is downloading MPY-cross and running it simple enough?
It's pretty simple. But it is a command-line thing, and not everyone is comfortable there. Fact is, once there's a 7 release, we'll be generating a .mpy bundle, so it's a non-issue. And folks that are comfortable living on the bleeding edge of development, should be ok with running mpy-cross if they need to.
fill does not cause the bug in the same version I encountered it:
Adafruit CircuitPython 7.0.0-alpha.1-844-g9e183bbbb on 2021-04-27; Adafruit QT Py M0 Haxpress with samd21e18
>>> import board
>>> import neopixel
>>> pix = neopixel.NeoPixel(board.NEOPIXEL,1)
>>> pix.fill((0,255,0))
I say "should" not in a declaratory sense, but in the sense that they're probably ok with venturing into the command line even if they've not dealt with it before.
Sorry for the late intrusion, but one thing I was thinking is that it might be useful to use the adafru.it/<PID> URL shortener for product links. That way they would always end up on the product page if the URL structure should ever change.
What made me think of this is that those are the URLs that are on the individual product packages - though space there is at a premium
I genuinely had no idea that there were short URLs for products.
I'm running into this now that all the 6.2 mpy files are deprecated for 7.0.0
That's very true - very good points. I was thinking more those who was running into space/memory constraints for their projects on the devices, but that might also be a "if size is that tight, this may not be the right board for the project". 🤔
Well folks who are writing their own libraries and so on should definitely be able to run it. I mean, you download a file, and then for easiest use, put it in the directory with the file you want to mpy-cross, and type ./mpy-cross file.py (at least on MacOS). It's not difficult.
Very true. Glad I asked, before I started a solution for a not-a-problem!
Thanks for the insight! 🙂
You're entirely welcome! I have wasted plenty of time fixing things that shouldn't be.
Those rabbit holes are really quite enticing!
@tulip sleet NRF hotfix CI is green
Also STM32 is re-tested and all set, no pressure on that though
I've re-tested this with all the new 7.0.0 and NRF stuff merged in - all sleep types and modules are still working.
it looks like the latest mpy format is hex encoded bytes. do we want to make them proper binary files?
i'd think so. hex encoding for small filesystems, why?
i wonder if it got changed back
I think the version from 1.12 is the latest
@vale spire any idea about mpy not being binary? 👆
@slender iron I don't see that. I did an mpy-cross built from the tip of micropython, and it produces binary
oh, it could be my editor being fancy
false alarm @vale spire 🙂
@onyx hinge sound "prelude" encoding in bc.h
oh that is complicated looking.
does that break the things we were talking about doing with the structure?
I think if I do renumber viper I can have mpy include 5 bits
just gotta update the other spots
@slender iron was skimming release notes and saw this: gc: add gc_sweep_all() function to run all remaining finalisers
Maybe we want to try that at vm shutdown
👍
@anecdata Great work on this. I'm following your pull request and look forward to helping with testing.
@RWhite-EDR Actually you could starting know if you download the firmware built for your particular board in the PR
https://github.com/adafruit/circuitpython/pull/4650
Here
https://github.com/adafruit/circuitpython/pull/4650/checks

If you already knew ignore the previous message 😄
Hey @idle owl could you trigger CI for my PR? https://github.com/adafruit/circuitpython/pull/4677
i updated to try and see if I got the make command right for doing Ladyada's suggestion for the JA build failing due to size
Running now.
Thanks @mental nexus
Hi, I have a question, I got a qt py and a TM 1637 7 segment display, got it all wired up. When I put the TM1637 file in the /lib folder, then in the code.py folder try to import it import TM1637 it does not work. I've narrowed it down to the import statement which leads me to believe it cannot find the file to import.
Referencing this github repo: https://github.com/bablokb/circuitpython-tm1637
hey @bright imp this channel is intended for Circuitpython development discussion, I saw you posted in #help-with-circuitpython
you mean the language itself not working with it?
I just wasnt sure where the best place is to post, feel free to delete if you'd like
I can't delete, we just try to reduce cross posting
i don't think that library is maintained by Adafruit
did you get it from the community bundle?
The lib im trying to import is from that github repo, but it seems to not be able to import anything. Even if I put a simple class in the .py file under /lib it wont import it
I can delete my post if you would like, lmk
Let’s take this back over to the help with circuitpython
👍
@ornate breach you need your workflow kickstarted? I seem to have a button for that
Yeah, I think I got it fixed now to pass
no mpy-cross 7.0 for windows binary?
The pin names of GP* come from Raspberry Pi, and I have no idea of their use cases. Defining I2S_* pins will be convenient when using audiobusio module. However, I also wonder if it may not be necessary to define aliases of those pins used as a group (such as RTL_* and I2S_*), as far as they are accessible in other ways. Which option do you think is suitable?
- Add I2S_* definitions to board module.
- Remove RTL_* definitions from board module (only DAC0/1 remain)
- Others
In ad...
FYI -- I was able to "workaround" this but using adafruit_pypixelbuf on adafruit_dotstar instead of _pixelbuf
That is, in adafruit_dotstart, just import adafruit_pypixelbuf as _pixelbuf
It now works with 7.0.0 (tip of main)
Something is still amiss. Hmm
@tulip sleet got a minute for a bootloader question?
sure, but if it's ESP32-S2, I'm no expert.
may be more general -- I amnually loaded thetinyuf2 bootloader from the repo to a funhouse. Should I next copy over the update bootloader as well?
I'm still confused by the role of the update_bootlaoder?
I'm not sure about the tinyuf2 update, but I would assume it's just to update the bootloader to a newer version. So if you've already loaded the latest, I wouldn't see a need to update it.
are there version numbers for each?
ah -- ok so it just does the update, it does not modify the currently loaded bootloader
I would think with the name "update_bootloader", it does update the bootloader