#circuitpython-dev
1 messages Β· Page 379 of 1
I will make a PR. I'd like to make an alpha.4 today, to include stuff like this.
I didn't even have to be connected to serial, if I let it sit, it would start.
I'll approve it.
really .... I didn't see that, I had to pound on ctrl-C. I did fix some other DMA problems in this PR, so maybe that's helping too.
anyway, I'll submit this
Yeah seriously. It was bad. Made testing this lib rather frustrating because I had to hard reset every 2-3 minutes to see what was on the display. Poor bongo cat was so fragmented, didn't even know what it was anymore.
This fixes some but not all RP2040 audio issues, and fixes MacroPad display issues.
There are a several DMA cleanups. Ctrl-C interrupts of SPI and PIO transactions are also disallowed. SPI ctrl-C interrupts are not allowed on other ports. Allowing ctrl-C can cause bad data/commands to be sent things like displays.
Tested by @kattni on a MacroPad. Prevents display mess-ups that rendered the display unusable.
I know there is still some underlying DMA problem, and am continuing to work ...
@todbot please open a new issue. Closed issues are hard to track and I suspect this might be a different problem from the original. (My guess is that the safe mode restart isn't working.)
@tulip sleet Wait, should I also test audio for this build you sent me?
I have wav file playback in the macropad lib
it's a line of code to test it.
wav playback is not fixed yet
thanks π
@slender iron I don't know if you want to review #4974. It is a partial fix for some problems while I continue working on some deeper RP2040 DMA issues. I would plan to merge it because it's a lot better even though it might not be the final fix. The current situation is unsatisfactory.
and we need to get macropad working better ofr now
So glad I asked my partner to blur her background on Zoom ages ago because otherwise a meeting full of people I've never met would have seen me do a happy dance just now when Pylint passed.
This might be due to us having BLE HCI support enabled.
@tulip sleet I can take a look. what are you thinking for the alpha release?
I am thinking #4974 only from the open PR's. #4964 is still in process. #4961 might have unexpected consequences. #4936 could be fine, we were worried about things fitting.
i would expect to do an alpha.5 soon
but we have a backlog of necessary fixes
you don't have to review #4974, it has been pretty well tested
The release notes are all set to go. Then I will add #4974 assuming it builds and make a release within an hour or two.
yup! just gotta make sure to keep releasing as easy as possible
Changed the logic in RP2040 PulseIn to pass the pulseio_pulsein object reference as an argument in the interrupt call. This avoids getting an incorrect pio/state machine reference when checking the input FIFO and using more that one PulseIn.
Closing this for now. Can always be revisited later since there's some useful setup work here.
Adds rainbow module with colorwheel() function. Removes colorwheel() from _pixelbuf.
I did a thing!
it looks fine! I will test it after it builds. Congrats on learning arcanity!
Thank you! π I am super excited about it.
I've got a functional library for Sensirion SPS30 (particulate matter sensor) for i2c only if Adafruit wants to adopt this: https://github.com/kevinjwalters/Adafruit_CircuitPython_SPS30
As the CircuitPython grows, it may at some point no longer be possible
to squeeze it on some of the flash-less SAMD21 boards, so it would be
good to have the option of shrinking the filesystem size on per-board
basis. This change allows to define CIRCUITPY_INTERNAL_FLASH_FILESYSTEM_SIZE
inside the board's mpconfigborard.h file.
I am assuming you probably did not want this keyword to continue on? I did not see it defined in the new module.
Did a quick look, everything seems fine with me. One question but probably something you did on purpose.
Automated website update for release 7.0.0-alpha.4 by Blinka.
New boards:
- espressif_kaluga_1.3
- pimoroni_pga2040
And the FX29 documentation certainly leaves room for improvement. Here is the documentation for the I2C controller that is in it.
IDT_ZSC31015-Datasheet_DST_20161114.pdfI think the actual controller inside is ZSC31014.
The diagrams in the FX29 appear to be a slightly photoshopped ones from the ZSC31014 datasheet.
...
The one failure is that some escornabot_makech builds were too big. That board is a robot with wheels, etc. Based on that, you could turn off MIDI and I think that would not crimp any uses.
In ports/atmel_samd/boards/escornabot_makech/mpconfigboard.mk, add CIRCUITPY_USB_MIDI = 0. An example of that is in adafruit_proxlight_trinkey_m0/mpconfigboard.mk (along with other things).
Once #4903 is merged, we won't be so close to the edge on many builds.
@dhalbert Fix submitted. Also updated copyright in _pixelbuf that I meant to include in the first place, but did not want to restart the entire CI process for only that change.
The odd comment on Sparkfun site
Sensirion has written drivers for both the UART protocol and I2C. Unfortunately we've found the I2C is limited to only mass concentrations (not number concentrations) using the Arduino platform. So if you plan to use this sensor with an Arduino, use the UART interface. Both interfaces are described in their datasheet.
might be explained by this
@ladyada has indicated that this may be better solved by a change in the adafruit_displayio_sh1107 library.
I added a comment that running setup.py to create the source distribution file takes place during make stubs
I didn't try to change the address, but I did successfully change the sleep mode. The eeprom is writable.
I've got rough circuitpython code for accessing FX29, including putting it in command mode and reading/writing eeprom.
The code assumes that the sensor is powered via one of the I/O pins.
https://github.com/Artem-B/g29-lc-brake/blob/9a248062c8dd1c18d630049240bef1b498b4bc5b/code.py#L40
Pylint complains that it can't import 'board' or 'neopixel'. I copied .pre-commit-config.yaml from a different project, but I didn't use cookiecutter. Should I just start over with cookiecutter?
@cwalther I'm sorry I've been taking a while to catch up on this, I've had a chaotic last couple of weeks. I'm hoping to get it fully tested next week.
Partly addresses #4976.
@kattni Now that #4976 is merged, do you want to narrow the scope of this?
How about making MP_TYPE_FLAG_FULL and EXTENDED_FIELDS use the same nomenclature?
MP_TYPE_FLAG_EXTENDEDandEXTENDED_FIELDS
orMP_TYPE_FLAG_FULLandFULL_FIELDS
Then one would be more of a reminder for the other.
One comment about naming. Thank you for working on this. I haven't thought hard about the macros, etc.
Sorry I just looked at this. We shouldn't call this rainbow because of the existing pypi package: https://pypi.org/project/rainbow/
We could call it adafruit_rainbow though. Or rainbowio :-)
adafruit_rainbow is ok by me. or pixel_colors, or rgb, or something like that.
adafruit_rainbow is ok by me, or even rainbowio. Or:
rainbows(not taken in PyPi)pixel_colorsrgbcolor_mathcolor_calc
fix submitted, plz try it :)
Hi @kevinjwalters I have some time for the UART implementation. I see you have a repo going, I'll have a look. Just curious: do you have SHDLC encapsulated?
No, I've focussed on i2c and I've not done any SHDLC but I'd imagine there's a lot of code out there for inspiration.
On i2c front my SPS30 works well for returing 16 bit integers but I can't get it (running V2.2 firmware) to go into floating point mode. I'm probably doing some daft...
Is this for a Adafruit Library?, I have not experienced this before with Pylint, but normally I found the easiest to work directly with cookiecutter as does a lot of stuff for you
It's more a 'guide to CircuitPython audio.' I want the code to look like library code.
Working better now that I have a valid '.pylintrc'.
Any thoughts on "audioio for ESP32 S2" ? I was hoping to use it, but looks like it isn't in the ESP32 S2 port. Maybe there is a better alternative to DAC audio?
I've had some good results with I2S on the FeatherS2.
I meant that experimentally, a duration of 13us doesn't guarantee that a pulse will be output at 38kHz 50%. I thought that might be because the 13us window fell on the wrong phase of the PWM cycle, but PulseOut timing isn't that precise anyway, so maybe not.
Thanks for the info! I have to drive a speaker directly -- thus needing the DAC. The PWM works well for simple tones, but when I sweep the frequency it sounds terrible!
If I understand right, PulseIn is streaming 1-bit samples from a PIO at 1MHz with a 128-bit buffer, so that has to be serviced at least every 128us or it will lose some. (And that's why disrupted measurements are always on the short side.)
Theoretically, would it be a good thing if the PIO did more of the work? Is the PIO program size a concern?
To me, the option of calling the flag "extended" makes the most sense; changing the macro to FULL_FIELDS makes less sense to me. I can make that change if it's preferred.
Hmph.
MicroPython 7.0.0-alpha.4-10-g319135780-dirty on 2021-07-09; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> help()
Welcomeler/src/circuitpython/porAdafruit CircuitPython 7.0.0-alpha.4-10-g319135780-dirty!
Pleage/extmod/ulab/code/numpyvisit learn.adafruit.com/category/circuitpython/code/numpy/vector/vector project gu>>>
``` well something's not right .. (I am messing with compression again)
@cunning galleon I think @onyx hinge did some work on the DAC and it had lots of issues
So I really like rainbowio but on the off chance we have to make a Python library version of colorwheel(), I should perhaps accept adafruit_rainbow so the name would be the same and all the code would work. It comes down to, what is the likelihood that we'll have to do a Python version? The only reason the Python version of Pixelbuf exists is that _pixelbuf was too big for tiny builds. rainbow built fine into all but one build, so I'm inclined to think we're not going to need a Pyth...
@cunning galleon I investigated implementing analog AudioOut on the esp32-s2 but it was different than the esp32 and I didn't get it working before another task took precedence. Unfortunately, I don't recall the details anymore.
It had to do with how to get the DAC to be driven from memory data, like I couldn't find the necessary info or something
I am OK with adding this to
supervisorper the PR, and then writing a small Python library. It's most important on small boards that are tight on space already. @tannewt, what do you think?
Single function here + small python library sounds good. The reason to make a new module would be that we could make it available on some boards but not others then. That's also ok with me.
EXTENDED makes sense to me. thanks!
Try to accurately measure the costs of including a word in the dictionary vs the gains from using it in messages.
This saves about 160 bytes on trinket_m0 ja, the fullest translation for that board before and after this change. Other translations on the same board all have savings, ranging from 24 to 228 bytes. The list below sorted the fullest translations (before the change) to the top. The numbers shown are the "bytes free in flash firmware" reported during a local build.
Trans...
We could make a rainbowio pypi package if we really wanted to.
Having PIO do more work is one way to handle it. The other would be to DMA out of the PIO into memory so the buffer is larger. (We might do this already.)
@slender iron I guess I don't quite follow what's going on PyPI and why. There are packages for all the native modules..? Or Python versions of all of them or...? I don't quite get it.
generally native modules are provided by Blinka on pypi
so we could put rainbowio there. I didn't want to use rainbow because there is already an existing pypi package (and module) with that name. its good to not duplicate names to reduce confusion
I tried with tip of main on metro m0 with above code and got memory error as below. Just switch to test with M4 for now.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Traceback (most recent call last):
File "code.py", line 1, in <module>
File "/lib/adafruit_midi/__init__.py", line 29, in <module>
MemoryError:
Thanks @DavePutz! I appreciate you working on all of this pulseio stuff.
@candid sun Hey! Are you available to test something for me?
I don't have MIDI testing capabilities, and I have a library that wrappers MIDI, and I need it tested.
sure thing!
Great! Let me get you a zip.
@candid sun This should have everything you need. But I don't know MIDI, so make sure that example is even doing anything to begin with, and feel free to test any of the other features or MIDI things I included. You're the first to work with this, so know that feedback is welcome!
That example is from I don't even remember where, and adapted to run with the library. So.... feel free to do something entirely different π
awesome! do i need the macropad to test though?
βΉοΈ sorry i don't have one yet
There's not an easy thing to mock up to make one either.
No worries!
Thanks for offering though!
no problem!
How will it work with Blinka if libraries are updated with it ?
Does Blinka have supervisor or will it require some conditional coding, like 6.x compatibility ?
The above stats apply to the FIRST commit only. The second commit may affect things a little bit, but only for the better. The problem with potentially accepting "negative valued" dictionary words only came into play with another change I'm testing locally which allowed for more dictionary terms.
@makermelissa do you have an opinion about the placement of this proposed ticks_us function in circuitpython, for best results in blinka?
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.3-501-g53c01176e on 2021-07-09; PewPew 10.2 with samd21e18
Code/REPL
.
Behavior
With CircuitPython 5.3.1 β the last version of CircuitPython that ran on the pewpew10 without issues β the display is very stable: https://youtu.be/_gLVneUf4yQ β the disappearing bricks are due to interplay between my camera's refresh rate and the PWM of the LED.
With CircuitPython 6.0.0 and later, there were...
Does anyone know if the RP2040 "Nuke" .uf2 can be used on any RP2040 or only on the feather rp2040 -- I wonder if it would help here #help-with-circuitpython message
Never-mind -- I see now there is a similar file - may be the same file -- linked from the RP2040 connect page -- apparently it did not help.
is this a raw multiplexed display? are you doing the display muxing in c?
@ladyada it's an 8x8 LED matrix driven from a timer interrupt. The code for the interrupt is here: https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/common-hal/_pew/__init__.c#L36-L89
This looks like something is disabling the timer interrupt periodically (or otherwise preventing it from firing on time), so that it is "late" and some of the lines get much more time than others, and so become brighter.
I noticed that those lines appear much less randomly and for longer time when USB cable is connected. I'm going to try bisect tomorrow to see if I can find the commit responsible.
7.0.0-alpha.2 works fine, 7.0.0-alpha.3 is flickering, so it's something recent.
Somehow PR https://github.com/adafruit/circuitpython/pull/4200 got
reverted, repeating it, with a proper tag.
I found the reason. Somehow the PR https://github.com/adafruit/circuitpython/pull/4200 got reverted, reverting the workaround I made for problems with time.monotonic() in 6.0.
I found that my repository wasn't tagged properly for some reason.
I'm repeating it in https://github.com/adafruit/circuitpython/pull/4980 β with a proper tag, this should fix it.
ok, I connected up the BLE serial too: https://code.circuitpython.org/
Pin definitions for LED and GP25 were missing. Tested that GP25 does exist on the board and does run the on-board LED.
haven't done a build in a while, anyone know what this issue is? build-espressif_saola_1_wrover/firmware.elf section `.dram0.bss' will not fit in region `dram0_0_seg'
Hi, I posted this in a different channel and was told I should post here, but I'm following along with the "Building CircuitPython" tutorial on Adafruit.com, and I'm having an issue when It comes to building for the rp2040. I had success busing for the circuitplayground_express, as in the tutorial, and qtpy_m0. But when it comes to the rp2040 boards ( the raspberry_pi_pico, adadruit_feather_rp2040, and the adafruit_itsybitsy_rp2040 are the boards I've tried) I get the following error. Any help is appreciated
Following the changes to OnDiskBitmap merged in https://github.com/adafruit/circuitpython/pull/4823 there are a number of libraries that need to be updated and tracked here:
Task list coming soon...
grep -r "pixel_shader=.*ColorConverter()" * | sort at the root of Adafruit_CiruitPython_Bundle gives
libraries/drivers/il0373/examples/il0373_1.54_color.py: t = displayio.TileGrid(pic, pixel_shader=displayio.ColorConverter())
libraries/drivers/il0373/examples/il0373_2.13_colo...
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.4-7-g58fdf9e94 on 2021-07-09; Raspberry Pi Pico with rp2040
Code/REPL
import array
import board
import time
import rp2pio
pinIn = board.GP1
program = array.array("H", [0x4001]) #in pins 1
sm = rp2pio.StateMachine(
program,
frequency=1_000_000,
first_in_pin=pinIn,
auto_push=True,
)
print("frequency", sm.frequency)
time.sleep(3)
buffer=array.array("L", [0] * 4)
zeroCount = 0
oneC...
@DavePutz those "stray pulses from IR" could be #4983 where I'm getting 4-7us lows while the pin is definitely high. (I just checked that PulseIn uses the restart function.) If that's the case, you might be able to remove the MIN_PULSE filter.
Supposing the PIO pushed on edges instead of every 32us, we don't actually gain much on fast protocols because it's wasting most of the bits. So not as helpful as I first thought.
I don't think PulseIn is doing DMA currently.
Would I be right in thinking that interrupts don't stack? So it only has 32us to respond? And that could be solved by fetching all of them rather than just the one?
Also if FIFO Join is possible here, that doubles it again.
Hey Dan, can i message you privately? I have a question but it isn't something i can ask in open forum
nevermind, i figured out what i had a question too
Reviewing what I did in MicroPython, it was the "wait pin" version. The following program needs to be restarted to return to the waiting state. This program was behaving itself in MicroPython and not in CircuitPython.
.program samples
wait 0 pin 0
loop:
in pins 1
jmp loop
Anybody know how I would test if a HID descriptor works properly as a "boot keyboard"? Is there something to do besides trying to actually get into a PC BIOS screen via the device?
After too many hours of fiddling I have discovered the issues with integer and floating-point data selection. The argument for data type in the SPS30 start command is only used by the sensor after power-up - the value is retained regardless of subsequent start commands while the device is powered. A stop then a start works to change data type, I'm going to change my code to do that.
OK, well, I have a laptop where the boot screen operates with the traditional USB keyboard descriptor but not with a "bitmap-style" keyboard descriptor ... and it DOES work again with the magic "hybrid" descriptor. So, for compatible systems you get NKRO + boot compatibility with this descriptor and supporting code. https://gist.github.com/jepler/3f507711de499fa4f3cb756680bea927
this builds on the bitmap-style stuff I just blogged up https://emergent.unpythonic.net/01625944378 and the concept linked from https://blog.adafruit.com/2021/05/16/n-key-rollover-nkro-with-usb-keyboards/ of how to be compatible with both
but I worry that testing on one dell laptop is not a great guarantee of working everywhere π
I'm going to steal this anyways
I've also found it's easy to knock the (Sparkfun) cable loose or out of the SPS30.
I grabbed the stats across all boards. Here are the savings for all the builds that were within 200 bytes of full before this PR:
| Board | Translation | Before | After | Savings |
|---|---|---|---|---|
| sensebox_mcu | ja | 4 | 160 | 156 |
| sensebox_mcu | de_DE | 100 | 232 | 132 |
| arduino_nano_33_iot | ja | 112 | 268 | 156 |
| feather_m0_rfm69 | ja | 144 | 324 | 180 |
| blm_badge | ja | 168 | 280 | 112 |
| blm_badge | de_DE | 172 | 272 | 100 |
| arduino_mkr1300 | ja | 192 | 352 | 160 |
Some boards were a ...
.. I tested this on a feather rp2040 with my calculator/keypad project and it was fine.
If I am going to build ports/stm32/boards/stm32f411ce_blackpill_with_flash to be flashable via tinyuf2, am I going to need to make changes to ports/stm/boards/STM32F411_nvm_nofs.ld to reflect a uf2 bootloader being present and the CP image being offset? At present official binaries for that board are just built as .bin starting at 0x80000000 and flashed with the regular stm tools (dfu or stlink).
No problem with doing the work myself but just seeking a little guidance if this is the right place to start or if its even needed at all.
Not strictly true because including a word into the Huffman tree bumps up the encoding lengths of all words in the same subtree. In the extreme case when the new word is so frequent that it gets a one-bit encoding, all other words will cost an extra bit each.
The improvement in the heuristic's accuracy is excellent, I just wish the comment describing the new heuristic were more accurate.
This happens to me when doing a debug build.
build-microdev_micro_s2/firmware.elf section `.dram0.bss' will not fit in region `dram0_0_seg'
yes, itβs a debug build, no firmware is generated
yes, fails at last step... would you like to create an issue?
yes iβll do that, thanks for chiming in
CircuitPython version
current main
Code/REPL
make (no code)
Behavior
[658/658] Generating ld/esp32s2.project.ld
/Users/a/.espressif/tools/xtensa-esp32s2-elf/esp-2020r3-8.4.0/xtensa-esp32s2-elf/bin/../lib/gcc/xtensa-esp32s2-elf/8.4.0/../../../../xtensa-esp32s2-elf/bin/ld: build-espressif_saola_1_wrover/firmware.elf section `.dram0.bss' will not fit in region `dram0_0_seg'
/Users/a/.espressif/tools/xtensa-esp32s2-elf/esp-2020r3-8.4.0/xtensa-...
@jepler @tannewt for breaking changes like these, we need to put a plan in place for who will go through and update all the guides and tutorials. lets chat on monday and come up with a system since there are so many breaking changes in 7.x :)
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.4 on 2021-07-08; Adafruit PyPortal with samd51j20
Code/REPL
# SPDX-FileCopyrightText: 2021 ladyada for Adafruit Industries
# SPDX-License-Identifier: MIT
"""Simpletest example using Adafruit PyPortal. Uses the touchscreen to advance between examples."""
import board
import adafruit_touchscreen
from adafruit_pybadger import pybadger
import time
# pylint: disable=invalid-name
# These pins ...
Verified something similar still happens in latest build Adafruit CircuitPython 7.0.0-alpha.4-15-g22e8a5058 on 2021-07-11; Adafruit FunHouse with ESP32S2 with this code:
import time, board
import pwmio
while True:
for f in (262, 294, 330, 349, 392, 440, 494, 523):
with pwmio.PWMOut(board.SPEAKER, frequency=f, duty_cycle=2**15) as pwm:
time.sleep(0.25)
time.sleep(1)
The above will result in 3 tones being played and then the error:
Traceba...
Finally got around to testing this. It no longer crashes, but the external 8MB SPIRAM no longer seems to be recognized:
Adafruit CircuitPython 7.0.0-alpha.4 on 2021-07-08; LILYGO TTGO T8 ESP32-S2 w/Display with ESP32S2
>>> import espidf
>>> espidf.heap_caps_get_total_size()
155852
>>> espidf.heap_caps_get_free_size()
130460
>>> espidf.heap_caps_get_largest_free_block()
65536
Finally got around to testing this. Confirm no crash with espidf.heap_caps_get_largest_free_block() call:
Adafruit CircuitPython 7.0.0-alpha.4 on 2021-07-08; LILYGO TTGO T8 ESP32-S2 w/Display with ESP32S2
>>> import espidf
>>> espidf.heap_caps_get_total_size()
155852
>>> espidf.heap_caps_get_free_size()
130460
>>> espidf.heap_caps_get_largest_free_block()
65536
>>>
7.0.0-alpha.1 - works correctly
7.0.0-alpha.2 - works correctly
7.0.0-alpha.3 - crashes
7.0.0-alpha.4 - crashes
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.4-15-g22e8a5058 on 2021-07-11; Adafruit FunHouse with ESP32S2
Code/REPL
# boot.py
import usb_midi
usb_midi.disable()
print("disable MIDI")
import usb_hid
usb_hid.disable()
print("disable HID")
import usb_cdc
usb_cdc.enable(console=True, data=True)
print("enable CDC console & data")
Behavior
On reset or power up, board goes into boot loop. No way to escape it, without `esptool.py ...
In relation to the second (positional arguments) error, there was something on @FoamyGuy 's stream yesterday while working on library code that was generating a positional argument error that didn't appear to relate to the code referenced
https://youtu.be/0AwRphuQPys?t=5123
Changes made to correct handling of short initial pulses as well as (hopefully) improve short pulse accuracy somewhat.
FYI, I put a few observations about datasheet, behaviour and Sensirion libs in https://github.com/Sensirion/embedded-sps/issues/15#issuecomment-877713715
I also need add support for some of the other functions like cleaning and review the style of interface as lots of the Adafruit libraries use properties for values fetched over i2c/similar.
I'm doing keyboard with display. On display showing total pressed keys, I'm need to write this in controller memory (I'm using pi pico), but all memory operations so long (beetwen 0.4 and 0.7 sec for write). If I press key while data writing, I miss this key (or show with really big delay). My controller has two cores, but now it impossible to use both of them or write data in async operation which no lock main cycle
Correct state machine restart code by adding a stop before re-starting. Tested OK with the sample Python code provided.
Iβm looking for the Python/CircuitPython equivalent of a map in Java. The goal is to associate a color name as a key with its RGB tuple value. User gives a string of the color name and gets the tuple back.
You'll want a python "dictionary"
Yes, I think you will need to modify the linker
My guess is that your ulab submodule is out of date. Make sure you do a git submodule update --init and check git status
OK, at least I'm on the right track there. It seems that tinyuf2 isn't quite there yet on that board port so I've got a bit of time to figure out what I need to do.
π thanks for looking into it!
I would like to see CP binaries moving to UF2 on STM32 if at all possible, since some of the boards are really tempremental on timing to get into DFU mode.
There might be some problem on STM32F4 with not efficiently being able to allocate the flash segments adding a second bootloader into the picture though, nvm might need to be rethought.
Since I think it occupies one of the precious 16k segments all to itself.
that'd be nice! I'd love to have uf2 everywhere
thank you @slender iron . I knew the structure existed... i just didn't know what it was called, making a search difficult. Here is the function I worked up:
def setcolor(colorname):
global color
colors = {
"black":(0,0,0),
"red":(intensity,0,0),
"green":(0,intensity,0),
"blue":(0,0,intensity),
"yellow":(intensity,intensity,0),
"cyan":(0,intensity,intensity),
"magenta":(intensity,0,intensity),
"white":(intensity,intensity,intensity),
}
color = colors.get(colorname, (0,0,0)) #defualt to black (off)
This macro should be at least prefixed with MP_, maybe MP_TYPE_EXTENDED_FIELDS?
There are not many slots left in a base mp_obj_type_t, most have been moved to the extended struct. Did you do an analysis to see which should be in base and which in ext (based on reduced code size)?
I would call these functions something like mp_type_get_call_slot(). Otherwise it could be confused that the function actually does the operation (eg call) rather than getting the entry.
Aah, I see that you did an analysis at the top of this PR. But did you compute code size savings with the latest changes?
Is there an intention to add a compile-time config macro for this feature, so that ports that have the space can opt out of this to improve performance?
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.4-18-g0c6dc6f0a on 2021-07-12; Raspberry Pi Pico with rp2040
Code/REPL
import array
import board
import time
import rp2pio
import adafruit_pioasm
asm = """
pull
mov isr osr
push
"""
program = adafruit_pioasm.assemble(asm)
sm = rp2pio.StateMachine(
program,
frequency=1_000_000,
)
def readAnswers():
answer = array.array("L", [0])
time.sleep(0.001)
while sm.in_waiting > 0:...
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.4-18-g0c6dc6f0a on 2021-07-12; Raspberry Pi Pico with rp2040
Code/REPL
import array
import time
import rp2pio
import adafruit_pioasm
asm = """
pull
mov isr osr
push
"""
program = adafruit_pioasm.assemble(asm)
sm = rp2pio.StateMachine(
program,
frequency=1_000_000,
)
item = array.array("L", [0])
for i in range(10):
time.sleep(2)
print(i)
sm.write(item)
Behavi...
Is there an intention to add a compile-time config macro for this feature, so that ports that have the space can opt out of this to improve performance?
In CircuitPython, I think we decided to always use this size savings. However, the preprocessor CAN disable this feature, with macros something like
#if !defined(MP_TYPE_FLAG_EXTENDED)
#define MP_TYPE_CALL call
#define mp_type_get_call_slot(t) t->call
#define MP_TYPE_FLAG_EXTENDED (0)
#define MP_TYPE_EXTENDED_FIELDS(...) __VA_...
The grep above shows it infrequently, but that excludes the types created by MP_DEFINE_EXCEPTION; we have 66 instances of MP_DEFINE_EXCEPTION in CircuitPython, putting this field at 73, about the same as print.
Due to the time required to move a field between the base and extended fields, I didn't specifically investigate this possibility or gather numbers about it.
Size savings by board, sorted by savings:

The smallest savings is 1340 bytes, on fomu. The biggest change of 3472 bytes was on electronut_labs_blip. The average is 2554 and the median is 2792.
Here's a full summary for PYBV11 with some analysis (on Google Sheets)
https://docs.google.com/spreadsheets/d/1DQG7xZwCjo0DbFJbPwh92gtyjRfPiS-nJvG1kRSvG8k/edit?usp=sharing
The basic approach was:
- Remove all
STATICfromconst mp_obj_type_tdefinitions. - grep for all definitions, get all possible type names in the repo
- Python script to automate
print <type>.<slot>in gdb on pybv11/firmware.elf - Generate CSV
In MicroPython, on PYBV11 (see analysis sheet above), I get a predicted saving of 2504 bytes (this is just the memory used in the object definitions, not including extra code size added for accessing the fields).
Moving parent into extended reduces the saving to 1776 bytes. Note that MicroPython on PYBV11 only defines 23 exception types.
Note that 2504 is out of a possible 5216 bytes if a perfect system could be implemented with no metadata overheads. FWIW, the index table approach I...
Here's my own stab at a script to analyze slot usage: https://gist.github.com/jepler/5cb392d43c16845645b49296c27e0850
.. it works on an elf file
The resulting spreadsheet for trinket_m0:
https://docs.google.com/spreadsheets/d/1zcEAkoOfHaMzsCcB9Z1x8MyClU_jt_xDHfFMPpE-rbs/edit?usp=sharing
A further iteration tried all the combinations and found that my split was best, again for trinket_m0:
https://gist.github.com/d480e10a509c0af8de69bdb247df9f4a
Furthermore, the data savings was est...
Using @jimmo 's spreadsheet I found a slightly better split (based on PYBv1.1) that puts the protocol slot in the base set. That saves an extra 92 bytes (on PYBv1.1 at least).
Using a 3-way split (base + ext1 + ext2) of the following form:
base = (print, make_new, attr, parent, locals_dict)
ext1 = (call, unary_op, getiter, iternext, protocol)
ext2 = (binary_op, subscr, buffer_p)
saves an extra 672 bytes compared to @jepler 's scheme (on PYBv1.1).
A 4-way split can do a li...
Works for me with the example I provided, but unfortunately not with the "wait pin" scenario, so I'm preparing an example of that.
import array
import board
import time
import rp2pio
import adafruit_pioasm
pinIn = board.GP1
asm = """
wait 0 pin 0
loop:
in pins 1
jmp loop
"""
program = adafruit_pioasm.assemble(asm)
sm = rp2pio.StateMachine(
program,
frequency=1_000_000,
first_in_pin=pinIn,
auto_push=True,
pull_in_pin_up=1,
)
buffer=array.array("L", [0] * 4)
while True:
time.sleep(1)
sm.restart()
sm.clear_rxfifo()
while sm.in_waiting < 4:
pass
sm.readinto(buffe...
To re-cap some estimated size savings, now shifting to pybv11 (I think all these figures were from pyb types):
est. savings, exclusive of code size increase:
| scheme | savings |
|---|---|
| perfect | 5216 |
| jimmo-index-table | 3284 |
| damien-4tier | 3284 |
| damien-3tier | 3176 |
| jepler-2tier | 2504 |
I did some experiments on the generated code for the different approaches.
I have three branches that add an extra slot to mp_obj_type_t in three different ways:
- https://github.com/jimmo/micropython/tree/obj-slots-original -- this just adds a regular slot (baseline)
- https://github.com/jimmo/micropython/tree/obj-slots-split -- adds a split type (but the extended type only has this new slot)
- https://github.com/jimmo/micropython/tree/obj-slots-index -- index
They all add a `void m...
As long as there are at most 15 optional slots, can you use bitfields:4 instead of uint8_t for the slot indices?
As long as there are at most 15 optional slots, can you use bitfields:4 instead of uint8_t for the slot indices?
I think so! I do wonder if you end up doing a lot more work to extract the bits out for a relatively small saving, but I will test it out.
Using @jimmo 's spreadsheet I found a slightly better split (based on PYBv1.1) that puts the protocol slot in the base set. That saves an extra 92 bytes (on PYBv1.1 at least).
This is different than trinket_m0; I think we use protocols less heavily than you.
Is there a better way for "3 tier" to look than
STATIC const mp_obj_type_t uctypes_struct_type = {
{ &mp_type_type },
.flags = MP_TYPE_FLAG_EXTENDED2 /* (implies EXTENDED1) */ ,
.name = MP_QSTR_struct,
....
As long as there are at most 15 optional slots, can you use bitfields:4 instead of uint8_t for the slot indices?
I think so! I do wonder if you end up doing a lot more work to extract the bits out for a relatively small saving, but I will test it out.
Here's the disassembly for this approach (see code at https://github.com/jimmo/micropython/tree/obj-slots-index-bits)
0802c748 <mp_do_extra>:
802c748: b510 push {r4, lr}
802c74a: 4604 ...
Great, I haven't managed to crash it!
A full PWM cycle still seems to better. Requesting 1ms pulses at 1kHz gives a good result:

Requesting 500us gives unwanted behaviour like this:

Similarly at 38kHz with 2...
Here's the corresponding disassembly for M0 (rp2040)
Baseline:
100178e4 <mp_do_extra>:
100178e4: b510 push {r4, lr}
100178e6: f7f5 f99f bl 1000cc28 <mp_obj_get_type>
100178ea: 6bc3 ldr r3, [r0, #60] ; 0x3c
100178ec: 2b00 cmp r3, #0
100178ee: d000 beq.n 100178f2 <mp_do_extra+0xe>
100178f0: 4798 blx r3
100178f2: bd10 pop {r4, pc}
...
Code size, per access of type object field (@jimmo's code, counted manually by me)
| style | m4 | m0 |
|---|---|---|
| baseline | 18 | 16 |
| 2-tier | 34 | 36 |
| uint8_t index table | 26 | 26 |
| bitfield index table | 36 | 34 |
Hmm. It looks like this issue relates to the functionality of the SDK's pio_sm_restart() call. According to the Pico documentation, "This method clears the ISR, shift counters, clock divider counter pin write flags, delay counter, latched EXEC instruction,and IRQ wait condition." Notably, it does not reset the program counter. Thus it will not execute the "wait 0 pin 0" instruction from the example. We might need to decide whether following the SDK is the right thing to do, or if calling s...
I run MIDI-OX on VM and see the same output as reported with M4, but I don't know MIDI enough to know where is the issue. Could anyone help to point it out ?

Trying to break it now, 0c6dc6f crashes at 5. I guess it should throw an exception at the actual limit.
import board
import digitalio
import pulseio
import time
#GP0..N chained together
numPulseIns = 5
print("start")
digitalOut = digitalio.DigitalInOut(board.GP0)
digitalOut.direction = digitalio.Direction.OUTPUT
time.sleep(7)
print("creating PulseIns")
pulseIns = []
for i in range(numPulseIns):
pin = getattr(board, "GP%d" % (i+1))
print(pin)
pulseIn = p...
@hathach, the "90 45 0A" and "80 45 00" is the valid data being sent. All other data in that screenshot are the errors. (e.g. "90 0A 00" and "80 00 00")
@hathach, the "90 45 0A" and "80 45 00" is the valid data being sent.
All other data in that screenshot are the errors. (e.g. "90 0A 00" and "80 00 00")
AH ok, got it, sorry, I am not familiar with MIDI and wasn't too sure.
Looking again at 3-tier, based on trinket_m0 types, I found the best saved 2152 bytes, or an additional 200 bytes compared to 1952 with the two-tier system.
My optimal 3-tier was:
| tier | fields |
|---|---|
| base | (base flags name) print make_new attr parent |
| first | getiter iternext protocol locals_dict |
| second | call unary_op binary_op subscr buffer_p |
code (runs for quite awhile) & output (just the few lines at top and bottom) in gist: https://gist.github.com/254a06c86...
This almost looks like an off-by-one error on a send buffer. Most MIDI USB packets are 4-bytes (cable number, midi status, data1, data2) but it's like it's got an extra byte in there that's being sent out with pre-existing cable number and status byte
Hi <@&356864093652516868> -- the weekly Discord meeting is about 90 minutes from now. If you have notes for me to read, or plan to speak, please update the notes document accordingly: https://docs.google.com/document/d/17UaJ2NvMP61i1V6rIwAq5VecsdoTKfSQVTOHetINmQw/edit -- if you're just listening in, no need to do anything. We'll see you in the CircuitPython voice channel at around 2PM ET!
If it's your first time speaking, please make sure we have added you to the CircuitPythonistas role. This also gets you a small number of notifications through the week, mostly about the meeting itself.
CircuitPython Weekly for 12 July 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canβt make the meeting and would still like to participate, add...
How bizarre. And I'd just assumed it was the same issue.
Looks like MicroPython noticed this and decided that their restart function will go to the start of the program: https://github.com/micropython/micropython/blob/e3291e1801f27e49ac0e6be275c742777507207f/ports/rp2/rp2_pio.c#L605
CircuitPython version
Adafruit CircuitPython 6.3.0 on 2021-06-01; Adafruit Feather M4 Express with samd51j19
Code/REPL
import board
from analogio import AnalogIn, AnalogOut
def case1(pin):
'''Should not throw error if pin is released properly
'''
c = AnalogIn(pin)
c.deinit()
c = AnalogOut(pin)
c.deinit()
c = AnalogIn(pin)
def case2(p1, p2):
'''Should always throw error since pin being changed was not releas...
thanks for your extra information, I will take a closer look at this tomorrow and try to fix it asap.
@onyx hinge What change did you make to OnDiskBitmap? I used it in the MacroPad library. Pretty sure I used the latest documentation, but now I'm wondering.
This is a snippet of the relevant code: py with open(file_name, "rb") as image_file: background = displayio.OnDiskBitmap(image_file) sprite = displayio.TileGrid( background, pixel_shader=background.pixel_shader, x=position[0], y=position[1], ) group.append(sprite) self.display.refresh()
Happily lurking and easting some leftover chicken milan.
Just listening today.
Finishing up an internal meeting, we'll be there soon!
Not participating. I have just put a kind of group hug, but did nothing this week.
https://github.com/adafruit/circuitpython/pull/4823
I was told as long as it's working with the latest CircuitPython, I'm using the latest changes π
beep-boop.
π Thanks!
π
time.microtonic() and time.nanotonic() are the new versions.
@idle owl be happy to test macropad -- I have some time in the next few days.
MacroPad library PR: https://github.com/adafruit/Adafruit_CircuitPython_MacroPad/pull/1 If you have a MacroPad, please test to see if your current examples can be adapted to use it, or try it with the simpletest.py or your own ideas of how to use it! cc: @solar whale
anyone notice a difference in SAMD21 clock frequency depending on whether it's connected to a USB serial, or just powered with the USB socket? I have a Seeeduino XIAO that I'm using for PWM servo control, and it programmed just fine with 60 Hz pulses with 1.5ms pulse widths using the PWM library. When that same microcontroller is just powered via USB, the frequency drops to ~58Hz and the pulse width goes to 1.54ms, indicating to me that something is messing with the chip clock frequency
@slender iron I do have a v2 and will try to test.
@misty garnet ya, that's typical. the SAMD21 uses USB as a clock reference when it can
when there is no other crystal
@slender iron well, that would explain it, thanks. sounds like if I want specific timings for when it's not connected, I need to take that into account and tweak the program values
you can take a look at the circuitplayground code. it actually stores the clock tuning config so that the timing changes less between on and off usb
it takes a bit of flash space though
thanks all!
@slender iron thanks!
Well it's interesting to hear the thoughts π
I know we could check out at any time, but we can also leave?
Better than that last hotel I stayed at!
This came out of #4926 - the scope of which was refined to an initial step which is nearly completed by #4991.
This issue is to address the part of the previous issue not yet dealt with - renaming _pixelbuf and adafruit_pypixelbuf to adafruit_pixelbuf so they match for seamless usage. This will simplify the usage in NeoPixel and DotStar, and any future applications.
The current suggestion is to create a new Python library called adafruit_pixelbuf and copy adafruit_pypixelbuf ...
@dhalbert I created a new issue (#4992) since this issue became specific to the native rainbowio module.
@gilded cradle I have some Blinka questions, if you have a few minutes.
Sure @idle owl what did you have?
When a new module gets added to CircuitPython, how does it get "added to" Blinka? Does Blinka simply know about all of them, or is there a process for that?
Generally, they aren't available until somebody adds them.
Ok, how would I go about doing that?
Which module?
Limor wants this rainbowio module I added that has the colorwheel() function to work with Blinka.
And the next thing on my list once it's merged it to make that happen.
It would be added here: https://github.com/adafruit/Adafruit_Blinka/tree/main/src
Alright
You would create a rainbowio.py file. Start with Raspberry Pi. You can look at some of the other modules to get an idea.
Ok
We probably should create a guide on how to add new modules to Blinka.
@gilded cradle Is it ok if I ping you when it's merged and have you work with me on adding it?
sure
Thanks!
Added code to reset the State Machine program counter to the initial offset during a restart. There is not a way in the SDK to reset X,Y, or OSR. If those are of concern you might have to put in a PUSH to the register(s) at the start of your PIO code.
?Serverinfo
Oi, my fork is still called Adafruit_MicroPython_Blinka. I have apparently done nothing with the Blinka repo in a LONG time.
π
This is a clear case of delete and start fresh. π
Here is the notes document for Mondayβs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youβll be attending the meeting - itβs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1fV_bv403ON4s5V7kyC9SQQU09w5qNU4zhW7QKJ92fHw/edit?usp=sharing
CircuitPython Weekly for July 19, 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canβt make the meeting and would still like to participate, ad...
I think you'll want to stop before running the exec otherwise you risk the pc advancing before you can disable the state machine. IIRC the enable only changes the auto-pc advance behavior. exec will still execute commands when the sm is "disabled".
I think we'll want to make a second top-level module entry that maps _pixelbuf to adafruit_pixelbuf and rename the files internally. Then in 8.0.0 we can remove the _pixelbuf naming in favor of adafruit_pixelbuf.
Should reference to
reset_pin_number(PIN_PA02)in code below be replaced withreset_pin_number(self->pin->number);?
Yup! Would you mind making a PR? Let me know on discord if you need help testing.
@dhalbert How would you like to handle PIO mistakes?
What is the behavior you expect? Its not clear to me what you think the issue is.
I think this is all correct. We use the array typecode to do an 8, 16 or 32 bit transfer. The memory structure of the RP2040 will then do 32 bit writes to the peripheral and mirror the 8 or 16 bit value to the other bits.
@tannewt @dhalbert I did the suggested re-namings. As discussed in the meetings I'd like to merge this now into CP knowing we may have to re-do it if upstream does even more/better than we did here, but it needs a fresh review.
I'm doing keyboard with display. On display showing total pressed keys, I'm need to write this in controller memory (I'm using pi pico), but all memory operations so long (beetwen 0.4 and 0.7 sec for write). If I press key while data writing, I miss this key (or show with really big delay). My controller has two cores, but now it impossible to use both of them or write data in async operation which no lock main cycle
async won't help you on the RP2040 because the code is running from the...
This sounds like a memory write issue that is stomping on byte code the VM is trying to execute.
@ionic elk got time this week to sync up?
Are there bugs we want to fix for 7.0.0 that need this to debug? Otherwise, I'd prefer this being a long term issue. The 7.0.0 milestone list is very long already.
The interrupt routine should be entered a subsequent time if the fifo is still full after the first get. This has a bit of cost instead of having a loop here but its pretty minor.
rp2pio_statemachine_construct should do a FIFO join automatically.
What protocols need this tight of timing? I don't know of one.
@jepler Mind tracking and reviewing these PRs?
Sorry for the regression! Submodules are a bit tricky.
I mentioned in the issue thread that I was concerned about restart followed by the exec'd jump. If tannewt is right that exec still works when stopped, sounds like it could go stop,exec,restart.
It's now tracked in https://github.com/adafruit/circuitpython/issues/4982 and I've asked @jepler to do the reviews for @lesamouraipourpre on that issue.
It's my fault for failing to tag it correctly.
By the way, this interrupt disabling in the time functions may still be affecting other modules, like pulseio, pwmio, or audioio, so maybe it would be good to revisit it when there is some time.
Based on what you just said, I expect start and end to refer to the indexes of the input array for 16 and 32 bits, as well as for 8. (The mirroring was just a little surprising, and had me confused about what the intended behaviour is.)
@onyx hinge Mind chatting changes a bit? (text chat)
@lone axle When you have a moment, I'd like to chat about some things. Please DM me when you have a few minutes. Thanks!
@slender iron The plan with gamepad is to "replace" it with keypad? e.g. Where gamepad is used, implement keypad? Or did I misunderstand things I heard in passing.
@idle owl yeah if it's still relevant!
@onyx hinge Quite relevant!
okeiieaieo
Perhaps you can answer the question I asked Scott about gamepad/keypad first
Yes, I think the idea is to change anything that used gamepad to use keypad, which includes at least some libraries (and guides?)
so that gamepad can be removed (in 7, I think)
which creates "how do you do a compatible with 6.3 version" problems
Right.
I think it's worth saying that it's on the table to NOT do this if the consequences are too great.
if it means we have to wait until we stop supporting 6.3
Right. I follow.
okay
The example code above is not particularly efficient and is creating new displayio objects with every iteration and churning memory.
Changing the code so that it only updates the screen when required prevents the crashes in the short term.
@onyx hinge Those are the changes I have listed so far. I don't know where to find the library-specific issues that came up. You may have known some of them? Or was it more that the core stuff affected libraries?
the one I know of that's not listed is the extensive renaming in ulab
yes the changes are implemented in 7.0 already
ulab is used in some guides and in the examples of some libs but not in lib code itself
Breaks current code or is still backwards compatible?
The compatibility plan, at least as far as I'm concerned, is to make code that works with 7.0 only.
breaks current (6.3) code quite extensively
if there were library code I'd say otherwise
And, finally, have we filed any issues about updating code for it?
yeah, I'm set up to test the main ulab guide, but there are some others like philb's light painting one
no, I do not think any github issues have been filed
Ok
the library examples are ```python
libraries/drivers/ov2640/examples/ov2640_displayio_kaluga1_3_ili9341_ulab.py:import ulab.numpy as np
libraries/helpers/ble_adafruit/examples/ble_adafruit_clue.py:import ulab
the guides are ```python
CLUE_Light_Painter/bmp2led.py:import ulab
CLUE_Metal_Detector/clue-metal-detector.py:import ulab
Ocean_Resin_Lightbox/code.py:import ulab
Ukulele/code.py:import ulab.numerical as numerical
ulab_Crunch_Numbers_Fast/benchmark.py:import ulab
Ok created another sheet in there with this information.
OK
I think we need to file an issue on the core to track this though. I'll sort out that happening.
Ok, so as for library changes. Were there things we discussed that were lib-specific, or was it all how core things related to libs?
It seemed like Scott said at some point that "all those things" were in libs, but now I can't remember the things that were in libs
I tried to follow all of it, but I didn't know I'd be taking over handling it until after it was all discussed π
Yeah. Same.
Ok.
I will start with what I have and email Scott and Dan I suppose, since I said I would email Dan about it.
I think that's it for now. Thanks, @onyx hinge !
Ah, the interrupt fires if the FIFO is full? In that case looping won't help much and neither will the length.
@idle owl glad I could help some
I just wanted to look at the promiscuous wifi issue.
What protocols need this tight of timing? I don't know of one.
I don't know much about serious protocols and which ones might be affected by losing a few tens of microseconds. I guess nobody will be doing IrDA in PulseIO. There's this? http://www.numericana.com/answer/ir.htm#455
I'm in a club for reverse-engineering toys that communicate with each other. One of our members is also making a new toy with a Pi Pico and CircuitPython, and hopes to interface with some existing ones. After ...
Thank you for doing this! I hope we don't fill the space up too quickly. :-)
Right, normally the PIO program would put something into X/Y/OSR.
@dpgeorge @jimmo really appreciate your feedback on this, let me know if I can pitch in on the implementation in micropython.
Attempting to fix issue #4990
BLE serial access is in added in #4957 for nrf only.
This was added in #4918 and uses the protocol defined here: https://github.com/adafruit/Adafruit_CircuitPython_BLE_File_Transfer
#3493 allows for changing the tx power of an advertisement. It does not carry over to any connections (we reset to 0 dbm for connections) but this should satisfy this issue.
Bumps addressable from 2.7.0 to 2.8.0.
Changelog
Sourced from addressable's changelog.
Addressable 2.8.0
fixes ReDoS vulnerability in Addressable::Template#match
no longer replaces + with spaces in queries for non-http(s) schemes
fixed encoding ipv6 literals
the :compacted flag for normalized_query now dedupes parameters
fix broken escape_component alias
dropping support for Ruby 2.0 and 2.1
adding Ruby 3.0 compatibility for development tasks
d...
FWIW here's some (rough) timing data on the different approaches. This is milliseconds, for 1000000 iterations of calling mp_do_extra with the code in those branches (but with the print removed from list_extra). Calling it for three different types (testing the "extended, has the slot" (list), "extended, doesn't have the slot" (dict) and "not-extended" (str) paths).
(str was a bit of a bad choice in hindsight, because it uses a different path in mp_obj_get_type).
Baseline:
str: ...
Is nvm actually implemented on any stm32 device? I am noticing that the blackpill_with_flash device has a linker segment defined for it but the module is not built in. STM32 Feather and blackpill without external flash has neither the module nor any flash space reserved.
I'm wondering if that space can't be co-opted for bootloader purposes on the blackpill_with_flash
OK, in my local repo I think I've got something with a new board entry and linker map that at least compiles. Given that tinyuf2 is not fully operational yet on the target hardware though I can't test.
using sector 0 for bootloader, 1 for isr, 2-7 for firmware (current is 0 isr, 1 nvm (but unused), 2-7 for firmware)
@tannewt yea, I was solved this by using external EEPROM. But so many cases in my project when I'd like to use threads. Two text lines on display (len. around 14 sym), each of them updating around 40-60ms, and together in locks my keyboard on 100ms (it's really long when typing). Solved by slice lines and update each symbol separately at different time. To many math (total around 120ms) - solved by partially execute all unimportant functions in loop, step by step. Of course, all problems sol...
Hey folks, I just came across this issue while researching an issue I'm experiencing and it sounds exactly like Kattni described above. I'm using the Tiny S2 from Unexpected maker with a 60 neopixel ring. The animation works just fine apart from random flashes of other colours. It occurs even under the most basic of code conditions. Please let me know if there is anything I can do to help debug.
If it helps, I caught a video of the glitch... it appears towards the end of the video https://www.youtube.com/watch?v=WQKzEdR0QGc
should fix #4895 .
Note as side effect, tinyusb update also include RP2040 double buffer https://github.com/hathach/tinyusb/pull/891 which could increase throughput for rp2040.
This should be fixed by #4995 , @todbot please give it a try when you have time :)
@slender iron hi sorry I'm caught in two weeks of insanity, bunch of family stuff + moving + work prep. I'm squeezing some hours in today, should have all of next week free, but the rest of week is mayhem. Today or Friday might be good, if that works
I developed two device descriptors that support NRKO (https://emergent.unpythonic.net/01625944378). While doing so, I noticed that the standard adafruit_keyboard class had no way of knowing that the report didn't match what it expected, until it encountered an exception trying to send a wrong-sized report.
I don't know exactly what is necessary or useful, but it seems like it would be nice if Keyboard could instead say "this descriptor isn't quite what I need"; this might consist of loo...
Getting weirdness on Trinket, where I'm using the DotStar, and it keeps saying pin in use. There's nothing else going on in the code.
I think DotStar is borked.
Hmph.
If someone else has a Trinket and could test this, let me know.
@idle owl What version of CP?
@solar whale Absolute latest, I just built it.
Ill give it a try -- be a few minutes -- need to update and build
@solar whale You could grab it off of S3. I don't think it's a CP issue.
Here is the example I'm using: ```py
import adafruit_dotstar
import board
pixel = adafruit_dotstar.DotStar(board.DOTSTAR_CLOCK, board.DOTSTAR_DATA, 1)
while True:
pixel.fill((255, 255, 0))
Give it a minute to sit, or soft reload or something, and then it fails with Traceback (most recent call last): File "code.py", line 4, in <module> File "adafruit_dotstar.py", line 112, in __init__ ValueError: APA102_MOSI in use
You can switch the pins to use the APA102* pins, same result.
Line 112 is where it switches to using digitalio if busio isn't working.
So, I think it's trying to do both even though it should only do one.
its is working for me -- after soft reboot
I have your code as code.py -- I install adafruit_dotstar.mpy and adafruit_pypixelbuf.mpy from todays bundle
I have one from not today. Let me download today's bundle.
this is on a trinket m0, correct?
seems happy here
Hmm.
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Traceback (most recent call last):
File "code.py", line 7, in <module>
File "adafruit_pypixelbuf.py", line 204, in fill
KeyboardInterrupt:
Code done running.
Press any key to enter the REPL. Use CTRL-D to reload.
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
it is running -- I do control C to stop then control d to reboot
Mine is soft reloading on its own and failing after that.
Trying alpha4
Same issue.
I don't make changes to code, or anything, and it reloads eventually, and fails.
I am using latest ```
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 7.0.0-alpha.4-49-g9fdecacec on 2021-07-13; Adafruit Trinket M0 with samd21e18
I was running latest a minute ago
wanted to see if it was something in my build
so I tried alpha4 too
Alright, thanks for testing. Who knows. I don't have time to dig into this, really. If folks aren't complaining, it's probably a me-issue.
ah - if I write to the CIRCUITPY drive while it is running , it reloads and fails
Oh.
Ok so it's not a me issue.
MacOS does writey-type things all the time I think
so I'm getting the reload more often
probably -- it is fin on my Linux system as long as I don't write to it.....that does sound like a CP issue...
code.py output:
Traceback (most recent call last):
File "code.py", line 4, in <module>
File "adafruit_dotstar.py", line 112, in __init__
ValueError: APA102_MOSI in use
Code done running.
``` happens when I write to the CIRCUITPY drive
This is line 112: https://github.com/adafruit/Adafruit_CircuitPython_DotStar/blob/d471f9e21e7881a8f43f2e82925ef95bfd92cecb/adafruit_dotstar.py#L112
So my thought was that it's doing both of those sections (try and except) when it shouldn't be.
It's odd because it still says "soft reboot" when I write to the DRive -- just like it does when I do a Control-D
Yeah, but ctrl+D fixes it. It's only on the write action where it reloads on its own that it fails.
it is not a "NotiMplemented Error" it is a "ValueError"
I meant, it's trying busio, and then trying digitialio. When it should only do one or the other.
That try/except woulde be a "notImplemented Error"
Hm
No worries π
the reboot should release the MOSI pin -- but there may be two reboot paths in CP -- slightly different.
next week is totally fine. no need to add extra stuff. good luck!
@idle owl mine behaves the same on my Mac (M1 Mini) -- it is running OK through control D reboots, but if I do touch /Volumes/CIRCUITPY/junk it crashes ```
Press any key to enter the REPL. Use CTRL-D to reload.
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Code stopped by auto-reload.
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Traceback (most recent call last):
File "code.py", line 4, in <module>
File "adafruit_dotstar.py", line 112, in init
ValueError: APA102_MOSI in use
Code done running.
Press any key to enter the REPL. Use CTRL-D to reload.
@solar whale So you think it's a CP issue?
Yes -- I think there is something wrong in the auto-reload.
Can you file an issue for it, please?
sure.
Thank you!
@gilded cradle Hello! I'm looking at adding rainbowio to Blinka. Seems like all the different modules are implemented slightly differently, and I'm not sure which one to model after, or what I'm supposed to be importing. Also, it should be supported on every board, it simply contains the colorwheel() function. But I don't know that it would work on everything for certain. That's an assumption.
As in what to import inside the detector lines.
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.4-49-g9fdecacec on 2021-07-13; Adafruit Trinket M0 with samd21e18
Code/REPL
code.py:
import adafruit_dotstar
import board
pixel = adafruit_dotstar.DotStar(board.DOTSTAR_CLOCK, board.DOTSTAR_DATA, 1)
while True:
pixel.fill((255, 255, 0))
### Behavior
Runs normally and continues to run normally after a Control-D soft reboot
but if I write soemthing to the CIRCUITPY drive w...
USB-C is a pretty notable feature to search on.
I also considered a feature for USB Micro, but then I felt it would be excluding USB A, USB Mini, Castellated, and pin headers. I felt adding each possible USB connectivity would make the filter list lengthier and a little awkward.
I also correct the markdown syntax on a board to remove the "Wi-Fi Bluetooth/BTLE" category. It now filters into each category correctly.
@idle owl filed -- add any comments you want.
Thank you!
you're welcome!
@gilded cradle I feel like there's more to this that I'm missing π
@idle owl if there's nothing board specific about it, then there's no reason to detect the board. π
Good call. Then what does rainbowio.py look like then?
It kind of depends on how you make use of rainbowio in CircuitPython. Do you have a code example?
@gilded cradle Yeah. Here's a pseudocode example: ```py
import neopixel
import board
import rainbowio
pixels = pixel-setup
while True:
pixels.fill(rainbowio.colorwheel(0))```
Or from rainbowio import colorwheel but yeah.
Probably something like this then:
[imports]
def colorwheel(color):
# Code to display rainbows goes here
I imagine it will be fairly small
So it's a python implementation of it..?
yes
Blinka is 100% Python
Oh!
We even rewrote the ioctl stuff to Python
So it's not really "using" CircuitPython.... it's reimplementing it?
Yes
That was where I was lost, I think.
No worries
OK, I'll give this a try.
I should say it's really like 98% Python since there's a tiny bit of compiled code such as libgpiod stuff.
Fair enough.
@gilded cradle How do I test this? I've tried multiple ways of trying to "install" Blinka from my local copy, but it's not working. What am I missing?
You can find where the files are installed with pip show Adafruit-Blinka or sudo pip show Adafruit-Blinka. Then just copy the file into the folder.
Ok. Thanks.
np. I think I have that in my Blinka guide.
@gilded cradle Have you seen this before? This is with an example that previously worked. Traceback (most recent call last): File "/Users/kattni/neopixel.py", line 4, in <module> import neopixel File "/Users/kattni/neopixel.py", line 6, in <module> pixel = neopixel.NeoPixel(board.NEOPIXEL, 1) AttributeError: partially initialized module 'neopixel' has no attribute 'NeoPixel' (most likely due to a circular import)
No. But it mentions a circular import, which means that something is importing something that imports it.
Oi. Ok...
The new module doesn't import anything. And it does that even without the new module.
Is neopixel.py your test script?
Yeah.
Rename it and it should fix it
Yeah, there's already a neopixel.py and it's getting confused
I feel so much better now, having done that myself!,
π
@gilded cradle Should I add an example using it?
Not sure how to make a board-agnostic example with LEDs though
so maybe skip it for now.
Answered my own question.
PR incoming.
@gilded cradle Actually one more thing - do I add it to setup.py ?
And do we have to do something to make it end up on PyPI?
Nah, you probably don't need to worry about an example. Maybe a guide page in the Raspi Blinka guide if you're feeling ambitious. Yeah, I forgot you probably will need to add it to setup.py.
To get it to PyPI, just publish a new release.
Under pymodules=[], right?
yes
New release of..? Blinka? I meant is there supposed to be a separate rainbowio thing on PyPI?
New release of Blinka. Nothing separate. We have displayio and bleio separate because they're big repos.
yw
@gilded cradle PR submitted!
Thanks, I'll take a look
@gilded cradle Failed on things I didn't change?
Oh... Hah. Yeah it does that.
Does Blinka use pre-commit?
We had to pin it in the libs because of pre-commit.
Doesn't appear to. That's a whole other thing to set up if we want to do it.
No, it's on the to-do list.
Yes please
On it.
Thank you
Pinning to the version used in the libs.
@gilded cradle Well that narrowed it down to 2 failures from that huge list.
I'll fix it.
It's an issue with the disables.
Yeah. it probably hasn't run since an even older version. Thanks.
This might be due to the board specific pin mask that prevents reset. (I forget what its called.) We should probably remove it completely in favor of never reset.
Thanks @AdamCummick and @microDev1
@gilded cradle Whew. Ok. Passing now.
Want to do a release?
Sure!
Looks good to me! Thank you! I'll merge once the tests pass.
I don't know much about serious protocols and which ones might be affected by losing a few tens of microseconds.
This is my impression too. I think what we have is good enough and we shouldn't spend time making it better when it won't get us anything additionally.
I'm going to close this issue. If you find other devices that expect more accuracy (rather than synthetic test signals) please open issues for those. Thanks!
Yup, I think this is a bug here: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/bindings/rp2pio/StateMachine.c#L360
start and end need to account for the byte length of each entry in the given buffer.
I verify this issue that was present in 7.0.0-alpha.4 and is now fixed in the CI builds.
Tested with RP2040 and SAMD21 builds.
Thanks @hathach!
I wonder if going the other way, and generating a string for struct.pack from the descriptor to ensure it's correct wouldn't be easier? It would let you avoid the error in advance.
@turbid radish In the newsletter, there is that picture, that does not seems to match the description above or after:
The limit should be 8 (2 PIOs with 4 state machines each) assuming no other state machines are in use. . I'll look at why it hangs on 5, and make sure an error is raised when the limit is exceeded.
@idle owl You are probably aware of this, but your keypad demo in the macropad guide needs to be updated for the new rainbowio -- it tries to import colorwheel from _pixelbuf and throws an error
Thank you! I was not specifically aware. I know there's things to update, but I was going to wait until there was another release. Do you think I should just update now?
Not sure -- is the change in alpha.4 or after that
anyone using the "latest"releases, can figure it out on their own π
but if it's in alpha.4, I'd recommend updating it.
@thorny jay @turbid radish that's just one of the generic banners on my website; there wasn't a specific image for that article
It dates way back to this project ... https://emergent.unpythonic.net/01113670404 but I just liked the image.
The question on my mind was this: Where do I get a nice, fast DAC to run an XY display? How do I keep it fed with values? I discovered a very simple answer that I hadn't heard of before.
The harβ¦
Then I think it's ok to wait -- unless you want to go through the try/except trouble...
I really don't. π That was the whole point of this.
To avoid that.
I've got it on my radar, there's quite a few things in Learn to be updated. I mean, relative to the other changes we caused, there's NOTHING.
But it's a short list anyway.
No problem -- As I noted -- people on the "cutting edge" should expect such things.
True! Thanks for letting me know though. If you run into it after the next release, definitely let me know again.
The raw bytes of the descriptor are stored indefinitely, because we're not sure when USB enumeration is complete. I did not provide a read-only property for the descriptor because the descriptor is known to the the creator and I was try to save code space in the API.
See #4868 for my idea of how the API will change in the near future, before 7.0.0 final.
@lone axle Hey! So I talked to Dan - he'll be back tomorrow sometime and will look more closely at the list. In terms of priority, I think we'll decide together because it all needs to be done, so perhaps whatever is simplest first. Or already in progress.
@lone axle I have a spreadsheet that I want to go over with you at some point later this week or next week depending on when we sync up. It's meant to simplify things, but it ended up getting a bit complicated, heh. Or maybe it's not as bad as I think it is?
Sounds good, simplest first does make sense to me as well so that the easier ones can be done and not hindering anyone else while we tackle the more complex or larger ones.
Yeah, for sure. OK, I'll let you know what Dan has to add, and we'll sync up later this week. Thanks again!
iirc my branch that added the descriptor as a property increased binary size by 100ish bytes so it wasn't something to add lightly.
The hack I arrived at was that I could tell the difference between the two descriptors by trying to send an all-zeros report and see which length succeeded. This is OK for keyboards since all-zeros is "no keys pressed". It's probably not a general solution.
We are working on a new Feather board based on the STM32L4R5 and I would love to have CircuitPython support for the board. I know CPy already supports the F4, but I would love any guidance you all could provide on how to get started with a new port, where to look, etc.
Thanks!
@slender iron is it ever acceptable to set a PWMIO to a frequency of 0?
(it is not ok for ESP32S2 but I'm wondering if this is a think we want to check for in shared bindings)
Hi @bsatrom, that chip looks neat! Looks like TinyUSB already has support for it: https://github.com/hathach/tinyusb/tree/master/hw/bsp/stm32l4r5nucleo
Our stm port (in ports/stm) relies on the STM HAL so it shouldn't be too bad to add support within that port. The README includes build instructions: https://github.com/adafruit/circuitpython/tree/main/ports/stm It doesn't look like there is any L4R5 support yet in CP so you'll likely want to mimic an existing board and mirror the chip fami...
I would encourage you to check out #3069 and #3192, which is where we discussed adding the F1 series - I laid out the steps required to add a new STM32 family in some detail there, and you can see the commits involved in adding the new family. While we ultimately closed it (the selection dev boards for the high end F1s wasn't great) there are parts of that implementation I'd encourage you to try and re-use, such as the page-based flash implementation.
I've made a number of python utilities...
No, I don't think it should be ok
@slender iron want me to add a ValueError in Shared Bindings for it?
I'm putting through a PR fixing that ESP32 timer leak
Resolves a number of issues within the ESP32S2 PWMIO module, including issues with the deinit function not releasing system timers properly, various unchecked issues with variable frequency channel assignment, and duty cycle config recalculation when the frequency is changed.
Resolves #4259
My testing for #4999 resolves your test case for my Wroom but if you can, please give that PR a spin and let me know if you encounter any additional problems.
usb_hid.devices should be in the order that boot.py added the devices with usb_hid.enable. So you don't need to use find_devices to search; just index directly.
sure!
Yep seems to work. I tested this on a MagTag with this CI build (Adafruit CircuitPython 7.0.0-alpha.4-65-ge2888cba6 on 2021-07-13; Adafruit MagTag with ESP32S2)
Is there a possibility that the ESP32-C3 will work with the Native Bluetooth CircuitPython port?
There is issue running tinyusb on crystaless L4, I haven't got time to look at this issue since https://github.com/hathach/tinyusb/issues/126
Hi, i have the same issue with a raspberry pico, i use comet animation suddenly some leds show a random color.
I'm using the pl9823 version of neopixels. Any ideas?
is it just me or does this file name end with a space ? github does not seem to be able to notice except in the URL, but I notice it locally, and it makes the windows Github GUI app error when trying to clone the repo. I would PR a fix.
https://github.com/adafruit/circup/blob/main/LICENSES/CC-BY-4.0.txt
Hi Neradoc. Any response or news about setting the ESP32S2 as an access point? I tried this: https://github.com/adafruit/circuitpython/issues/4246 (see anecdata's post) which seems to work for him but fail for me, on feathers2 (fail with start_ap doesn't exists for radio object, at wifi.radio.start_ap("Bob", "abcd1234")). So I have set the board as STA... but would be much better as AP. Let me know if heard something about that!
PS: Ha ha, didn't realised you actually opened this article...
are you useing the latest version of Circuitpython ?
Latest stable, from what I understand. 6.3.0, if I remember well.
Yep, just checked: Adafruit CircuitPython 6.3.0 on 2021-06-01; FeatherS2 with ESP32S2
Is it working with another version?
yeah so no, AP mode is in 7
Oh, goody. Is it stable enough?
eeeeeeeeeeeeeh you can try it, some things are definitely not stable in it, still a lot of bugs π¦
Hmm... I don't need much - AP spiting the connected sensors' data through some kind of UDP socket, that's all... I'll try and see how it goes. May post here based on the result. π
I want to implement FTP on IOTS2 module through circulePython.
Because OTA updates the underlying firmware, I can't update the main code of code.py, which bothers me a lot.
Referring to some of the routines in mircuitPython, one of them didn't work on my board.
from setuptools import setup
Post-run prompt "No module name 'setuptools'"
What do I need to solveοΌ
You are correct:
ls 'CC-BY-4.0.txt ' MIT.txt Unlicense.txt
PR incoming
thanks π
Awesome, this is plenty to get me started, thanks all!
Hi all, is the new WebBluetooth feature expected to work on the Feather nRF52840 Express? The latest release from S3 (adafruit-circuitpython-feather_nrf52840_express-en_US-20210714-e7c5165.uf2) does the blue flash but then nothing, almost like it crashes/halts. I scanned for Bluetooth devices with an nRF52 dongle and couldn't see "CIRC". It's also unresponsive over USB-Serial. Short video of the test here: https://www.youtube.com/watch?v=4OcNAR42abc
Quick attempt to use WebBluetooth from the latest Circuitpython build adafruit-circuitpython-feather_nrf52840_express-en_US-20210714-e7c5165.uf2
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.4 on 2021-07-08; Adafruit Metro M4 Express with samd51j19
Code/REPL
import time
import board
from neopixel import NeoPixel
pixel = NeoPixel(board.NEOPIXEL, 1, brightness=0.3)
lightshow = [0xFF0000, 0xCCCC00, 0x00CC00, 0xCCCC00]
step = 0
while True:
pixel[0] = lightshow[step % len(lightshow)]
time.sleep(0.1)
step += 1
Behavior
Traceback (most recent call l...
I want to implement FTP on IOTS2 module through circulePython.
Because OTA updates the underlying firmware, I can't update the main code of code.py, which bothers me a lot.
I believe #3454 might allow what you want to do, by uploading the file to the board, then resetting to run a script that replaces the old code.py with the new one and reset again to run the new code.py from then on. You have to make the drive writable too, that's covered in [the learn guides](https://learn.adaf...
Not without someone adding support for it. We don't have ESP BLE support yet.
@wide sail The AP as the UDP server, with multiple clients? The trick will be to determine the IP addresses of the connected UDP clients at the AP level. As I noted in the PR, the AP is currently fixed at the default IP address 192.168.4.1, and Station clients to that AP seem to get assigned IP addresses incrementing from there by the underlying DHCP on the AP device, but I'd say that could be a bit fragile. But UDP functions like recvfrom_into will reveal the IP.
If there are not multiple UDP clients, then I don't think it matters which is the AP and which is the Station, or they could both be Stations, they're just IP devices on the network.
hm, my project was going well but just after I changed my code so that it tries to write to CIRCUITPY from CircuitPython (storage.remount in boot.py) .. it crashes when I construct the camera object, which was working 99% before that (and certainly not hard-reset-crashing before). I'm going to try a fresh flash of CP itself and see if that cures anything.
well re-flashing it fixed the problem and now I successfully wrote a jpeg so .. that's nice
@juandoplt you might want to make a new issue, if you're experiencing problems with the RP2040. Since the underlying hardware is totally different, it's very unlikely to be the same issue across both vendors.
Successfully tested by me (Wroom Saola) and @todbot (magtag)
For a discussin in #general-tech Does anyone know if bleio is supported on the RP2040? -- it is not in the default build.
nevermind -- yes it is -- _bleio
What am I forgetting to do if I get "No adapter available" when I try to usr any of the ble examples with an Airlift -- I have NINA 1.7.1 installed.
Does this wiring look correct for the debug to a second USB? I haven't tried this level of debug before.
you need a uart to usb converter
ya, it should work. it does sound like it's unhappy
its early so there definitely bugs
This fixes build issues with USB off, tweaks the README to allow
for BLE-only boards and adds the Micro:Bit v2 definition.
Fixes #4546
Will this work?
https://www.adafruit.com/product/954
or this too https://www.adafruit.com/product/3309
I'm building CircuitPython for a super-simple custom board I have with an ESP32-S2 Wrover module on it, and I've gotten TinyUF2 built and flashed, and I built the latest CircuitPython from main but when I copy over the .uf2 file I get a series of RGB LED flashes and the CircuitPython drive doesn't show up. Is there something I look into to help debug what I have wrong here? I don't have a JTAG programmer on me, but the LED pattern appears to be Purple -> 4x Yellow -> Purple -> Purple
with ESP the debug UART is a good thing to read
I think the 4x yellow might be the safe mode wait for CP
purple is the bootloader I think
Gotcha, I can definitely try out reading the UART! I can hook up a UART->USB adapter to these pins that I've defined in my mpconfigboard.h?
#define DEFAULT_UART_BUS_RX (&pin_GPIO44)
#define DEFAULT_UART_BUS_TX (&pin_GPIO43)
Or is it a different set of pins? What baud rate should I need?
its not the default uart pins... its an idf setting
and you do a DEBUG=1 build of circuitpython
Gotcha, thanks! I'll dig around a bit then! Hopefully it'll be very obvious what's wrong once I can see that debug info
Ah, perfect, that's super helpful, thanks!
We can help with questions like this on Discord or if you are in china we have a CircuitPython WeChat group. You can add me on wechat as tannewt and I can add you to the group.
CircuitPython version
CircuitPython 7.0.0-Alpha.4 on 2021-07-15, Feather STM32F405 Express.
Code/REPL
None
Behavior
NeoPixel indicator short blinking (green) several times, then off, no REPL, CIRCUITPY drive not appear.
Description
No response
Additional information
No response
Try the 'absolute newest' build the "S3" https://circuitpython.org/board/feather_stm32f405_express/
7.0 .0 alpha4 did not work for me either (as you described) but the latest build does work
7.0.0-Alpha.4 (2021-07-15 github custom build) on 'STM32F411CE Black Pill' works fine.
Ah - I found that 7.0.0 Alpha.4 does actually boot and mount but it took quite a long time -- maybe 20 - 30 seconds after pressing the RESET button
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 7.0.0-alpha.4 on 2021-07-08; Adafruit Feather STM32F405 Express with STM32F405RG
>>>
also same with newest. build
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use ...
Question on circuit python and RP2040 Feather. Are there plans to port the alarm library to the RP2040 Feather? I sure could use the functionality that the library provides.
it's in
if you look at https://circuitpython.org/board/adafruit_feather_rp2040/ you'll see the alarm module under "CircuitPython 7.0.0-alpha.4"
will these prints be desired in the final version or are they just for debugging?
ditto (I won't cite every location)
The debug printing changes looked weird, but if it's intended then it's OK to merge. No testing performed.
some reading: https://github.com/adafruit/circuitpython/pull/4816
@tulip sleet At some point, I'd like to go over the breaking changes situation with you. I have plenty to do in the meantime. I'd like to get Tim spun up on that and info from you is the last piece, I think, before I can start that bit.
@tulip sleet @onyx hinge I'm at my desk now if we want to go over the 7.0.0 issue list
@slender iron I'm around as well
(no rush from me)
i am here too. My regular desktop seems to have a thermal problem and I had to roll back to my older computer.
@slender iron @onyx hinge ^^
maybe needs new thermal paste on the cpu?
I had one desktop unhappy until I redid the cpu cooler
want to do issues now?
sure; eating noodles but can do that in the background
@onyx hinge ^^
OK, join you in a moment!
With dynamic USB descriptors (#4689) you can do things like this. In my experimentation, I successfully created a descriptor with NKRO which also worked in the BIOS boot menu of a Dell (https://emergent.unpythonic.net/01626210345 & https://emergent.unpythonic.net/01625944378). However, functioning as a boot keyboard (particcularly on macs) is still a problem (#1136).
I'll add the match_all kwarg so we can remove all in 8.
I mean we're breaking everything else, might as well break more! π
Fixed by #3383. Thanks @DavePutz
This works for sure on esp32-s2 (I was using SD cards with it today), but is appears it's not properly supported on nrf or spresense. Oddly, sdcardio was tested and working on feather sense https://learn.adafruit.com/adafruit-microsd-spi-sdio/feather-sense-adalogger-featherwing.
Presuambly closed by #4999.
@laurastephsmith Please re-test and let us know if this is still a problem for you. We believe it was fixed by #3936.
One thing to try would be putting the neopixel code in RAM so that its running doesn't have to contend with flash accesses.
@robertgallup Do you know if this is fixed in the latest 7.0.0 builds?
We may not fix these errors but we should make the errno non-zero.
The reason is stored in a supposedly "reserved by ESP-IDF". Check if TinyUF2 is using the same RTC register as CircuitPython. Try a different one?
We can fix this so that referencing an unwritten key simply returns 0. In the long run we might want to rewrite this using, say, a single NVS key.
Use supervisor.ticks_ms() as added by #4936
Closing this because there have been many updates to TinyUSB. If you still see this problem, please reopen.
Closing since we're moving from gamepad to keypad.
There has been yet another MIDI update in the past couple of days. @DynamoBen Could you retry with an "Absolute Newest" build?
I have an appointment at 2pm, I need to drop off.
For reference, the default is defined here: https://github.com/adafruit/circuitpython/blob/main/ports/esp32s2/common-hal/touchio/TouchIn.c#L59
In general, I don't expect the default to be perfect so this is fine.
After giving this some more thought... I think the nvm implementation should be refactored to just do a sequential byte-array write to maintain consistency with other ports (nvm is only meant to provide basic flash write functionality) and this way the full 20480 bytes will be available.
CircuitPython version
7.0.0
Code/REPL
see #4320
Behavior
see #4320
Description
busio.UART buffer size must be a power of 2 on SAMD 21 port. Use a better error message.
Additional information
No response
Fixed by the streaming parsing.
See #4311 (which we closed).
We now have an internal-only Guide page in "Building CircuitPython" describing how to make a release.
hi @slender iron @tulip sleet @onyx hinge , looks like you are going over the 7.0.0 issues... I had some comments about a couple of those issues, I tried joining in but my mic is acting up so I'll leave my comments on the issue themselves, btw when is 7.0.0 planned to release?
we want to release it "soon", but we have no schedule (we basically never do -- it's done when it's done)
we are trying to prune the 7.0.0 issue list to make it clearer what we really need
@slender iron @tulip sleet my internet broke, I'll rejoin when it comes back
Since the buffers are full, we never see the ctrl-C, because it hasn't been delivered yet. So we cannot fix this on the CircuitPython side.
i can still hear you fine
So basically the ETA is always ASAP?
section `.dram0.bss' will not fit in region `dram0_0_seg'
region `dram0_0_seg' overflowed by 2816 bytes
This is happening because debug mode changes optimization flags which in turn makes the firmware much bigger.
You can work around this by disabling some modules you aren't interested in debugging (ulab is probably pretty big) when using DEBUG=1.
Leave as interruptible for user code, but internal uses of PIO should be able to be non-interruptible.
@BradChan Closing for now. Please reopen when you're ready. Thanks!
@onyx hinge is de-optimizing the compiler something explcitly useful when debugging core code? https://github.com/adafruit/circuitpython/issues/4984#issuecomment-880935677
@crimson ferry generally speaking, higher optimization levels are regarded as interfering with the quality of debug information, so esp-idf turns optimization levels down when debug is enabled.
Thanks! This is fine for now; we can investigate refactoring later.
I'm going to close this now without prejudice., since this is still under discussion and the approach may change. We can come back to this.
Closing this for now, since the clock logic needs to be gone over carefully. Let's reopen if further work is done.
We can revisit this when you're interested again, but probably the efforts should be applied to the "main" (non windows) build. Thanks!
@DavePutz Any idea what could cause the second screen? Should we just merge this as-is?
its more about approach and prioritization than having any set target date
we're switching to prioritizing bug squashing so we can get it more stable
@crimson ferry @supple gale want to finish https://github.com/adafruit/circuitpython/pull/4131?
Yeah, I think it's better to know what you need to do and do it rather than try to plan a date and rush to meet deadlines
just tried to build microbit_v2 but failed with this ```jerryneedell@jerryneedell-ubuntu-macmini:~/projects/circuitpython/ports/nrf$ make BOARD=microbit_v2 -j8
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
QSTR updated
215752 bytes used, 62776 bytes free in flash firmware space out of 278528 bytes (272.0kB).
38528 bytes used, 92544 bytes free in ram for stack and heap out of 131072 bytes (128.0kB).
Create build-microbit_v2/firmware.uf2
python3 ../../tools/uf2/utils/uf2conv.py -f 0xADA52840 -c -o "build-microbit_v2/firmware.uf2" build-microbit_v2/firmware.hex
make: execvp: hexmerge.py: Permission denied
make: *** [Makefile:270: build-microbit_v2/firmware.combined.hex] Error 127
make: *** Waiting for unfinished jobs....
Converting to uf2, output size: 431616, start address: 0x27000
Wrote 431616 bytes to build-microbit_v2/firmware.uf2
did you install pip install intelhex?
ah -- no -- will do and retry
says I already have it installed
Requirement already satisfied: intelhex in /home/jerryneedell/.local/lib/python3.8/site-packages (2.2.1)
hrm, not sure why you'd get a permission issue
Actually, did it fail -- or just was it waiting -- the files are there....
is there a firmware.combined.hex file?
background.o common.ld firmware.bin firmware.uf2 main.P sd_mutex.P
background.P device firmware.elf genhdr nrfx shared-bindings
bluetooth extmod firmware.elf.map ld_defines.pp peripherals shared-module
boards fatfs_port.o firmware.hex lib py supervisor
common-hal fatfs_port.P firmware.objs main.o sd_mutex.o
no
@idle owl @tulip sleet I think something like```c
#if CIRCUITPY_PIXELBUF
extern const struct _mp_obj_module_t pixelbuf_module;
#define PIXELBUF_MODULE { MP_OBJ_NEW_QSTR(MP_QSTR__pixelbuf),(mp_obj_t)&pixelbuf_module },
{ MP_OBJ_NEW_QSTR(MP_QSTR_adafruit_pixelbuf, ... },
#else
#define PIXELBUF_MODULE
#endif
that is needed because it'll have the softdevice included
ok -- I'll look at the makefile and see if I can figure it out.
I copied this down.
π re ETA ASAP -- that implies schedule pressure. We have goals for a release, and when they're done we're happy. But we can trim the goals back or add new ones.
Personally I consider ASAP to be lacking a schedule, just... When it can be done. But yeah, I think it's better to have loose goals and go with the flow of what's needed. It's not like it needs to be done or someone loses their job!
@lone axle Shared the spreadsheet with you for breaking changes. We can go over it when we're both available. Simply wanted to get it to you.
"I think I'll make a cake. I have to buy the ingredients, and then mix things up and put them in the oven. I might get interrupted, but I will have a cake eventually."
I need this approach in more aspects of my life
Wisdom from Dan.
Thank you. I think I should be around tomorrow or monday if either works for you.
Monday will probably work better. Tomorrow is a short day for me.
It is still an issue (as far as I know). I haven't had any time to look at it lately though.
What I do know:
- The behavior is what would be expected if the column select command is sent 0 instead of a real value. Verified this by sending 0 on purpose.
- The logic analyzer shows the correct value being sent, but the display renders otherwise. I'm not sure why the discrepancy.
- I changed the flow at one point to send each column select command byte one by one (ignoring DMA). In that ...
@slender iron do I have to specify anything other than make BOARD=microbit_v2 ?
maybe make BOARD=microbit_v2 SD=s140
@tulip sleet Thanks -- but still getting the permission error -- happens on Linux and Mac...
Try running hexmerge directly
So I'm interested in helping with the dev process for CP... but I've never used GitHub, and I'm still pretty new to CP -- should I wait until I'm more familiar with CP before trying to help? Or are there smaller things to be done that I can be helpful and also become more familiar with CP?
(On my phone)
OK -- trying to figure out the full command....
Have you seen https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github ? Take a look at the open issues (including "Long Term") to see if you see something you'd like to start with.
hmmm -- where is hexmerge??
we have a few "good first issue" issues marked
ahh erryneedell@solar whaleeedell-ubuntu-macmini:~/projects/circuitpython/ports/nrf/build-microbit_v2-s140$ hexmerge.py bash: /home/jerryneedell/.local/bin/hexmerge.py: Permission denied
chmod +x hexmerge.py
Y'know, now I realize I had looked at that and forgot about that page XD thanks. I'll take a look at that again!
why do you have a hexmerge.py your .local/bin?
no idea
π how old is it?
someone must have pip-installed it
-rw-rw-r-- 1 jerryneedell jerryneedell 4542 May 12 2020 hex2dump.py
-rw-rw-r-- 1 jerryneedell jerryneedell 2850 May 12 2020 hexdiff.py
-rw-rw-r-- 1 jerryneedell jerryneedell 3662 May 12 2020 hexinfo.py
-rw-rw-r-- 1 jerryneedell jerryneedell 6207 May 12 2020 hexmerge.py
-```
I pip installed intelhex
you got hexed
re-installed -- mow executable
yay! that worked!
Now for the really silly question -- how do I get it onto the microbit_v2?
i think it shows up as a drive, and you drag the .hex to it. Kind of like UF2.
Thanks! I will give it a try tomorrow .... priority interrupt at home π
Now the big question is, should the Adafruit pixelbuf Python repo be called Adafruit_CircuitPython_Pixelbuf or Adafruit_CircuitPython_pixelbuf. It won't affect the file name, so it's simply a matter of choice.
or even PixelBuf? I think BusDevice is the example to follow?
I think it's become a proper noun at this point. So Pixelbuf works.
I named my phone after it (it's a Pixel to begin with) but the lady in my headphones tells me they're "Connected to pixel-byoof" and it makes me snicker every time. Not as much as her saying they're connected to "Robo-creep" (My computer is called Robocrepe. She doesn't know French apparently.)
@idle owl would it be pronounced better if you added one more f at the end?
Who knows. Distinct possibility.
byooff?
btw, I name my computers by computer constructs from fiction, and my work computer is called murderbot, which has led to some weird looks already
Entertaining series of books, the ones with "murderbot". I was put off by the name, but glad I tried it anyway.
yeah, it's a self-deprecating name
My current main workstation is Rocinante
watching a fictional TV show is their goal
All of my machine names are from media [except a few test things, lol]
The Cucumber boards are basically Saola boards, with different form factor, an LED, and second USB-C connector (and sensors on the "S" versions). Saola firmware runs just fine on these boards.
In this PR, are we doing 1 board (R/RS), 2 boards (R and RS, or M/MS and R/RS), or all 4 boards (M, MS, R , RS)?
If R & RS are combined, I think it's OK as is to define SDA and SCL, but not I2C, though on the R version, it's just Gravitech's color coding and compatibility with the RS version...
@tulip sleet Hah, joke's on me - the class in adafruit_pypixelbuf is called PixelBuf.
Β―_(γ)_/Β―
The simpletest is kind of gnarly in Pypixelbuf. But there's really not a good way to test that lib alone. Most folks aren't using it directly. Haven't heard anything bad about it, so I'm not going to think to hard about it.
Are there any other Adafruit pin naming conventions (like
board.LED) we should add extra pin names for in board? Saola is bare-bonespins.c, onlyIOpins,RX/TX, andNEOPIXEL.
If there is a single-color LED, definitely add board.LED. In general we try to make the pin names correspond to the board silkscreen names. It is not necessary to add board.TX, etc., if they are not labeled as such.
Should we try to normalize pin naming longer-term across all ESP32-S2 boards?
...
I thought I misread that as Cucumber, but no it was not a misread.
Ok, I need to test it, but I think the adafruit_pixelbuf Python implementation is ready to go.
Makes sense to me. I did two definitions, for the M variants and the R variants. As you said basically the Saola with an additional led. (and I2C sensors.
Although some pins are not specifically labelled on the board they are on the pin-out diagram so it makes sense to me (fwiw) to define them.

Tested on Trinket. Works.
Tested on QT Py for NeoPixel. Trinket is DotStar. Both work.
@tulip sleet The Python side of things is in place and ready to deploy. I'll look at the CircuitPython side of things now and tomorrow. Is that quickly enough to ensure it ends up in alpha.5?
Yup, this was intentional and should be guarded by an #if still.
I did two definitions, for the M variants and the R variants.
@skieast can you commit the M/MS version? Are there differences besides in ports/esp32s2/boards/gravitech_cucumber_*/sdkconfig?
@tannewt - let's not merge this yet. I'll see if I can get things to have
more consistent timing.
On Thu, Jul 15, 2021 at 2:37 PM dmcomm @.***> wrote:
I propose making the minimum pulse time a whole PWM cycle instead of half.
β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/pull/4964#issuecomment-880961042,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF...
sgtm, thanks for the review dan.
fwiw, I ended going back to C for my matrixportals. chaining them together just didn't leave enough memory for me to do anything interesting. Also was able to update the lib to (theoretically) support 888 rgb instead of 565. So I ended up losing interest in this one, my apologies.
Now we use never_reset which is generally more correct and easier
to get right.
Fixes #5001 and fixes #4997
@itacainnovation please review this for your board. I wasn't sure why you had some pins set to not reset.
PA00 and PA01 are the APA102 pins, but they are commented out on lines 6 and 7. Is that a mistake? They are not commented out in the regular trinket_m0/mpconfigboard.h
This is a nice cleanup! Just one question.
I don't know. I assumed they may share flash pins.
I looked at the schematic, and PA00 and PA01 are still just connected to the NeoPixel. So I think those lines should be uncommented.

The alorium tech board needs a #include, and it looks like the cache key for xtensa needs to be bumped again: all those builds failed with the typical error caused by a bad cache :/
I did two definitions, for the M variants and the R variants.
@skieast can you commit the M/MS version? Are there material differences besides in
ports/esp32s2/boards/gravitech_cucumber_*/sdkconfig?
I don't have an M board to test so my version for that board is theoretical.
The only changes should be in sdkconfig, mpconfigboard.c (MICROPY_HW_BOARD_NAME), mpconfigboard.mk (USB_PID and USB_PRODUCT). As I can't test this board I would not commit my initial changes
No. It does not seem to be fixed. I just tried the irremote_simpletest.py example with CircuitPython 7.0.0-alpha.4 and and V7 adafruit-irremote.mpy library. Auto-reload still doesn't work. Also, remote_simpletest.py randomly exits after some passes through the While True loop, which is an error, I think.
I spent a evening attempting this and couldn't make enough progress and I wont have another opportunity for months. Unfortunately, @PranavMKrishnan gave it his best as well but wont be able to implement deep sleep either. :(
@hierophect if I were to pool some money together into a "bounty," do you have the bandwidth to attempt this?
I believe this was already resolved by this pull request I made that was accepted
https://github.com/adafruit/circuitpython/pull/4011
I believe this was already resolved by this pull request I made that was accepted
Thanks! We think there may still be a problem with UF2 builds and will re-test.
@dmcomm - I agree with your proposal; I changed the minimum pulse to be a whole PWM cycle and it helps. Also, I'm not sure if your excellent test scripts are just to show a condition; but if you want more accurate pulseout timings on the RP2040 you should consider changing the PWM duty_cycle value to 65535. That helps the pulse consistency, particularly for shorter pulses. @tannewt I think we can merge this one now.
CircuitPython version
7.0.0-alpha.4 on Tiny2040
Code/REPL
import board
import busio
import displayio
import digitalio
from adafruit_st7789 import ST7789
import usb_hid
from adafruit_hid.keyboard import Keyboard
from adafruit_hid.keycode import Keycode
import usb_midi
import adafruit_midi
from adafruit_midi.note_on import NoteOn
from adafruit_midi.note_off import NoteOff
# if you want to use this as an HID keyboard, set keyboa...
I implemented a traceback module for this here.
Currently it just moves sys.print_exception() to traceback.print_exception().
I don't have an M board either. @cotdp are you still around? If not, maybe we stick with the R-variants for this PR.
This is very useful!
An old issue #3301 would be fixed with this!
Thank you for working on this.
A
I implemented a
tracebackmodule for this here.
Currently it just movessys.print_exception()totraceback.print_exception().
It would also be super helpful to be able to obtain the traceback-string instead of just printing it.
@DavePutz thanks! Yes, these scripts are just for illustration. I did previously try to do non-modulated output with a high frequency and 100% duty cycle, but my signal was too fast for that, so using PIO now.
I am trying to checkout the MicrBit V2 build, but I am very confused about how to actually access it. Are there instructions anywhere for using it? I have it loaded on the board and but I just can't make much progress via code.circuitpython.org.
I get this far using the USB connection, but not sure what to do next...
@tannewt I see that the Makefile now relies on a script hexmerge.py which is not in the source tree.
Where is it supposed to be taken from?
hexmerge.py is part of the intelhex package.
I installed it via pip3 install intelhex
@tulip sleet Good morning. I'm going to proceed with the _pixelbuf rename. I will definitely need some help. I talked briefly with Jeff about it yesterday, so at least one question is essentially answered, but there will certainly be more.
Already have one.
@tulip sleet Let me know when you're available.
I would be happy to help with testing this build, but I am completely baffled about how to use the board.
I have occasionally managed to get the serial device to spit out the CP version info (see screenshot), but nothing else. I can see the CIRCPY BLE device but have made no progress connecting to it.
Should I be able to get to the REPL via something like screen? I can connect, but get no responses....
Clearly, I am missing something. Are there any instructions for using code.circuitpython...
Has anyone tried using the Adafruit_CircuitPyhton_Airlift library recently -- I am not able to get ti to communicate with the HCI device on several boards -- issue here: https://github.com/adafruit/Adafruit_CircuitPython_AirLift/issues/4
Hmm. I might have done it.
>>> import adafruit_pixelbuf
>>> dir(adafruit_pixelbuf)
['__class__', '__name__', 'PixelBuf']
>>>```
That looks good. Suppose you import _pixelbuf
>>> dir(_pixelbuf)
['__class__', '__name__', 'PixelBuf']```
This is what it looks like: #if CIRCUITPY_PIXELBUF extern const struct _mp_obj_module_t pixelbuf_module; #define PIXELBUF_MODULE { MP_OBJ_NEW_QSTR(MP_QSTR_adafruit_pixelbuf),(mp_obj_t)&pixelbuf_module },\ { MP_OBJ_NEW_QSTR(MP_QSTR__pixelbuf),(mp_obj_t)&pixelbuf_module }, #else #define PIXELBUF_MODULE #endif
I presume we delete the fourth line once 7 is released stable?
I think we would delete it in 8
I didn't change the references to CIRCUITPY_PIXELBUF because CIRCUITPY_BUSDEVICE is how that was done.....
so, yes, when main becomes 8.0.0 dev branch
I guess I can PR what I did and you can tell me if I missed things?
that made sense to me; CIRCUITPY_ADAFRUIT_PIXELBUF was too long.
did you edit the doc string in shared-bindings to change the class name? You might add a note that it's also available as _pixelbuf, but that's deprecated.
I did not change the class name. Let me check what I did there.
There's nothing there to change. I didn't change the class name. Should I have?
That would change a lot more that I would need help with because I don't follow what C is doing with "classes".
you need to change __init__.c; that's where the module name is. The class name is the same; it's the module name that's changing
i wonder about the TODO there
you might need to do something here for the matrix to have it correctly https://github.com/adafruit/circuitpython/blob/c16f5595745c2246565a069fe77a67ecf2a76244/docs/shared_bindings_matrix.py#L65
Thanks Neradoc.
It would also be super helpful to be able to obtain the traceback-string instead of just printing it.
Yup! as mentioned above the plan is to have an api equivalent to cpython traceback module but the availibilty of the module functions will vary depending on the board due to flash restrictions.
Works on CPX. Circuit Playground Library no longer works on CPX. lol.
@tulip sleet Oi. The import block in NeoPixel and DotStar gets uglier for the time being. py try: import adafruit_pixelbuf except ImportError: try: import _pixelbuf as adafruit_pixelbuf except ImportError: import adafruit_pypixelbuf as adafruit_pixelbuf
Unless I'm missing something to maintain compatibility for now.
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.4 on 2021-07-08; Adafruit CircuitPlayground Express with samd21g18
Code/REPL
import adafruit_circuitplayground.express
Behavior
main.py output:
Traceback (most recent call last):
File "main.py", line 1, in
File "adafruit_circuitplayground/init.py", line 12, in
File "adafruit_circuitplayground/express.py", line 31, in
File "adafruit_circuitplayground/circuit_playground_ba...
Hah. Literally just found this out ^^
I need to redo the library to not use gamepad. I'm uncertain how to do that since the point of the gamepad usage in it is to track "were pressed" for the buttons.
@tulip sleet Wait, due to the other code, is keypad basically a drop in replacement here? https://github.com/adafruit/Adafruit_CircuitPython_CircuitPlayground/blob/63ac92f42b42bafc3fede9827318bcc22802148b/adafruit_circuitplayground/circuit_playground_base.py#L594
which other code?
Hold on, trying something.
I was going to write a tiny library for were_pressed kinds of things.
the problem is that gamepad takes DigitalInOut's but keypad takes pins, so there is a use conflict for .button_a and keypad, for instance. But this is not hard to re-code
Let me write the little helper code. I was thinking about it last night.
Ok.
Thanks.
Because this is something we need to fix ASAP.
heh
Whatever I did is running in safe mode. π
This is an issue with the Circuit Playground library. I'm looking into it now.
Now it came up. "Expected a Pin". So that didn't work.
Oh I see what you mean.
Pin in use now.
@idle owl hey. got library / bundle question if you have time.
Sure. What's up?
if you download the .py bundle and look at the code for this:
https://github.com/adafruit/Adafruit_CircuitPython_BNO08x
it's different than what's in the repo
there's more code in the bundle version
"more code"? More files? More in specific files?
the uart.py file in the bundle has this:
class BNO08X_UART(BNO08X):
"""Library for the BNO08x IMUs from Hillcrest Laboratories
:param uart: The UART device the BNO08x is connected to.
:param ~digitalio.DigitalInOut reset: The pin object to reset
:param bool debug: Enables print statements used for debugging. Defaults to `False`
and a ton more lines of documentation
is this a master vs main issue?
but it's like the repo code is behind
yeah it does.
Master was deleted. And I think took that code with it: "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." is what it says when you view the commit for the latest release.
Yeah PR 23 needs to be recreated.
Dylan thought she caught all of those that happened with.
But apparently this one slipped through.
ok, so a known hiccup that can happen with the branch move?
Yeah if PRs were open, and they weren't manually updated to be merged into main, then they could be merged into master still.
also, a weird thing where they sometimes autoclosed, but that's not this.
need any more info from me?
File an issue and assign it to Dylan please.
in that repo?
w3rd
done
Cheers.
- Renames
_pixelbuftoadafruit_pixelbuf. - Aliases
_pixelbuftoadafruit_pixelbuffor backwards compatibility.
The updates to NeoPixel and DotStar are incoming.
@solar whale what OS were you using chrome on?
macOS and chrome book
I've gotten it to work on macos
the first step to debugging is opening the web developer tools to see the javascript console output
Ok. Should screen work to get to the REPL via USB?
yes but its actually through the uart
I was debating leaving that on. I suspect I should turn it off soon to reduce confusion
Ah so do I need a uart to usb converter connection
no, the microbit has an interface chip on it
just explaining why its a ble-only board
Hmm, I connect but no response in screen
did you try ctrl-c?