#circuitpython-dev
1 messages ยท Page 358 of 1
๐ฎ
yes, only DHT
I looked to the C code to see if the resume changed a varaible or something but I could not figure anything out of it
The only MCU different that I cant test is the black pill and the feathers2 but that one is similar to the metro esp32s2, do you want me to try your code?
not unless you have a servo control signal to test against
oh no, no I dont have any servo
looks like there's a lot more going on with the DHT
Would you keep me posted if you find something interesting, please?
will try
@slender iron (not urgent) but if you can read scroll back and let me know if you think this is issue or pebkac
@tidal kiln ya, it sounds like a bug
ok. thanks. want me to open issue?
yes please
okie doke. will do. thanks.
np
Hi, I've just noticed I can run CircuitPython on Meowbit. Is the screen brightness supposed to work? I tried setting value to 0 and it doesn't change.
The goal here was to read a standard hobby servo input signal.
Here's the general hardware setup, blue box is the receiver generating the signal (transmitter not shown):

Here's what the signal looks like at the voltage divider (1k/2k resistors) which is what goes to the input pin:
 I also am unsure that it will actually change issue filer behavior.
Is this separate issue still valuable alongside #4280?
Ya, I think so. Issues can live when inactive and PRs should be closed when they are. We can close this when the 1.14 merge is done.
Are there any estimates when 6.2.0 will be released?
Nope. We are hoping to get there soon by punting much of the RP2040 stuff to the following release. One thing we do want to fix though is the I2C issues on the S2. It's on Dan's plate.
Thanks for the update! It looks good. However, I thought of another case that probably needs to be handled. We likely need to set one of the globals from PWMOut so that it doesn't allocate to the channel A pin at the same time. Could you try making a countio and then making a PWMOut on the other pin? It should error. Thanks!
Thank you! I'll file an issue to document the minimum bar for translations and then hopefully hand it off. I'm swamped myself.
The ESP32S2 gives POWER_ON as a reset reason when pressing the reset button (I expected RESET_PIN).
microcontroller.reset() gets a WATCHDOG reset reason (expected SOFTWARE).
Tested on MagTag (latest) and ttgo (beta 2), printing out microcontroller.cpu.reset_reason.
@tannewt do I open a new one for the S2?
We've added a few translations that haven't gotten any translations actually added. To save build time, we're turning those off. As we discussed it, we thought it'd be helpful to have a minimum set of messages to translate before turning a new translation on. My idea was to have any interaction messages translated but error messages are optional/best effort.
Looks like Weblate has a priority feature that does what we'd like: https://docs.weblate.org/en/latest/admin/translating.html#strin...
Thanks Dave! One more request.
I don't think we need this anymore because port_reset should call reset_rp2pio_statemachine. rp2pio is meant to be port-specific so it shouldn't influence any code outside of ports/raspberrypi
@slender iron OK having looked into it a little bit I see why you didn't go all the way from the "source" .S file of boot2 to the bytes that need to be included, inside the CircuitPython build process...
๐
just reading the assembly makes me want to not do assembly
I may figure out how to do it with C or have python gen asm
Ya, I'm worried about reading an infrared remote that is more free-running.
The frequency and delay times were figured out mostly by trial and error; if there are better ways to accomplish the task I would be glad to attempt implementing them.
I think your definitely on the right track. Most implementations only get within a few us at best anyway. I'd choose a frequency that is an even number of microseconds to make the math simpler.
Update them to have your name. :-)
@slender iron do you want me to "review" that PR so it can go in when complete? I see that it got tested
what PR?
the boot2 one
I see from internal comms that Limor tested this successfully.
Fix for #4292
This will let wait_for_safe_mode_reset run if the reset reason is RESET_REASON_UNKNOWN to account for ports that don't implement it fully.
However it might not make sense when the reset reason is implemented though, since we only want to do that when powering on or pressing reset. So a better fix might be to use a #define (in each port's Processor.c/h) to remove the test altogether when not fully implemented (that might even save a few bytes on those ports).
Ultima...
I think you can do the exec the wait before enabling the sm and it'll continue to delay. This will be better because the API allows you to set the idle state which means we need to be able to wait on high or low depending on the setting.
Looks good! Thank you!
Code looks good to me! Thank you! ugame10 looks unhappy though unfortunately.
Thanks for these notes @omsai! My plan with the flash is to do the flash toml bits, cascade toml and generators for it. I don't think I'll go so far as to do the boards.
I'm not sure what a good small step for this is. One thing I'd do later is optimize across boards. For now we could just generate a giant ninja file to build everything separately. That still could be tricky because we likely want to factor out some of the compiler and board settings as we do that.
This task feels like ...
Hiya @idle owl, I've gone over the open issues list, and I wanted to check in with you when you have some time about some of the open ones.
.. all the necessary steps to transform it into a padded, checksummed file are now done by the build system.
Since it is assigned by "?=", it should be the case that individual builds can override it.
I did not "test" this per se, but it gives the same content and checksum (except for the identifying comment with a path) as #4302.
I noticed that one of the busy-waiting loops in the pio I/O code was not allowing a keyboard interrupt to break out of it. Fix it!
@slender iron doesn't need to queue jump, but it made me itch so I implemented #4308..
that helps me figure out how to hook it in but I don't want to rely on their .S code
I'm sick of dealing with flashes differently for every port
it needs to be unified
though it can't hurt for now
Thanks! Want to switch the pico back to the qspi version?
I wanted to get the teensy4.1 working with the jupyter circuit python kernel. It is not natively supported as it isnt an adafruit board. Is their a benefit of putting a pull request in to add this board to the library. https://github.com/adafruit/circuitpython_jupyter_kernel, it is quite simply just adding the vendor id to the check on which board is connected.
@vague latch yup! PR would be helpful
ya, that'd be neat!
done... max is 3 so we can have one more.
thanks!
I think i got the PR right. I haven't had to do it before.
- The reset button is wired to S2's chip enable pin so it literally turns off the chip. That's the reason for
POWER_ONstatus. - I am getting the expected
SOFTWAREas reset reason when usingmicrocontroller.reset(). Can you try with current main.
tested feather artifact, its good!
tested both pico and feather 2040, both enumerate
can you post your updated script to your first post, so that other could reproduce as well when they try to take a look
Ah I was thinking something like that might be going on with the reset button. That's too bad.
I tried latest S3, and compiled current main on the Magtag.
Adafruit CircuitPython 6.2.0-beta.2-230-g64192b0eb on 2021-03-01; Adafruit MagTag with ESP32S2
I tried manually calling microcontroller.reset() in the REPL.
I also used this code on battery to exclude the possibility of USB messing with it.
I get WATCHDOG in both cases. (Well, except on first boot).
import board
im...
Still unable to replicate this. Tried both in REPL and code.py.
Adafruit CircuitPython 6.2.0-beta.2-230-g64192b0eb on 2021-03-02; microS2 with ESP32S2
>>> import microcontroller
>>> microcontroller.reset()
# <--- Reset --->
>>> microcontroller.cpu.reset_reason
microcontroller.ResetReason.SOFTWARE
That sounds like a really good idea.
I don't see a problem expressing the error the same way you would express them in the language itself
(Scott merged this pull request together with the fix of his strings in the last live stream).
ugame10 has been enhappified
Return as reference voltage, 5V for pins A0, A1, A4 and A5. These pins are only available on the extension board. For pins A2 and A3 the reference voltage will differ depending on the board. For main board it is 0.7V and for extension board it is 5V. For this reason, I return 0 for these pins.
@dhalbert See my other PR: https://github.com/adafruit/circuitpython/pull/4310
For pins on the extension board, 5V is 65535 full-scale. Is that a problem?
That would be a good test, will do
Would you want to have multiple pin names for the pins that differ only via level shift on the main board and the extension board? The AnalogIn object would have to remember them since the internal pin numbers are the same. It would be a bit tricky. I am fine with the current scheme. I assume you will document this somewhere.
I generally dislike the templates because often I file issues with only a sentence or two of info.
This won't be a problem... by default its optional to use the templates.
hmm, I put the tud_disconnect() to my example with pretty the same code, and it could reset and re-mount just fine. I dived into the dcd driver, and it seems to behave correctly within my simple example. However, in cpy, it stucks as jepler said. :thinking: :thinking: and :mag: :mag:
`import time
import board
import usb_midi
import adafruit_midi
from adafruit_midi.note_off import NoteOff
from adafruit_midi.note_on import NoteOn
from digitalio import DigitalInOut, Direction
MIDI settings
midi = adafruit_midi.MIDI(midi_in=usb_midi.ports[0],
midi_out=usb_midi.ports[1],
in_channel=(1),
out_channel=0)
Debug LED
led = DigitalInOut(board.LED)
led.direction = Direction.OUTPUT
...
Excellent! Let me know when you're around today. I should be pretty available.
@idle owl so if I want to apply the cookiecutter pylint patch along with my own PR in some circuitpython lib that's okay?
patches/0001-Removed-pylint-process-from-github-workflow-patch-2.patch is it this one?
@onyx hinge Please tag me so I can verify it, but yes, if you'd like to add it in, go ahead. The patch will simply skip that library. As long as everything is happy.
I need to check. Hold on. Because Dylan did a second one.
@onyx hinge Yes that appears to be it. If you're not sure, check cookiecutter's versions of build.yml and .pre-commit-config.yaml.
WIll do. Having hardware issues. again (le sigh). So can't get to my list o' questions. So will try to get it fixed up, or try to remember what they were!
No rush! I'm around
By default its optional to use the template.
I would like the template to be minimal. Something like the following for bug report.
Firmware
Adafruit CircuitPython 6.2.0-beta.2 on 2021-03-01; Raspberry Pi Pico with rp2040
Code/REPL
import busio, bitbangio
i2c = bitbangio.I2C(board.GP1, board.GP0)
Behavior
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TimeoutError: Clock stretch too long
**Descr...
@idle owl review request sent https://github.com/adafruit/Adafruit_CircuitPython_PIOASM/pull/12
I need to use this code in a guide so if you have a chance to review it I'd appreciate it
Ah fair enough. I was going to skip reviewing the rest, but I'll take a look.
This is beyond me. Can you walk me through the changes and why? I don't think I can really review it otherwise.
I get why you imported microcontroller ๐
Is this for upcoming boards that will have a built-in NeoPixel versus the Pico which will have an external one on GP16? if hasattr(board, "NEOPIXEL"): NEOPIXEL = board.NEOPIXEL else: NEOPIXEL = microcontroller.pin.GPIO16
Right, I want one unmodified example to work across the Pico and all of Adafruit's RP2040 boards
Ok, then what's going on with the rest of it.
because of reasons, init= is just not needed anymore (and there was much rejoicing)
Ok
and if you just send one color of pixel you can't tell it's doing anything
it skips using pixelbuf and all that stuff for "simplicity"
Right on. I'll approve.
thank you! it's very helpful
Does anyone know the max values you can obtain from a PDM MEMS mic? Is it 66535 or whatever that number is? Or am I way off on that.
I'm trying to do math with it and everything I'm doing works sort of but it's entirely arbitrary. I have no idea what the value range might be.
tested pico & feather rp2040 - both artifacts enumerate
Google is failing. (to give me a useful answer)
@idle owl yes, in CircuitPython when you use 'H', the theoretical values range from 0..65535, but what the center and extreme values are varies.
it's nice if the center value is around 32000 and if the 0 and 65535 values aren't reached in normal conditions
@onyx hinge Alright. Thanks.
I can't scream at this thing to test it, but it could end up used in loud places, so I want my math to work in "real" situations.
I get more consistent crackles if I'm doing PWM led (with dc changes) at the same time as playing (non-looping) sample. I've tried it disconnected from host computer too and it still crackles.
@microDev1 That works for me! Is it possible to add the template via a PR?
I didn't merge this during my stream. I only ran make translate. (See: https://github.com/adafruit/circuitpython/blob/main/locale/circuitpython.pot#L1089 is the original) @dhalbert do you want to update this PR with the rewording?
@onyx hinge did you see my issue comment about message priority in weblate?
Thanks - I am going to approve this for now and any pin changes can come later.
merge party!
This change looks good! Unfortunately, it looks like including the safe mode wait overflowed a few builds. @dhalbert how hard would it be for us to switch to the -Os libgcc?
OK, I will make these changes in the web interface, and will then push a make translate.
mp_raise_ValueError(translate("Out-buffer elements must be <= 4 bytes long"));
mp_raise_ValueError(translate("In-buffer elements must be <= 4 bytes long"));
@tannewt do I open a new one for the S2?
Yes please.
Running the following:
import time
import board
import touchio
touch_IO1 = touchio.TouchIn(board.IO1)
touch_IO2 = touchio.TouchIn(board.IO2)
while True:
if touch_IO.value:
print("Touched IO1!")
if touch_IO.value:
print("Touched IO2!")
time.sleep(0.05)
will result in A1 constantly reading as touched. If additional pins are added (IO3, IO4, etc) then all pins before the last one created will constantly trigger.
@ladyada ping so this i...
@dhalbert how hard would it be for us to switch to the -Os libgcc?
I will look into that, and also see if a simple CFLAGS_INLINE_LIMIT change would immediately.
oooooh having common_hal_mcu_processor_get_reset_reason return a constant made the compiler optimize away the whole rest of wait_for_safe_mode_reset ! I didn't think of that...
Long time no C as they say
Unable to replicate this. Tested with :-
Adafruit CircuitPython 6.2.0-beta.2-230-g64192b0eb on 2021-03-02; microS2 with ESP32S2
I suspect interference problems. Can you try with pins which are physically apart from each other.
@microDev1 interesting. I've edited the post to include the board (Saola Wrover). Your guess was correct, the pins only interfere when they're adjacent, putting them one or more pins away (IO1 and IO3) stops the issue. Should we consider tweaking the threshold value, or breaking it out on the board level? When using a wire to connect, it's so sensitive that even just holding your hand within an inch the wire causes it to go off.
Removed it and still tested OK. Thanks!
Nevermind, I see it's in the API. Sorry, haven't worked with TouchIO before.
Ya... while implementing TouchIO... I did all the testing on my microS2 which has very small traces + it is 4 layers thus having different electrical characteristics then most other boards. I think we can settle on a middle ground for threshold values which works for all of the boards... the api also offers some filtering features which might be helpful.
Looks good to me! Thank you!
I'm available at any time between now and the next 4 hours
@fossil gorge Excellent, now is good.
I still can't get into my computer to get my list, so going to try and go from memory a bit...
That works
So going through the list, I noticed there were two different extremes - Either many issues for one device/sensor, or some very old ones - like for the TLC59711 that's up to 785 days
Yeah the author is still working with us slowly on that one, so I've left it open.
Ah, ok. I was trying to sort out what would be most beneficial to work on - the old ones (guess not?), or devices with many issues, though some are also feature requests. Is there any preference in order, or whatever one's comfortable working on?
Whatever you're comfortable working on! I'd much rather you pick something obscure if it's something you'll enjoy doing than to pick up something and end up feeling like you don't want to follow through with it. That can be discouraging and frustrating and I want to avoid that for you.
I mentioned the Magtag issue yesterday, since I have one, and it's the new [available/released] hotness, and it's fun to work with
Understandable, and appreciated ๐
The oldest one is still active. The old-but-younger-than-that-one ones are probably not as active. If at all.
But don't let age determine what you decide to pick.
If you want to start with something on MagTag that would be perfect. I simply wanted to make sure you weren't limited and had more options if you wanted them.
Actually, maybe something that could help on that contributing page, might be (if possible), an "activity" indicator? Maybe how long it's been since something's changed (commit, comment, etc),?
Hmm.
Just a thought
I have no idea if that's doable, but I bet it is.
you can sort an issue based on its age or based on most recently updated (e.g. a recent comment)
Oh dang, I need to check in with my optometrist. TOTALLY glossed over that combo box ๐คฆ ๐
Right but I think Hugo is asking for something on circuitpython,org/contributing to show the last activity time on issues.
Oh good that that'll work for you!
yeah, I'm saying if it's in the UI, it's probably in the API
@tulip sleet Ah I follow now
Currently /contributing can be sorted by label but that's it.
It would require UI changes to more sorting options there, but it's possible.
@fossil gorge File an issue please? https://github.com/adafruit/circuitpython-org/issues
Sure thing
Be specific that it relates to the /contributing issue list.
I don't know if we need to update Adabot too. I can't remember off the top of my head if that's where it's pulling from.
Pulls some library info from there.
And then, as far as what to pick up and work on, I think I'm good for now. I'll let you know if I run into anything
@fossil gorge Excellent
aside from my computer losing it's mind
Indeed!
Thanks for your time! ๐
Thank you for yours!
While testing an example, noticed that board.LED did not exist. This adds it as another name for board.D13 / microcontroller.pin.GPIO13.
@ladyada don't know if you care to test/review, I don't have HW
This could include (or perhaps a separate issue & pull request) displaying the time since any action was taken on the issue.
@gilded cradle I need to add a new LCD driver to blinka, I'm not sure on how things are setup in terms of blinka/CPY drivers. I've got the LCD working using busio already...but I thought it's best to share the code in case others want it. Could you point me in the right direction for which git project or projects should contain the code.
@lucid solar the displayio code for Blinka is at https://github.com/adafruit/Adafruit_Blinka_Displayio but the individual LCD drivers it uses are the same as the CircuitPython ones.
are they seperate per driver_IC? so I'd need to make a new project
Correct.
It's the st7565 by the way
Ah, that one. I'm not sure if that will work in the Blinka Displayio drivers as monochrome display support hadn't been added yet.
Does it work with CircuitPython displayio?
I've only tested it using blinka and busio
That would be a cool one to add. I'm pretty sure I have one of those laying around somewhere.
What would you suggest is best? I can spend quite a bit of time on it...so if you'd like it done in a certain way, I'm up for it.
Maybe a separate CircuitPython library would be better for that particular one. Here's an issue I created a couple years ago for it: https://github.com/adafruit/circuitpython/issues/1505
This LCD (https://www.adafruit.com/product/250) is supposed to work fine with 3V logic, so I think it should work fine with CircuitPython. After looking at the Arduino code for this LCD, it looks l...
Is it SPI, I2C, or something else?
SPI
Ok, if you can get it working with CircuitPython displayio, that'd be awesome because once Monochrome Blinka Displayio is added it should just work. If not, you could just create a separate library for it.
https://github.com/adafruit/Adafruit_CircuitPython_ST7789 << should I base it on this? or maybe the nokia screen?
Probably the nokia screen. The ST7789 is a color display.
I cleaned up some more mpconfigport.mk files that I had missed before, and fixed the overflows.
It doesn't work if you set GPIO12 as input. Any solution to that?
Hey folx. I'm also updating the .pylintrc file to have the duplicate code check ignore imports as we do have some lib files with lengthy imports that exceed the duplicate code check threshold. Nothing needs to change on anyone else's part, simply an FYI. Cookiecutter is already updated.
Question: has the Cypress FX2 Hi-Speed USB chip with its Mass Storage Driver support been considered as a way to bring circuit python to any non native-usb microprocessors? Any existing examples or prototypes?
@gilded cradle I've progressed a little!
@hollow gazelle I don't know much about that chip, but an 8051 CPU core with 16kB RAM is too small for CircuitPython. "Snek" (https://github.com/keith-packard/snek) might be more likely to fit on such a small microcontroller.
Awesome @lucid solar, that looks great!
@gilded cradle Thanks ๐ Can you create a git repo for it? or should I ask @slender iron?
Sure, just a moment...
I guess https://github.com/adafruit/Adafruit_CircuitPython_ST7565 ?
๐
Ooooh, a package like adafruit_datetime does need adafruit-blinka due to use of const...
Great...I'll do a PR soon @gilded cradle
I was wondering why but answered the question for myself
@onyx hinge blinka can just use the full datetime library
@gilded cradle I'm developing something that can run on circuitpython but I have unittests in standard python
Unless you're thinking for portability
I used adafruit_datetime when running in standard python to ensure the tests were as close to reality as possible
Ok, gotcha
so I'm glad that blinka can install on standard computers ๐
Could you put this adjacent to the D13 def, below line 27?
@jepler is this all fixed and ready to merge? Did @ladyada test?
@gilded cradle https://github.com/adafruit/Adafruit_CircuitPython_ST7565/pull/1 Yay...PR#1
@lone axle I do have something you can help with though if you're up for it. The patches don't work on every library when we run them because some file is different or whatever. We have ~45 libraries that need the patch manually applied, which is to say, the updates applied via PR. Would you be able to help Dylan with that?
yep I can do that.
Alright let me put together the changes needed.
not that I know of
@lone axle Ok here is the list: https://gist.github.com/dherrada/aa7c621177f1e6e9f02d871d7c611da8 and here are the necessary changes: https://gist.github.com/kattni/6628ff59eb3b6cf01c391fb39f53c877 Please let me know if anything is unclear. Thank you so much!
I think I got it. Will start on them now and let you know if anything comes up.
We should port CircuitPython to the Cortex-A class Raspberry Pis. The main early benefit would be easy HDMI capable displayio.
Prerequisites:
- [ ] Port TinyUSB to the BCM chips. (Should be relatively easy because it uses Synopsis USB IP.)
- [ ] Add internal flash support for the emmc peripheral of the BCM
This should get CP booting and the workflow working. Then it'll be the common steps or implementing standard hardware APIs like I2C and displayio.
DTS that describes peripherals: https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/bcm2711-rpi-cm4.dts
Peripheral datasheet: https://datasheets.raspberrypi.org/bcm2711/bcm2711-peripherals.pdf
Compute module datasheet: https://datasheets.raspberrypi.org/cm4/cm4-datasheet.pdf
@idle owl first one done here: https://github.com/adafruit/Adafruit_CircuitPython_MLX90395/pull/1 the changes look the same from Dylans gist to me. Let me know if you see any issue with this one. I'll keep working my way through the list.
@lone axle Please request review from (at)dherrada and me so we both receive emails about them. Looks good to me!
@gilded cradle https://github.com/adafruit/Adafruit_Blinka/issues/308 << this is my next project. Might start it tomorrow. I've got a big Blinka based project coming up, so expect quite a bit of development coming outta Sweden in the coming weeks ๐
@idle owl I canโt find the read the docs for the new grid_layout library. Is this missing, or does it just take a while for ReadTheDocs to load it, or is google just not mapping it?
This is the library https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_Layout
Brainstorm from an email with Avram:
Why do you want to make CP a bootable system for Raspberry Pi?
I think it'd be neat because CP is much simpler than Linux. (It'll never be able to do everything Linux can.) This fits the nostalgia niche of the Pico MicroPython and emulator demos but easily support HDMI devices. It would take the simplicity and accessibility of the CircuitPython workflow and bring it to "the big screen". (Libraries are already available in CPython on Linux.) It'd be...
@slender iron for the countio/pwmio channel use check, seems to make sense to just make the pwm channel_use variable global - though I'll have to rename it or it collides a lot with other places
you could do that or add a private function to "claim" it
that you could use a different name for and it hides the variable
like add "claim_channel" to pwmio that countio can call? (and unclaim as well i guess!)
sure
figured easier to ask before I submit it
๐
always feel free to ping me if you want to run things by me
I'd rather chat about something before work is done than after
Yup same here. Like most problems so many different ways to solve it but rather be somewhat consistent
@mental nexus I have just tested the fix in BitmapSaver. Great Work!
@mental nexus Send me an email, kattni at adafruit dot com. It needs to be set up in a particular way that probably wasn't done. I can do it tomorrow but I'll forget!
Tested again as of https://github.com/adafruit/circuitpython/commit/15615effc2f8a9f991ace105f8a9f7bb51982059, and it still happens.
Sorry, but because I do not have an SWD debugger or a logic analyzer, I cannot provide any more info or debugging help.
Tested using bus_device, and it appears to hang when attempting to init the device, unless I pass in probe=False. Then it gives me the OSError I was getting before. Here's the code I'm using:
import board
import busio
from adafruit_bus_device import i2c_device
i2c = busio.I2C(board.GP17, board.GP16)
while not i2c.try_lock():
pass # Interestingly, it doesn't work without locking the bus. bus_device examples don't seem to require this.
print("i2c locked.")
lcd ...
Try using bitbangio.I2C() on absolute latest. I am still working on getting busio.I2C() to work.
bitbangio.I2C works perfectly, thank you.
i did test, i had a wierd hardfault once but couldnt repro it, and i think it had more to do with USB so this is ok to merge!
tested with feather + matrix featherwing!
I was thinking of using the FX2 as a peripheral, like we use an external chip for wireless.
Well... not exactly perfectly. I have to pass in probe=False, or else it just infinitely hangs.
@skieast and @microDev1 , I've been away from CP for a few days. How is the IDF update looking? Is there anything I can help with?
Looks like builds are failing:
Build raspberry_pi_pico for en_US took 7.80s and failed
make: Entering directory '/home/runner/work/circuitpython/circuitpython/ports/raspberrypi'
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
common-hal/pulseio/PulseIn.c: In function 'common_hal_pulseio_pulsein_construct':
common-hal/pulseio/PulseIn.c:76:15: error: too few arguments to function 'rp2pio_statemachine_construct'
76 | bool o...
I believe changes have been merged affecting the call to
rp2pio_statemachine_construct()
since PR 4262
was created. I will update my branch used for the PR to correct for this
change.
On Tue, Mar 2, 2021 at 8:12 PM ajs256 notifications@github.com wrote:
Looks like builds are failing:
Build raspberry_pi_pico for en_US took 7.80s and failed
make: Entering directory '/home/runner/work/circuitpython/circuitpython/ports/raspberrypi'
Use make V=1, make V=2 or set BUILD_VERBOSE similar...
Hello, before start the build rabbit hole and test, would anyone take a look a this code for the I2C peripherals for the PICO, I am more worried here about the semantics, and all the building blocks to do a CircuitPython library. any help is appreciated. Feel very free to code shame me.๐. C is not my mother language. https://github.com/jposada202020/PICO_I2CPeripheral
The RP2040 I2C hardware does not do writes of 2 bytes or less. They must be done via bitbang.
- Handle short writes with
bitbangio.I2C. A singlebitbangio.I2Cobject is created once, not on the heap, for use as needed. - (Style cleanup) Split
shared-module/bitbangio/types.hinto separate files:I2C.h,SPI.h, andOneWire.h. This makes it consistent withbusioand similar modules.
Tested and works with the following sensors:
- LIS3DH
- LIS3DML
- SHT31D
- BME280
- VCN...
@skieast and @microDev1 , I've been away from CP for a few days. How is the IDF update looking? Is there anything I can help with?
I too took a little break after running into a wall with the I2C and WIFI issues. I've started again and will probably ignore the wifi for a bit.
- Adds templates for
Bug ReportandFeature Request. - Also adds links to forum and discord server.

Is it possible to add the template via a PR?
Yup! #4316.
One thing I didn't quite understand. Are the i2c and WiFi issues in the current IDF version in CP?
thanks @jepler gdb trace, I have ound the issue. After tud_disconnect() is called:
- pull-up register is disabled and
- device got both
Bus Reset(SE0 > 2.5 us) andDisconnection event(SE0 > 2us)
The difference between my example (and other pico-sdk example) and circuipython is cpy disable the alarm pool feature PICO_TIME_DEFAULT_ALARM_POOL_DISABLED=0
There is no telling when the dynamic USB descriptors will be implemented โ we have been talking about them for years, and they are not a very important feature, but there are few people with the expertise. On the other hand, I have a number of devices that rely on this, and that got broken with #4283 โ if we had this earlier, we would have caught the problem. I suppose it's a trade-off between build times and coverage.
By the way, I did this with Fluff M0, because that's what I'm using, bu...
Yes. I'm not sure when the problem first appeared but it's defnitey there with 4.2. I was hoping that 4.3 would fix or at least change the issue. As I said I'm going to get i2c working then see if spi works. Those were the two areas where compile errors appeared that required changes. Then look at wifi.
I think there are two reasons to have this:
- You have a project used by multiple people that depends on no MSC (like the stenotype project I think you mentioned), and it is impractical to supply a custom build for that. That is what I though the original motivation was.
- We need to test whether various compilation flags actually work or not. This particular flag is one of many. I could imagine adding a test build that compiles a single language and board multiple ways. I would do it d...
Since I'm not actually selling those projects yet, I am mostly concerned with 2. If you think there is a better way to test this, please feel free to close this.
OK, I will close. I think the point you are bringing up is well-taken: we don't have a testing story for things like this, and we need to think about it in the long run.
Is it possible to exclude a directory from the docs build?
@analog bridge you can, via conf.py::exclude_patterns here: https://github.com/adafruit/circuitpython/blob/4167778bbce552c6e578a74e22db922c9cfb458e/conf.py#L151
.github is probably an acceptable addition, since none of those files should be included in the docs build.
or maybe .github/ is better?
thanks! @raven canopy... ya I want to add .github to it.
yw. should clear up that CI failure.
@dhalbert I will think how to handle it. This will be documented when we release our documentation for AnalogIn module.
The failed builds are all xtensa-build, unrelated to this PR. They are not even consistent with the other xtensa builds. I will try a re-run.
I don't know if I'm allowed to say anything here, but here it goes...
In my opinion, to the error template, it would be great to add a "Expected behaviour" section.
It might sound stupid because some issues like #4311 where the expected behaviour is to do not trigger adjacent pins.
Others, like my issue #4279, the expected behaviour is that it should throw an exception because the filesystem is readonly.
Others, like #4300, could be that the frequency should be different or similar....
Hi, on GitHub, why do CircuitPython libraries' README.rst files have a link to the information on building library docs? I would expect a link to the ReadTheDocs page for the libraryโฆ thx
@lavish saffron you can click the hopefully "passing" docs image at the top
we should make that explicit
Please make a PR so we can comment on it. ๐ No code shaming here. Only constructive criticism
Aha. I assumed (and see where it got me ๐ ) that the badge was a pat on the back for the docs building ๐คฆโโ๏ธ Thanks for the quick response. Perhaps we could make it a little bit bigger, too.
@shell bolt let me know if you have feedback on the nvm.toml stuff
we shouldn't have to do releases if the library code itself hasn't changed. @idle owl @trim elm
We need to decide what requires a release and what doesn't and update Adabot to ignore everything that doesn't. We've sort of done that with some things, but not since we changed how we're doing a lot of CI.
The only thing that should matter for release is library code or example code.
anything else, README, CI, whatever, shouldn't require a new release.
agreed. the only other thing I can think of is if the packaging settings themselves change
I'll talk to Dylan about it today.
I'm sure he'll jump on it since.. yes that. He's the one doing most of the work.
@lone axle the repos you couldn't request review on are missing write access for circuitpythonlibrarians
feel free to ping me on them and I can add the access. I just did two repos for you
@ismael-miguel That is great feedback! Since there is a PR (#4316), that is a better place for feedback.
Do we have an issue to add these tests?
@hathach We might be able to turn the alarm pool on. I didn't put a lot of thought into how we're using the SDK's timing. I was mainly trying to avoid the SDK doing any allocations because we're using all of RAM ourselves.
will do, thanks for the heads up.
@slender iron I will update the draft release notes in a little while. maybe we can do a release today
Looks good! Thank you!
@DavePutz There are five comments from me that haven't been responded to. Mind responding to those individually?
I think the main thing left is moving to the interrupt only handling the queued data rather than waiting for the output buffer to be filled.
Thanks for the PR! This does look very nice! It's cool that we can link out to the forum and chat.
about: Unofficial chat with many helpful folks and normally prompt replies.
about: Official Adafruit technical support forum. Good for getting help on getting a project working.
As per recommendation in https://github.com/adafruit/circuitpython/issues/4291#issuecomment-789852208, I'm giving my (edited) feedback here:
In my opinion, to the error template, it would be great to add an optional "Expected behaviour" section.
Some issues, like #4311, the expected behaviour is to do not trigger adjacent pins. (Duh!)
Others, like my issue #4279, the expected behaviour is that it should throw an exception because the filesystem is readonly.
Others, like #4300, could b...
it would be great to add an optional "Expected behavior" section.
Thanks! for the feedback @ismael-miguel. I expect the "Expected behavior" to be part of the Behavior section. Its not necessary to adhere to the format provided. The template just provides a minimal structure that can be further modified by the issue filler's needs.
it would be great to add an optional "Expected behavior" section.
Thanks! for the feedback @ismael-miguel. I expect the "Expected behavior" to be part of the Behavior section. Its not necessary to adhere to the format provided. The template just provides a minimal structure that can be further modified by the issue filler.
In Sphinx, does anyone know how to put extra text below the function definitions? I want to add documentation about a library, but I want it to be below the function. Otherwise, at first glance somone would have to scroll down to see the functions.
I've tried adding a text block after the function definitions but Sphinx just ignores it all. Do I need to add some other special .. something:: command?
Working on moving to an interrupt per word basis. I suspect this will affect the necessary frequency, as the SM program will change.
When I moved the exec things stopped working. I will use a different method to allow the API to work - replacing the fist word in the SM program based on idle_state.
The frequency needs to be lower so that we have fewer words to deal with in the interrupt handler. As noted in the previous comment I will likely need to adjust this.
Working on moving to a per-word interrupt basis. This requires saving some state between interrupts, and the timing will change; so the frequency/calculation will require adjusting.
Merging anyway, because failed checks are irrelevant.
@mental nexus Oh hmm. Try doing .. on a blank line above the text block, and then indenting the text block 4 spaces under the potentially-already-indented ..
Thank you for your insight @microDev1.
Personally, I would assume that Behaviour is meant as Observed Behaviour, therefore the suggestion to add the Excepted Behaviour section, to keep the waters separated.
But, in the end, I agree that the user can just ignore the template, despite being highly recommended to follow it.
@mental nexus Sphinx is serious about whitespace. It all has to be exact. Could be the number of blank lines between isn't proper or some such as well.
We still need to fix it though, the alarm pool is still infinitely check for SE0 every 1ms. This particular issue, it got lucky since reset happen. Else it will keep the alarm timer running until tud_connect() is called or cpu got reset.
So https://github.com/hathach/tinyusb/pull/692 would fix this for now? Should we update TinyUSB in CircuitPython?
I tried the latest master hathach/tinyusb, with the fix above, but it does not resolve this issue. So I won't update for now.
@mental nexus Did you see the collections.rst in the doc library, I think that is what you are looking for
@dhalbert no it doesn't yet. But the next one will. I tried to do too many small improvements while testing and it has too many unrelated modification. Therefore I merged it first, so that I could have a cleaner PR for this only and will tag rpi team for discussion in the next PR.
I don't see a collections.rst in most libraries. Can you point to an example?
<!-- Thanks! for testing out CircuitPython. Now that you have got a problem... you can
file a bug report for it. Feel free to modify the below format to better suit your issue. -->
HTML comments work in GitHub Markdown. Comments are usually used for instructions like this.
Looks great! I just suggest some changes to add clearer instructions.
<!-- Include your code that reproduces the bug here. Try to distill down to the minimum possible to reproduce. -->
<!-- Include the version of CircuitPython you're running. You can see it in the `boot_out.txt` file, as well as in the REPL. -->
@slender iron GP29 is the fourth ADC right? Pico did something special with it so they didn't expose it... But that's how we get 4 analog pins on the Feather RP2040?
correct. the pico board uses it itself
@slender iron On the Pico, there are SPIx CSn pins. What does CSn mean? Chip select?
yes
Thanks
@slender iron Sorry for continued questions. The RP2040, is capable of handling I2C and SPI on many pins, but am I understanding it right that it can only handle 2 of each at a time, and only on differing sets of pins? As in you can't do two I2C devices on two pairs of pins that are both I2C0, you have to choose an I2C0 and an I2C1? and same for SPI? Or am I misunderstanding what this means entirely.
correct
Ok
I think you know this stuff. ๐ How about writing it up as you think and then I can review after?
Ok. It's going into the Feather guide anyway.
๐
We're getting bad cache builds again, it looks like.
@slender iron @onyx hinge I think we are ready for beta release as soon as the builds clear. The RP2040 PulseIO PR is still in process, and there's nothing else imminent except for a weblate PR. We are getting xtensa build failures which I think are cache-related so I submitted a PR for that. If that clears, I would merge the latest weblate, and that would be it for beta.3. Does that make sense to you?
"as soon as" could be a while...
sounds good to me!
thank you @tulip sleet -- no objections
hummmm just pointed out to me by @idle owl the default board.UART() isn't enabled on feather rp2040 yet .. I'll file a PR
The board objects for SPI, I2C and UART use the "default" pins on the Feather, right? So the pins labeled SCK/MO/MI, SCL/SDA, and RX/TX? Because if I'm reading this right, and the pins really do match the Pico pins labeled on the back of the board (and in the schematic), then GP20 doesn't even have SPI on it. Unless the Pico pinout diagram is wrong.
@tulip sleet is it normal that the REPL is still available with CIRCUITPY_USB_CDC=0?
yes, the CDC in this case refers to the secondary CDC. There is CIRCUITPY_USB_REPL or REPL_USB, but I'm not sure it's functional
we will see in moment :)
@idle owl so I don't understand WHY but those pins ARE acceptable to CircuitPython. I don't have a device to check if they work, however. ```>>> b = busio.SPI(MISO=board.MISO, MOSI=board.MOSI, clock=board.SCK)
Neither do I.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid pins
``` and non-valid pins are reported in at least some cases
I think the diagram might not be right. The datasheet says it's SPI0:
Is that from the datasheet?
is that pinout art adafruit's or rp's?
it works
I scanned the datasheet and couldn't find something useful to pull from. I'll look again
@onyx hinge RPi
I think they omitted it because GP23 is not available, so the complete set GP20, 21, 22, 23 is not available
Hmm ok
This list is better than the diagram anyway
I'm struggling to translate this diagram to the Feather
that is not that good a reason, but ...
What is the F8 list?
the datasheet is the ground truth. The diagram is from RPi. I moved some elements around to make it narrower, but it's from them.
CLOCK GPIN0 etc.
I'd ignore it
I'll ignore it
OK. What are UART CTS and RTS?
ignore ignore
if you have a 1990s telephone modem you may care about RTS ๐ but I don't think our UART implementation can do anything with it
someday it might. if the pico C sdk provides it then maybe it should be in the pinout, since the pinout is not CPy only, is that right?
do we go to this level of detail about 'alternate' I2C, SPI, etc, on other feather guides?
We have pins 24/25 as well, and the Pico doesn't so that diagram was really not helping me. @tulip sleet Thank you for pointing out this list.
@onyx hinge I was asked to explain what these pins can do
Based on the Pico diagram. So I assume I'm supposed to go into this detail?
I mean if I don't explain the I2C0 and I2C1 thing, folx might try to do I2C on every set of pins that do it.
Easier to explain that 0 and 1 exist, and you can use one of each, and then number them in the list.
it is like the SERCOM<n> thing, but less general
@tulip sleet I saw that, thank you
thanks Dan for quickly clarifying with the datasheet!
Bleh have to keep referring to the SPI TX and SPI RX translation on the pinouts page in our Pico guide. Finally just copied it to a text file that is visible from behind my browser. Ugh.
I suppose it's worth including an explanation of PWM on RP2040 and the PWM slice/input info on each pin?
it seems like it's something confusing that needs explaining. I actually haven't tried to figure it out myself yet ๐
I actually understand it, as far as I know.
The MP book had info on it.
I'll write something up and see if it works.
Just a heads up -- something in tip of main is breaking font display on CLUE see <#learn-adafruit-authors message> works on 6.2.0-beta2
Tested on itsybits M0 and QT Py M0. The uart loses characters during reception at 115200 bit/s.
A PC with serial interface is connected to RX of the device and sends 26 characters (a-z) every 300ms. The attached test code reads the data and prints the result, the receive buffer is set to 64 bytes. Th test code waits for the begin of a data packet (while com.in_waiting == 0) and then reads all data it can get with a 100ms timeout. This code works fine with Version 5.3.1 but loses characters...
Ok. I think what I have here is right then. Thanks.
okay huh this is weird. I have a bdf font and a pcf font. the bdf font works fine. the pcf font shows only the first line, if there are newlines...!
(5, 8, 0, -1)
>>> f1.get_bounding_box()
(0, -249, -128, 121)
well that's clearly not right
and would explain all manner of weirdness
is https://github.com/adafruit/circuitpython/pull/4287 a step in the right direction also. We should merge it if it makes sense.
Did something recently change in how displayio or display_text handles updates to a label.
Can we move Print failure info to make it more relevant or just completely remove it... currently the ui defaults to showing it, hiding whatever fails above
>>> import time
>>> import adafruit_datetime
>>> for i in range(10):
... print(adafruit_datetime.datetime.now())
... time.sleep(1)
...
...
...
2000-01-01 00:27:44
2000-01-01 00:27:44
2000-01-01 00:27:44
2000-01-01 00:27:44
``` well this is weird
oh it's floats ๐
@ajs256 Thanks! for the suggestions. I am not adding all of the tags as they cause the enclosed content to not show up in preview.
If 4.3 doesn't introduce any new problems, does it makes sense to Merge 4.3 and work on issues not related to IDF 4.3 separately?
Thanks! @askpatrickw and @skieast for looking into this.
We can deal with issues not related 4.3 later. So far I have only found i2c and spi to be a concern.
@onyx hinge would you mind approving https://github.com/adafruit/circuitpython/pull/4318 ? It has apparently fixed the broken xtensa builds problem
thanks!
I couldn't uncover any way for Sphinx to put the help documentation below the parameters and methods in the ReadTheDocs. Instead, I learned how to make links to other sections. I can use that so folks can quickly navigate to the parameter/function list with just a click. I'll summarize my latest Sphinx battle as they say: "If you can't beat 'em, join 'em."
The text should now be mutable on all display_text label or bitmap_label. What issues are you seeing?
I am checking what HAT/pHAT board could work with the Pico. Board like the Braincraft and Adafruit Voice Bonnet do I2Sout (headphone) and I2Sin (microphone). Is it right to say that on CP side we only support I2Sout and PDMin, but not I2Sin?
That's unexpected. There have been some recent baseline additions, and there's a PR in the queue to handle tabs. Could it be putting your text somewhere off the screen? Strange that font file type would matter. Maybe it's recognizing \n as a glyph?
@mental nexus it's the font-reading code, I think, the bounding box is nuts
@slender iron To verify - the bootloader drive on the Feather RP2040 is also called RPI-RP2, correct?
yes, that's true for all RP2040 boards
Thanks. Wanted to make sure.
@mental nexus is there an API change? I was using @tidal kiln new guide for the "milk" checker https://learn.adafruit.com/digital-nose-gas-sensor-milk-freshness-checker/code-- it works on 6.2.0beta2 but the text updates give garbled output now.
Ok, send a note if you think it's and issue inside display_text.
@mental nexus I am not very displayio- fluent so hard to create an issue....
No problem, will see if I can check it out on my pyportal. Give me a few minutes.
Strange. The pyportal is hard crashing when it tries to display the text.
Definitely something about the mutability of the text. Looking deeper now....
I was originally running a CP version with the new "mutable Group" option loaded. I just loaded the latest stable from CP.org, and it's working ok. I'm suspicious that display_text is highlighting some issue with the Group.pop(), maybe it can "overpop" now? Let me go dig in more...
BTW - tha's a cool cow.
I think we need a "weblate - translator" for displayio ๐ and agreed -- cool cow!
^^ looks like a bug
It's working with the latest 6.2beta from CP.org. I can't find my firmware.uf2 from yesterday. I've got to go rebuild the new one with the mutable Group.
Maybe absolute newest has it...
you can use any "Absolute Newest" build since later yesterday. the "Group is a list" PR was merged yesterday
@tulip sleet Do you have a few to review this pinouts page? (It's super long, but I'm mostly concerned about the explanations in the Logic Pins section.) I think I explained it well enough, but I might have used a wrong word or something somewhere.
Thanks Dan, just noticed that, so it save me trying to track it down. Ok, confirmed that absolute newest is hard crash when text is changed.
It's crashing whenever the group list element is trying to modified on this line:
self.local_group[tilegrid_count] = face
@stuck elbow ^^ Group as list issue. @mental nexus Could you file a quick issue with a simple test case?
I think we will need to raise an issue with deshipu and revert the group change for now. This is issue: https://github.com/adafruit/circuitpython/pull/4233
Sure thing Dan. Let me make a simple code and I will add it.
unless someone sees a quick fix...
@tulip sleet I will look into it tomorrow
thanks!
@stuck elbow I think maybe this:
void common_hal_displayio_group_set(displayio_group_t* self, size_t index, mp_obj_t layer) {
_add_layer(self, layer);
_remove_layer(self, index);
mp_obj_list_store(self, MP_OBJ_NEW_SMALL_INT(index), layer);
}
should be mp_obj_list_store(self->members, MP_OBJ_NEW_SMALL_INT(index), layer);
@mental nexus I can make a quick test build, for which board? If you have time to test
i think i have the fix
The following code causes a hard crash when the group element is changed:
import time
time.sleep(5) # allow time to Ctrl-C if you need to
import displayio
my_group=displayio.Group()
bitmap1=displayio.Bitmap(1,1,2)
palette=displayio.Palette(2)
tilegrid1=displayio.TileGrid(bitmap1, pixel_shader=palette)
tilegrid2=displayio.TileGrid(bitmap1, pixel_shader=palette)
print('appending')
my_group.append(tilegrid1)
print('len(my_group): {}'.format(len(my_group)))
prin...
I'm using pyportal
Thanks Dan.
No crash on my test code, and now the cow code is giving me a smiling Cow. (note: But now I can't see the REPL with Mu.)
Looks good to me.
Screen can get to the REPL ok.
ok, I will make a PR! This build has the secondary CDC port, so Mu may be confused about which is the REPL COM port. However, I have always seen them created in consecutive order, and Mu looks for the first one, when I tested it
@tulip sleet argh!
simple fix!
how did that work in my tests?
Deshipu, sorry I missed it with my testing. I was only popping and appending with my initial look at it.
yeah, me too, come to think of it
And I probably added labels, but never tried to modify an existing label.
I will test it all a bit more over the weekend, I wanted to finally start on writing the game
Thanks for the quick fix, dan!
Fixes #4321. Tested by @kmatch98.
@tulip sleet thanks for finding it, I was looking straight at it just now and didn't see it
np - that was an easy one
@tulip sleet thanks!
@solar whale if you can review, I can merge when it's built
@tulip sleet I canโt test until early tomorrow. Happy to do it then if no one else can do it first.
And many thanks to deshipu for this awesome addition!๐ฏ
kmatch98 do you ahve a github id?
Itโs the same.
@tulip sleet If you have @mental nexus comment on it, I can approve it so you can keep moving forward with it. If that works for you.
Actually Deshipu already commented. I can approve if you like.
that would be great, thanks!
I verified the code working with the test code shown in https://github.com/adafruit/circuitpython/issues/4321 amd with the โcow codeโ https://learn.adafruit.com/digital-nose-gas-sensor-milk-freshness-checker/code.
@idle owl I just noticed displayio_layout never had a release. Should I go ahead and do that? or does it need pip env credentials or anything else you know of I should hold off for?
@lone axle All of that is global, so no, you can go ahead and do a release. That's necessary to add it to the bundle. It's not in the bundle, I filed an issue for that if you want to add it.
@idle owl one more question, on libraries that are failing the duplicate code check within module code (as opposed to example code) is the intention that we should refactor the module? or look into a similar fix as the examples?
Yes. Refactor. Please file an issue similar to the one on the PyBadger lib, I think it was.
will do, thank you.
@slender iron I am a bit puzzled .. when I ctrl-c and re-run the pioasm_neopixel demo it shows the wrong colors sometimes, and when it starts showing the wrong colors it's wrong until I reset... I'll try to characterize it better after S&T unless it cures itself.
Wasnโt there a floating issue with pins before that needed clean up and a ctrl-c might not be allowing that to happen?
Probably worth making mention of that in the contributing to libraries guide.
@fossil gorge Please send me an email at kattni(at)adafruit.com with that suggestion to discuss when I'm back on Monday.
Woah, copied your email address verbatim, with the (at) in there, pasted into GMail, and it "decoded" it. The machines, they're learnining!
@microDev1 Just to make sure I'm following. The i2c and spi issues are the same ones as before or new ones?
If they are not new, maybe you should make a PR from you branch where you had everything building and we can close this.
@onyx hinge could it be related to this? https://github.com/adafruit/circuitpython/pull/4160
I'm running Black on my local repo but when I push to GitHub, Black reformats a file. What settings do I need to change on my local version of Black so that it matches the pre-commit version? Thx
`
black....................................................................Failed
- hook id: black
- files were modified by this hook
`
There were changes to the IDF with 4.3 that require changes to i2c and spi. I2C is mostly done and seems to work as before. There is an issue with soft reboot / or wifi. You get to pick which one works. I am starting to look at SPI now. So basically should be the same as before once everything works. SPI had a lot of changes I think so I am hoping whatever microdev did works out of the box. :)
The version used in the repo is specified in the .pre-commit-config.yaml file ,e.g. https://github.com/adafruit/Adafruit_CircuitPython_BLE/blob/master/.pre-commit-config.yaml
You can install pre-commit locally to vet your changes before you commit:
$ pip3 install pre-commit
$ cd the-repo
$ pre-commit install
I'm looking for a circuitpython library for the Sensirion SPS30, sold by Sparkfun:
- https://www.sensirion.com/en/environmental-sensors/particulate-matter-sensors-pm25/
- https://www.sparkfun.com/products/15103
I haven't found one, so planning to start development myself:
These seem good places to borrow code:
- https://github.com/Sensirion/embedded-uart-sps (nice C/C++ code, I'd prefer circuitpython)
- https://github.com/adafruit/Ada...
Automated website update for release 6.2.0-beta.3 by Blinka.
New boards:
- unexpectedmaker_tinys2
- pimoroni_tiny2040
- pimoroni_picosystem
- pimoroni_keybow2040
- qtpy_rp2040
New languages:
- en_GB
@slender iron I noticed the QT PY(s) have a NEOPIXEL_POWER pin that is enabled in board_init, too late for init_status_leds and in particular wait_for_safe_mode_reset. How would we change that ? Would it be with a define that would be used in init_status_leds ? An entry in pins.c or board.c ?
I am hoping whatever microdev did works out of the box. :)
It should work, shouldn't it. ๐ค
I think only spi_hal_cal_clock_conf() has a major change.
I've been trying to work with the watchdog module on my UnexpectedMaker FeatherS2 (esp32s2) running 6.2.0-beta.2, and have noticed that the watchdog.deinit() function doesn't successfully stop the watchdog, nor does it raise an error indicating that deinit() is not available for this platform. My example script is:
from watchdog import WatchDogMode, WatchDogTimeout
from microcontroller import watchdog as w
print("Initial mode:", w.mode)
w.timeout = 10 # Set a timeo...
Delete subscribed task before watchdog deinit. Fixes #4324.
@tylercrumpton Thanks! for reporting this. Can you please test the fix in the linked PR. You can find the build artifacts here.
Hello, I am currently trying to connect to some ESP32-S2-Saola devboards that are running CircuitPython 6.1.0 via the USB OTG pins, but the device shows up as as "Unknown USB Device (Device Descriptor Request Failed)", and I see the following error in Windows' Device Manager:
Windows has stopped this device because it has reported problems. (Code 43)
A request for the USB device descriptor failed.
The boards I tried are manufactured by Espressif and are powered by the ESP32...
@tulip sleet @tidal kiln 6.2.0beta3 works fine with the "Milk" detector -- thanks for the quick fix!
- fix #4066, need https://github.com/hathach/tinyusb/pull/700 to merged first to be able to bump up tinyusb (draft for now)
- also use the normal usb_irq_handler() as well with dcd_int_hanlder() wrapper added with tinyusb recently.
The xtensa builds are using an old cache id. We can ignore their failures.
The xtensa builds are using an old cache id. We can ignore their failures.
I am doing rebase and will push force again.
Testing performed: Loaded a FW from this PR, ran storage.erase_filesystem(). It worked.
Thank you!
Lol. Crashed when doing the spi construct. I'm on the ski hill for a few hours and will dig in later. I have an idea what it is. Probably wrong but it's an idea.
Tested this with my sample watchdog deinit() script, and it all looks good here! The script:
from watchdog import WatchDogMode, WatchDogTimeout
from microcontroller import watchdog as w
print("Initial mode:", w.mode)
w.timeout = 10 # Set a timeout of 10 seconds
w.mode = WatchDogMode.RESET
w.feed()
print("Watchdog running mode:", w.mode)
w.deinit()
print("After deinit mode:", w.mode)
while True:
try:
while True:
pass
except WatchDogT...
Done! It all works as expected now, thanks! I tried out both the RAISE and RESET modes, and they both allow me to deinit() and re-setup the watchdog now.
Let's ignore the build failures for now, though I'm surprised the rebase did not help.
Thank you for the quick fix, and @tylercrumpton, thanks for testing!
Ignoring single failure due to build cache.
@slender iron @onyx hinge I am trying something different with release notes: I created a draft beta.4 release note immediately and will be adding PR's as they are approved. Let's see if I can keep up. It will make it a bit easier to decide to do a beta.
A user of TinyUSB noticed the MIDI Endpoint descriptors were 7 bytes instead of the 9 bytes specified by the USB MIDI 1.0 spec. The size reverts to 7 bytes in the USB MIDI 2.0 spec, adopted in May 2020.
This was fixed by @hathach in https://github.com/hathach/tinyusb/pull/688. He noted that CircuitPython is using 7-byte descriptors.
The odd thing is that our current code works. I think the descriptors may even have be...
@dhalbert both the host and device stack is able to skip the endpoint descriptor correctly using the bLength (1st byte of the descriptor). And both the additional synch and refresh bytes aren't used by MIDI v1. It is pure luck that it works so far :smile:
Still crashes on 6.2.0-beta.3. Works fine on a PyPortal, so it's something specific to the MagTag, perhaps specific to EPaperDisplay.
Ran the mentioned code on microS2 and pi pico with nothing attached in both cases... crashes on the S2, works fine with the pico.
The modules SSL and Socketpool aren't present on the Matrix Portal M4. Explaination?
Maybe it's as simple as doing board_init before LED init
The matrix portal doesn't have native networking
it's SSL and socketpool equivalents should be provided by a library (ESP32SPI)
I confirmed that this fix does not fix the crashing. It's important, but there's some other bug.
@tannewt shared with me some initial code related to rotaryio, but it's incomplete: https://github.com/tannewt/circuitpython/tree/rp2040_rotaryio
@jun2sak has figured out how to do this in a draft PR for sleep on the nRF52: https://github.com/adafruit/circuitpython/pull/4236#issuecomment-788114698
@gilded cradle thank you for that matrixportal PR. Any idea on why that data source was causing that memory error to begin with?
@slender iron ^^
@gloomy shuttle yeah, the data source is probably too big. I did a gc.mem_free() right before the json parsing and it had like 52KB free.
Alright, thank you!
The reason Magtag works is because the requests module is built into CP on the ESP32-S2
So it has a bit more free memory
yw
Still, I'm going to see if I can make it a bit more memory efficient.
There is several update for rp2040 lately. I will try to update & test with this next. Though I am using Linux, not sure if it has any differences.
Ya, feel free to change it. We inherited that from micropython
Reopening as #4287 does not fix this.
Please post a picture of the boards you are using with the USB cable connected.
Great! Thanks for working on it. Another good reference for standard sensor property names and units is: https://circuitpython.readthedocs.io/en/latest/docs/design_guide.html#sensor-properties-and-units
Great! Let's start with this. Thank you!
- The ability to query the depth of the rx fifo
- The ability to set pull up/down/bus-keep
- A function to check if pins are sequential
Also a few other things "crept in":
- A missing deinit call in PDMIn
- StateMachine.h was not a self-sufficient header, it needed the declaration of mcu_pin_obj_t
With this tree, it's possible to implement a form of IncrementalEncoder in pure Python:
Click to show Python code
# This example is adapted in part from micropython:
...
Whee. PIO is so well-behaved. What a breath of fresh air.
I put a printf at the end of _update_current_y() in TileGrid.c on a Metro M4. The values for self->absolute_transform seem way off. dx and dy are multiplicative scaling factors, so a dx of 117 is way off. The absolute_transform structs are shared as pointers: the child points to the parent one, so if it got smashed, bad things would happen. The Metro M4 doesn't crash but that's just an accident. This is not port-specific. The bug still needs to be found but this is pointing tow...
Thanks! I think you need a make translate. Code looks good otherwise!
@tulip sleet Thanks for the help with graphviz. Got it working on the displayio_layout library documentation today. Thanks for the detailed steps to get it working!
@slender iron I am trying to fix the transpose_xy bug. I know what is wrong, but I'm not sure about a NULL absolute_transform in TileGrid. the _update_current_x and y routines assume the aboslute_transform is not NULL.
VectorShape in vectorio has a special null_transform value. to avoid this It never uses a NULL pointer. I could use that and never use a NULL pointer, but it might slow things down? Just not sure of your intent in this code. If .transpose_xy is set to true with a null transform, would the position move or not?
I started using graphviz eons (decades) ago. It is really neat
I've paged out that info. I'd need to go back and squint at it
@mental nexus has been in that code more recently
I've never delved into the transform issues in the TileGrid core (actually just learned that transformation it was available last week). And I know even less about vectorio.
ok thanks. the last q is really the operative one. If the tilegrid doesn't move with a null transform when transposed, then it's easy to fix. I will stare at it a little bit longer
that's not the right q, but yes, I need to update the width to be the height and vice versa, so I need to do something
Using cPy 6.1.0 firmware and load to nucleo-f767zi board. Selecting properties on cPy drive shows total size about 90K which is significantly lower than the 2M available on the board. Flashed uPy for same board and it shows the correct amount of available storage 2M. Looked at the STM32F767_fs.ld files in each distro and find that the uPy distro version has another line in the file: "FLASH_APP (rx) : ORIGIN = 0x0800x000, LENGTH = 2016K
I believe this line needs to be inserted into the cPy...
Changes made to allow interrupts on a per-word basis; other minor changes made.
Build errors with latest distro and STM32F767ZI nucleo board. Error output is:
make BOARD=nucleo_f767zi
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
QSTR updated
../../lib/tinyusb/src/common/tusb_fifo.c: In function 'tu_fifo_write':
../../lib/tinyusb/src/common/tusb_fifo.c:149:6: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
if ((p > p + offset) || (p + offset > f->max_pointer_idx))
^
cc1: all warnings being treated as errors
../../py/mkrules.mk:55: recipe for target 'build-nucleo_f767zi/lib/tinyusb/src/common/tusb_fifo.o' failed
make: *** [build-nucleo_f767zi/lib/tinyusb/src/common/tusb_fifo.o] Error 1
Need some help with this error...
Fixes #4284.
Setting TileGrid.transpose_xy forces the x,y, height and width to be recalculated using _update_current_x and _update_current_y. Those routines did not handle the case of absolute_transform being NULL, and used NULL as a pointer to a transform, so they got random values.
This fix guards against that. It also makes null_transform, an identity transform defined for use in vectorio, be a global. I used it in the fix.
An alternative fix would be to never use a ...
This error should go away if you use the gcc 10 toolchain. My guess is you're using an older compiler. See https://learn.adafruit.com/building-circuitpython for toolchain installation info
Thanks! I think you need a make translate. Code looks good otherwise!
@tannewt done -- if you get a chance to check again, that'd be dandy
I thought I'd try upping the buffers a lot.
left = WaveFile(left_file, bytearray(2 * 8192))
right = WaveFile(right_file, bytearray(2 * 8192))
Those (16k stereo 16bit) play sequentially with some minor distortion but when some PWM GPIO stuff runs and audio plays the Pi Pico dies and becomes non responsive over USB. PWM output is left running. Never appears to recover. I reset via the RUN pin and it does not do the hard fault handler thing. Do you want that as a separate issu...
For general clock changing we could just make
microcontroller.cpu.frequencysettable. We'd need to validate that all of the downstream clocks are ok when this is done though.
@tannewt Was something similar to making microcontroller.cpu.frequency settable ever done? Running the stm32f405 at 168Mhz creates noise that jams GPS antennas, so the stm32f405 feather cannot be used with the GPS featherwing at that freq. Having it settable would allow users that are using it with gps to ...
We haven't touched this in a while and currently the STM32 clock setup settings do not have any mechanism to change them at runtime. But I'd also note that allowing the user to lower clock speed across any microcontroller family could lead to some huge power improvements, now that we have the Alarm/DeepSleep module enabled.
I tested this with a FeatherS2, CircuitPython 6.2.0-beta.3, and the latest adafruit_il0373.mpy. There were no errors.
One thing that I have seen is that a stray copy of a library is left in / on CIRCUITPY instead of in lib/. sys.path is set so that / searched before lib/. Also, any .py version of a file takes precedence over a .mpy version, so if both were available, you might have gotten an older version of the library.
I will close this for now but please reopen if y...
Moving to a 6.x.x milestone since there's now a workaround.
Moving to 6.x.x bug fixes since using bitbangio.I2C is now a workaround.
the STM32 clock setup settings do not have any mechanism to change them at runtime.
Would it work putting an option in boot.py then? (sorry if that's a dumb question, pretty new to this)
Yes, I will try this tonight, Both in the "simple" code example and in the New Veritcal label proposal. Thanks @dhalbert . I will report my tests in here.
I have had "freeze" of the console on the PICO and Mu being unhappy with very simple code in the REPL: import board + import digitalio (nothing else). This is after stopping code.py. And this is with beta3. There must be something wrong that interact with my code.py and what take place in the REPL just after. I still get unresponsive to Ctrl+C from time to time.
Sorry, I cannot really replicate, just if you have similar issue but ignored it, then I am not alone.
Two questions:
- Should I still work on the
feather_m0_expressin the top comment for building out the ninja script? Or is there reason to merge the years' worth of changes from main back to the ninja branch?
$ git clone -b ninja https://github.com/tannewt/circuitpython.git
$ cd circuitpython
$ git log --oneline origin/main..ninja
8d63932dd (HEAD -> ninja, origin/ninja) Fix qstr generation. Fails with linker script now
d2838e585 Merge remote-tracking branch 'adafrui...
After the checks pass on a library pull request, how can I go review the documentation files that were generated during the Sphinx build?
@dewalex no, unfortunately. There is no way to modify them from Python. If you are confident with C, the existing option for reducing clock speeds would be to build Circuitpython yourself, after redefining the clock macros in ports/stm/peripherals/stm32f4/stm32f405xx/clocks.h in ports/stm/boards/<yourboard>/mpconfigboard.h. This has been done once before for the stm32f746g_discovery board by an advanced user. You would also need to calculate the appropriate clock settings using ST's Cub...
Here are some pictures of the board and some of the wiring attemps I've done.
<img src="https://user-images.githubusercontent.com/7206320/110038609-3e356e00-7d40-11eb-9c74-2a1a26c7d046.jpg" height="240"><img src="https://user-images.githubusercontent.com/7206320/110038615-41c8f500-7d40-11eb-94f0-b1be00c2d424.jpg" height="240"><img src="https://user-images.githubusercontent.com/7206320/110038619-442b4f00-7d40-11eb-8b6e-85113b0d7699.jpg" height="240"><img src="https://user-images.githubuserc...
is this a typo?
https://circuitpython.readthedocs.io/en/latest/shared-bindings/aesio/index.html#module-aesio
in the example:
cipher = aesio.AES(key, aesio.mode.MODE_ECB)
extra mode ?
Hi folks, can I please get some clarification on how AnalogIn (ADC reading) on the ESP32-S2 port is handled re ADC setup for range?
I remember some discussion early on about folks confused it wasn't 0-3.3V(ish) by default and there was discussion about making it 0-3.3V in CPY instead of the default 0-1.1V range.
I'm not sure if this is helpful or even close to what you are asking, but playing with the ambient sensor on the FeatherS2 on a moderately bright day was giving me readings in the 51k range.
The ambient sensor divider wasn't setup to be a direct mapping of voltage like what you'd want if you were reading the VBAT voltage etc.
Thanks for that advice. I've added pre-commit to my workflow. Eliminating the Black version from the equation led to a solution ๐
@tulip sleet Heads up I have just tested the fix for the transpose_xy, with the simple code and the Magtag did not crash, I will do more testing and put my final findings in GIthub, thanks for the fix!!!!
I verified my Saola will mount (Mac though). But take a lok at your command line, I believe b is baud: --chip esp32s2 --baud 115200
So those MCU running from flash, could they run faster running from ???
Thank you Scott.
@hierophect sadly my confidence in C is even less than Python. Do you think these boards could have two separate bin files for setting up CP, where the user could choose which one to install based off their use case? I would imagine the GPS featherwing is the most popular wing, so there will be a lot of people that would have the need to run the clock one step down.
I missed any verification of the pins being in order, as required for pio. In #4329 (pending) we will add a convenience function for checking this.
do we need a "never reset rp2pio_statemachine"?
looks like main doesn't build, a trinket m0 fw is too full. if nobody else picks it up I'll look tomorow I guess.
In the ParallelBus python interface you only give it data0 and the other pins are by definition of the interface immediately following.
Did we change something from 6.1.0 to 6.2.0-beta3 that could affect the SPI, the library adafruit_bitmapsaver works for me in 6.1.0 but fails in 6.2.0- beta3?. I have problems when saving to the SD card.
This was tested in using the new proposal Vertical Library PR122 https://github.com/adafruit/Adafruit_CircuitPython_Display_Text/pull/122
in
Adafruit CircuitPython 6.1.0 on 2021-01-21; Seeeduino Wio Terminal with samd51p19
Results

and in the MAGTAG
Adafruit CircuitPython 6.2.0-beta.3-14-gb1268107a-dirty on 2021-03-04; Adafruit MagTag with ESP32S2
Results
![...
Please file an issue with details. It could be many things. Thanks.
For my own knowledge are the never_reset_* functions checked so when we go to the REPL they don't get reset and lose the display or anything else?
If so then yes we do need it, I can look at figuring out how to add it to this PR or make it a separate PR and wait to resubmit this one?
Is there a GUI tool to copy CPy libraries to a connected board. If not, this would be super useful. It could also keep the library bundle up to date. I'd make it myself but I'm net very good with making good usable GUIs.
I think our plan is to integrate circup into editors/extensions
Thanks, I didn't know about circup so I'll check it out.
Makes sense to me, but I didn't test.
On man, that is pretty much what I'm looking for. I'm OK with a command line tool and this it going to save me a lot of time.
I love circup, it took me a long time to start using it and I regret that I waited. If we can give users a good UI for it, it'll be even more amazing.
@onyx hinge Good catch on the never reset statemachine - it actually does already exist just not in the .h file. So fixing up my build for it
I'm good with the command line but might add search capability for the available libraries and completion for installation. I suppose fulfilling dependencies might be an option too.
@blissful pollen you're welcome
it does manage dependencies
or maybe you mean like reading a requirements file ?
I mean if I do 'circup install xxxx' that it looks at what libraries xxxx depends on and installs everything.
Fixed in the latest commit. Had to include common_hal_rp2pio_statemachine_never_reset in the bindings .h
it does, try circup install adafruit_magtag and see the libraries flow
if you see cases where it doesn't, that's a bug to report
That's awsome. I'm working with the Wii nunchuk atm so I'll check it out.
Here is another vote for it :)
By now i've tried arduino, vusb, teensy, and pico pi and only teensy seems to have a full featured keyboard that works in BIOS and KVM devices.
The teensy itself is also a composite device, having keyboard, mouse, serial and still works fine with a KVM. So my best guess is, that it only depends on a correct implementation of the boot keyboard.
As far as i know, a boot keyboard needs its own descriptor and endpoint and on top of it, it has two additional funct...
Firmware
Adafruit CircuitPython 6.1.0 on 2021-01-21; Adafruit ItsyBitsy M4 Express with samd51g19
Code/REPL
import board, busio, ps2io
kbd = ps2io.Ps2(board.A2, board.A5)
spi = busio.SPI(board.SCK, board.MOSI, board.MISO)
Behavior
code.py output:
Traceback (most recent call last):
File "code.py", line 3, in
ValueError: MOSI in use
Code done running.
Description
If the kbd line...
We are currently out of endpoints on most boards with 8 endpoints, having added a second CDC. If someone would like to contribute boot keyboard and mouse descriptors and compile flags, we'd be happy to include them. We would not turn them on normally, since they would remove having MIDI or the second CDC available by default.
This is another indicator for user-configurable USB and USB HID descriptors. However, we are pretty much out of space on the smallest builds, and don't have room to a...
The trinket_m0 build was running out of space on the latest PR's. It has more in it due to having a DotStar (I think).
These compile options saved about 500 bytes total.
Still left as a possibility is to use a -Os libgcc.a, instead of the current -O2 one, which makes software floating point and various other arithmetic routines noticeably smaller (by at least 1kB or 2kB, I forget which). I have not measured the performance decrease.
I am getting paradoxical results on pewpew_m4: the --param max-inline-insns-auto increase is increasing the size rather than decreasing it as on the trinket_m0. Turning this into a draft while I experiment.
does anyone know if the FeatherS2 has support for audio over the (two) DACs? https://feathers2.io/ shows it has two DACs, but the board page on CPy.org (https://circuitpython.org/board/unexpectedmaker_feathers2/) doesn't show that audioio is included in a build. thanks! (please thread or @ me since I'm going to be afk for a while)
@twilit geyser audioio is not currently implemented on the S2.
Remove Print failure info from CI as in the case of a failure the ui defaults to showing it, hiding whatever fails above.
Nooooooooo. Do you know if I can still have audio output from it though?
the S2 does support audiobusio and there is an issue tracking the audioio implementation
https://github.com/adafruit/circuitpython/issues/3898
@dhalbert boot keyboard doesn't need to be on its own interface and/or take extra endpoint. It can be used with existing HID device. Basically the HID device has 2 mode (or protocol): boot mode, and report mode (default).
- In report mode: it is composite (keyboard + mouse + media key)
- In boot mode: it only report 8 bytes of keyboard report (no report ID)
Most bios will always start with SET_PROTOCOL = BOOT upon enumeration. We only need to handle the callback, set the mode correctly ...
Aha, great, thanks! I will await your example. It would be more complicated to add a boot mouse, but at least having a keyboard will satisfy many needs.
Is there a definitive place to check whether a certain merged PR was included with a specific release like the new beta.3 release for instance?
the release notes lists all the PR's between beta.2 and beta.3
the betas are currently done from main, so anything before the time of the tagging would be included. We have not created a beta branch separate from main
this is not always true, but right now main and 6.x are the same
the release notes are done by hand, so I might have missed one ๐ but I try to be thorough
Okay thank you. The one I'm interested in is microcontroller.nvm on rp2040. I'm assisting a user whose having some trouble with that. Wanted to make sure it was expected to be in beta.3 before we got too far along.
I do see that one listed there. This is great, I'll have to remember to check these release notes. Really great source of information here.
This is fine by me. A number of things make debugging tough on these samd21 boards as it is.
Unfortunately, the gains are not uniform. for instance, "meowmeow" no longer fits:
Build meowmeow for de_DE took 17.64s 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.
/usr/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: build-meowmeow/firmware.elf section `.text' will not fit in region `FLASH_FIRMWARE'
/us...
I'm trying the NVM example on: https://circuitpython.readthedocs.io/en/latest/shared-bindings/nvm/index.html?highlight=NVM
using the line: microcontroller.nvm[0:3] = b"\xcc\x10\x00" after importing microcontroller, both in REPL
This gives a syntax error Invalid Sybtax

boot_out.txt is: Adafruit CircuitPython 6.2.0-beta.3 on 2021-03-04; Raspberry Pi Pico with rp2040
each interface can only either support boot keyboard or mouse, to support both, we need an extra interface though.
But when in boot mode, you don't need MSC and CDC and MIDI, no?
This is a docs issue... can you try with microcontroller.nvm[0:3] = b"\xcc\x10\x00".
But when in boot mode, you don't need MSC and CDC and MIDI, no?
Good point - it's more a question of having code space on the smallest builds to switch back and forth.
Yes, that appears to work fine - Many thanks microDev1
This is fine by me. A number of things make debugging tough on these samd21 boards as it is.
Documentation has a stray \.
Not used outside of PulseOut.c
@dewalex I'd rather directly go for dynamic frequency adjustment through @tannewt's microcontroller.cpu.frequency suggestion, if possible. I'm not sure if we have precedent for having multiple bin files for different clock settings, it's possible we'd need to create a whole new board profile.
Not sure if this is super helpful or not, but the Pi 3A+ also has OTG, I think.
(Also, really REALLY cool idea! happy to test it on my pi 0 w and pi 4 once alpha builds are out)
This is an AWESOME idea! Can't wait to test some alpha builds when they come out!
Creating this so that frequency/overclocking/underclocking issues can all go to the same place, as opposed to being specific frequency requests per port.
The idea here is to make microcontroller.cpu.frequency adjustable at runtime to allow either overclocking for performance gains (#4176) or underclocking for power savings/noise reduction (discussion in #2284). However, this could end up being a bit tricky in practice, since system clock changes tend to cascade into the peripherals and c...
Perhaps we could do this "on next reboot", so that all the initial setup stuff is done with the new clock speed.
@tyomitch Are you doing a by-hand code audit, or are you using a tool? Could you consolidate these into one or a few PR's? Thanks. Each PR generates about 40 minutes of CI time.
@dhalbert that would be one way to do it, but it'd also be nice to give it a way of doing this before and after sleep mode. Clocking down has massive power implications for STM32 and I assume the same goes of the other ports.
I wonder, do we need to build all languages for every PR, or we could do just one, whichever is the largest at the moment
The single failure in the latest build was a network error, on a build that did not fail before. @jepler, this is ready for re-review.
The largest can vary by board to some extent. We could build a few instead of all, thought at merge we will want to build them all. We just turned off several languages that had real translations.
@lone axle heya, are you around?
I am for the moment, but an in and out a bit today.
Could I merge this PR in for you (https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/pull/124) ? Need the CI to pass - duplicated pylint errors :\
This is a PR fixing pylint's duplicated code errors, am I understanding that correctly?
wahoo, anybody want to kick the t(i/y)res of rotaryio for rp2040/pico? I had one problem left, and suddenly it became clear ๐ https://github.com/adafruit/circuitpython/pull/4329
yep You can approve / merge. It does deal with duplicated code errors, but only in the examples. If they are in the library this PR won't make it pass.
I have a volume-control program I could try this on
@lone axle I'm going to see if my PR fails, then merge into master and merge into my PR. Thanks for the clarification.
@onyx hinge I would but don't have any rotary...rotaries..around my desk rn :\
@prime flower I discovered the same. I know there are some somewhere because adafruit.com says I bought them in the past.. but I can't find 'em. Software is fine for generating test patterns, though
been there!
when you've looked in all the likely spots .. give up and order another
works with my volume program!
@tulip sleet thank you for testing!
I tested with a volume-control program I use daily on a Trinket M0. It works just fine!
Did you diagnose the "dead spot" problem from #3967? I don't see that issue immediately.
No, I used the same quadrature decoder as the samd port.
Print Failure Info is for printing differences detected by 'Test all'. When some other step fails, then "*.exp" doesn't match any files at all, and this step fails too.
Following https://stackoverflow.com/questions/4839214/does-ash-have-an-equivalent-to-bashs-nullglob-option detect when "*.exp" doesn't match anything and avoid an error.
This is hard to test, so testing performed: Looked at 7 lines of shell script and was unable to see any problems.
This is an alternative to #4334,...
@tulip sleet think I should merge #4329 based on testing, or wait for scott to give it a code review next week?
I'm having trouble with my QT Py with the GD25Q16 soldered on the bottom. I loaded is with the 6.1.0 haxpress uf2. I run the neopixel blink code for the QT Py and it works but when I hit the reset button or unplug/plug the board it reverts back to hello world and the lib directory is empty. Here's a pic of the flash chip soldered on. It looks OK to me.
I am looking for a specific open issue and can't find it. Does anyone recall which item is open to implement an HTTP server? Hmm... now that I read that back to myself, maybe this is a library not in the CP repo...
If I wanted to have a FeatherS2 output audio (not just a beep), do I have any options besides using a separate board for that?
It just got worse. I have a second QT Py doing the same thing.
is there any way to read Neopixel data from the seesaw i2c?
I don't do any audio work, but have you had a look at audiobusio?
I kinda did?
how would that be very useful? AFAIK, i'd then need a I2S to output board
although that wouldn't be a problem i guess
Yeah, there is not a speaker on the FeatherS2 so you'll need something for sure
I bet there is an amazing learn guide on Audio, let me look
@tropic rain How are you copying your files to the QT Py?
yes
@twilit geyser nothing specific to the Feather S2... There is some Audio on the Maytag guide, but it has different hardware components than the S2.
I'm using circup to get the libraries to the board and then using cp to copy the program. It runs fine and I can see the files. restarting seems to be the issue.
Are you ejecting the CIRCUITPY drive before resetting or unplugging it?
Tried both with no luck.
One style thing. Thanks for doing this!
Just always put the comments on a separate line; I think that's the best policy.
Since there are significant additions to StateMachine.c, I would defer to Scott on those.
I also tried the 6.2.0 beta uf2 file and it acted the same.
The haxpress version?
On the QT PY (M0 and 2040) there is a NEOPIXEL_POWER pin required to enable the neopixel. It is set in board_init, after the rgb_led_status_init (in main.c), too late for wait_for_safe_mode_reset to use the neopixel.
This PR moves the LED inits and safe mode related functions to after board_init().
@tropic rain are you copying the new UF2's to QTPY_BOOT (correct), not CIRCUITPY? I just tried this on a QT Py Haxpress and unplugged and plugged it in and it's working for me
make sure the version shown when the REPL starts up is correct
did you get the GD25Q16 from us? I can't see any markings on the one you soldered on. the filesystem would get reset only if when the board restarted it thought there was not a valid filesystem on the board. Then it would reformat it and put back the "Hello, World" program.
I don't understand the use of an obscenity here. And you could use nullglob as suggested.
I was unable to determine whether the CI is guaranteed to run with the bash as the shell. The snippet above is intended to work with any sh. If it's guaranteed to be bash, then nullglob is a better solution.
@hathach Are you sure about the not needed extra endpoint? I tried a few times getting this to work with the arduino environment and to have an idea where the issue is i used this tool https://www.thesycon.de/eng/usb_descriptordumper.shtml and a real keyboard always used an extra endpoint.
@dhalbert
during my research i never found someone asking for a boot mouse. Most BIOSes are configured by keyboard and Hotkeys in KVMs are also done with a keyboard
I tested this by hand, and it works, but it's pretty obscure. Could you add a comment about what it's doing?
@hierophect Yes, that definitely sounds like the better route to go, I just wasn't sure how much work would be involved in that for getting it working for all boards. The idea of clocking down to save power sounds really useful too. Thanks for opening the new issue.
The shell is bash now, and can't be changed lightly without breaking workflows, so let's assume it. I've changed the code to set the nullglob shell option instead of using the complicated and portable way.
You should find it as soon as your order arrive.
Mmm, I'm definitely getting into boot mode and the device name is QTPY_BOOT and REPL and boot_out.txt show:
Adafruit CircuitPython 6.1.0 on 2021-01-21; Adafruit QT Py M0 Haxpress with samd21e18
did the flash chip come from Adafruit?
Tested on Teensy+Dazzler hardware, looks good.
Superseded by #4339, to generalize across ports.
Build failure is a network glitch.
Closing in favor of #4340.
Is the Feather M4 Express the most capable (non ESP32-S2) feather I should use for testing?
My plan is to also get an Airlift Featherwing for those times when I make sure something works on non-native wifi.
I think so
Or put differently.. what's the most common setup CP users have ... that's probably the better question.
I'm deeply in love with my M4
โค๏ธ
I'll say that the S2 has been catching my eye lately
same, but i need audio for my next project
Thanks... ordering now ๐
woot
the Samd51 M4 is the one used in Adafruit devices that have the ESP32SPI integrated
I do my Airlift tests with a Feather NRF52 Express though, 'cause I already put the right headers
I ordered the two-board setup as a worst case scenario as far as testing goes. ๐
I did get the parts from Adafruit. When I cleaned the flux from the board after I soldered them using isopropanol, it also erased the markings. I've only had this happen a few times in the past.
@tropic rain so is the scenario you are seeing?
- Start with a fresh CIRCUITPY
- Edit code.py (e.g., just change "Hello, world" to something else)
- Save the file
- ctrl-d in the REPL and you see the altered program run
- unplug and replug the board
- code.py reverts to the original "Hello, world"
Is that right? Do you have other boards that work fine on the same computer?
I'll give that a try. Here's some new info, it works fine if I use the regular non-SPIFlash build of CPy. Is there a way access the flash using spi using this build to test it. I could write some diagnostics if there aren't any already.
I'll look around for another QT Py. I bought 3 but I forget if I gave one to a friend.
yay my feather RP2040 arrived, that was fast. I also somehow ordered two mini jTag debuggers instead of just 1 oops!
If this change compiles, it seems like it has to be right.
Firmware
Adafruit CircuitPython 6.2.0-beta.3 on 2021-03-04; Raspberry Pi Pico with rp2040
Behavior
On usb_cdc.serials[0], receiving a CTRL+D (\x04) control character causes the board to reset.
On usb_cdc.serials[1], nothing happens.
Additional Info
Was just expecting the board to reset, as sending a CTRL+D (\x04) over usb_cdc.serials[0] has that behaviour.
Maybe nothing happens because the REPL doesn't read that channel, and t...
I think this is the intended behavior. The new CDC "channel" does not have any special use for ctrl+d and ctrl+c. That way if you application requires to use them it won't get interrupted by circuitpython things.
That's correct, and there is no way to indicate an "end of file" on the channel. All data is passed both ways unimpeded. Think of it as a UART channel over USB.
I did find my 3rd one and I did what you suggested. I put it into boot mode and copied the 6.1.0 Haxpress uf2 file, reset the board. hit return in REPL. I change code.py to say "Goodby World!". I hit control-D and it printed out the changed text. I hit reset and I printed "Hello World". So either I got a batch of bad flash chips or I damaged them while soldering them. I'm using a Weller temp controlled station. Being new at soldering surface mount, I prob did heat them a little longer than I would like but I don't think it was extreme. I guess some diagnostics would be in order. If there's no CPy method to do this I could look around for Arduino code to do so.
I don't think it should happen on three different Haxpress boards. What editor are you using, and could you try this on some other machine, say an RPi or a Mac, if you have either?
I do have an RPi. The machine I'm using now is a Mac but it's running Mint 20.1. I'll try the RPi.
try writing a larger file (> 4k) or several files to CIRCUITPY. It's possible CircuitPython not actually writing to the flash successfully but using an internal cache. Your soldering looks OK to me and the orientation is correct.
what editor are you using?
I'm using vim and then cp to move the file to the board. In the last test where I edited HeloWorld I edit xed which is the default text editor in mint.
after you cp do a sync on the command line. That will make sure it's written out
but try writing a much larger file that's > 512 or maybe 4k, like just a bunch of long print statements.
i will say I have not seen a problem like this before, where a write appears to be successful
Well that's interesting. I've been passing a 60 character string to magtag.exit_and_deep_sleep and the magtag has been dutifully sleeping without complaint. What I meant to do was multiply an int by 60 and sleep that long. This worked fine until I switched to a 2 digit string. Maybe it would be a good idea for exit_and_deep_sleep to type check its input? Or can it? Should I file an issue about adding error checking?
could you show the exact lines that include the alarm creation and the sleep call?
I think the old code was like this
update_frequency = secrets['update_frequency'] * 60
magtag.exit_and_deep_sleep(update_frequency)
when I changed update_frequency in the secrets file to 4 digits I got some kind of error about bad floating point type
and then I noticed that instead of multiplying a number by 60 it was making 60 copies of a string
so update_frequency went from being "3600" to "360036003600...." etc
which is my error but it seems like it would be helpful for exit_and_deep_sleep to do some error checking, if possible
i guess if that's c code then maybe it doesn't know what type its input is
you are supposed to pass an alarm to exit_and_deep_sleep() so I'm surprised it didn't complain to you ๐
there is code to validate that it gets passed a list of alarms. I'm confused you got it to work, unless it was a very old version?? before some checks were added (thought I thought the checks were there from the beginning).
MagTag's magtag.exit_and_deep_sleep takes a float
@tulip sleet When i plug my Pico or rp2040 feather in I'm seeing two COM ports now, is that expected with your COM port changes?
I should say PortalBase
YES, first one is the REPL, second is just data: you can send anything back and forth, no ctrl-c issues or anything
OH MAGTAG, sorry!
i don't use the library very much :0
it might need to be renamed to imply it's only time alarms
eh probably not (the underlying call has _until_alarms)
@tulip sleet what would you use for a quick gut check of CircuitPython interpreter speed? Something more sophisticated than 'for i in range(LARGE): pass' ?
Oh cool, though at least in this boot COM19 is the data one it seems, COM20 is the REPL - may be my PC just checking in case things were an issue
I would just do some arithmetic in the loop or something like that
@jaunty juniper Oh, its supposed to be a float? I fixed my problem by casting the string to int. should I change it to float? It seems to work ok
oh, that is too bad, all the testing I did showed they were in order. You may want to clean out your COM ports and have them assigned fresh. Use the Uwe Sieber USB cleanup tool (google that) with the board unplugged
if you do int(some_string) it will convert it to an int
that's what happened
nah, python doesn't care
Thanks I'll poke at it some more
drat, my good idea cuts interpreter speed in half ๐ฆ
Yep, that's what I did. I was just wondering if i should change it to float(somestring) (or whatever the equivalent is)
maybe that test was flawed, it was half the speed just one time
you can sleep for a floating-point number of seconds, like 10.5
maybe a gc happened. i usually tried to avoid loop ops that might trigger a gc, or I would run it 10 times or whatever
OK so I made a program that looks like this
'''
while True:
print("Hello World!")
<repeat 511 times>
'''
and it gave me this error:OSError: [Errno 5] Input/output error (which I am ignoring)
So I commented out all but 4 of the print statements so the file is still long (a bit over 12k) and it runs but it still reverts to Hello world when reset. I did do a sync after the cp but the program had already started showing output so it was written across USB.
I'll try the RPi now and if it still fails I'm going to write an Arduino program using the SerialFlash library to test the flash.
On the QT Py it looks like the flash chip is wired to do SPI and not QSPI. Am I correct about this?
that's right, the SAMD21 doesn't support QSPI
@tropic rain does your RGB led turn blue every time you power or reset the board? That indicates it is writing a new copy of BOOT_OUT.TXT because it can't find an old one or the old one is different. That would be a very good indicator the flash isn't working right.
It's possible you have some kind of power problem. If the board comes up but the voltage is low, the CPU can start running before the flash chip is ready, and it will look like it's unformatted. Try another USB-C cable if you have one
or if you are using a USB hub, try removing it (or interposing a powered hub)
@still zephyr do you have the LabelBase class started already? if so is that pushed to github or anywhere?
i am beginning to lean toward a power or cable problem as the most likely issue, given that it happens on multiple boards
I found two size optimizations in the main "virtual machine" implementing function, mp_execute_bytecode. It causes a modest speed decrease. It would be possible to make these trade-offs configurable, and only enable them on highly flash-constrained boards if desired. We could also take just one of them now and leave the other for later.
There were two optimizations:
- First, (thanks to @dhalbert for a related idea about "pointer compression") a table called
entry_tablewas reduced from...
well that was exciting!
wowza!
Not in github. Are you going to work in that now?
In a little bit. Maybe 15-20 minutes.
Ok. Let me know i do not have much. But we can discuss and I can send my ideas I was arranging my desk to work precisely on that. 20 minutes sounds good
Is that ok?
II do see the LED flash pink and blue for a really short time before it blinks green. I'll try a a different cable and also the RPi. I also can use a stand alone power supply. If I program the QT Py with the blink program and then unplug the USB cable and then start using the separate supply this should provide a solid power source on startup. This will eliminate a few variables (cable, hub, computer).
Yep sounds good to me. Be back shortly.
it waits a good 1.5 seconds as blue if it's writing boot_out.txt
soooo how do I cancel a pull request that I made and is actually bad ?
@still zephyr okay. I am back now. ready when you are.
I am ready.
you prefer text chat or want to go to one of the voice rooms?
voice rooms it would be easier
I will join Amelia room.
HI, is there a learning guide to updating a library that is already in the community bundle? Thank you
@lavish saffron I don't know if there is. If it's your library, you just have to create a new release tag and then it should automatically be picked up within a day. If it's not your library, you need to go through the pull request process with the library author, and then they need to create the new release tag.
Ah OK. thanks. I've created the tag, so I'll wait and see
Firmware
Adafruit CircuitPython 6.2.0-beta.3 on 2021-03-04; Raspberry Pi Pico with rp2040
Code/REPL
import usb_cdc
usb_cdc.serials[1].connected
Behavior
Running the following code ALWAYS returns False, even when reading data to/from the Raspberry Pi Pico, on that USB CDC channel.
>>> import usb_cdc
>>> usb_cdc.serials[1].connected
False
Additional Info
Despite returning False, th...
@lavish saffron If it's not been picked up after 24h then check back or file an issue in the community bundle so we can help you out! Thank you
@garethhcoleman It should be possible to add to the en_GB translation weblate now! We're slightly changing our strategy about when builds with particular translations are enabled, so @tannewt can work with you to define a milestone to reach before we turn that flag on. Thank you for helping us improve CircuitPython, and don't hesitate to ask (especially in Discord) if you have questions about anything.
Oh wait that won't work.
filesystem_init must be before board_init (because of SPI displays as stated by the comment in main.c).
board_init must be before wait_for_safe_mode_reset so the status LED can be used.
wait_for_safe_mode_reset must be before filesystem_init (uses safe_mode in an argument). (How did I miss that ?)
This needs a different type of solution.
CI failures seemed to be network-related.
Just for clarification, the document has two stray \ - b"\xcc\x10\x00" as opposed to the correct b"\xcc\x10\x00"
I do not see this problem with beta.3, either on Windows or Linux. I do have to be connected to serials[1] before it turns to True. In the screenshot below, I at first did not have a connection to COM18, but then when I did connect via TeraTerm, you can see it changed from False to `True'.

@still zephyr Thank you for sharing that sandbox code. I have a branch here: https://github.com/FoamyGuy/Adafruit_CircuitPython_Display_Text/tree/label_base_class I built from that that has split out the duplicated parts into LabelBase.
it still needs some more work for actions, but I think the duplicated code issue is handled in this one
Good, I see good point you create label and bitmap_label depending on Base_Label that depends on displayio.Group. very nice!
Needs some more thorough testing, but so far things seem to be working correctly ๐ค. I'll probably work on this some during the stream.
Now I can apply my 360 text to this :). Do you want me to test it?
Sure if you'd like to give it a try, that would be awesome.
yes, no problem
@lone axle works good I used all the previous test code for previous PR
Thanks for trying it out!
We could try it it on a device on the stream ๐
Yep, was just getting my devices set up under the camera. I'll test it out on devices and hopefully get it cleaned up all the way to pass actions.
Interesting ...
When I use C# to connect to it, it returns False, but I can read and send data without issues:

But when I use PuTTY, it return True:

I revised implementation design a lot, and have just done "git push".
deep/light sleep, with/without USB host connected, are tested. pretending-to-deep-sleep works as well.
Measured consumption current while in deep sleep (now it is System ON idle) looks larger than that of previous implementation, I would investigate it.
Here is the implementation note:
README_impl_r3.txt
Implementation Notes on nrf sleep...
Looks like a commit 31b879b might have unintentionally snuck in... or is it intentional?
I wonder if the C# code you are using is closing the connection after each write or something like that. If you do a read with a timeout in C# so it hangs while you check, does it show as connected during that time?
The C# code uses the SerialPort.DataReceived event, and waits for a text line.
(https://docs.microsoft.com/en-us/dotnet/api/system.io.ports.serialport.datareceived?view=netframework-4.7.2)
It opens the connection and waits.
There's nothing written to close the connection.
<hr>
I've tried to stop on the serial.ReadLine(); method, in C#:

But it still returns False:
...
Hi all, Im a total newb and trying to tinker with Circuit Python on a Magtag device. I have followed the instructions by uploading the UF2 file and imported the minimum libraries outline on Adafruits site but Im getting an error stating Import Error: no module names 'adafruit_display_text.wrap_text_to_lines' Any thoughts on how to resolve this?
You may find more help in the #help-with-circuitpython channel. But offhand do you have the adafruit_display_text library in your lib folder? and I think that may have been updated recently so you may want to ensure you get the latest library bundle (https://circuitpython.org/libraries)
Is rotario available for the pico yet?
@stone iris I've been working on a pull request to add it -- https://github.com/adafruit/circuitpython/pull/4329
you can pick up a uf2 for testing: https://github.com/adafruit/circuitpython/actions/runs/625397304#artifacts
Hello all!
I'm adding a port for Franzininho WiFi Board with the ESP32-S2 module. I followed this guide to build the port.
Please let me know if I need to make some fixes or is everything ok.
Thanks
Hello all!
I'm adding a port for Franzininho WiFi Board with the ESP32-S2 wrover module. I followed this guide to build the port.
Please let me know if I need to make some fixes or is everything ok.
Thanks
@tulip sleet Regarding the QT Py prob. All 3 boards act the same when connected to the RPi. I flashed them with the non-haxpress uf2 and they work fine. I'm going to move forward with the thing I wanted to do with them. At some point soon, I'll use some Arduino code to run some diagnostics on the flash and maybe get to the bottom of it or just add new chips to my next order. My guess is that I did something to fry them. Thanks for your help.
Thanks very much for this! In the long run I have been thinking about labeling builds as "192kB", "256kB", etc., rather than "FULL_BUILD", etc. to give a little more information. But the SAMD21 distinction works well for the current mix of boards.
0x239A is Adafruit's private USB Vendor ID (VID). You can get your own from USB-IF, or if your board is open-source, get one at pid.codes. I believe @tannewt is on the team there and is hinting people in that direction.
0x239Ais Adafruit's private USB Vendor ID (VID). You can get your own from USB-IF, or if your board is open-source, get one at pid.codes. I believe @tannewt is on the team there and is hinting people in that direction.
Sorry, I forgot to change VID in mpconfigboard.mk. Now It is ok. Thank you
Dang it! I just discovered this when trying to put multiple displays on the Pico. I understand the limitation but it's surprising, considering these are just SPI devices and the Pico has so many GPIO for CS/RST/DC pins.
I am not sure why CP 5.3.1 is working, but I think I can offer some insight here. The Cortex M0 UART has a 16-byte FIFO buffer. You will note that in your output the first 16 characters (up through the 'q') are correct. Your code has a .01 second loop sleep, which is 10 milliseconds. At a baud rate of 115200, the 26 characters in your test take up about 1.8 milliseconds. So, if those characters arrive while you are sleeping and the FIFO is full... Note that if you reduce the sleep time signif...
In 6.x, time.sleep() was changed so that it does a WFI instruction, which simply hangs waiting for an interrupt, in this case either a timer tick (about a msec) or a UART-related interrupt. I don't know whether some behavior of the UART interrupt routine has changed, but was going to take a look at some point.
In your test program, it's best not to sleep at all, as @DavePutz implied. But is the test simulating some larger program which is now suffering dropped characters?
I think the site module adds these two pseudo-built-in functions so that people beginning with Python can type exit without parens get a useful message. Without that, Iโm not sure that these functions have enough value to be added.
Firmware
Adafruit CircuitPython 6.2.0-beta.3 on 2021-03-04; Adafruit Feather RP2040 with rp2040
No additional hardware. Feather is connected to host computer via USB.
Code/REPL
# no code needed to replicate
Behavior
# no code needed to replicate; just copy libs or fonts until it crashes.
Description
Feather RP2040 should have 7MB available for CIRCUITPY. When copying a group of files fr...
@lavish saffron I think the bundle now has your update -- see the release notes for yesterday's release, https://github.com/adafruit/CircuitPython_Community_Bundle/releases/tag/20210305
That's it. Thank you Jeff ๐
Hello my favorite purple snake folx!
I've added the SparkFun MicroMod nRF52840. I'm opening this PR as a draft, because I don't have a PID to use. Gonna try to get in touch with someone from SparkFun and see if they've got some PIDs they'd like to use for the bootloader & CircuitPython. As well, I've got a draft PR for the bootloader open here, which I'm also waiting to see if I can...