#circuitpython-dev
1 messages · Page 407 of 1
If this was directed toward my question about the sensor, it is i2c, so just a python library using busdevice and register.
There is this but it is noticeably out of date: https://learn.adafruit.com/extending-circuitpython
Excellent! Now I have some things to read instead of blundering through the code by trial and error quite as much.
Thank you!
Yes sorry forgot to hit reply. There are a lot of libraries you could use as a template
I have looked at the AHTx0 (quite familiar to me) and the mplrs (it's a pressure sensor) libraries. I found the learn guide for creating a module, so I figured I start with that. Then grab the datasheets for the existing and new. Reverse engineer the old, cross-reference the new, and build/test. The sensor is the SDP31 pressure differential sensor.
Sounds reasonable to me. I know the adafruit_register module took me a bit to really get but really easies writing i2c sensor libraries
it's very meta
In the core, what’s the preferred method for printing a “Warning” to the user and keep running (but not causing an Exception and stopping execution)?
We don't really have any examples of this, because the user might not have a serial connection. And if you don't control when it gets printed, you might print it many, many times, say in some loop that causes the warning over and over
what did you have in mind?
So, 2 hours later, I got the results of the CI run on my first pull request. All of the test runs succeeded save for one, which failed with this error:
Error: Build sparkfun_redboard_turbo for ru took 34.35s and failed
make: Entering directory '/home/runner/work/circuitpython/circuitpython/ports/atmel-samd'
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
253708 bytes used, -12 bytes free in flash firmware space out of 253696 bytes (247.75kB).
11900 bytes used, 20868 bytes free in ram for stack and heap out of 32768 bytes (32.0kB).
Too little flash!!!
make: *** [Makefile:391: build-sparkfun_redboard_turbo/firmware.elf] Error 255
I’m not sure what to do next. Can someone help aim me in the right direction? This doesn’t seem like an actual failure with my code, but I don’t know what to do to fix it.
Did you see this part:
253708 bytes used, **-12 bytes free **in flash firmware space out of 253696 bytes (247.75kB).
So your build on that particular board is short 12 bytes with your new code in. Not all that unusual on smaller boards
Yeah. So what do I do about that?
What is your PR doing? sorry not familiar with it
It’s adding a check to the neopixel code so if you try to call show() on a neopixel after you’ve called deinit() on it, an exception will be raised instead of the show() silently failing with no message (or in some cases with a crash).
it means that board was probably very close to using all flash before, and your change just pushed it over the edge
I'm assuming neopixel is important for that board so just seeing if maybe something else could be turned off. But while I can suggest I wouldn't want to decide
@viscid pine That was my thought too. I just haven’t a clue what to do about that.
probably someone will help you disable some modules on that redboard to make some space
To see what is included with the board builds you can look in the ports/atmel-samd/boards/boardname/mpconfigboard.mk file
That would be great. And on the good side, this is my first PR and it passed 277/278 of the CI workloads on the first try, so I guess that’s a victory. 🙂
if you look at say the feather_m0_rfm9x board vs the sparkfun_readboard_turbo you can see where the feather turns off the full build (CIRCUITPY_FULL_BUILD = 0) and then enables certain modules only.
so in theory you could try turning off something like USB_MIDI and that may save the space. You could try doing a build on your own computer against the sparkfun board to see what could work. Then make a comment in the PR
Hopefully that makes some sense
It does. Let me see what I can come up with. Thanks!
Feel free to ping me if you have a question I should be around for a bit
Thanks!
also it is for a particular language (you can see that in the log). so do make ... TRANSLATION=ja or whichever language is overflowing.
The English translation is smaller than others
It looks like it was the Russian translation that failed.
Note that feather board doesn't have spi flash, the sparkfun one does. Full build would probably still be ok just with one or two modules turned off
Good point. I couldn't quickly find a different example
audioio and audiobusio are ones i'm seeing disable in a few other boards
but i'm thinking, if this one samd21 board went over then others are likely to soon too, maybe some things should be disabled for all samd21 board with small flash
sorry if im overloading you with info, im thinking out loud a bit
Seems likely. OK, trying again without audioio, audiobusio and USB MIDI - we’ll see what happens. And no problem - I’m happy to help solve a larger problem and not just my one bite-sized “first contribution” PR. 🙂
random trivia for anyone here: if you ever need more ram on a board without much ram, disabling usb midi helps a lot due to statically allocated buffers
(simply disabling it in boot.py doesn't do it)
Interesting, and good to know. Change pushed, waiting for the 73 million CI runs again. 😂
were you able to get it building locally?
The “Contribute to CircuitPython with Git” Learn guide probably needs a note somewhere that for contributions to CircuitPython itself, the CI process takes a lot longer than “a few seconds to several minutes”. LOL
@viscid pine Yup. I built it for that board and translation, and I can’t imagine it didn’t save the 12 bytes I needed. But we’ll find out soon enough.
And this is a good learning experience for me when I try to tackle larger issues.
another thing about the huge ci is that it amplifies random intermittent issues
Yeah, for sure.
A bunch of boards on my recent PR failed with Error: Internal Server Error occurred while resolving "actions/cache@v2". Internal Server Error occurred while resolving "actions/checkout@v2.2.0". Internal Server Error occurred while resolving "actions/setup-python@v2". Internal Server Error occurred while resolving "actions/upload-artifact@v2"
some internal part of github actions just falling over
Oops.
I am going to turn off something else instead. This board is a lot like Metro M0, and there is something easier to turn off to gain small space
@tulip sleet Sure thing. Just let me know what you need me to do and I’m happy to do it. I don’t even know the range of things I can turn off, so I’m sort of improvising as I go along right now.
Does the CI process build every combination of board and language that exists in the ecosystem?
if the change is only in a particular port or board, it rebuilds only that one. Otherwise it rebuilds the whole Cartesian product
Wow. No wonder that initial CI run takes a long time!
it is like 2500-3000 builds
Each language doesn't have to recompile every file, only the files with messages
That’s still a lot of stuff.
could you make a "dummy" language with the biggest translation for each string and build that?
or does building every language do more than just testing for size
the strings needed vary because it depends on which features are turned on or not
not per language, but per board
This process is making me wish we had a CI process for the work I do for my day job. (I’m a Data Engineer maintaining a date warehouse solution for a healthcare company, and our current platform’s tech stack is not really amenable to implementing a CI solution, unfortunately. Which hurts my heart, but I can’t change it.)
I’ve got a build running that allows access to the REPL displayio group, so you can view the REPL screen on your display at the same time as the result of your other displayio code. I know its dangerous to toy with the REPL since you could mess it up and you won’t get feedback as to why it’s gone. So if your code ends or you call display.show(None) after you’ve placed the REPL group into another group, I want to rip it back out of any groups and put it back where it belongs. Anyway, I thought it would be useful to raise a warning to the user that something dangerous happened to get back access to the REPL. Probably not a very important use case to add something new.
CircuitPython version
Adafruit CircuitPython 7.2.0-alpha.1-243-gf4872d346 on 2022-01-29; Raspberry Pi Zero W with bcm2835
Board ID:raspberrypi_zero_w
Code/REPL
"""CircuitPython Essentials NeoPixel example"""
import time
import board
import neopixel
print("time.sleep(20)")
time.sleep(20)
pixels = neopixel.NeoPixel(board.D18, 20, brightness=0.3, auto_write=False) # Raspberry Pi wiring!
RED = (255, 0, 0)
YELLOW = (255, 150, 0)
GREEN = (0, 255, ...
Ok, next problem. My new code failed the pre-commit formatting test in a bunch of files under tests/circuitpython-manual but I didn’t change any of those files and “pre-commit run --all-files” passes locally. Waiting to see if the rest of the CI run succeeds.
I am making changes in your PR. you don't need to do anything right now
you can pull my changes
as a maintainer I can add commits to PR;s
Ok. Thank you!
I turned off atexit and getpass for these SAMD21 "full builds" (which cannot be so "full")
Ah. Nice!
there are other builds that are very close to full (a few dozen bytes away) so it was inevitable
So pull the adafruit main branch into my local repo?
just pull from your own branch
but I am seeing the same precommit issues. It's because the black formatter just published a new version today.
like a few minutes ago, I think
If I just do a “git pull” in my local repo, git says my working branch has no tracking information.
Displaying a flash of the logo and console on startup has nothing to do with showing errors on a program crash; the first is not necessary for the second.
Echoing what @zestyping is saying, it's pretty annoying and looks a little...beta-ish? don't understand why we have to see blinka by default.
your working branch should be attached to the remote branch, hmm. Well, don't worry about it at the moment, I have kind of taken over things here.
you might google that
you should be able to recover
Ah. I figured it out. For some reason when I pushed the local branch to my repo, The local branch and remote branch were not associated with one another. Got it fixed now. Weird.
black decided to put spaces around the ** operator in Python now
Lovely.
Extra changes:
rutranslation failed on one SAMD21 board with external flash. Other builds were very close to overflowing. Disabledatexitandgetpassfor these SAMD21CIRCUITPY_FULL_BUILDbuilds. This should give us some breathing room.blackwent to version 22.1.0 in the past few minutes, so pre-commit Pytyhonblackchecks were failing. Only issue was it wanted spaces around the**operator.
thanks for being awesome dan
Seconded. Thank you!
Thanks for catching this! And it provoked some other things we needed to as well.
Yay! My first PR merged! 🎉 Thanks everyone for the help!
Congrats!
Thank you! Been wanting to contribute to CircuitPython for a long time, and got thrown for a loop by pandemic stuff and also a major medical crisis last year. Glad I’m able to start doing it now.
just received the new Seeed_XIAO_nRF52840_Sense board and circuitpython doesn't work, nothing on usb or bt, just a few led flashes
how do i go about debugging this?
If you tried https://circuitpython.org/board/Seeed_XIAO_nRF52840_Sense/, I'm not sure what to suggest, but Seeed has forums that might be helpful: https://forum.seeedstudio.com/
https://github.com/adafruit/circuitpython/pull/5877 related maybe
still trying to understand why he changed it to 7.0.1
uf2 doesn't contain sd, had to create my own uf2 from the combined hex file that has the sd
hey! I'm having trouble finding the usb_hid driver or helper for circuit python. I know it comes with the uf2 file but I installed blinka on my rasberry pi pico running micropython and I wanted to send keyboard inputs. I can't find the library I need to put in my folder. So far I put in the adafruit_hid folder in my lib folder but importing usb_hid gives me an error
usb_hid is part of circuitpython, you can't use it with blinka
i'm not sure
Alrighty, thanks for the help though!
And add installation tutorial which contains details to enter the DFU bootloader mode.
Also, add "stretch" the content by adding a list and some breaks.
Tested with STM32 F4VE board
https://stm32-base.org/boards/STM32F407VET6-STM32-F4VE-V2.0.html
Re-configuration the SPI on STM32F407 causes SCK signal to toggle.
This leads to Fast ReaD (0x0B) command failure in check_fs: 0x0B is treated 0x85

/* Find an FAT partition on the drive. Supports only generic partitioning rules, FDISK (MBR) and SFD (w/o partition). */
...
In case others look at this, I got this error when I tried to add a KC.ASTERISK key in my keyboard.keymap = [ [.... Removing that element from the keymatrix resolved the error.
hmm -- latest build of CP won't boot on my PyPortal --- 7.2.0-alpha.1 does boot...trying to narrow it down
beginning with adafruit-circuitpython-pyportal-en_US-20220121-9a353a4.uf2
CP will not boot on my PyPortal.
The previous build /home/jerryneedell/Downloads/adafruit-circuitpython-pyportal-en_US-20220121-f2713af.uf2
boots OK
Same. You’re not alone.
I am seeing this too, doing a bisect
was doing I2C testing on Metro M4
@mental nexus @solar whale atmel-samd build seems to have gone bad on this PR: https://github.com/adafruit/circuitpython/pull/5422
based on a bisect
Various SAMD51 builds have been reported not to work as of right now at the tip of main. They simply don't start at all.
I did a bisect, which says that the problem commit is b6858e4ca7158b68074aef5082a46a1058f42079, which is part of
- #5422
Agreed. That was what I found as well
I have a Metro M4 Express handy if there’s anything I can do to help with testing or whatever.
And an ItsyBitsy M4. Somehow those seem to be the only SAMD51 boards I can find at the moment.
- Fixes #5950.
Before #5422, the singletons for board.I2C() were stored as i2c_singleton, etc. and were NULL if not instantiated. #5422 allowed multiple board, objects, but removed the separate singleton storage slots, and relied on checking whether the objects were deinited() or not to see if they were valid. But all-zero objects were not recognized as deinited() in some ports (which caused crashes). For instance, in atmel-samd, deinited() checked for a pin being NO_PIN ...
Tested on PyPortal - boots OK
Thank you!
Looks like the "ru" build is just a few bytes over on a few of the samd21 builds.
<@&356864093652516868> Reminder that there is a CircuitPython Weekly meeting today. 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! https://docs.google.com/document/d/1YU2kvEr3cFDF6GpmVm_l500xPcxhSu1ox3iXYrL_ZUo/edit?usp=sharing
CircuitPython Weekly for January 31, 2022 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to participate...
Won't be able to make it, but early group hug to everyone! Love this community! 
@tulip sleet Is there a preferred board for asyncio? i.e. I'm going to be templating it and wanted to know if there's a specific board I should be using.
I planned to do it this week and did not think through bringing the right hardware. So I'm trying to sort out what I need. Might end up running home instead, but if I can fake it with stuff I can get from the shop, that would be ideal.
anything other than SAMD21 and similar tiny boards should be fine
Alright thanks
I tested on a Metro M4 a lot
Fair enough
but an RP2040 should be fine too
I'll give it a try on RP2040 so it's more tested that way along with all of this.
My auto-lighting menorah project runs on the RP2040 and I'm loving it! I think my use case does do some networking which I believe is in the pipeline to be more integrated, but otherwise I'm pleased and plan to stick with the Pico!
@ladyada sorry to ping you here but I'm trying to understand this in the context of using a KB2040 on a split keyboard. Both half should be communicating in UART and are linked on the Rx pin. With https://github.com/KMKfw/kmk_firmware/blob/e70ce5f4315db02beb25302f4ce027f739fba99b/kmk/modules/split.py#L111-L118, it means that the (default) left half uses the Rx pin as a receiver end, and the right half uses the Rx pin as the transmitter pin.
Is that code (KMK split module) broken with #451...
@alecharp hi please do not post on an unrelated, closed issue
you can create a new issue if there is a circuitpython bug :)
Sorry, didn't see it was unrelated. Creating a new ticket.
CircuitPython version
Adafruit CircuitPython 7.1.1 on 2022-01-14; Adafruit KB2040 with rp2040
Code/REPL
import board, busio
busio.UART(tx=board.RX, rx=None)
Behavior
Traceback (most recent call last):
File "", line 1, in
ValueError: Invalid pins
Description
On a Sofle keyboard, with KB2040, the two D1 pins of the boards are connected through a TRRS connector (and cable). However, the connection cannot be made.
Trying ...
Thanks for the followup 🙂
I am super late for filling the meeting notes... There is a little risk if I write while someone read. Skip me if it is too draft.
starting in a few minutes; we just finished our internal meeting
Love that keyboard, clicky.
whoops I didn't add my notes yet.
kinesis free style edge split kbd
brb!
Anyone have any last minute news/projects/coming soon for the newsletter?
CircuitPython Weekly for January 31, 2022 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to participate...
That xkcd was pre circup and I won't be surprised if I end up writing the pdm-circuitpython plugin. 🙄
Thanks @CharString! Happy to match the convention.
is a lurky mclurkyface (hi everyone!!!! hope you're all well)
Maybe our standard verbiage should say "and resellers"... also relevant when it comes to international people where it can make a difference to tarrifs.
I can see adding that.
Always! 😄
Yes. I just ordered 4 magtags from Pimoroni... But Brexit slipped my mind... Had to pay some hefty tarrifs. 🤦♂️Also a unified search box for resellers would be nice... I spent quite some time copy pasting in search for stock
Nothing there yet because I'm still setting everything up, but my Twitch stream will be:
https://www.twitch.tv/tammymakesthings
Computer geek, electronics/space nerd, singer/musician, writer/novelist, photographer. Casual gamer (Nintendo Switch). LGBTQIA+ rights are human rights. Black lives matter. Down with racism and fascism. Feminism must be intersectional. Just say no to hatred and bigotry.
I am by no means an expert, but have been streaming weekly for the bulk of the last year. If you run into issues getting set up and are interested, I'd be happy to help where I can or offer up anything I can that you think may be helpful.
Thanks! I appreciate that!
thanks
Here’s a demo of a split screen showing a resizeable REPL/console along with some displayio elements. Perhaps useful as an interactive debug console for graphics.
@solar whale do you have a public GitHub?
Oh, THAT is cool!
That's really neat
That is awesome! I think this could be a great tool to help folks learn the very basics of displayio. The instant feedback and interactivity the REPL is a great way to learn things for some people.
Thanks all!
yes - https://github.com/jerryneedell -- it is not well organized or maintained. I don't keep a lot of my projects on it, but will try to do more and would be happy to put anything you are interested in there.
@solar whale thanks! you work on a wide variety of interesting projects, and it would be interesting to see some behind-the-scenes 🙂
Thanks -- I'll try to be better about putting them in the repo. It's a good habit to get into.
@lone axle Hello! I have a Thing ™️ I'd like to add to your list, but not for today. I want to try to schedule it for next week or the week after since you're hosting the meeting next week - don't want to overload you all on one day.
@lone axle I want to have Eva teach you how to do Adabot patches. Eva's the only one doing them right now, and it's a great task for her when she has the time, but I feel like having others able to do it is a smart move.
So I'm thinking two weeks from today.
Sounds good to me.
Make that 4 weeks. I might be busy two weeks, three weeks is a holiday.
It's not really a rush thing so that's ok.
Is this achieved through a custom build of CircuitPython? I wonder if ultimately we could have some kind of setup in boot.py that could "activate" this split screen mode.
Yep that works for me as well. Sounds good.
I just created a repo for the mlx90640/rfm9x work -- still a WIP but thanks for prompting me to do that!
I put it on my calendar for 3:30pm on the 28th. Eva's on board.
Yep I’m considering a PR in the core to allow this. The code adds public access to the REPL displayio group and adds one function to resize the REPL. Main question to me is whether opening this up is too dangerous since you could lose sight of the REPL. I’ll submit a PR and see what folks think.
Here is the notes document for the upcoming Monday, February 7, 2022 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/1dlQ-p6WYbsgfwqtEoDw7NfvMKG8CntRsvUSQ-n7ZEb0/edit?usp=sharing
CircuitPython Weekly for February 7, 2022 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 th...
I verified this PR now boots properly on the pyportal. Thanks @dhalbert!
This exposes the REPL's display group elements as supervisor.splash. Also, this adds a function to resize the dimensions of the REPL terminal window. This allows the user to view the REPL and console print() output as well as view any display elements at the same time.
Warning: This is somewhat dangerous since exposing the REPL display elements allows the the REPL to be relocated where it is no longer visible.
Here is an example creating a split screen with the REPL at the b...
Problem with countio: I have several Wemos/Lolin S2Mini board. According to the latest CircuitPython page, countio is available on the S2mini. I can import it ok. Unfortunately "Edge" does not seem to be defined. The documentation says there should be a class countio.Edge. When I run
>>> import countio
>>> dir(countio)
['__class__', '__name__', 'Counter']
I poked around in other modules without success.
When I run the example I get
check the docs for the version you flashed
readthedocs shows the latest
there was a change in the api
I am running
Adafruit CircuitPython 7.1.1 on 2022-01-14; S2Mini with ESP32S2-S2FN4R2
Ok. 7.1.X does not have Edge.
Ahhh. How do I find which version is "latest"?
From the download page for the LOLIN S2 Mini I see a 7.2.0-alpha.1. Is that what the latest documentation is for?
it's either that, or the "absolute newset" below that
latest is the repository main branch
you get that if you compile it yourself, or download the builds from ci
I recall a discussion about making it so that (some) Safe Mode occurrences could be intercepted / detected by User Code so it could automatically reset, but I couldn't find it in Discord or Issues. Does anyone know where that discussion was? (it would be a really useful feature)
I haven't worked on this code in quite a while. We've never officially started supporting it with Adafruit-funded folks so it's unlikely we'll get to it soon.
It does look like the rtc module talks to the internal RTC. The place to look is here: https://github.com/adafruit/circuitpython/blob/main/ports/mimxrt10xx/common-hal/rtc/RTC.c
That's the code that configures the RTC of the device. supervisor/port.c may have some clock initialization in it as well. Losing the value may be a po...
Thanks for the references! It does like a good inspiration for synthio and friends.
@slender iron My 2022 post is done, but it's not anywhere accessible yet. I'm not feeling great so I think I'm done for the day. I'll get it up on the blog first thing tomorrow. Wanted to give you a heads up since it seemed like you might be waiting on me.
@idle owl no worries. feel better
Thanks, working on it
Sorry, two more minor things. I suggested conflicting changes to you before wrt the * and kw_only. More folks are using the stubs so think it's worth correcting now.
{ MP_QSTR_i2c, MP_ARG_OBJ | MP_ARG_REQUIRED },
//| def __init__(self, is31: is31fl3741.IS31FL3741, width: int, height: int, mapping: Tuple[int, ...], *,
Why is board.DISPLAY.brightness insufficient?
Sharing a pin between the display and pwmio is tricky internally and I'm trying to avoid us having to do it. (The status neopixel rework made this much simpler.)
I don't think you want to do this. Removing this configures will break cases where the flash is on a shared SPI bus with a device that has different settings. This is rare but possible.
Instead, the port should guard against repeated calls and exit early. https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/common-hal/busio/SPI.c#L216-L222 This protects the SPI from similar issues when used by SPIDevice which also calls configure before each transaction.
Looks good to me! Thank you for the quick fix.
Is D1 only for reception and cannot be used as the transmitting pin? Do this means that the crossing of the Rx/Tx connections have to be done on the hardware and cannot be made on the software?
With busio.UART() yes because it uses the UART peripherals of the RP2040. However, you can use pio to do either UART TX or RX.
For TX, ensure you have the absolute newest version of CircuitPython. I recently added support for a PIO feature used by UART TX. There classes that present the same ...
I like this functionality but I've got some questions:
- Could we add the ability to get the current Group from Display instead of having a separate accessor?
- Could we reset the location of the terminal at a certain point in case things go awry?
- Would it be more versatile to provide the serial input to terminal into userland so that it can create it's own Terminal?
From the description of #5584, the is31fl3741 is supposed to only be enabled for the led glasses board. I found that it was mistakenly enabled by default on all nrf boards.
Also fixed the an uninitialized variable warning that prevents the module from building in debug mode. I don't actually know anything about this device and I just assumed the variable was supposed to start at zero. I don't own the led glasses board, so I was unable to test.
I confirmed the led glasses build still i...
Ok thanks. I've got an iPhone that I tested this with.
Example code (will PR to the BLE repo too):
# SPDX-FileCopyrightText: 2022 Scott Shawcroft for Adafruit Industries
# SPDX-License-Identifier: MIT
"""
This example does a generic connectable advertisement and prints out the
manufacturer and model number of the device(s) that connect to it.
"""
import time
import adafruit_ble
from adafruit_ble.advertising.standard import Advertisement
from adafruit_ble.services...
Feature request based on some discussion in this issue:
https://github.com/adafruit/circuitpython/issues/2694#issuecomment-740624686
It would be very useful to have a mechanism for user code to intercept or detect Safe Mode, and trigger its own reload or reset. Or, have a user-settable indicator not to go into Safe Mode for at least some causes. Ideally we'd want to identify and fix every last intermittent software cause of Safe Mode, but sometimes they are rare and very difficult to d...
Here is a slightly improved version that sets values the other device can read:
# SPDX-FileCopyrightText: 2022 Scott Shawcroft for Adafruit Industries
# SPDX-License-Identifier: MIT
"""
This example does a generic connectable advertisement and prints out the
manufacturer and model number of the device(s) that connect to it.
"""
import time
import adafruit_ble
from adafruit_ble.advertising.standard import Advertisement
from adafruit_ble.services.standard.device_info im...
I can live with the brightness control.
It was the change from prior, and another "pin in use" scenario that wasn't intuitive (to me). The use cases are probably limited (for example, futzing with PWM to make a glitchy-looking display).
If there's isn't a compelling reason to override the complexity in the core, we can close this.
This is a cool feature, and probably faster than approximating it with a partial-screen terminalio.Terminal(which also probably needs some gyrations to get print() statements to be natural).
Thanks for the constructive comments.
- being able to access the current Group would be more general. Yet if you’re somewhere already deep in your display code, it would require you to do a
display.show(None)to access a handle to the splash group. Probably not a huge deal and you could turn off auto_refresh so it would be hidden to the user. Let me know your decision and I’ll make edits. - I assume that when code.py stops that it essentially does a
display.show(None). I’ll hunt for...
Yes, maybe.
But the other device is an IPhone / IPad and IOS connects to a keyboard if the user selects this in the Bluetooth Settings.
The use case is:
The (Blind) user has one Braille-Keyboard and an IPhone and one IPad he want's to pair his Braille keyboard with his IPhone and his IPad.
The user is using Voiceover as the screen reader on both devices to get Speech feedback and maybe a Braille Display to get braille dots from Voiceover. All this works if he also has two Braille Keyboa...
When Scott fixes it, it stays fixed.
I believe this fixes all these ESP32-S2 I2C issues:
- Fixes #5934.
- Fixes #5906.
- Fixes #5871.
- Fixes #5680.
As suggested by @tannewt in https://github.com/adafruit/circuitpython/issues/5680#issuecomment-1024511731, this PR provides a new common_hal_busio_i2c_write_read() operation. shared-bindings/busio/I2C.c no longer calls write and read separately itself, but calls the combined routine.
- On ESP32-S2, the
common-halI2C routines use the new ESP-IDF `i2c_master_device....
I totally messed up my commits. I’ll see if I can enlist help on discord to get the revision sorted out.
@ladyada is this what you'd like: is31fl3741 enabled only on the glasses driver board?
where are the vid/pid of circuitpython boards used?
or more directly, why is it important that they are unique?
The missing initialization is fixed in #5726 which has a lot of changes to the whole structure of the is31fl3741 module. The PR is still waiting to be merged.
As to which boards it is enabled on I cannot remember the initial discussion but an product like https://www.adafruit.com/product/5201 can take advantage of this module as well.
At the time I submitted the first PR I had only been working on NRF boards so had not had the time to test it on other types of boards like ESP/RP2040...
They are used by the host system to identify the board. Similar to how your computer can know it is a Logitech mouse plugged in and process it correctly.
I'm not sure if anything currently checks it or not but if they shared VID/PIDs then the USB host would have no way to differentiate different types of boards
"I don't think it's much of an issue. Mu no longer depends on VID/PIDs to identify boards. "
so mu used to want it for some reason?
I believe to set the mode. I haven't upgraded in forever and it detects a device to change the mode. Someone else probably has a much better answer then I do!
Mu used to depend on the vid/pid to find a board, and its serial port when opening the serial panel to connect to the REPL. Now it uses the Adafruit_Board_Toolkit module
and prompting to switch mode to Circuitpython when detecting a board
Ok, this is ready for another review:
- Created an accessor for a displays
root_group. - Resets the REPL size and position when
display.show(None)is called.
Working on a PR for the "movable REPL", in case you want to follow along: https://github.com/adafruit/circuitpython/pull/5954. Thanks for the encouragement!
arduino still relies on vid/pid, so this may also (I couldn't verify it quickly) help with showing the board type correctly when you're in the arduino environment about to re-program a circuitpython board.
.. no, boards.txt doesn't associate pid 0x8023 with the Adafruit Feather M0 Express, so Arduino environment support may not be the reason.
This is awesome! I have not tried it out on a device yet, but I'm looking forward to it.
Looking over the code and example presented above my only question ATM is around naming.
Is the "splash" term previously used somewhere for this concept (or something similar)?
I have seen it used as the name for a Group object in some example code scripts. But I've always thought that when originally written the object may have been named that way because it was used for a "splash screen" whic...
@dhalbert yep only on the led glasses
@slender iron I have a link for you. It's not live yet because of the tricksy scheduling we have to do so Twitter doesn't freak out, but it should be live in 15 minutes or so. Ping me when you're around, since I imagine it'll be live by then and I'll drop you a link. (That way it's not a 404 here for the next 15 minutes.)
@idle owl thanks! I just got to my desk so feel free to ping me whenever it's live. I'm not in a rush
thank you
Thanks! @gamblor21, I will merge this for now, and we can still work on your PR.
Thanks @FoamyGuy for the good feedback. Per @tannewt comments above I modified the functionality and naming. To clarify, here is the current status of what is added and the names.
display.root_group: the root displayio Group that is currently displayed. To access the “splash” screen group (with Blinka and the REPL terminal output) you first have to dodisplay.show(None)and then procure thedisplay.root_group. If you don’t want that to disturb the display you can turn auto_refres...
Thanks! @gamblor21, I will merge this for now, and we can still work on your PR.
Sounds good. I'll try to take a look later but it probably will not conflict.
@lone axle when you've got time, the james webb api was shutdown: https://forums.adafruit.com/viewtopic.php?f=60&t=187894
Removing this configures will break cases where the flash is on a shared SPI bus with a device that has different settings. This is rare but possible.
I see. I also was not sure about this change. But I was not aware that shared SPI bus use cases are possible with circuitpython.
Instead, the port should guard against repeated calls and exit early. https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/common-hal/busio/SPI.c#L216-L222 This protects the SPI from similar ...
I can add a warning alert that the API data source is no longer active. I wonder if there would be interest in hosting our own copy of the API server somewhere? The location data isn't as relevant anymore but the NASA page does still show temperatures for a few things. If there were a scraper API hosted somewhere the guide code could be tweaked to show more of the temperatures.
Some typo corrections and cleanup to the ESP32 doc
My point is that it's possible now.
I'm not arguing we shouldn't add an accessor to the mac address of a connection. I'm arguing why it isn't a priority.
@lone axle it looks like the status page does it's own call: https://jwst.nasa.gov/content/webbLaunch/flightCurrentState2.0.json?unique=1643741752388
capital improvements!
the unique parameter is the current time
Perfect! I was just thinking: it would be ideal if NASA provided the data directly as JSON.
🙂
I looked a few weeks back when I built the MagTag project but couldn't figure out where the data came from.
Have we done the adding a board.I2C1() thing yet to CP?
it should be in absolute latest
I'm not sure all boards that could use it do though
Fair enough.
I'll keep that in mind.
Nice!
Nope, not all boards do.
You are correct.
QT Py RP2040 does though.
yup there's board.STEMMA_I2C on the QT PY 2040
it should be added to the ESP ones in the same way
Looks like ESP32... yes that.
and add it to to other boards as a simple alias to board.I2C if that's what we want to do
Is there an issue open for this?
I'd like to start using it, but probably shouldn't until it's applied to all relevant boards.
Right on.
Looks a bit more complicated than I'm used to in the core.
I'm sure I could figure it out, but not right now. Need to finish this guide.
Thank you for doing this! It looks good. Nice to be rid of the stop param.
@prplz @UnexpectedMaker This was closed by #5958, and I reduced a timeout, but reopen or make a new issue if you are still seeing slow scan times, and we need something like #5908 (or comment in that PR).
Thank you! This looks good. It just needs conflicts resolved and then will be good to go.
I did start the alias thing, like a year ago, it's basically just adding this line to all the boards that have the stemma connector on the same pins as the I2C pins, but I must be missing a lot now.
{ MP_ROM_QSTR(MP_QSTR_STEMMA_I2C), MP_ROM_PTR(&board_i2c_obj) },
I like that idea. Consistency is good.
Would a safemode.py work in your case? How does this interact with the internal watchdog?
Safe mode is really meant as a "we don't know what went wrong and don't expect to recover". Anything recoverable should be done through exceptions instead.
What version did it work in? Sometimes in early ports we don't have proper pin in use checking.
- One other idea I toyed with is whether resizing the REPL should also forward over any text data from the previous incarnation of the Terminal tilegrid. Currently the tilegrid is obliterated and a fresh one is created. However that would require allocating the new tilegrid memory, copying the tilegrid data that will fit and then deallocating the previous tilegrid. Is it worth this effort/code space to keep the REPL text even when the size changes?
I think this would be way more work tha...
So just making sure for a call to common_hal_busio_i2c_write() the stop bit flag is now gone? (just have to drop it in my PR merge conflict if so)
ya, it's always true now
if you have a case where it's false, then you should combine it and the following read into a write_read
thanks they're just writes so easy fix
I don't recall what I had on originally. Closing this. Someone can re-open or make new if there's a compelling use case.
Thank you for the iteration. It looks good!
The builds are failing because supervisor_stop_terminal is only linked in for boards that support displayio. I've added a suggestion that should fix it.
I agree the term "splash" isn't ideal but that's what I used when I added it. Maybe "serial_terminal" is clearer? I don't care if you change it or not in this PR. The term is only used internally so we're not committing to it.
//| """Reset the CircuitPython serial terminal with new dimensions."""
#if CIRCUITPY_DISPLAYIO
supervisor_stop_terminal();
supervisor_start_terminal(mp_obj_get_int(x_pixels), mp_obj_get_int(y_pixels));
#else
mp_raise_NotImplementedError(NULL);
#endif
safemode.py would work fine. Anything that the user can control.
watchdog module doesn't catch these since the code stops feeding it, nor do Exceptions. I'm not sure if there would be any interactions / complications from having both. Nothing comes to mind.
Most (all?) of my Safe Mode occurrences are intermittent but fixed with a restart. 95% sure it's not power or hardware. The idea is that the device can self-recover with a software restart.
@tidal kiln I need some help with hex addresses again. The base address on the Arcade QT doesn't follow the convention we made the table for, and so I'm confused because it's an ATTiny817, which I thought was a fixed concept in this area, but apparently that is wrong.
They're all tied to GND to begin with from what I can tell. So I assume it starts at the base address and goes up from there. But that means a new table. And me figuring out what the higher-end addresses are in hex.
something like this?```py
starting_address = 0x80
soldered_address_pins = 0b0111 # {first bit not used) A2 A1 A0
final_address = starting_address + soldered_address_pins
final_address
135
hex(final_address)
'0x87'```
Maybe?
Seems like that's not enough addresses
Let me post the current table
It's like this except that it starts at 0x3A instead of 30.
ah, so in my example, the first bit would be A3
So I would need to know what comes after 0x3F and how far beyond it I need to go
the table isn't intuitive to me, because it has the least significant bits on the left, rather than like we do base-10 numbers with the tens then ones moving to the right
after 3F comes 40 of course
Hmm
just like in base-ten
I did it for beginners, I guess. Carter asked for it because of support issues
and told me how to do it
@idle owl ok. back. looking...
I'm confused why this one starts in the middle though.
To begin with.
Same seesaw chip and firmware afaik, so...??
what's the starting address of this new thing?
you're working with this?
https://www.adafruit.com/product/5296
"0x3V"? that's a new one
in the guide... "0x3V -- cut traces A0 and A1"
the one cater linked
oh, sorry, I jumped to this guide https://learn.adafruit.com/arcade-synth-controller/build-the-arcade-synth-circuit
feedback left
Because in the code it's listed as 0x3A through 0x3D I think.
not seeing special firmware build for it:
https://github.com/adafruit/Adafruit_seesawPeripheral/tree/main/examples
there all tied to GND
what base address is it showing up as?
0x3A
At least that worked in code.
I'm not sure I scanned.
I can.
I2C addresses found: ['0x3a']
Traces are intact.
Thanks!
just an aside, due to routing constraints I assume, some boards have the addresses in AN ... A1 A0 order, other boards have them in reverse A0 A1 ... AN order, so yeah definitely a chart or aid is super useful in guides
Hmm oki
You beat me to linking it.
Yeah.
So, back to part of the original question
Do the extra addresses follow on up the line of hex values?
yes
yep
Thanks, @tidal kiln . And thanks @crimson ferry for popping in as well!
@tidal kiln Worth making a second table?
yes please
I'd need you to verify it.
so need a table that just maps jumpers to "weird number that starts with 0x thing"
so I see where you're coming from.
Should I flip the table per anecdata's suggestion?
At least I think that's what they were getting at
ooh tough call... natural place order, or match the order on the silk
I think it's as simple as dragging columns around, FWIW.
Silk is probably best
but Carter would know better
i'd say keep as is. agree it's confusing for those that can read hex/bits naturally. but target audience is opposite.
yep
keen. Thanks.
@tidal kiln Might ping you with the guide copy as well, since I'll need to update it to reflect the current starting address. Or wait. Should I even bother with that whole explanation since the table is there? Are folks learning from it? Or is it simply confusing?
you should mention base address, since that'll be the default that needs to be used
the table would be used for any multi-board configs
do you have a code snippet near table?
that shows passing in non-default address?
"cut jumpers as you need/wish. use table to figure out resulting ADDR. use that value in call to begin()"
No, it's on the Pinouts page.
The examples are on the CP and Arduino pages.
Or will be anyway.
You have to pass in an address regardless or it doesn't work
oh yah. would need CP code snippet also.
so the examples will cover that
I don't think it makes sense on the Pinouts page
But mebbe am wrong on that.
Could link to the examples on the respective code pages
CP will have a two-board example
JP's Arcade Synth guide will stand as the multi-board Arduino example.
Still have to fix the Arduino example to match the silk.
@tidal kiln I went with the same thing as the other seesaw QT breakouts: ```In the center of the back of the board are four address jumpers. These jumpers allow you to chain up to 16 of these boards on the same pair of I2C clock and data pins. To do so, you cut the traces between the the two pads.
The default I2C address is 0x3A. The other address options can be calculated by “adding” the A0/A1/A2/A3 to the base of 0x3A.
A0 sets the lowest bit with a value of 1, A1 sets the next bit with a value of 2, A2 sets the next bit with a value of 4, and A3 sets the high bit with a value of 8. The final address is 0x3A + A3 + A2 + A1 + A0 which would be 0x49.
If only A0 is cut, the address is 0x3A + 1 = 0x3B
If only A1 is cut, the address is 0x3A + 2 = 0x3C
If only A2 is cut, the address is 0x3A + 4 = 0x3E
If only A3 is cut, the address is 0x3A + 8 = 0x42
So for example if A2 is cut and A0 is cut, the address is 0x3A + 4 + 1 = 0x3F.
The table below shows all possible addresses, and whether the pin should be high (cut) or low (closed).```
Check me if you have a moment.
@idle owl lgtm
Excellent, thanks
wait, is the bit set when the jumper is cut, or when it's not cut?
Cut?
They start connected...
If that answers your question
I'm fuzzy on a lot of this, which is why I've been asking for so much help. Trying to answer, not trying to be snarky if it's coming across that way.
is there a schematic?
that enables it. see other link above for actual addr incrementing code.
right, but how is that variable set in this particular firmware?
without it we don't know
and by variable I mean constant
ok then, sorry, just checking
the code setup is sort of weird for the firmware. sort of a hack. code (implementation) is in header files which are "configured" via the arduino sketches (.ino) in the "examples" folder
a C question, in the CIRCUITPY_BOARD_BUS implementation, could we remove the need for an additional define with the number of ports and instead use sizeof ?
#ifdef CIRCUITPY_BOARD_I2C_PIN
#define CIRCUITPY_BOARD_I2C (sizeof(CIRCUITPY_BOARD_I2C_PIN)/sizeof(board_i2c_pin_t))
#endif
@tulip sleet The longer leg of the LED is + right? Because more lines needed to make a + than a -? (I'm hoping I remember this properly.)
right, you disassemble the + sign and put the pieces end to end (that's how I think of it)
I had never heard that but now I hopefully will never forget it!
I made that up for myself years ago
That's a great way
I apparently haven't forgotten it 😄
Had to google it literally every time before. Or Dan- or JP-it.
I'd also use the hook it up to my multimeter to see which way lit up
I'm sad with multimeters.
Don't use them enough to have it stick. Always have to ask for help. Or google it.
It's pretty bad. Though I'm missing a lot of fundamentals due to the path I took to get here 😄
If anyone is ever looking for an API for a demo project I just found the NHL has one with a ton of information. Was looking at how those automated goal light works and found they have crazy amounts of data. No API key even required
Oh yeah? Can you link? I think PT is always looking for more stuff like that. Especially when it's not controversial.
https://gitlab.com/dword4/nhlapi
Someone documented it all. I was going to try it a bit during the Winnipeg game tonight. There is a live update feature where you say "new plays since X time"
I'm trying to figure out what visual image I have, I believe I'm thinking of a faucet, the "plus" side is the longest so it it's stuck in the ground, and the current flows to the other side
Thanks! Passed it on.
is that weird ?
Haha not if it works for you.
i like it
If I get around to using it I'm sure I'll show it off. Would be neat for a live score for your fav team type thing
Good way to remember it as well.
CircuitPython version
Adafruit CircuitPython 7.1.1
Code/REPL
import audiocore
import audioio
import board
import array
import time
import math
# Generate one period of sine wav.
length = 8000 // 440
sine_wave = array.array("h", [0] * length)
for i in range(length):
sine_wave[i] = int(math.sin(math.pi * 2 * i / 18) * (2 ** 15))
print("Sin", sine_wave[i])
dac = audioio.AudioOut(board.A0)
sine_wave = audiocore.RawSample(sine_wave)
dac...
Adds STEMMA_I2C on the other QTPY boards that have separate pins for the stemma QT connector.
Also changes the other busses to using the new format.
I think I actually have a chance of remembering now! 
electrolytic capacitor ± markings get me... often it's "-" written sideways down the capacitor, but many of mine use an outline font and it looks like a "0" (zero), so of course I think 0 (negative) and 1 (positive), and then I end up looking at the lead length anyway to be sure
The reduced timeout in espressif common_hal_busio_i2c_probe doesn't work. From what I can tell, the esp-idf won't do a timeout lower than 1s: https://github.com/adafruit/esp-idf/blob/f30a865fd1a44d880b909b84112f74741412c2ce/components/driver/i2c.c#L1171-L1173.
Beats my strategy of buying two of everything, hoping for the best but watching for smoke haha
I think that visual is great for LED direction.
Based on the ESP32-S3-DevKitC-1-N8 board files. Verified on the actual HW.
Requested the PID here: https://github.com/espressif/usb-pids/pull/34
Let's see, if they disagree then I'll just change it to use the DevKitC PID :)
CircuitPython version
Adafruit CircuitPython 7.2.0-alpha.1-274-g5435a40c5-dirty on 2022-02-01; ESP32-S3-DevKitC-1-N8 with ESP32S3
Board ID:espressif_esp32s3_devkitc_1_n8
Code/REPL
import board
import pwmio
rl = pwmio.PWMOut(board.IO40)
while True:
for cycle in range(0, 65535): # Cycles through the full PWM range from 0 to 65535
rl.duty_cycle = cycle # Cycles the LED pin duty cycle through the range of values
for cycle in range(6...
I attempted to build from this branch and run on a PyPortal but it seems that I'm getting a hard crash.
Immediately after the UF2 finishes pasting, the device reboots as normal. And for just one second I can see the serial output on the display as normal:

But immediately after this the display goes dark and I never see CIRCUITPY or the serial port connect ...
All the merge fixes are good. One build failed with a 403 error that doesn't seem related to the changes.
One spot where I think you want a write_read.
It looks like this should be a write_read.
@FoamyGuy this pyportal issue was resolved by
https://github.com/adafruit/circuitpython/pull/5951
I pulled the repo before that PR was merged so it’s not incorporated in this repo. Do I need to merge in those changes?
and remove line 131, I think.
The latest build should have removed both and replace them with the write_read
@kmatch98 ah I see! I don't think you need to merge it to here(I believe github works out the differences correctly in most cases), but I am not certain. I'll try it again tomorrow and merge that PR into my local repo to build.
3741
thanks, please submit a PR if ya can!
Just adding my interest in this feature.
CircuitPython version
N/A
Code/REPL
N/A
Behavior
N/A
Description
The "Edit on Github" links for core module documentation at https://circuitpython.readthedocs.io/en/latest/ appear to be broken. For example, on any of:
ok, bulids work again. Problem was most likely related to #5951
This aliases board.I2C and board.STEMMA_I2C on all boards where they are on the same pins. Meaning they both return the same singleton object. I went through the whole list on circuitpython.org, hopefully I didn't make too many mistakes.
I'm a little worried it might be confusing though. Documentation and guides will have to clarify when I2Cand STEMMA_I2C are the same and when they are not.
Note that one sparkfun board already also had a board.QWIIC alias.
Final step for #4638 ?
CircuitPython version
built from tip of main
Adafruit CircuitPython 7.2.0-alpha.1-274-g5435a40c5 on 2022-02-02; Adafruit QT Py RP2040 with rp2040
Code/REPL
Ran demo code from https://learn.adafruit.com/neopixel-mini-vu-meter/coding-the-neopixel-mini-vu-meter
uncommneted line to print PDM Mic readings.
# SPDX-FileCopyrightText: 2022 Liz Clark for Adafruit Industries
# SPDX-License-Identifier: MIT
import time
import array
import math
import ...
CircuitPython version
Adafruit CircuitPython commit 9b32d549, Custom board with STM32F412CG
Code/REPL
None
Behavior
I am adding a board to CircuitPython with a STM32F412CG micro on the board. I ran into an error while building CircuitPython about USART3 functions:
common-hal/busio/UART.c:484:9: error: implicit declaration of function '__HAL_RCC_USART3_FORCE_RESET' [-Werror=implicit-fu...
Moved the code for crc32() from uzlib into modubinascii as suggested by @dhalbert
... successfully did the changes discussed and opened my very first PR ever
@kattni What do you think about whether board.STEMMA_I2C should exist on boards where board.I2C and board.STEMMA_I2C are the same?
Fixed an erroneous documentation string. Local docs build ok now. This is ready for another review.
I'm testing this on the affected boards.
CircuitPython version
Adafruit CircuitPython 7.1.1 on 2022-01-14; Adafruit Matrix Portal M4 with samd51j19
Board ID:matrixportal_m4
Code/REPL
"""
MOON PHASE CLOCK for Adafruit Matrix Portal: displays current time, lunar
phase and time of next moonrise or moonset. Requires WiFi internet access.
Written by Phil 'PaintYourDragon' Burgess for Adafruit Industries.
MIT license, all text above must be included in any redistribution.
BDF fonts from the X....
Tested on QT Py ESP32-S2. Did not have S3 protos to test.
@kattni What do you think about whether
board.STEMMA_I2Cshould exist on boards whereboard.I2Candboard.STEMMA_I2Care the same?
@ladyada: same q for you.
@dhalbert I want to see this happen. Consistency is important, and if we have it on the boards that use SCL1/SDA1, I think having it on all boards would work. We can document that it's an alias if that is desired, but I would love to see this across all boards.
Thank you for doing this extensive inventory!
@dhalbert I want to see this happen. Consistency is important, and if we have it on the boards that use SCL1/SDA1, I think having it on all boards would work. We can document that it's an alias if that is desired, but I would love to see this across all boards.
OK, sounds good! I was not sure if there were hidden considerations. It will certainly make Learn Guide code easier. @ladyada -- I will not wait for your reply.
yes please have it point to the same if they're the same!
@tulip sleet Good call on the potential hidden consideration. I discussed it yesterday with Neradoc, so I was already on board with it. 🙂
excellent - I was just not sure if there was some template consideration, etc.
Even if there is, I'll make it work.
I seriously love the idea of STEMMA_I2C()
So much more descriptive.
it does sound good, because the code is interchangeable, and unless there are address conflicts, I2C and STEMMA_I2C can be the same bus
We'll have to deal with the potential for folks trying to use both when they are the same and getting pin in use issues, but we get that anyway for who knows reasons.
and the advantage for boards with separate buses is great, as you say, much more descriptive ("affordant") than SCL1/SDA1
Exactly.
I tested crc32 on a Metro M4, and it gets the same result as CPython. Excellent, thanks.
Some builds are failing due to size. I will do some squeezing and push some commits to fix those.
when is the hackchat with the Guys on?
https://www.youtube.com/adafruit/live says "Adafruit's Limor "Ladyada" Fried and Phillip Torrone will host the Hack Chat on Wednesday, February 2 at noon Pacific / 3pm Eastern."
Thanks @crimson ferry for the info. Do you know if they will be on any other channel
I thought I remembered them going to be on a picast also
Yeah that's a separate thing
When is it?
The Pi Cast Celebrates 10 Years of Raspberry Pi: New Episodes With Ladyada, Eben Upton, and others. Adafruit’s Limor Fried will be on a livecast on February 15, 2022
Ok thanks @idle owl
You're welcome, Charles.
@tidal kiln Do you have any of the ATtiny817 STEMMA QT breakouts and a Pi? Have you ever tried to use one on a Pi?
@gilded cradle ^^ Same question for you.
I assume if one works, they all work, but I haven't tested any of them and am adding it to the Arcade QT guide.
@idle owl yes. no, or at least i don't think so.
Fair enough. Thanks
No, I simply realised I've never tested it
It should work.
But things happen 😄
I try not to guide stuff I haven't at least sort of tested
i could test breakout if you want
but don't have arcade
but also - pretty easy to connect/test if you have pi?
I don't have a Pi with me or I'd have tested it 🙂
I think any of them is a good test
since they're all the same base hardware/firmware ish.
@idle owl meh, testing breakout probably not super useful. it'd just be a repeat of this:
https://learn.adafruit.com/adafruit-attiny817-seesaw/circuitpython
Ohhh. You only have the base breakout.
I was thinking of one of the other things that uses the chip.
Would be a good test.
I can't even remember if I tested that.
There was so much going on in that guide.
It's probably fine.
I do have one, but haven't used it on anything.
did you test neoslider?
https://learn.adafruit.com/adafruit-neoslider/python-circuitpython
On Pi? Don't think so.
i have one of those. i'll test real quick.
(blinka) pi@raspberrypi:~ $ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
(blinka) pi@raspberrypi:~ $ python3 slider_test.py
Traceback (most recent call last):
File "slider_test.py", line 13, in <module>
neoslider = Seesaw(board.I2C(), 0x30)
File "/home/pi/blinka/lib/python3.7/site-packages/adafruit_seesaw/seesaw.py", line 150, in __init__
self.chip_id, _SAMD09_HW_ID_CODE, _ATTINY8X7_HW_ID_CODE
RuntimeError: Seesaw hardware ID returned (0xc3) is not correct! Expected 0x55 or 0x87. Please check your wiring.
hmm
Someone ran into this the other day............. And I have no idea what we did to fix it.
going to sanity check on a qt py
Adafruit CircuitPython 7.0.0 on 2021-09-20; Adafruit QT Py M0 with samd21e18
>>> import slider_test
576
289
132
221
hmmmm
Some builds are failing due to size. I will do some squeezing and push some commits to fix those.
Fantastic. Thanks!
@onyx hinge Do you understand enumerate in Python?
Pylint is telling me to use it and I don't have time to go through trying to figure it out on my own. Hoping someone else gets it and can help.
it provides an index as well as the iterator
Um..
It wants me to replace this for n in range(len(button_pins)):
which is used for button and LED numbers.
so would it be for count in enumerate(button_pins) or something?
for i, foo in enumerate(some_list_of_foos):
what is foo there though
the first one
I mean, why use it if I'm only using i in that scenario?
seems extraneous.
basic iterator usage
Fair enough
second provides an integer that can be used for indexing
i would be 0, 1, 2, 3 etc.
inside the loop
what is button_pins?
List of initialised button objects
wait
no
supposed to be buttons
which is a list of init button pins
what are you wanting to do inside the loop?
for n in range(len(buttons)):
leds[n].value = not buttons[n].value```
while True:
for n, button in enumerate(buttons):
leds[n].value = not button.value
*I meant enumerate
^^ yah, that, was just typing same
Doesn't the buttons.value need the iterator?.... oh
many typos
nope. you get both.
I would say it's nitpicky in that context, but that's pylint for you
first, think of the non-enumerate version
for button in button_pins:
button.some_button_func()
Always.
yeah typically I use enumerate when I go from for X in Y and realize "oh but I need the index"
enumerate does same thing, but also provides the integer counter
so two things are provided in loop. the samebutton as before, and then the i or n or whatever you setup to be the incrementer
^^ double yep. you typically get there by a "oh i need index" realization
now back to this fun...
pi@raspberrypi:~ $ source blinka/bin/activate
(blinka) pi@raspberrypi:~ $ python3
Python 3.7.3 (default, Jan 22 2021, 20:04:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import board
>>> from adafruit_bus_device.i2c_device import I2CDevice
>>> i2c_dev = I2CDevice(board.I2C(), 0x30)
>>> out_buf = bytes([0x00,0x01])
>>> in_buf = bytearray(1)
>>> with i2c_dev as i2c:
... i2c.write_then_readinto(out_buf, in_buf)
...
>>> in_buf
bytearray(b'\xc3')
>>>
oof
same thing on qt py:
Adafruit CircuitPython 7.0.0 on 2021-09-20; Adafruit QT Py M0 with samd21e18
>>> import board
>>> from adafruit_bus_device.i2c_device import I2CDevice
>>> i2c_dev = I2CDevice(board.I2C(), 0x30)
>>> out_buf = bytes([0x00,0x01])
>>> in_buf = bytearray(1)
>>> with i2c_dev as i2c:
... i2c.write_then_readinto(out_buf, in_buf)
...
>>> in_buf
bytearray(b'\x87')
>>>
@idle owl you saw this before? was it here on discord or somewhere else?
Yeah Discord, I think. I don't think they dug in that far, I wouldn't have told them to. But they ran into the wrong hardware warning.
bee-are-bee lunch time.
@tidal kiln Back if you're still fighting with the NeoSlider. I mean, I'm back regardless of what you're doing. But pinging you to let you know.
@idle owl ok, yah, stil looking. seems odd.
@gilded cradle are you available to test also?
@tidal kiln So.. Arduino: Adafruit PID 5296 I2C QT 4x LED Arcade Buttons test! seesaw not found! But I'm on a QT Py RP2040, so maybe that's my issue?
I'm not sure how to fix this and therefore test the code.
And... wait no, I have a TFT Feather ESP32-S2 with me too. Was going to say don't have any other MCUs with me, but I do. So I could try on that I guess.
don't have any SAMDs?
No. 😕
Wasn't thinking about code not working. Made the obviously false assumption that it would be fine.
OK. I'll report back in a few.
Yeah, the pins are wrong for the LEDs and switches, but the rest should work.
Wrong as in backwards from the silk.
I'm going to fix it once GitHub is back up and I can verify it works.
Hmm same fail on ESP32-S2.
Seesaw not found.
Feather TFT STEMMA connector is same SCL/SDA pins.
So that's not the issue here.
I mean, obviously it worked at some point
The forum feedback we got wasn't "it doesn't work" it was "it's not matching the silk."
try an i2c scan
Ok, where is that code?
it's failing the basic init
@idle owl oh yah, need to deal with i2c power on tft feather
Nothing... I noticed the power LED wasn't on for the breakout when connected to the....
oh right.
That.
Wire1
I think I got it uploaded properly, but I can't tell since it's all the same code. I changed a print to verify.
stemma connector is Wire1
go back to tft feather
it has that lipo sensor on board, so should show something even if breakout is being odd
It finds another sensor. As a side note.
on qt py?
oh. another sensor tested. ok.
Yeah
good sanity check
Also I thought Arduino did it by default.
pinMode(TFT_I2C_POWER, OUTPUT);
digitalWrite(TFT_I2C_POWER, HIGH);
add that to setup()
testing now
LED is on
No devices found.
(╯°□°)╯︵ ┻━┻
JP got it to work ok on whatever he used for the synth project.
So Arduino does work for it...
But these are weird boards.
I don't have any not weird boards to try.
😕 sigh.
remove the arcade
Ok
yah, my tft feather is on the way. so i'm guessing at things.
Not on this one
There's a spot for it
but not populated.
CP is seeing something without the arcade attached
(on the display)
And the arcade when I plug it in
I2C addresses found: ['0xb']
I2C addresses found: ['0xb']
I2C addresses found: ['0xb']
I2C addresses found: ['0xb', '0x3a']
I2C addresses found: ['0xb', '0x3a']
I2C addresses found: ['0xb', '0x3a']
I2C addresses found: ['0xb', '0x3a']```
Right
hmm...so working in CP
Yeah
I am confuse.
I don't have Arduino chops to rely on here to troubleshoot this. 😕
That's what I get for not bringing a Metro or something.
got that. but not arcade.
Right
@gilded cradle Did you say you have an Arcade QT board? Or do you have something else...
The thing is that
common_hal_busio_spi_constructsets default SPI frequency (baudrate) that differs from the SPI flash settings.
We're careful with the starting baudrate due to picky SD cards. That's where the 250k (IIRC) comes from.
I have added
common_hal_busio_spi_configureback tospi_flash_read_dataandspi_flash_write_data. But they are called before chip select signal is activated now. Moreover I have addedcommon_hal_busio_spi_configuretospi_flash_init_device...
I don't know who got one. JP did but I'm pretty sure he's slammed at the moment.
It's a bit of an unusual breakout, so it's probably not ubiquitous.
Something else. I didn't get an arcade one. I think I was saying I had the ATtiny817 breakout.
Fair enough. Thank you for replying.
OK. I guess the Arduino page waits then. Probably until tomorrow when Limor might have more cycles.
Sounds good
@tidal kiln This is currently happening with CircuitPython: I2C addresses found: ['0x3a'] I2C addresses found: ['0xb', '0x3a'] I2C addresses found: ['0x3a'] I2C addresses found: ['0xb', '0x3a'] I2C addresses found: ['0x3a'] I2C addresses found: ['0xb', '0x3a'] I2C addresses found: ['0xb', '0x3a'] I2C addresses found: ['0x3a'] I2C addresses found: ['0x3a'] I2C addresses found: ['0x3a'] I2C addresses found: ['0xb', '0x3a'] I2C addresses found: ['0x3a'] I2C addresses found: ['0x3a'] I2C addresses found: ['0x3a'] I2C addresses found: ['0x3a'] I2C addresses found: ['0x3a']
The lipo monitor comes and goes.
The charge LED is inconsistent too. Must be something to do with the monitor itself.
Ah got it.
I'm less concerned about that, heh.
But it could explain Arduino not seeing it I guess. But it popped immediately with CP. So... eh.
Maybe a safemode.py could also be used to account for brownout safemode occurrences in battery/solar powered projects.
@dhalbert did you reduce the datum_imu board size already?
Ok. @tidal kiln Thank you for slogging through this with me. I guess I'll move onto something else for now. I'm pretty sure the CircuitPython code for this was more important right now anyway because there were no examples for it previously.
np. sounds good. i'm not helping much without hardware. just sleuthing from the schematics, etc.
You always manage to help even when you're sleuthing your way through it.
This looks good to me! I think the one board that's too big may be fixed by another PR so we can merge this.
Looks good to me! Thank you!
Thanks for all your reviews on this @slender iron !
just doing my daily pass @blissful pollen 🙂
Let's close this in favor of #5763
We're tracking this here: #5763
Thanks for the issue! Is the best fix to switch to the STM repo for st_driver? Would you mind making a PR for it?
@dhalbert did you reduce the
datum_imuboard size already?
Yes, fixed by https://github.com/adafruit/circuitpython/pull/5969/commits/0d43e3e734e52c262323c1d509b332f38874b76d
@tannewt
I was able to build successfully by only updating the stm32f4xx_hal_rcc_ex.h file to the latest from ST's repo.
I noticed that circuitpython has an archived repo as a submodule I think for the ST drivers. Are archived repo's able to be modified? This is the archived repo: https://github.com/hathach/st_driver
I'm not familiar enough with circuitpython yet to say whether it would be feasible to update to ST's latest release... There must have been a reason to point to an archiv...
It looks like TinyUSB switch to direct submodules to the ST repos: https://github.com/hathach/tinyusb/pull/544
@tulip sleet you around? I could use a BLE chat
yes, but Carole just came home; I need to speak with her for a bit
k, I'll go have lunch
we were planning to go for a walk before it got dark. I can ping you again in about an hour
sounds good. no rush from me
@lone axle the PR on the Controllable REPL just got merged so it should be easier to try out now. Raise an issue if you observe anything weird. https://github.com/adafruit/circuitpython/pull/5954
I toyed with it for a few minutes before I started work today and did get it built and running on my device. Are you able to share the updated version of your demo script by chance?
I swapped a few things around in it and did get it running but ended up with the displayio shapes group getting drawn in front of the serial output rather than above it in the Y pixel direction.
I'm guessing I must be close but still need to tweak something else. Will definitely be tinkering around some more with it tonight.
CircuitPython version
Adafruit CircuitPython 7.2.0-alpha.1-278-ga04cd6444 on 2022-02-02; ESP32-S3-DevKitC-1-N8R2 with ESP32S3
Code/REPL
import alarm
import board
import digitalio
import neopixel
import time
np = neopixel.NeoPixel(board.NEOPIXEL, 1)
while True:
np[0] = (50, 50, 50)
time.sleep(1)
np[0] = (0, 0, 0)
# Create a an alarm that will trigger 5 seconds from now.
time_alarm = alarm.time.TimeAlarm(monotonic_time=tim...
Here's the latest demo code for moving the REPL position and adding some displayio objects:
import board
import displayio
import supervisor
import time
display=board.DISPLAY
# Create a bitmap with two colors
bitmap1 = displayio.Bitmap(display.width//4, display.height//4 - 10, 2)
# Create a two color palette
palette1 = displayio.Palette(2)
palette1[0] = 0xff00ff
palette1[1] = 0xffffff
# Create a TileGrid using the Bitmap and Palette
tile_grid1 = displayio.T...
Sorry I missed adding the updated demo code. Here is the demo that puts the REPL on the bottom half of the screen and draws some rectangles up top: https://github.com/adafruit/circuitpython/pull/5954#issuecomment-1028431918
I ran it on a pyportal.
Thank you!
Single build problem was fixed. All done. Thanks again!
Only tested that CIRCUITPY comes up.
Looks like commit 3e13d4f (sideset_enable support) may be the culprit. I will continue to investigate.
Pin 40 (GPIO40) was missing from the boards module (pins.c) for esp32s3 devkit builds. This PR adds the it.
You should add IO40 (see #5975)
@mental nexus this is such a neat way to interact with displayio! I've taken part of your code and split it off into a helper file that can be used from REPL https://gist.github.com/FoamyGuy/f1e6da12ccb07caac980e5093cfb74eb
so in the REPL you can do:
>>> from screen_splitter import split_screen
>>> import board
>>> displayio_group = split_screen(board.DISPLAY)
and then create and add whatever you want to displayio_group
That’s cool and makes it easy to use. I think you’ve just invented a new library.
This will update the ST drivers to the latest from ST, as well as fix the issue https://github.com/adafruit/circuitpython/issues/5968 .
I had to use CMSIS_5 tag 5.4.0, as I was getting the error in the below issue when trying to build CircuitPython.
https://github.com/ARM-software/CMSIS_5/issues/1397
Successful builds:
- espruino_pico
- espruino_wifi
- feather_stm32f405_express
- meowbit_v121
- nucleo_f746zg
- nucleo_f767zi
- nucleo_h743zi_2
- openmv_h7
- pyb_nano_v2
- py...
Merging anyway. WIll fix too-large build later.
Can you merge from upstream and push again? It looks like you might have version skew on locale/circuitpython.pot.
Some ports can't read a digital io while it is in output mode, see in the sda_read function it is switched to input, read, then switched to output again.
I used PULL_UP because the sda_read function also uses PULL_UP, but I'm not sure if this is the right thing to do. Should it depend on CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP? And if so, should check for pullups during construction like the busio version does?
Yeah, we should switch to official st repo which is only available recently. The st_driver repo is created way before that.
Which ports can't read while in output mode? I'm guessing you encountered this in a particular situation.
Espressif, nrf, maybe stm and samd.
We have used bitbangio successfully on STM and SAMD, including with devices that need clock-stretching. So does it not work on Espressif? I mean, have you tested it?
Should it depend on CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP?
This was added in #5237, due to a particular Espressif dev board that didn't include external pullups despite having on-board sensors. In general, the internal pullups are often marginal for I2C, or in cases like RP2040 (i...
We have used
bitbangiosuccessfully on STM and SAMD, including with devices that need clock-stretching. So does it not work on Espressif? I mean, have you tested it?
I don't have any devices that I know for sure need clock stretching, but I can get it to do a lot of weird stuff. One example is if I were to ground SCL and do a scan, I get a list of 100+ addresses instead of the expected TimeoutError: Clock stretch too long that I get with this PR.
Currently, there seems to be no way to set the modified time or (less importantly) the accessed time of a file in circuitpython, because the os library is lacking utime(). Could this be added?
Im doing it with CLK=GP26, DATA=GP27, same result, sample rate is 44099. It makes the PDM breakout useless...
Adafruit CircuitPython 7.1.0 on 2021-12-28; Raspberry Pi Pico with rp2040
Ok,
I checked out the code and tested it in the CP-application for our keyboards and I can use it to decide which one connection to keep and to disconnect the others.
I had hoped, that the .serial_number member of the DeviceInfoservice object would hold the serial_number of the IOS devices, but it didn't.
A quick (and dirty) fix for my problem would be to either put the mac-address string into the serial_number member if the serial number is not available for the device.
Or not so ...
Can you merge from upstream and push again? It looks like you might have version skew on
locale/circuitpython.pot.
I fixed this with a couple of other commits.
This is not working, it looks like
i2c_master_cmd_begincaps the delay at 1 second minimum: https://github.com/adafruit/esp-idf/blob/circuitpython/components/driver/i2c.c#L1172
This was a reported as a bug:
https://github.com/espressif/arduino-esp32/issues/5934
https://github.com/espressif/esp-idf/issues/4999
went back in time, and when I2C_CMD_ALIVE_INTERVAL_TICK was first introduced, it was a ceiling, not a floor:
https://github.com/espressif/esp-idf/blame/9075b507b54a99ce73...
Having done this, I can
wifi.radio.connect(...)
wifi.radio.mdns_hostname("qtpy")
and then on my desktop computer I can ping qtpy.local. This will also be useful when using wifi boards as http servers, since they could be reached by name rather than by IP address on systems that support mdns.
A second step may be to add support for mdns services, which for instance allow a device to publish that it is a webserver, file server, printer, etc.
I created an issue on the STMF4 HAL repo for the unused variable error we're seeing when trying to build the stm32f412zg_discovery board.
https://github.com/STMicroelectronics/stm32f4xx_hal_driver/issues/9
Perhaps clarify the distinction between hostname and instance name for the docs.
CircuitPython version
Adafruit CircuitPython 7.2.0-alpha.1-224-gac7a80753 on 2022-01-26; Adafruit QT Py ESP32S2 with ESP32S2
Adafruit CircuitPython 7.2.0-alpha.1-224-gac7a80753 on 2022-01-26; Saola 1 w/Wrover with ESP32S2
Code/REPL
import time
import wifi
from secrets import secrets
DELAY = 0.5 # this is fine, but 0-0.4 or so lead to Safe Mode after a couple of pings
wifi.radio.connect(secrets['ssid'], secrets['password'])
while True:
print(...
If I wanted to play with the esp32-s3 stuff is this good? https://www.digikey.ca/en/products/detail/espressif-systems/ESP32-S3-DEVKITC-1-N8R8/15295894
yes, strong preference for varieties with extra PSRAM (R2, R8)
Thanks, was ordering some other stuff and thought about it
Although the -S3 has more internal SRAM... 512KB, increase from 320KB in the -S2. That extra 192KB is really nice.
Never enough memory 🙂
internal good for wifi and other esp stuff; PSRAM for CircuitPython
doesn't actually call out the PSRAM unfortunately, you're left to interpret the model numbers
Adafruit has N8R2 in the shop, the others with PSRAM (N32R8 (!) and N8R8) are sold out atm
Thanks! This was at least partly motivated by getting to free shipping on a digikey order I was already making
I have so much inventory for that exact reason
"hey, free shipping if I also get this"
Yup, i mean maybe I'll use two of these even if I just wanted one. Maybe even three!
@slender iron a little research on other BLE stacks:
- https://github.com/ARMmbed/ble - appears dead
- https://github.com/packetcraft-inc/stacks from https://www.packetcraft.com/. Apache-licensed, appears to be what "Cordio" evolved into. No activity in GitHub, only implemented for Nordic. Dialog and TI have stacks for their own chips.
- https://en.wikipedia.org/wiki/Bluetooth_stack#Embedded_implementations
thanks for looking @tulip sleet. I think nimble is the right direction. ESP support is helpful
yes, the others didn't look very promising, though it's good to know now, esp the packetcraft ones
It turns out this is a hardware problem specific to the QT Py ESP32-S2. We know how to fix it, but it's not an easy trace-cutting or something like that. For now, you may want to switch to a different board. We could get somewhat less sleep current by using ESP-IDF "light sleep" (which is not the same as CircuitPython's light sleep), but it would still be several mA.
I seriously have to question the QA procedures because something like should have never happened in the first place.
@muendlein if ya cant use the board, we can refund it. future boards will have the fix and we'll get screenshots of low power usage to verify for new designs!
A debug trace from the IDF would be super helpful. That should show how we get into safe mode.
Is this something that we can expect from all wifi instances? Could we provide it ourselves on top of other network interfaces? Maybe it'd be better to have a separate module and API for it.
I worry that by putting it in Radio you are suggesting all implementations of the radio API should have it.
Thank you! Do you want to wait for ST or should I fork and fix that build error? That's normally what we do if the source repo has a bug.
@tannewt I'll leave that up to you. If/when they eventually fix it, I'm guessing we can switch back to theirs?
This has been a problem for a few PR's at the moment.
https://docs.python.org/3/library/os.html#os.utime
This should be easy to add because FATFS has a corresponding function: https://github.com/adafruit/circuitpython/blob/a672ee6da50def65e5544ee24bcf960236d985a2/lib/oofatfs/ff.h#L299
This makes sense to me. I wouldn't expect the get_value to return the line state when doing output anyway. I'd expect the value we're set to output.
Thanks for looking into this @DavePutz !
OK by me too. I just wanted to make sure someone had tested it on hardware.
It is probably safe to fork and fix by just removing the unused variable, it looks like the f7 qspi driver has this fixed:
https://github.com/STMicroelectronics/stm32f7xx_hal_driver/blob/27458ea876aabd8fd568c5e2a8a3448f082e2817/Src/stm32f7xx_hal_qspi.c#L874
@runic crest just replied to you on the forum. I don't have a good answer for you
@tannewt I'll leave that up to you. If/when they eventually fix it, I'm guessing we can switch back to theirs?
Yup, that'd be the idea.
I'll make a fork and remove that line. Would you mind updating this PR after I do?
@slender iron Looks like my PR might be good to go other than the seeeduino_xiao issue I see there is a PR for now
Thanks for finding that @tulip sleet
@lone axle The CircuitPython Org Bundle (library bundle)... Is that worth mentioning when mentioning the library bundles? Or what's the deal there. The name is kind of confusing and requires explanation I think, which this page doesn't have room for. But I don't want to leave it out if it's as important as the others.
And I guess I'm not even sure how to describe it in a few words. "It is made up of..." and I don't know how to end that sentence.
@slender iron Same question to you, I suppose. ^^ Since you kind of spearheaded the CircuitPython Org in the first place.
(will get back to you after we're done chatting with jimmo)
Ok thanks.
It's made up of libraries maintained collectively by the community (rather than individually by single members like the community bundle).
I'm am in favor of listing it because I think the higher visibility means higher chance people will use the libraries within, and higher chance we find more folks that want to get involved with it.
However in it's current state I would say it's fair to say it's behind the other two bundles both in terms of libraries contained and active contribution. So I could understand leaving it off for the time being. My hope is that it continues to expand with DisplayIO widgets and other libraries that the community is interested in supporting rather than Adafruit directly.
Fair enough. I'm ok with including it. This is for circuitpython.org/start which isn't a thing yet.
IIRC It has some infrastructure things that need doing as well still like the automated bundle generation via adabot or similar tool.
Sounds about right.
Hmm. Maybe shouldn't include it yet since it's not easy to find.
The others are on /libraries
I think I'll leave it out for now since I'm linking to the bundle download page for this section, and the Org bundle isn't there yet.
I will specify the Community Bundle is "individual community members" in preparation for adding the Org bundle being "maintained collectively by the community."
Sounds good. The things in it ATM are probably a bit deeper than would be needed for primary audience of a /start page if I am imagining it correctly anyhow.
Added it in a comment so it's there somewhere, but not public facing
@idle owl thanks. I agree with foamyguy
Thanks for following up. I left the sentence in there in a comment so we have the verbiage when we're ready.
I just got a ship notification for the replacement MicroMod. I'll post up a PR once I've confirmed that everything works.
I just got a ship notification for the replacement MicroMod. I'll post up a PR once I've confirmed that everything works.
Thanks! I got a back-in-stock notification, but the documentation hadn't yet been updated.
hi everybody, I'm new to discord, so please bear with me 🙂 @slender iron kindly suggested that it would be easy to add os.utime() because FATFS has a corresponding function.
Welcome! No worries about being new here. We all started that way at some point. 🙂
thanks @idle owl
so is this the right place to ask for (a lot of) help with the above task?
Absolutely!
Ask away, but be patient, as folks aren't always around. Someone will help as soon as they can though!
@zealous current I think you want to start at https://github.com/adafruit/circuitpython/blob/main/shared-bindings/os/__init__.c
@stuck elbow - yes, I found that but I'm a Python guy ignorant of c and its type definitions, pointers, etc. First of all, I guess for circuitpython it should be sufficient to implement os.utime(path, times=None), right?
welcome @zealous current! the best place to start is to find a similar function that we do have implemented
@slender iron that's what I'm trying to do. So I would start with STATIC mp_obj_t os_utime(mp_obj_t old_path_in...
now what do I do for an optional tuple of ints? (none of the other functions have something like that, afaics)
kwargs are easiest to do with the MP_KEYWORD stuff
tuples may be easiest to interact with via the struct https://github.com/adafruit/circuitpython/blob/main/py/objtuple.h#L31-L35
you can check the type with: https://github.com/adafruit/circuitpython/blob/a672ee6da50def65e5544ee24bcf960236d985a2/py/obj.h#L823
taking a step back. python objects are C structs under the hood
shared-bindings is all about validating those structs to make sure they are the right type and then converting them to the corresponding C types
@makermelissa This issue is just an issue with the example. I have traced through the code and discovered:
- There can only be one
socket_poolperwifi.radio- Initializing the radio twice isn't helping
- The fix can be done entirely in
code.pyusing these librariesMy only minor gripe is that I have to load
secretsinside my code. It would be great if there was a public accessor or a way to pass the secrets throughMagTagintoPortalBaseandNetworkBase...
@slender iron so does STATIC mp_obj_t os_utime(mp_obj_t path, mp_obj_tuple_t times) {... look right?
@mental nexus I noticed in your 2022 thread one of the widgets you mentioned was a scrolling text box. I've created this one: https://github.com/FoamyGuy/CircuitPython_Winamp_Player/blob/967e70137d8a078a8559702c1a5d0e5d3427a4c2/code.py#L47 recently for the winamp player project. It needs a little cleanup and maybe a few more spots need to be more generalized, but I'm hoping to add it into display_text as a new type of label that people can use.
I noticed that, too. I'm hoping the get the latest schema doc up before it gets here. If not, I'll poke Sparkfun for it.
@zealous current I'm not sure how that will work with kwargs. I tend to use this style https://github.com/adafruit/circuitpython/blob/main/shared-bindings/busio/I2C.c#L191-L204
@slender iron thanks, I'll have to muse over that a bit. Close to midnight here - gotta go. I'll be back.
thank you! this is the best place to get help
I don't know if this is part of the crash behavior, but on the countio side I have discovered an odd thing about the M4 port that isn't true elsewhere afaik: if I define a counter in a file that I then import (e.g. encoder = countio.Counter(board.MISO)), that counter doesn't work. It uniformly reports 0. If I deinit that counter in the repl and define a new counter on the same pin, it works fine. If I define the counter in code.py directly instead of defining it in in an imported file, it wor...
@rp10007 Could you open a new issue about the countio problem? Thanks!
That definitely caught my eye last night in show and tell. Thanks for sharing. I’m also thinking about how to make a big scrollable text box, like with a long paragraph. With limited memory, main issue is you don’t want to store a huge bitmap. Last year I made something that just rendered what you see and maybe a line above and below. Then as you scrolled it rendered what needed to come into frame. It got way complicated way fast. Seems like there should be an easier way than what I tried.
Ah, paragraph scrolling would be nice as well. The PlaylistDisplay widget in the same project could be molded a bit more into a paragraph text box I think. It's set up for specifically 3 lines atm though.
Also, I see you could use a text line selector widget to select tracks. Maybe that’s the same as a vertically scrollable text box + touch selection. I remember you made a hamburger selector. Maybe there’s a core building block you can make into several offshoot text widgets?
CircuitPython version
Adafruit CircuitPython 7.1.0 on 2021-12-28; Adafruit ItsyBitsy M4 Express with samd51g19
Code/REPL
code.py (finally working version):
from BrocItsyHelper import *
#encoder.deinit()
encoder = countio.Counter(board.MISO)
motor1.throttle=1; time.sleep(3); motor1.throttle = None
print(encoder.count)
BrocItsyHelper.py (works with above code.py, failed code commented out)
# BrocItsy helpers
import time
import board
import p...
I am still doing background research on converting touch to gestures but struggling to find libraries as starting points. Maybe in the meantime I should go back to the text box and see where I left it.
Found this from a year ago.
It's been a while since I did it but I remember doing some gamedev with touch, and basics were really based on start/end position. So X=5 to start X=50 to end they swiped right, etc.
Of course anything like circles gets much more complicated
STM32F4 HAL driver submodule changed to the fork in adafruit to fix the unused variable error until ST fixes it in their repo.
I’d like just a few key gestures: one finger pan or slide, flick for scrolling a list, pinch zoom in/out. Seems like you could cover a lot of use cases with those. Still trying to pick a display with multitouch capability but there are too many options, and I can’t figure out what is the most common one. May just throw the darts and buy one and go from there.
Ooo nice that scrolling looks great
Let me go find it and see if I can library-fy it.
I wonder if the keyboard event library could be modified for this purpose? It tracks time of press and that type of information that you would require to figure out gestures
Hello! To what extent, if any, does MicroPython's Zephyr support extend to CP?
Sorry its been a long while, I just tried this version, still not working for me....
I believe the answer is not at all. Ports are not shared from MP to CP.
MP Ports: https://github.com/micropython/micropython/tree/master/ports
CP Ports: https://github.com/adafruit/circuitpython/tree/main/ports
One of the reasons for that, CP has a common hardware layer across all ports, where in MP it is port specific and not common\the same for every port.
Got it. I'm still learning but what confused me is that fact that each port includes port-specific HALs (I think) like the ESP-IDF, Nordic nrfx, etc. Is CP just using the driver implementations in that case, not their HALs?
Rereading things from today, I didn't know there was another bundle besides the Adafruit and Community, how do I access the Org one?
And is it possible to contribute to it? Also the intended difference between them? Take for example the CSV module I wrote, circuitpython_csv, I would actually prefer that to widely examined by others and contributed to, but realistically I'm the only one doing so right now, since it's not like a collaboration. Is there a preferred bundle?
oh hey somebody was looking for CSV reading in #help-with-circuitpython a few hours ago
See https://circuitpython.readthedocs.io/en/latest/docs/porting.html#architecture for how we separate the Python API from the port-specific implementations. There is a "common HAL" API called from the Python API side, and it's reimplemented for each port (or shared, if possible). ports/name_of_port/common-hal/.... On the port-specific side, we call that port's HAL, or sometimes use raw register manipulation, depending on what we need.
While it's possible we might use a different device with a TCP/IP stack that doesn't support mdns, it would be possible to have these properties always return None and error if a non-None value is ever assigned.
I could remove the "instance name" for now, it is more useful when your device has an "mdns service". In this case, the "friendly name" (instance name) can be shown in the service browser. For example, in the avahi-browse -a output line like
+ enp8s0 IPv4 OctoPrint instance...
Thanks! Is there a preferred difference between repos in the Org vs Community?
One build failure was a network problem, the other is an atmel-samd build that is out of space in the russian translation. Did the main branch not encounter that problem?
the other is an atmel-samd build that is out of space in the russian translation. Did the main branch not encounter that problem?
I fixed that in #5981, since it kept showing up.
well the idea is to be a place for libraries that people collaborate on, but I tend to think that most libraries start with one person and others come later so I don't know how relevant that is
but the idea of the Circuitpython Organisation is to put more stuff in there rather than under the Adafruit name, so more people (that don't work for Adafruit) would be part of it and maybe create their libraries there, and then put them in that bundle ?
Hello all! I created an open source command line tool called piku to help my CircuitPython development. Its patterned after npm and poetry. You can use it to create a project, download and add modules from the bundle, deploy to the device, and connect to serial via the command line. I'll try to post about it again. I hope it is useful to someone else, and I would love your feedback: https://github.com/mraleson/piku
Is this the right channel in which to post a question about stepper motor control using circuitpython?
You may get a faster response in #help-with-circuitpython this is more about developing the circuitpython itself
ok thanks
@tannewt I clarified the documentation to state that if the networking stack doesn't support mdns then
- the value of the property is always None
- setting it to a non-None value will raise a ValueError
does this allay your concerns about a future networking stack that doesn't support mdns, or do you still want this in a separate module? If a separate module, would you care to suggest a name? Here are the first two alternatives that came to mind for me:
import mdns
import...
It's also possible to silence diagnostics strictly within source files and headers from a third party, meaning it may not be necessary to fork a repo just to make the ST code compile cleanly with our preferred CFLAGS.
To silence a warning inside a header controlled by a third party, modify the CFLAGS so that it is the "-isystem" flag that introduces the location where the header resides, rather than "-I" or "-iquote". For example, in the espressif port we have
espressif/Makefile: ...
@jepler you're getting outside my comfort zone. If you can tell me what to add to what file, I can switch back to using the ST submodule and add something to the Makefile to ignore unused variable warnings just for the qspi driver.
Looks good, just a couple little typos: "unset or unset" and "then e value" in the first, and the "then e value" got pasted into the second too.
Thanks, I fixed the docs more. I shouldn't have done it in a hurry, but I did.
Woo! I got a native built mpy module loading
This is awesome! I really wanted something like this! I'll definitely check this out and let you know. Is there any kind of git integration? My big problem is sometimes my local git repo and what's on the board don't match up, because I'll edit the code directly on the board and forget to copy/paste the changes back to my local repo. Having it all be ONE place is super helpful, so if there were any sort of way to use this with an existing git folder (or create a git folder within/as the piku folder) that would be incredible!
@weary hill please email cpnews@adafruit.com and we'll include it in the circuitpython newsletter
