#circuitpython-dev
1 messages · Page 402 of 1
the esp32-s2 devkits are $9, with PSRAM. and they have both USB connectors and are skinnier so fit on a breadboard with a row of pins to spare on both sides 🙂
just like the s3 devkits
It's probably best to tag CircuitPython Librarians in case I'm not in like yesterday.
It may only apply to the WROOM module -- does not appear to be an issue with the WROVER
FYI -- I updated CP and libraries and retried -- now only the first capture after reboot is valid -- all subsequent images are not able to be decoded by AIO
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 7.2.0-alpha.0-146-g190aee551 on 2021-12-16; Saola 1 w/Wrover with ESP32S2
>>>
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Connecting to WIFI
Connecting to Adafruit IO
Captur...
Ah gotcha and I guess there is no current work arounds at the moment?
That is right, sorry. You could look into using one of the TPL power switches to force a power cycle, or figure out some other way to hard reset or power-cycle the board.
Hello!
Please activate collections deque in CircuitPython. Thanks!
@slender iron Yay! Compute modules are back in stock -- ordered one with an I/O board
nice! at adafruit?
yup
https://www.adafruit.com/product/4982 going fast
ah - are you using this one https://www.adafruit.com/product/4782
yup, I have one of those
ok -- I got one of those as well -- only 1 left
great!
emmc shouldn't be too hard. the sd card code should be able to handle it. I just haven't tested it
What could go wrong 😉
For Windows bash, yes. I thought I had added a comment indicating this.
I understand this can't stay, but needed it to build on my side.
Looking for input on this - no idea how to resolve.
I am having lots of issues with the 4b and zero2w now --- I put some very confusing results in the 4b issue
I haven't had a chance to look at it yet
will look in a bit and see if it triggers anything in my mind
Ok, so do away with the existing code beneath this comment?
// This appears to be a board-specific way of supporting internal pullups without
// going through all of the changes I've made - @dhalbert can you comment?
// Not going to change anything here before discussion - will just throw internal_pullup away
#if CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP
gpio_pullup_en(sda->number);
gpio_pullup_en(scl->number);
#endif
This is in ports/espressif/common-hal/busio/I2C.c around line 64.
Ok, will fail on compile due to conflicting definitions? Remember that I call this method using the added param.
I haven't tried to investigate or fix this since Jerry initially reported it.
If move this up to line 124 and remove the #if CIRCUITPY_REQUIRE_I2C_PULLUPS, won't the pin pulls be set down after I set them up by the code following the else you suggest?
I think you mean I should put all of the test code into the else:
// Set pulls up if internal_pullup is true
if (internal_pullup){
nrf_gpio_cfg_input(scl->number, NRF_GPIO_PIN_PULLUP);
nrf_gpio_cfg_input(sda->number, NRF_GPIO_PIN_PULLUP);
}
else (!nrf_gpio_pin_read(sda->nu...
Ah, right. This could have a problem on boards without long int support. Otherwise we won't be able to have all 32 bits set.
I think the functionality may need to change a little. If only <=24 bits are used then do the current behavior of using white when all channels equal. If >24 bits are used then assume the highest byte is white.
I didn't see any coordination here. Did I miss it?
If it does need to be coordinated, then I'd expect it to be part of the existing object.
It'd also be helpful if you'd link to the prototype library.
Thanks!
Reopening this from a branch in my fork. That'll reduce the CI that runs.
pixelbuf needed it. I'll enable it in my branch so it comes in the next PR. Thanks!
@dhalbert Short answer: yes, and I get a voltage but no device addresses.
The steps required are as follows:
- Set the sensor Power Pin to 1: When I measure voltage on the declared I2C pins I get ~3.3V
- Create an I2C interface and look for device addresses using the following code
scl = microcontroller.pin.P0_21
sda = microcontroller.pin.P0_20
i2c = busio.I2C(scl, sda, internal_pullups = True)
while not i2c.try_lock():
pass
try:
while True:
print...
What board are you using? Some of them won't have space for it.
I'm using the Raspberry Pi Pico.
I was actually looking in the code to see if I could activate it and
recompile?
Thanks :)
On Thu, Dec 16, 2021 at 3:14 PM Scott Shawcroft @.***>
wrote:
What board are you using? Some of them won't have space for it.
—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/issues/5734#issuecomment-996162096,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKBDH547IIX4GKCJAPT44DURJCC...
start 0 count 0 is the print of the partition for the CIRCUITPY drive. Having it zero will mean CP doesn't have flash. I can add more prints to output the partition table info.
The command timeout on Zero 2 W is what I see too. Somehow, it isn't recovering from an error correctly.
The last Pi4b output is working I think. These are debug statements, not errors. My guess is that it's initializing the filesystem but is slow due to the debug prints. You can see that arg is increasing by o...
You can set MICROPY_PY_COLLECTIONS_DEQUE to (1) to enable it.
Thanks!!
I will definitely try it. It's also going to be an opportunity to learn how
to build it :)
On Thu, Dec 16, 2021 at 3:25 PM Scott Shawcroft @.***>
wrote:
You can set MICROPY_PY_COLLECTIONS_DEQUE to (1) to enable it.
—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/issues/5734#issuecomment-996169022,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKBDHZN2GR3V5E6T3FZQJ3URJDLNANCNFSM5KG5MDDA
.
Tr...
Is this a good place to object to the behavior of setting the white channel when R==G==B?
- There are at least three different color temperatures of RGBW NeoPixels, and in none of them will R+G+B white accurately correspond to W white in either tint or brightness.
- Altering the numbers in results in the getter returning a value different than was passed to the setter, and this is certain to result in misunderstandings. While not exactly the same thing, the way the Arduino library handles...
@tannewt no I do not. I will try to set it up, if I will have more time.
I just noticed this on github today.. It created a log like this for my python library: ```
What's Changed
- Add lgtm, do other stuff by @jepler in https://github.com/jepler/wwvbpy/pull/19
- Cover the
wwvb.gencli program by @jepler in https://github.com/jepler/wwvbpy/pull/20 - Etc by @jepler in https://github.com/jepler/wwvbpy/pull/21
- Small fixes by @jepler in https://github.com/jepler/wwvbpy/pull/22
- Add sextant, json output formats by @jepler in https://github.com/jepler/wwvbpy/pull/23
- Add macos & windows to the testing matrix by @jepler in https://github.com/jepler/wwvbpy/pull/24
Full Changelog: https://github.com/jepler/wwvbpy/compare/2.0.0...2.0.1``` -- looks good & super convenient!
@slender iron heads up that you can't merge this PR without setting up the required secrets first.
@tulip sleet my guess is you all built adabot before gh cli existed. I was able to do PRs much more simply without using the web api.
Are there unit tests to verify library changes for backwards compatibility without having a variety of physical hardware devices to test on?
For example, could changes to https://github.com/adafruit/Adafruit_CircuitPython_framebuf formats be tested on a local machine without having access to the different display hardware?
Most libraries don't have unit tests, but there are a few that do. To my knowledge none of them are designed to run against hardware. There have been efforts to introduce automated testing on hardware but it's a tough thing to solve comprehensively
A community member created this: https://github.com/mytechnotalent/CircuitPython_Unittest that can execute unit tests on hardware.
hum, main is failing to build ... ulab/numpy/__init__.pyi:51: error: Cannot assign multiple types to name "_float" without an explicit "Type[...]" annotation ulab/numpy/__init__.pyi:54: error: Cannot assign multiple types to name "_bool" without an explicit "Type[...]" annotation I don't think anything was changed in that area lately. however, mypy was updated yesterday and I saw problems elsewhere due to it.
yeah verified it's the 0.920 update that caused this problem
fix pr'd over in ulab https://github.com/v923z/micropython-ulab/pull/461 but we may find it easiest to pin mypy for a bit until we can percolate it into circuitpython (esp. 7.1.)
This should fix the doc build, which currently fails
ulab/numpy/__init__.pyi:51: error: Cannot assign multiple types to name "_float" without an explicit "Type[...]" annotation
ulab/numpy/__init__.pyi:54: error: Cannot assign multiple types to name "_bool" without an explicit "Type[...]" annotation
since mypy 0.920 was released.
After https://github.com/v923z/micropython-ulab/pull/461 or another fix is merged and our submodule ref is updated, we can un-pin mypy. However, as w...
Adding md files for 3 new boards.
Still need to update pictures and store links.
I turned-off the downloads to a couple as they are not ready on Tindie yet,
Thanks, I might be able to use that for something later on. I'm looking for tests that run locally without hardware. Can you link me to a library with unit tests that can run on a local machine?
also try to turn on pin 21 high on boot (to enable TFT before we init the display)
Pinging @tyomitch, who contributed
synthio.
On my Meowbit (which has audiopwmio but not a DAC-based audioio) with 7.1.0-beta.3, the example from the docs (with board.BUZZ.play(melody)) works with no problem.
I'd be happy to help, but I don't have a pybadge to test on.
BTW, what sound should it make? Is tempo=640 too high?
http://atari.ruvds.com/level.mp3 (the start-level sound from QBasic Nibbles)
The tempo affects only the interpretation of the MIDI stream; as op...
CircuitPython version
Adafruit CircuitPython 7.0.0 on 2021-09-20; Adafruit Feather M4 Express with samd51j19
Code/REPL
USB keept dropping out, plugged in battery and got error message Crash into the HardFault_Handler. Maybe this is a brownout related bug/behaviour?
Behavior
cannot run any code
Description
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.
Please file an issue wit...
Press the Reset button or power cycle to get out of safe mode.
Checked against schematics; looks good!
It drops right back in to safe mode. I will try to format the 'drive' if I can get USB to stay alive for long enough.
This may be because your code is using lots of NeoPixels or other power-hungry hardware, and the USB power is sagging.
What else is connected besides the Feather M4 Express?
Did it, I'm now back to Hello World. I suspect that as I debugged my original code, more and more hardware got powered and I gradually moved into brown-out territory. Will reinforce power supply and try again. Thanks for helping.
I'm closing this for now, but feel free to discuss this kind of support issue on discord: https://adafru.it/discord or the forums: https://forums.adafruit.com/viewforum.php?f=60.
It is also possible you are exercising a bug that is causing the hard fault. In that case, reopen this or open a new issue, with the specific code that is causing that problem. Thanks.
@tulip sleet which do you prefer -- upgrading ulab [there aren't many changes, just one other bugfix to any()/all() in their main branch] or pinning mypy?
if mypy is only causing that one problem, the upgrading ulab is ok with me. Would this be in 7.1.x and main?
you can do it in 7.1.x and we can merge to main immediately
@tulip sleet yeah I at least assume the build problem is affecting all our branches
we'd have to pin mypy in both branches anyway, so we may as well fix the new issue
do you need to wait for v923z or can you proceed yourself
do we care if there's a tag in ulab for the commit we use?
if not, I don't think I need to wait
no, a commit is a commit, and when v923z does a release, we can move up if needed
This fixes a doc-building bug and also a bug with any()/all().
Thanks! Merge on successful CI.
@onyx hinge so does #5740 supersede #5737?
Backport #5738 to 7.1.x
BGRBGRBGR blows raspberry :tada:
Another quick question for you - I have changed the code, recompiled and
re-flashed the firmware.
The import now works.
When I try to use it:
self.stored_chars = deque([], 4)
I get a ValueError. I am trying to create an empty queue with a maximum of
4 elements.
Can you please give me a hint as how I can investigate this further, as all
I have is a ValueError without any other trace information?
*code.py output:Traceback (most recent call last): File "code.py", line
130, in <modu...
BGRBGRBGR blows raspberry :tada:
I will merge this to main and add to #5741 backport.
@tulip sleet frustratingly, the CI of #5740 skipped building docs due to path checks, so we won't really know if it's fixed-fixed. doc building passes in my local testing, though. The relevant regular expression looks like it intended to fire on changes in ulab but seemingly it didn't. ```python
doc_pattern = re.compile(
r"^(?:docs|(?:(?:extmod/ulab|ports/\w+/bindings|shared-bindings)\S+.c|conf.py|tools/extract_pyi.py|requirements-doc.txt)$)|(?:-stubs|.(?:md|MD|rst|RST))$"
)
why are the /'s escaped
I'm not sure why the forward slash characters are escaped either
I was literally just typing that 🙂
lol
does the ?: bind to the whole parenthesized thing or just the ulab part
nesting is confusing:
the ?: modifies the whole (...) group
so what's the purpose of the first (?:
jepler@bert:~/src/circuitpython/tools$ PYTHONPATH=../docs:adabot CHANGED_FILES='["extmod/ulab"]' python3 ci_set_matrix.py
Adding docs/boards to build based on changed files
Building docs: False
::set-output name=build-doc::False
Building boards:
datum_imu
good news: I think I can test locally
i will not merge without your ok
Try deque((), 4). The MicroPython code does not support initialization, and only allows an empty tuple, not an empty list.
I can't explain the whole design of the regular expression, but I think I know why it didn't do what was desired in this case... I'm pretty sure extmod/ulab has to be followed by \S+\.c i.e., a file with a C extension. But it won't be, because it's a submodule.
PYTHONPATH=../docs:adabot CHANGED_FILES='["extmod/ulab/blorp.c"]' python3 ci_set_matrix.py | head -2
Adding docs/boards to build based on changed files
Building docs: True
If a filename was received, it would have built the docs
if you are going to fix it, I would say remove the escaped forward slashes, at least.
Thanks! Merge on successful CI.
can be tested in an online re tester?
do you have one you trust?
OK updated one more time with the escaping of forward slashes removed..
there are lots, including ones that claim to be python:, e.g. https://pythex.org/
I did a couple of local invocations of the script and the results look plausible still
CI doc failure only, which we are fixing.
I don't know why the CI rebuilt so many things for a one-board change.
Hey there. Is there any Adafruit code that uses exponential backoffs for CircuitPython? I was mainly looking at reusing, or coding something new, for devices like the MagTag when they get network errors to not loop and retry with time.sleep(), but with exponential backoffs and deep sleep.
I am guessing I can store the current backoff number in sleep_memory
CircuitPython version
Adafruit CircuitPython 7.1.0-beta.3 on 2021-12-13; Raspberry Pi Zero 2W with rp3a0
Code/REPL
import time
time.time()
time.localtime()
time.mktime()
Behavior
File "", line 1, in
NotImplementedError: No long integer support
### Description
_No response_
### Additional information
_No response_
Excellent, thank you!
On Fri, Dec 17, 2021 at 10:30 AM Dan Halbert @.***>
wrote:
Try deque((), 4). The MicroPython code does not support initialization,
and only allows an empty tuple, not an empty list.—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/issues/5734#issuecomment-996813270,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKBDH7LYOZSFDBQU5DRATDURNJTDANCNFSM5KG5MDDA
.
Triage notifications ...
I'm assuming (hoping :) ) the broadcom raspberry pi platform isn't space constrained so long integer support shouldn't be disabled?
Hi, let's leave this open until you add some pics. Even something quick like a board layout as a placeholder would work for now.
Requesting some photos to be added.
HI, replied to your queries, and deleted a few erroneous comments of mine.
Whoops, I was wrong. I thought this was part of a struct.
The idea of this PR is to be able to specify internal pullups at run-time, instead of compile time. Conceivably you would want board.I2C() or similar to use internal pullups, but that would be for a specialized board (e.g. your company board), not for any current board. That would be a reason to use a compile-time setting, and the reason I suggested BOARD_I2C_USE_INTERNAL_PULLUPS
not do away with it, but move it into the then clause of the if statement above
.. not enabled on s3 & c3 as I did not test there.
I hear you.
The only reason I've added a constant at all is to accommodate common_hal_board_create_i2c(void): It callscommon_hal_busio_i2c_construct which will include the internal_pullups param. I figured the least invasive change was to declare a constant rather than change yet another method signature.
Thoughts?
Ok, so remove the #if and wrap the contents into the if-else. Can do.
Right, I'm just saying check for the constant CIRCUITPY_BOARD_I2C_USE_INTERNAL_PULLUPS in common_hal_board_create_i2c(void). But define that constant directly, and then I think you can eliminate CIRCUITPY_I2C_INTERNAL_PULLUPS and I2C_USE_INTERNAL_PULLUPS.
In other words get rid of the older existing current compile-time checks for internal pullups; we are going to do it at runtime instead.
@onyx hinge if you have time to review https://github.com/adafruit/circuitpython/pull/5741, I will then merge 7.1.x back into main
Not to be thick-headed, but confused about what you mean by "define that constant directly".
To clarify, I assume you mean something like
mp_obj_t common_hal_board_create_i2c(void) {
// All callers have either already verified this or come so early that it can't be otherwise.
assert(i2c_singleton == NULL || common_hal_busio_i2c_deinited(i2c_singleton));
busio_i2c_obj_t *self = &i2c_obj;
self->base.type = &busio_i2c_type;
// ---> Check if board supports i...
My question is how can I know at runtime if the board has support for internal pullups?
With the addition of the internal_pullups argument to busio.I2C(), any board can now support internal pullups. You just have to ask for them by setting internal_pullups to be true in the constructor.
The question now for a particular board is whether board.I2C() asks for internal pullups by default. So I'm sayin to remove the older compile time constants, and add a `CIRCUITPY_BOARD_I2C_...
maybe dyno's under the weather
I expected this to play two notes, then quit.
Instead it plays a warbling sound that only ends
when I call dac.stop().
# synthio test
# Raspbery Pi Pico RP2040
# Adafruit CircuitPython 7.1.0-beta.3 on 2021-12-13;
import time
import audiocore
import audiopwmio
import board
import synthio
dac = audiopwmio.PWMAudioOut(board.GP26)
G2 = 43
C3 = 60
midi = bytearray([
0, 0x90, C3, 0,
25, 0x80, C3, 0,
50, 0x90, G2, 0,
75, 0x80, G2, 0
])
audio = s...
@turbid radish 32,443 users via the 'server settings'
Ah, I think I understand where I was confused; you're trusting the developer to specify (and therefore, know) whether the board has support for internal pullups - I was going the other way, requiring CPY developers to define this in .mk files.
If I understand, you're saying "assume the board doesn't, but allow the developer to tell us it does". If that's true, then I did need to remember internal_pullups, and can get this from the self pointer:
busio_i2c_obj_t *self = &i2c_o...
CircuitPython version
Adafruit CircuitPython 7.1.0-beta.3 on 2021-12-13; Adafruit Feather ESP32S2 with ESP32S2
Board ID:adafruit_feather_esp32s2
Code/REPL
# SPDX-FileCopyrightText: 2019 ladyada for Adafruit Industries
# SPDX-FileContributor: Modified by Reppad
#
# SPDX-License-Identifier: MIT
import os
import board
import neopixel
import ipaddress
import wifi
import rtc
import time
import random
import socketpool
# Get wifi details and mor...
Would you like to enable rgbmatrix on C3 & S3 as well, since main branch is being tagged as alpha and this will encourage more people to test rgbmatrix as it is easier to just load a pre-built firmware.
One more thing, not necessary for it to be a part of this PR, there is a new commit available of esp-idf v4.4 branch.
^^ I'm open to opinions about the choice of whether to enable rgbmatrix for s3/c3.
Did you post and then delete (retract) a comment there? To answer that, nearly all chips have always had the capability of supporting internal pullups, we just didn't expose that. Now we are. It's a choice of the user about whether they are going to connect some I2C devices without pullups. That could happen on any board.
And, there might be some boards, with board-mounted I2C devices, without external pullups. In that case, we might want board.I2C() to use internal pullups by default....
Ok. I'm confused about some of this, mainly because I'm trying to relate now to set your suggested CIRCUITPY_BOARD_I2C_USE_INTERNAL_PULLUPS at runtime, but perhaps it's better to put a pin in this?
In the interim, I can simply pass true to that part of the method and move on to the bigger issue: i2c.scan() is not returning any devices, even after I set the pulls up and read a proper voltage (3.3V) on them at runtime.
Not sure why this is necessary, but it prevents an off-by-one error in some (rare?) circumstances.
Fixes the bug found in #5725:
>>> import board, neopixel
>>> pixels = neopixel.NeoPixel(board.D5, 8, brightness=1.0, auto_write=False, pixel_order=neopixel.GRBW)
>>> pixels[2] = 0x400000FF
>>> pixels[2]
(0, 0, 255, 0)
This doesn't close #5725, since that it is also about whether or not the behavior of integer values with RGBW neopixels is appropriate.
Is anybody planning further work on the paralleldisplay module? Things like allowing arbitrary pins, or 16-bit mode?
Ok. I'm confused about some of this, mainly because I'm trying to relate now to set your suggested
CIRCUITPY_BOARD_I2C_USE_INTERNAL_PULLUPSat runtime, but perhaps it's better to put a pin in this?
I'm suggesting that the compile-time constant need not exist at all. The user code will decide whether or not to use internal pullups.
In the interim, I can simply pass true to that part of the method and move on to the bigger issue: i2c.scan() is not returning any devices, even after I ...
@daring pumice can we have an audio chat re the internal pullups PR? Would save some typing and we can get on the same page, and I can hear about your testing difficulties.
Would really appreciate that. How would you like to set that up?
do you have a mic? We can talk in the Amelia Earhart channel. Just click on it.
I do. Headed there now
I've reproduced your result.
But this ran a few hundred loops without issue:
import supervisor
import time
import random
import wifi
import socketpool
import ipaddress
from secrets import secrets
SERVERS = ("1.1.1.1", "1.0.0.1",
"1.1.1.2", "1.0.0.2",
"8.8.8.8", "8.8.4.4",
"9.9.9.9", "149.112.112.112",
"208.67.220.220", "208.67.222.222",
"208.67.220.123", "208.67.222.123")
print("Connecting...")
wifi.radio.conn...
@tulip sleet I'm trying to select a microcontroller for scaling across several high schools and colleges that I work with. My curriculum is definitely not the typical approach to intro material in that I am trying to teach async and event triggering.
We currently have a SAMD21 board and a bunch of micro:bit v2 boards (we liked them because makecode also works and has libraries unlike with other ARM boards), but looking at the list it seems like some of the libraries are not enabled on the micro:bit v2. Could we quickly hop into an audio room to chat about what can be enabled or what other alternatives I should consider?
Let's talk here first
micro:bit v2 is only experimentally supported by CPy, and doesn't have the normal USB workflow. SAMD21 has too little RAM and flash to support asyncio and numerous other things
Circuit Playground Bluefruit I think has experimental MakeCode support, but I'm not sure.
It has a good amount of RAM and flash
https://maker.makecode.com/ has definitions for nRF52 and M4 (SAMD51) adafruit boards
if MakeCode is a strong requirement
also #help-with-circuitpython or #classroom might be more appropriate channels; this is really the dev channel for circuitpython
oh I see - what's different about the workflow
microbit:v2 (and v1) only have serial connections over USB. They cannot present a CIRCUITPY drive, like all the other CircuitPython boards.
this is true, but for some reason the library on maker.makecode vs makecode.microbit seems to be different (I assume they must not be implemented using a common HAL API but are implemented using board-specific features) (way fewer on maker.makecode)
I would think it's not ping then, perhaps something with the global variables being set in-loop or issues with time?
If I remove the global variables and just have the function return True or False, it crashes in 2 loops or 4 pings.
I just got into python. I have no clue.
We are developing a BLE-based workflow to allow editing programs and talking the REPL over BLE instead of over USB. That would be the way to talk to the microbit:v2. However, it's early. See the PyLeap and Glider apps, which are still in beta.
Advantage of BLE-based workflow is that you don't need a USB host: you can use tablets and phones. Disadvantage is that there's more setup, less reliable connections, etc.
yea exactly
the other MCUs I had initially shortlisted were rPi Pico (seems to be the cheapest RP2040 board but no wifi or BLE), ESP32 (I believe this WROOM version is what I have to test https://www.amazon.com/KeeYees-Development-Bluetooth-Microcontroller-ESP-WROOM-32/dp/B07QCP2451/ref=sr_1_4?keywords=esp32&qid=1639785020&sr=8-4), or Particle Argon (but seems way too expensive).
Pi Pico is cheap, could use a reset button; there are many other RP2040 boards availble. ESP32 (plain ESP32) does not have CircuitPython support, again because no native full USB. We support ESP32 only as a wifi or BLE coprocessor. ESP32-S2 we support with a number of boards. We will be supporting ESP32-S3 (very new) and probably ESP32-C3 (only with BLE; no native USB)
My original idea was get a cheap but reliable MCU + rPi 0W for every student.
microbit v2 came into the list because of MakeCode and onboard debugger
The Circuit Playground Express is our workhorse educational board, with the Circuit Playground Bluefruit being very similar but more powerful
The Feather boards work well with rechargeable batteries, but if you are doing elementary or junior high, you may not want to have bare LiPo batteries around (too much of a hazard if punctured, etc.
But you can use them with USB also. Many add-ons for the Feather boards (FeatherWings)
no elem, junior high
lowest is grade 7, highest is early university/community college. typical is grades 9-12
Advantage of the CIrcuit Playground boards is onboard NeoPixels, sensors, mic, speaker (so no wiring needed) and easy connection via alligator clips for external stuff
sure. In some ways, having a bunch of onboard peripherals is a bit of a disadvantage, because then kids don't get the experience of building stuff. It becomes almost purely coding which can be less interesting
Can you try to see what minimal example still produces the hard fault? Get rid of everything not essential to the demo.
Single CI failure was a CI problem, not a code problem.
any suggestions for boards under $15?
https://circuitpython.readthedocs.io/en/latest/shared-bindings/support_matrix.html#module-support-matrix is it possible to set this matrix to look at modules included in 7.1?
But the "latest" is very similar.
Under $15:
hmm. I guess I was looking for asyncio to be listed here, but that's only 7.1.x right
ItsyBitsy M4 ($15), ItsyBitsy RP2040 ($10), QT Py RP2040 ($10), Feather RP2040 ($12)
I am not including the SAMD21 boards
asyncio is a CIrcuitPython library, not a built-in module. You just need 7.1.0 due to some things asyncio needs internally
Feather ESP32-S2 is $17.50 (< $15 in qty), there are other boards similarly priced, I think
check back soon for QT Py ESP32-S2 https://www.adafruit.com/product/5325 (I suspect they'll go fast)
It hard faults with this code very fast
import ipaddress
import wifi
# Get wifi details and more from a secrets.py file
try:
from secrets import secrets
except ImportError:
print("WiFi secrets are kept in secrets.py, please add them there!")
raise
modemIP = ipaddress.ip_address("192.168.100.1")
# count the number of pings
ping_counter = 0
print("Connect wifi")
wifi.radio.connect(secrets['ssid'],secrets['password'])
def check_connectivity():
...
wow that's tiny. I guess the only big limitation is # of gpios, though the I2C connector is nice. Similar to the SAMD21 Sparkfun Qwiic Micro board
Thank you for finding this! It is "obvious in retrospect", for at least some definitions of obvious, but I had looked directly at this code just recently and still not seen it for myself.
I'm approving this PR, but with the caveat that we may wish to have the bugfix in the 7.1.x branch. @dhalbert please advise on that point.
Here's a rough expression based on my understanding of C: When using the conditional operator such as cond ? x1 : x2, the type of the whole expression depend...
I had done a tiny bit of investigating of adding 16 bit mode but ended up deciding it needed more time than I wanted to devote to it. My interest was in the screen of the esp32-s2 "hmi" devkit... where I identified trouble was, sometimes data needs to go out in 16 bit mode [display data] and other times it needs to go out in 8 bit data even if there are many bytes [register setting, mostly] and I wasn't sure how to accomplish it. So I set it aside.
@proven garnet very early "alpha" version for the I2C EEPROM breakout is here: https://github.com/FoamyGuy/Adafruit_CircuitPython_24LC32. Reading and writing single bytes and slices seems to be working. I haven't gotten around to testing the write protection yet.
I will backport this to 7.1.x, no problem.
thanks! I only verified the into / from branch names, the changes themselves were all previously reviewed.
@jepler Interesting! It took me a while to figure out that the bug was simply coming from the inline conditional so I very much appreciate that explanation as to why. Thanks!
I expected this to play two notes, then quit.
It does play two notes, then quit, on my Meowbit
Does adjusting sample_rate have any effect on your board(s)?
Is it possible to run circuitpython libraries directly on a local machine cpython? For example, something like adafruit_framebuf doesn't seem to have any hardware dependencies
Some libraries have test suites that I assume gets run on a build machine so I think it's probably possible to run some things locally?
What system are you trying to run it on? There is an interface called "Bilinka" that support running CircuitPython Libraries with CPython on a Raspberry Pi and other single board computers. https://learn.adafruit.com/circuitpython-on-raspberrypi-linux
even on a desktop, with a gpio adapter
Doubling the tempo does make it play at twice the speed.
Also works on my homemade board with 24C65 and 24FC64
With 7.1.0 beta3 I get one note on the pybadge, followed by silence until I call dac.stop(). On the pi pico it loops the one note until I call dac.stop().
Maybe someone with a different STM32F401 board could give it a try. All my boards are ATSAMD51 or RP2040 boards.
Nice! Thank you for trying it out.
I have an assortment of various spi and i2c flash here. Will check on a Xicor X2402 later but that one might be iffy.
Hooray! My purchase wasn't all for not! I was really thinking about the long game 😉
The driver is currently I2C only. The one it's based on did contain SPI support, but I removed it because I didn't find any SPI based EEPROM breakouts searching adafruit.
x2402 is i2c, but its really old and I never really got them to work with any generic libraries before.
I'll give this a try now
Thanks I love it ❤️
Works great with Feather M0 Express and 24LC32 Breakout board at 7.1.0-beta.2
Let me know if you want any help like typing or testing. Also, it looks like you're using the __getitem__ and __setitem__ from the FRAM library so it should already support slices now 😄
Actually, I think it's slightly bugged and grabbing too large of a slice, let me fix that in the other library, I'll tag you so that change can carry over 
I can also look into the issue you posted there
I just submitted a PR to your repo to fix it, I'll do the same for the other haha
Thank you! definitely feel free to submit PRs for typing if you'd like. I did copy the majority of it from the FRAM library. It turns out the protocol it uses to communicate is very similar.
On a windows desktop machine. I'm getting this on blinka: NotImplementedError: Adafruit-PlatformDetect version 3.18.0 was unable to identify the board and/or microcontroller running the Windows platform.
I'm currently only running libraries like adafruit_framebuf which works entirely within a bytearray() so there's no need to access pins or any other devices.
There is an agnonstic folder in blinka but I'm not sure how to use it. Would I have to go through the platformdetect guide to create a custom windows chip.py, board.py, etc. to create a fake placeholder windows board, or is there an already existing empty board I can reuse?
Thank you! I just learned that boards like the MPC2221 (https://www.adafruit.com/product/4471) exist for adding GPIO to desktop. This means it would be possible to start using the debugger during development instead of relying only on print() for tracing issues
Wouldn't it be cool to drive a tiny OLED display, read a color sensor, or even just flash some LEDs directly from your computer? Sure you can program an Arduino or ...
I'm also having some issues with Blinka but unsure if it's just me and my setup or Blinka itself. Just wanted to see if that's anyone else. I just upgraded to the latest version of Blinka.
Anyone have any idea why i2c.scan() would cause a device to hang?
is the bus locked or waiting on a lock or something similar?
Did an older version of blinka work before? Which version can I try rolling back to?
I'm not sure, I don't use Blinka too often outside of quick testing, sorry :/
Oh ok, no worries
Oh good, glad it's transferrable! Submitted another one to fix the ValueError/slice issue across the two repos, let me know if you run into anything else and I'll be happy to make sure both get the update if applicable 
Okay, dumb question here..
I’m trying to build a new Espressif ESP32-S2 board and I’m getting the following error:
/bin/sh: xtensa-esp32s2-elf-gcc: command not found```
Is there something that changed that would cause this?
@ornate breach you need to run the install.sh script within esp-idf first, which will download a bunch of stuff from the internet and install it in the secret meadows and valleys of your computer .. then, each time you open a terminal to build for espressif you need to . esp-idf/export.sh. Omitting either of those will get you an error like the above..
top two causes I can guess at from here. just because it's a new board shouldn't have much to do with it
ah... so even if I had it on my computer already i would need to do it in the esp-idf folder within circuitpython
yep, that is how I have done it at any rate
odd.. okay, i have to clone down the lib again because macos made copies of things for some reason
what was the new script for pulling in the modules?
so i don't have to download all 20GB again
curious if anyone has any insight into this circup issue or if there's a way to have it give me more verbose error information
So it appears this was already fixed in a newer version of circup, the issue was a bad url but circup 1.0.1 works without issue:
There was a problem downloading the bundle. Please try again in a moment.
12/18/2021 19:18:03 ERROR: 404 Client Error: Not Found for url: https://github.com/adafruit/Adafruit_CircuitPython_Bundle/releases/download/20211217/adafruit-circuitpython-bundle-6.x-mpy-20211217.zip
Traceback (most recent call last):
File "D:\Disasters in the Making\circuitpy\venv\lib\site-packages\circup\__init__.py", line 470, in ensure_latest_bundle
get_bundle(bundle, tag)
File "D:\Disasters in the Making\circuitpy\venv\lib\site-packages\circup\__init__.py", line 685, in get_bundle
r.raise_for_status()
File "D:\Disasters in the Making\circuitpy\venv\lib\site-packages\requests\models.py", line 953, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://github.com/adafruit/Adafruit_CircuitPython_Bundle/releases/download/20211217/adafruit-circuitpython-bundle-6.x-mpy-20211217.zip
@edgy drum yes, recently we stopped publishing the "6.x" bundle. we don't have a way for circup to know which bundle versions are actively published, so for now we have to manually change circup when this happens (which is rarely)... hopefully someday we'll publish a json file or something that will let circup learn automatically about bundle versions. -- https://github.com/adafruit/Adafruit_CircuitPython_Bundle/issues/360
That's a great idea, I did some cursory digging into the bundle repo and the adabot repo but I couldn't seem to find the commit that disabled the 6.x bundle. Do you know where that decision is currently implemented? Feels like that might be the logical place to implement this sort of thing
@edgy drum looks like https://github.com/adafruit/circup/pull/132
PLATFORMS = {"py": "py", "6mpy": "6.x-mpy", "7mpy": "7.x-mpy"}
PLATFORMS = {"py": "py", "7mpy": "7.x-mpy"}```
I mean the commit that stopped the publishing of 6.x to the bundle repo releases
that appears to be the circup patch?
I think I've found it: https://github.com/adafruit/circuitpython-build-tools/commit/7da9c1d7897c5797cdfa232af2ed149946106221
urgh... i'm really tired of macos not cloning down everything in a repo
@edgy drum oh I misunderstood the question, apologies & glad you found the right commit
💪 I commented on your issue, might take a look at this issue next week to see if I can PR this sort of functionality in place without adding any new release steps
I was also able to make it work with the ancient Xicor X2402 256x8 EE with some modification (it uses only a single byte for addressing)
It had a date code of 1989
Does seem to work on most I2C EE devices, so might want to change the constructor to take a size as a keyword argument and not hardcode it in.
I may have found an ESP32-S2 bug with running neopixel animation libraries on an ESP32-S2 on battery.
it might not be battery related though
when running an animation loop of one animation, it gets a memory allocation error:
Traceback (most recent call last):
File "code.py", line 44, in <module>
File "adafruit_led_animation/sequence.py", line 112, in __init__
File "adafruit_led_animation/animation/__init__.py", line 210, in add_cycle_complete_receiver
MemoryError: memory allocation failed, allocating 32768 bytes```
it typically runs few a few seconds, maybe 10-15 before erroring.
# SPDX-FileCopyrightText: 2021 Kattni Rembor for Adafruit Industries
# SPDX-License-Identifier: MIT
"""
This example uses AnimationsSequence to display multiple animations in sequence, at a five second
interval.
For NeoPixel FeatherWing. Update pixel_pin and pixel_num to match your wiring if using
a different form of NeoPixels.
"""
import board
import neopixel
from digitalio import DigitalInOut, Direction
from adafruit_led_animation.animation.blink import Blink
from adafruit_led_animation.animation.comet import Comet
from adafruit_led_animation.animation.chase import Chase
from adafruit_led_animation.sequence import AnimationSequence
from adafruit_led_animation.color import PURPLE, AMBER, JADE
# Update to match the pin connected to your NeoPixels
pixel_pin = board.NP_STRIP
# Update to match the number of NeoPixels you have connected
pixel_num = 60
pixels = neopixel.NeoPixel(pixel_pin, pixel_num, brightness=0.1, auto_write=False)
blink = Blink(pixels, speed=0.5, color=JADE)
comet = Comet(pixels, speed=0.01, color=PURPLE, tail_length=10, bounce=True)
chase = Chase(pixels, speed=0.1, size=3, spacing=6, color=AMBER)
while True:
animations = AnimationSequence(chase, advance_interval=1, auto_clear=True)
animations.animate()```
i guess it's happening because the while loop keeps building the animation object
I think you are right with this. It should create the AnimationSequence before the loop and then inside the loop only call animate()
i was trying to use this to setup where i could cycle through animations on button presses
which is another issue i'm having
QSTR defined buttons always show up as in use.
Ah, I'm not sure about the QSTR button issue. For cycling through animations though you can create multiple Animations or AnimationSequences before the loop and then inside the loop check the button states and call animate() on whichever one makes sense based on what has been pressed.
seems reasonable
I'm not sure what that means.
>>> r_btn = DigitalInOut(board.BUTTON_UP) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: BUTTON_UP in use
what's the full code? Why do you think "QSTR" is relevant to what you're seeing?
Well, I can’t use buttons I’ve defined in the QSTR table
I tried a modified funhouse build since that one is supposed to work
Even if I try to call from microcontroller.pin.GPIO31 it still shows in use
modules/wroom.c: common_hal_never_reset_pin(&pin_GPIO31); a bunch of boards mark this pin as reserved. The associated comment indicates it's used by the SPI flash.
wrover excludes that one
That’s terribly odd because it’s broken out on the module
IO26 is used on a lot of boards though
https://www.espressif.com/sites/default/files/documentation/esp32-s2-wrover_esp32-s2-wrover-i_datasheet_en.pdf block diagram shows the internal connections which you can cross reference to the names shown in section 3.2 Pin Description. SPICS1 connected internally to SPI PSRAM is IO26.
Hey! I am not sure if I am supposed to ask this question here or in the 'circuitpython-help' thread. But since it is more related towards building and extending I chose this one. If I am wrong about that just say so and I post it again in the other channel:
I am currently trying to link a C library while building CircuitPython (The BSEC). While doing so there appear a number of errors about undefined math functions (Basic stuff like fabs). This shouldn't be a issue if I am not mistaken. I tried using (Or rather linking) the BSEC with gcc-arm-none-eabi-10-2020-q4-major outside of CircuitPython with the math library linked (-lm) and it didn't complain. After some digging it seems like CircuitPython uses its own libm version to safe some space. So I guessed that it is probably connected to that.
I tried disabling it by editing the INTERNAL_LIBM = 0. After trying to build a port (Without changing/linking/adding anything, a clean clone from Github where I didn't change anything besides the Value of INTERNAL_LIBM) for the Pico, I got a lot of new errors though - now certain functions like nearbyintf() aren't defined anymore. Other math functions seem to work as intended though, so I guess it is linking some kind of math library. Is this intended? Am I doing something wrong?
This just leaves me at a point where I am quite confused. Is there a way to link the toolchain math library while building CircuitPython?
I'd love any kind of help or maybe a pointer to what I could do next.
Guess I’ll change the pin usage on the next iteration
@unique beacon I doubt anybody is testing/building circuitpython with this flag, so it's no big surprise if it's broken. I see at least one 'obvious' problem that relates to trying to set INTERNAL_LIBM=0...
Ahh, that is what I assumed. It makes sense since I guess it isn't relevant for most people.
but now I'm 3 levels deep and there's still weird problems. It may not be simple to make it work out.
Oh, and thank you very much for the information! 🙂
@unique beacon https://gist.github.com/jepler/423fc40e86d3f297e02e61cae4f0ac97 this at least gets the build to finish but I don't know if it's right
problem 1: ifndef INTERNAL_LIBM is the incorrect check. problem 2: $(LIBS) was not actually used. problem 3: libm depends on some symbols from libc (errno & one other?) 4: something about copysign that I "corrected" by removing a bit about it from PICO_LDFLAGS
the first 3 changes would probably be fine to take into CircuitPython, but not sure about the 'wrap' one.
@ornate breach are you creating your digitalinout objects inside the loop as well?
No
@unique beacon this patch adds the double precision math routines from the pico sdk instead: https://gist.github.com/jepler/dca551994a0a10aa7e793a24f0ea89c3
@onyx hinge Thank you for taking your time to try it out. I'll check both patches out.
@unique beacon you're welcome. I don't have any code to actually test the double precision working so that's up to you. If you do get it working and there's some portion of it we should incorporate to make your project work better, open up a PR once the code is tested!
I'll make sure to do so!
<@&681912791711350805> I'm getting a "crashed hard" error when trying to add a library to my ESP32 board. Anyone up for helping me debug?
"CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler."
@subtle trail I replied in #help-with-circuitpython
Sorry Mark, I had to step away for the evening. Not sure if you're still here, but I can answer your question now.
If anyone else has any ideas, I'm still trying to figure out why i2c.scan() would cause a device to hang. If anyone has experienced this before, would appreciate any guidance 🙂
@blissful pollen To answer your question, I can acquire a lock - I've checked to make sure that happens.
can you connect to the device without the scan?
How do you mean? If I try to do anything with the i2c interface before acquiring the lock, I get an error asking me to get a lock 😉
I guess to take a step back what device are you trying to connect to?
I have two devices using an i2c interface - trying to talk to either of them (one at a time of course). I haven't tried to talk to both in the same script, only ever one at a time.
The first is a TI capacitance sensor, the other is a custom-built sensor
When I try to create an interface for the TI and run a scan, I get back no device addresses - i2c.scan() doesn't hang, but it returns an empty array.
When I try to talk to the custom sensor, the scan hangs.
Honestly, being able to talk to either would be a victory.
Put a different way, where is the code for i2c.scan CPY? Happy to trace through myself, but it's difficult for me to find out where to start looking.
in the core the code starts in shared-bindings/busio/I2C.c
Thanks @blissful pollen. I've seen this before - these appear to be lower level constituent functions for initialization, locking, reading and writing, but not for scanning.
I realize these methods are likely used within i2c.scan(), but I have no idea how and in what order/combination.
Is there somewhere I can find that code?
You're a champ. Thank you @blissful pollen 🙂
Is this a valid strategy to output some debugging info for that method?
for (int addr = 0x08; addr < 0x78; ++addr) {
bool success = common_hal_busio_i2c_probe(self, addr);
if (success) {
mp_obj_list_append(list,
MP_OBJ_NEW_SMALL_INT(addr));
}
else {
mp_printf(print, "probe failed for address :%d\n",
addr)
}
}
?
ie. will I get that msg in the REPL?
I usually use mp_printf(&mp_plat_print, "stuff");
ok, can I pass values in? like addr using standard printf syntax?
yeah you can
Awesome. Cheers 🙂
Ok. So running i2c.scan seems to disconnect the device.
When I dig in, there is an empty while loop within common_hal_busio_i2c_probe that runs forever (ports/nrf/common-hal/busio/I2C.c)
;
}```
Explains why this loops without ever returning.
So NRF_TWIM_EVENT_STOPPED is never getting generated.
Or is being generated incorrectly (e.g. with an incorrect offset)
This change introduces properties to access height, width, as well as tile_height, and tile_width for TileGrid objects. Can be accessed like this:
print("width: {}".format(tile_grid.width))
print("height: {}".format(tile_grid.height))
print("tile_height: {}".format(tile_grid.tile_height))
print("tile_width: {}".format(tile_grid.tile_width))
These values can make it easier to place a TileGrid in some relative position i.e. center it in the center of the display.
This passed pre-commit locally:
circuitpython_adafruit on tilegrid_size_props [$?] via 🐍 v3.8.10
❯ pre-commit run --all-files
Check Yaml...............................................................Passed
Fix End of Files.........................................................Passed
Trim Trailing Whitespace.................................................Passed
Translations.............................................................Passed
Formatting.............................
This also seems to have failed several of the builds in CI. But a local build of one of the same boards suceeded:
circuitpython_adafruit/ports/raspberrypi on tilegrid_size_props [$?] via 🐍 v3.8.10
❯ make BOARD=adafruit_itsybitsy_rp2040
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
mkdir -p build-adafruit_itsybitsy_rp2040/genhdr
GEN build-adafruit_itsybitsy_rp2040/genhdr/moduledefs.h
QSTR updated
text data bss ...
The build failures are due to tomlkit==0.8.0 being incompatible with 0.7.2. I'll look into it further. It'll probably need a cascadetoml release to fix.
The pre-commit failures are "correct", your code isn't properly indented. Let's figure out why your local config is not working. First, what's uncrustify --version print?
@jepler thank you
❯ uncrustify --version
Uncrustify-0.71.0_f
Thank you for notifying us. We'll look into this further and upgrade as we can.
At this point, I'm not seeing this particular security issue directly impacting us. Are you able to reproduce this issue in our repository?
Thank you for notifying us. We'll look into this further and upgrade as we can.
At this point, I'm not seeing this particular security issue directly impacting us. Are you able to reproduce this issue in our repository?
Closing this as a duplicate of: https://github.com/adafruit/circuitpython-org/issues/816
Both issues reference a similar issue.
After further review, there is no impact to this repository.
@onyx hinge audiomp3 q you might want to see: https://forums.adafruit.com/viewtopic.php?f=60&t=186385
thanks, answered.
@tulip sleet hum I don't see an actions workflow to make a release from cascadetoml....?
good point, the one on pypi is very old
do you think scott manually runs commands to do it? that's not ideal.
i agree
https://pypi.org/project/cascadetoml/ 0.3.1 was the prior release
I hope scott is in today
btw re python versions, I am wondering if we should specify "3" instead of "3.whatever". Btw, should also be in quotes, because otherwise 3.10 == 3.1
yes; I think he is off until tomw
I have upgraded to 3.10 on a couple of things without issue
bundle and asyncio
nice! I picked 3.9 since it matches what's on my debian bullseye machines, which means it's not crazy new (but probably not on ubuntu lts yet)
OK I popped in a couple of issues about releasing cascadetoml. in the meantime, do we need to do something to get circuitpython building again? we could put 'tomlkit==0.7.2 cascadetoml==0.3.1' in our requirements_dev.txt, for example.
or do we want to potentially just not be able to build all day until cascadetoml can get released
one of my personal projects has a matrix that covers each 3.x from 3.6 to 3.10 but I'm not sure doing that actually has any big advantage. well, it keeps me from introducing incompatibilities with old versions though I'm unsure why I care.
can we just manually release cascadetoml, or add a release.yml now?
I made a cascadetoml release in the github sense
i have the credentials for a pypi release
i think
oh, I see, it's only owned by scott
only "tannewt" is maintainer for cascadetoml. Looks like "adafruit-travis" would need to be added.
tomlkit==0.8.0 introduced an incompatiblity with cascadetoml=0.3.1. cascadetoml has been fixed, but right now there's a speed bump preventing us from performing a pypi release of 0.3.2. Instead, pin both tomlkit and cascadetoml at a version that works as needed. Once cascadetoml is release to pypi, this should be reverted.
then we'll need to merge that up into main, there's one other pending change as well it looks like
oh that was a backport so it doesn't make a difference
GitHub makes it really easy to do the merge up into main. I will click on that as soon as the pinning PR can be merged.
yup, appreciate it!
@slender iron I see you as Idle, will you be around today? See above
@tulip sleet ya, I'll be around after I feed cats and myself until 3pm when I have a dentist appt and errands
ok, I added adafruit-travis as an owner
@lone axle so if you are local to your git repo and you pre-commit run --files path/to/one/of/those/files.c it doesn't complain?
I have always done pre-commit run -a so far. I will check that way pointing at the files
calling it with the --files flag does fail for the formatting (and make the required changes on disk). Experimenting a bit I rolled back the changes to try again. There is definitely difference for me with --all-files vs. --files [path]:
circuitpython_adafruit on tilegrid_size_props [$!?] via 🐍 v3.8.10
❯ pre-commit run --all-files
Check Yaml...............................................................Passed
Fix End of Files.........................................................Passed
Trim Trailing Whitespace.................................................Passed
Translations.............................................................Passed
Formatting...............................................................Passed
circuitpython_adafruit on tilegrid_size_props [$?] via 🐍 v3.8.10 took 2s
❯ pre-commit run --files shared-bindings/displayio/TileGrid.c
Check Yaml...........................................(no files to check)Skipped
Fix End of Files.........................................................Passed
Trim Trailing Whitespace.................................................Passed
Translations.............................................................Passed
Formatting...............................................................Failed
- hook id: formatting
- files were modified by this hook
I wonder if something else locally could be causing --all-files not to be able to find everything?
This answer posted by the author of pre-commit suggests it may be smart enough to "only sending the changed files to the underlying tools". Maybe it's not finding it in this case because I made the commit with these actual changes a while ago so technically right now there are no changes in my local copy (or no uncommitted changes at least). https://stackoverflow.com/a/64772737/507810. I committed it previously without running pre-commit just to get it saved somewhere while I went to a different branch to test something unrelated.
Though the --help text makes no reference to only targeting changed files with the --all-files flag:
--all-files, -a Run on all the files in the repo.
that's interesting/weird!
I didn't suggest --files because I thought it would be different, but because I thought it would be quicker!
@lone axle some time ago you made a lib for storing structured data in nvm .. does it work with deep sleep memory? would it work with i2c fram/eeprom? [prompted by looking at your in the weeds topic just now]
Now its failing in the CI due to changes in tests/extmod/utimeq1.py and tools/pydfu.py but these files were not actually touched as part of the functionality in my PR. I noticed that the formatter modified them when I did originally run pre-commit run -a when I made the PR (at the same time that it didn't fail for the files that I did actually change). It seems like it didn't format them in a way that CI likes. I will try to revert those.
The library as it is now is hardcoded to nvm. But it could be made more general and as far as I know could work with anything that expects to store data into a bytearray-like structure. So anything that you write to like thing[0:3] = [0,3,2] could theoretically be supported.
it is essentially using the first few bytes to store a length of the total data and then after those first few bytes writing the results of msgpack.pack() on the input object.
Afternoon everyone 🙂
not that I know of. happy to review and merge improvements though
thanks, I will give it a try
How is the nrfx library integrated into CPY? Is it just dropped into the project, or has it been heavily edited to adapt it for CPY's use?
I think it's essentially as-is.
If we want to do something differently, we just won't use it.
Ok, so if I wanted to use the newest version, I could just clone it, copy over the files, and go?
Missing meeting today. Have a great week!
you too @solar whale
<@&356864093652516868> Hello! We'll be holding the weekly meeting starting in just a few minutes. Today's notes document is: https://docs.google.com/document/d/1L-I0fOE6yrnv7OV_jQZZiFGtgWmc86GiGP6_ecpnGQs/edit# -- if you will speak, or have notes to read, please drop them in there. otherwise, if you're just listening, we're happy to have you.
CircuitPython Weekly for December 20th, 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 particip...
@daring pumice you'll need to update the submodule
We fixed a few minor bugs, but the nRF version has been updated several times since and we haven't updated. We also added an important feature that makes a certain operation idempotent.
Thought I would pass along my experience in case it provides a clue.. I have a Magtag running
Adafruit CircuitPython 7.0.0 on 2021-09-20; Adafruit MagTag with ESP32S2
Board ID:adafruit_magtag_2.9_grayscale
It was running the Weather code from the Adafruit examples fine for a few weeks. And then one day it started with the Unknown Failure 205 error. During the course of testing, I deleted everything and reloaded all the libraries and code. Still have the problem.
I have tried bo...
The folks from Adafruit join us to talk about their latest RP2040 board, the KB2040, which is specially-designed to help you build your own custom keyboard, powered by Raspberry Pi's SoC and CircuitPython.
This phase in the development of the Retro RPN calculator tests the touch screen interface. The display shows the index of the button pressed and the button hold time (in seconds). Now that the CalculatorCase and CalculatorButtons classes are operational, it's time to start working on the numeric calculation portion of the emulator. Coded in Cir...
It is
It's not Christmas until your tree is topped with a glowing Rhombicosidodecahedron! It started as Raspberry Pi Pico project with 5 LEDs but I got carried away and also ended up with an ESP32 a strong of 300 RGB LEDS.
See my project write up here: https://russelleveleigh.medium.com/its-not-christmas-until-your-tree-is-topped-with-a-glowing-rhomb...
Lego base plates for STEMMA boards! #3DPrinted holders feature built-in standoffs for press fitting the PCBs. STEMMA boards plug-and-play with various devices and accessories, without any soldering! https://t.co/DaudvrSvLs #adafruit #3dprinting https://t.co/Y6eTZWZ1dC https://t.co/J2ym9Qdu3z
Lego base plates for STEMMA boards! These 3d printed holders feature built-in standoffs for press fitting the PCBs. STEMMA board and sensors allow you to plug-and-play together various devices and accessories, without any soldering!
https://learn.adafruit.com/stemma-lego-base-plates
LIVE CHAT IS HERE!...
Next week: Guest Editor Emeritus Phil Torrone
@idle owl would you mind requesting a circuitpython2022 graphic from bruce? Here is the one we used last year: https://blog.adafruit.com/2021/02/16/circuitpython2021-round-up/
Absolutely!
thank you!
Thank you!!
sorry forgot to add its some enhancements to the IS31 work
I';m going to wear my LED glasses to a New Year's gathering
Those LED glasses are amazing, a picture of me made a news article while wearing them
That's a great idea @turbid radish
Let's wait so Foamyguy can be involved.
I appreciate the info! I think I've tracked down the source of a hang on my device when doing busio.i2c.scan(), and am looking at ways to solve it. Was thinking that updating the nrfx code might be a good place to start, but unsure if this will break CPY.
Only one way to find out, right?
We would need to merge nrfx's upstream into our repo to update nrfx. But let me know the details after you'd tried it.
This is the current library for 24LC32 is here: https://github.com/FoamyGuy/Adafruit_CircuitPython_24LC32
@idle owl I don't think I have the permission needed to transfer directly to adafruit. When I look at create a new repo page I see it listed with (insufficient permission).
I did find the transfer button though and it looks like it can attempt the transfer and then get approved on the receiving side. Let me know if I should do that, or if you think it's easier to transfer to your account first?
If it'll let you send and we have to approve, that's easier than transferring to me. It would be the same number of steps to have one of us approve it on our end, so we can try that.
Will do 🙂 Seems like updating this submodule is (a bit) drastic. Trying to exhaust other options first, and see if the problem is elsewhere.
Okay, I filled in the confirmation thing and clicked the transfer button. It did indicate afterward this permission warning. Hopefully the approval request got sent over automatically though.
I'm not seeing anything yet. 😕
Drat. It seems like I do currently have permission to transfer it to circuitpython org. Perhaps that org then would have permission to transfer to adafruit?
I might frame this tweet 😅
Nah, transfer to me. I'll handle it.
Alright, just initiated transfer to you and it does report a more successful type of message after I clicked.
Nice. It even brings over open issues.
Yep!
Do you need me to do a release?
I will PR references to FRAM to change them this week. Probably best to get that done before release / add to bundle. Thank you!
Yeah for sure, PR it. I would say get it where you want it before release/bundling it.
Thank you! Let's follow up in a separate PR with rgbmatrix on C3 and S3 once they have been tested.
Yup, this should just be a flag we need to enable.
I don't know why the CI rebuilt so many things for a one-board change.
I think it did because the original commit was on an adafruit branch (and we do full builds on them.)
These failures are unrelated so I'm going to merge.
@tannewt yeah, getting the tagged 0.3.2 onto pypi would mean this wasn't necessary.
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/1NBK5WWMLkzOm3BYvKe3zdyLp1Z5S5DQfyDGdEudic5w/edit?usp=sharing
CircuitPython Weekly for December 27, 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 participa...
Is this a good place to object to the behavior of setting the white channel when R==G==B?
This is a good place to discuss it.
- There are at least three different color temperatures of RGBW NeoPixels, and in none of them will R+G+B white accurately correspond to W white in either tint or brightness.
Ya, I get that. This was done as a "just works" option.
- Altering the numbers in results in the getter returning a value different than was passed to the setter, and this is c...
A bit confused: Trying to grab a member of a busio_i2c_obj_t pointer (*self) which has been passed as a param:
self->scl_pin gives me error: 'busio_i2c_obj_t' has no member named 'scl_pin' - but it does.
Am I just doing the pointer notation incorrectly here?
1 moment - may be wrong name because of board
sry
appears so - sorry for the bother
@slender iron If you have time, can you let me know how you have your cm4io board configured. I have mine now an it works fine with a "pristine" SDcard. It boots and I get a CIRCUITPY drive, but the access to the drive only lasts until I power cycle then It no longer mounts and os.listdir() is empty. Did you do any special configuration or do you have any jumpers installed? I'm hoping to get it booting from the USB drive. This is absolutely not a crisis an I thought you were out this week so it can certainly wait until the New Year. But if you have any quick pointers, that would be great.
@slender iron Not that you're using a Mac anymore, but iShowU doesn't work on Big Sur. They recommend some other app, but I remembered BlackHole which didn't work last time I tried it. I installed it during the meeting and it worked on the first try - iShowU didn't even do that half the time. Anyway, FYI if you upgraded your Mac and you end up using it for the meeting at some point.
@solar whale I'm around until thursday ish. I don't think I have anything special setup. I am doing network boot
OK -- thanks -- how did you configure it for network boot?
thanks @idle owl. I haven't been using it regularly
I have a modified version of fb_tftp that hosts the files for me
Has anyone tried to use nrfx_twi_bus_recover? Getting a linker error despite it being in the nrfx submodule, unsure how to resolve this.
Thanks -- I'll review that!
I think that will also help me get it to boot from USB -- I'll try that tomorrow.
👍
We only compiled files from nrfx that we needed. In nrfx/Makefile, you can add nrf_twi_twim.c to SRC_NRFX, on line 148.
You just beat me to the punch! 😉 Thanks @tulip sleet
Am I alright to remove some modules from the build by editing the board-specific mpconfigport.mk file? I'm out of flash space, but there are a bunch of modules I don't need that are getting included.
damien has been making micropython smaller for so long, he's deleted hundreds of thousands more lines than he's added. 🤣
Yes, certainly, we do this all the time to squeeze builds to fit.
🙂 Thanks!
This looks good, thanks. Didn't actually test it. The cascadetoml build failures will need to be fixed by other means.
Wondering how to properly print the value of an mp_obt_t and busio_i2c_obj_t using printf (wrapped in mp_printf)?
e.g. if self is a busio_i2c_obj_t ->
NRF_TWIM_Type *reg = self->twim_peripheral->twim.p_twim;
if (reg == NULL)
mp_printf(&mp_plat_print, "reg is NULL\n");
else
mp_printf(&mp_plat_print, "reg is %s\n", reg);
You just want to print one of the members of the busio_i2c_obj_t? Like:
mp_printf(&mp_plat_print, "Value is %d\n", self->somevalue);
Trying to see if self-twim_peripheral->twim.p_twim actually has any value - right now it looks empty, but may be because I'm trying to parse it as a string, rather than as the appropriate type.
The base definition I can find is for NRF_TWIM_Type - not joy, there. Not really helpful, but knowing what it contains might help me find out what's wrong.
I think it's supposed to be "3.x", after looking at actions/setup-python. Also we can upgrade to actions/setup-python@v2. I did that in several libraries already and it was fine.
Catching up today on the meeting, Group Hug to @lone axle and dglaude for work on the EEPROM library!
Sorry for leading us astray earlier with the plain "3". It guess it might work too, but "3.x" seems more typical.
Also I hear word of repository patching for Python version fixing 👀 happy to help with the patch clean up whenever that is!
Good points. Maybe user’s issue is best fixed over in FancyLED by providing some alternative to pack() that instead provides an integer 3-tuple. In the meantime, I’ll suggest they just keep doing what they’re doing. I mean it’s not wrong, just peculiar, and the first time I’ve seen it come up.
is there any way to prevent the REPL window from closing after device disconnect? Hard to see what's going wrong.
in the Mu editor*
Is this the repo I should PR changes to? I've made some mods to my local copy and it basically should function with anything from 24C00 up to a 24C256 now.
(And actually the larger ones too but you need multiple instances)
It is closing so you cannot see it? Mine stays open. I've also used PuTTY before
Indeed - closes with a dialog saying "Can't find a valid device...."
Which version are you on? I think mine may be old
1.1.0.beta.6
right now, windows
I'm not sure why the latest Mu closes but you could try using PuTTY, its great and just have to find the close on exit/disconnect option and make sure it is off
I have putty 🙂 just use a serial connection?
I like tio, because it will reconnect after unplug/replug automatically
Yup I just use the serial connection and put in the COM port I have.
HI I follow the instruction add the board in the Circuitpython, and I has generate the firmware.uf2, but when it draw it to the board, my board doesn't have any reaction, can someone help thanks
Let’s jump over to #help-with-circuitpython I’ll “@“ you there.
Hi I want to add the new board in the Circuitpython, could anyone help thank, I has success build the uf2 file and work on my board.
Here is a guide on how to do that: https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython
the cascadetoml release didn't happen yesterday so let's just go ahead and take this for now...
yep, this is the main repo now: https://github.com/adafruit/Adafruit_CircuitPython_24LC32 PRs can go to there. Thank you!
Only when I created
- #5754
did CI run the windows build, which didn't use the requirements file to install the python dependencies, get run. It fails too, due to the cascadetoml/tomlkit incompatibility. Pin it here, too.
I'd rather see us keep uctypes in sync with micropython. It could be helpful for you to pursue with them (e.g., on their forum) how to attain your goals while using uctypes as it is.
Thanks! I'll keep you posted. This one might actually work on most of them because it's a simpler file which means less deviation to deal with. But I'm almost never right when I say that. 😄
@tulip sleet I thought that it was going to be 3, not 3.x. Did you find out it needed to have the .x after the fact?
In your cookiecutter PR.
3.x seems to be "more" correct. The examples that were given in the gihub action repo were 3.x
it might work with 3
but 3.x is better
I think we should try this on one library repo and do a release and check
Ok.
that all the steps work
I'll run LED Animations through it.
or if there is another library that needs a release anyway
Well we have to do all the updates.
Cookiecutter doesn't update the libs.
So once I do all the updates, it'll need a release anyway.
good point, I was being parsimonious
All the libs will eventually need this. 🙂
Once I get my mmpmhing IDE updated to work on this machine.
New laptop, who dis.
Wow that's fast now.
i thought it would transfer all your stuff automatically if you wanted.
It does. But I went from an Intel machine to an M1.
So I have to get all the native apps downloaded. Finding them as I go.
@tulip sleet 3.10.1 used. 🎉
I looked in the release and pypi gz and zip files, looks fine
okee dokee!
Thanks for the update! I'll let Eva know.
thanks for good test ideas
@tidal kiln Are you up for a schematic dive with me? I'm pretty sure it's entirely shallow end, but I've not seen this before on a board and wonder how to describe it for pinouts.
@idle owl sure
Do you want pngs or board files?
which board?
QT Py ESP32-S2
rev A?
B
lemme fetch
It has these two pads on the back labeled BAT and GND. And I traced them to the bit on the schematic labeled 3.3V LDO. And I looked up what an LDO is, so I know that it's providing the indicated voltage.... so are those pads simply a way to get 3.3V out of the board? I feel like it's something more than that.
LDO = low drop out
yep
Right ok, so wait....
is it for connecting a battery?
Because I'm looking at the schematic and that arrow is going the opposite way it should if it's providing voltage... right?
Yeah.
And come out 3.3V.
yep
pretty sure. the M0 qt has some similar pads.
And the 3.3V pin is for getting 3.3V out?
yes
Not putting it in?
ok
OK, thanks Carter. I was pretty sure, but wanted to make sure I understood it
i think worth pinging limor to be sure. but my guess is those pads are general purpose. you'd just solder wires direct. but they may also be a footprint for something specific? like a JST?
but in eagle, they are just generic 1x3mm test points
Right. Yeah. I will do that. But it's always better to go to her with an answer and be told you're wrong, than to go to her with an open question that she has to put in all the work for. 🙂
yep
The way it's presented as 2 pads, not one part, makes me think it's for soldering to
here's how the battery input looks on the CPX for example
and here I assumed nothing on the qtpy was ever chonky
Ah yeah.
no BAT, just 5V
Right.
in one of the livestreams... (maybe it was even last night), ladyada breezily showed the pads on the reverse and said it was for adding a battery, a nice little extra on a tiny board
Thank you for the confirmation!
Saves me a step of bothering her. 😄
CircuitPython version
Adafruit CircuitPython 7.1.0-beta.1-27-g013e688c9-dirty on 2021-12-01; lis_43271a_onyx with samd51j19
Code/REPL
WATCHDOG_ENABLED = True
...
from watchdog import WatchDogMode
from microcontroller import watchdog
...
if WATCHDOG_ENABLED:
watchdog.timeout = 16
watchdog.mode = WatchDogMode.RESET
...
while True:
if WATCHDOG_ENABLED:
watchdog.feed()
...
Behavior
This is a preliminary report ...
@idle owl https://youtu.be/dcAxSV3hbcg?t=4109
Here's what might be a dumb question - is the 4MB of flash built into the module?
I don't see a flash chip. or I'm missing it.
Yep, it's a dumb question. Yes it's built in.
yeah, presumably the S2FN4R2 with 4MB flash and 2MB PSRAM under the plastic (I think the Great Search a week or two ago was for that one) https://youtu.be/rMUil5q4i_8
(plus the 320k of regular RAM)
Ugh. Discord stopped working. But it seems to be an issue with the canary build, which is the only build that runs natively on M1, so I guess I'm dealing with super slow Discord for a while.
Hmm they have a middle ground with a public test build. Which is native, and working.
Fingers crossed it continues.
Thanks, anecdata. Sorry for delayed reply, Discord decided it was done.
@slender iron I requested the CP2022 graphic from Bruce, I put a due date on it of 31 December - I can make it sooner if needed. Let me know.
@slender iron Scratch that, it's already done! I'll get them to you. Ping me when you're around.
the feather m4 supposedly supports rs485 hardware wise, not sure about the rp2040. circuitpython has a couple lines of code in the busio library that are rs485 specific but I haven't seen anyone get circuitpython to do rs485. does anyone have experience with rs485 protocol in circuitpython?
The RS485 stuff was added here, but I think it's only really for i.MX https://github.com/adafruit/circuitpython/pull/2629
@idle owl I see it in my basecamp overview email. Thanks!
I can send you a zip if you want. I already made it.
sure 🙂
thanks!
I really like them this year
now I can draft the kick-off post
That's what I figured
ya, very cool
! https://www.adafruit.com/product/5325 is in stock for those who like their wifi smol
What has your favorite Espressif WiFi microcontroller, comes with our favorite connector - the STEMMA QT, a chainable I2C port, and has lots of Flash and RAM memory for your next IoT ...
😮
is there some method to uninstall and reinstall circup to work around the fact that 6.x is breaking updates even if not trying to use 6.x libs? getting the "There was a problem downloading the bundle. Please try again in a moment." problem for about a week now.
@eternal lantern assuming you originally installed circup with pip, you can upgrade it with pip install --upgrade circup. It should end with a line like Successfully installed circup-1.0.1.
@onyx hinge. AWESOME SAUCE, that's the magic I needed thanks.
Sorry I didn't do this yesterday. I did too good of a job of ignoring email. I've released 0.3.3. (Using flit publish locally.)
Reverts adafruit/circuitpython#5750
I've been working on this for a couple days with a RPIZero2W and so far haven't corrupted the SD card, however with both a clean build from the main github source and from the debug build from Scott's artifact page the flash is never mounted or accessible.
Strangely, if I download the prebuilt image from circuitpython.org, the flash mounts 90% of the time without a problem.
anyway, in case it's of any help, here's the output from the debug image:
sending cmd slot=0 op=52 arg=80000c08...
So I found a file that could use some updates to the type hints, and wanted to ask: So the "font" parameter says it should be any class that has get_bounding_box() and get_glyph() methods, which from my understanding is a good case for using Protocol (duck typing). But realistically I think it's only like a few class classes so Union[fontio.BuiltInFont, adafruit_bitmap_font.BDF, adafruit_bitmap_font.PCF] is also valid. Is there a preferred method, being explicit vs. duck typing?
@proven garnet that's a very valid question. Using that Union[] for now sounds like a good approach even if it's not fully correct.
I think Union makes sense, because otherwise there are extra definitions of codeless classes, etc., that will just take up space.
we could put the font interface in the fontio pyi file, I think
needs some docstrings, but I think this would work. then a later revision of typing of the modules like label could use fontio.FontInterface [name is up for discussion!]
Got it, I'll use the Union. Trying to get some last minute PRs out before the holidays!
I think an Interface would be great! Would definitely be helpful for typing 🙂
I assume fontio.BuiltinFont would be a subclass then? Unless that interface already exists and just isn't public facing
I don't do much on the display side of things, some day I will haha
ah maybe I want a Protocol https://mypy.readthedocs.io/en/stable/protocols.html#simple-user-defined-protocols
Just learned about them!
If I understand it, FontProtocol just needs to be seen by mypy, and nothing needs to derive from it
Resourceis a subtype of theSupportsCloseprotocol since it defines a compatible close method. Regular file objects returned byopen()are similarly compatible with the protocol, as they supportclose().
Yeah, my understanding is the methods need to be put in the Protocol, and it saves you having to use inheritance
I don't know how difference the font classes are all from each other and whether inheritance makes sense or not
This looks great! And it's a subclass of typing.Protocol?
nope, missed that 😅
Thanks @onyx hinge, this is awesome, should I add an issue to this library to eventually swap typing over the new protocol?
let's see what happens with this PR first, I'll file it in circuitpython soon
I'll @ you on it (same name on github right?)
Yup! Please do so I don't lose it!
The post-holiday notification checking is the worst, so it'll help haha 
oh, drat. import _typing is widely used in the libs already 😦
I wanted to rename it, because I don't think the name _typing is a good one to squat on
@tekktrik noticed that there was no convenient way to specify that a function takes "any kind of Font", including the built in one and the ones from the adafruit_bitmap_font package. By defining this protocol in our stubs, it's hoped that fontio.FontProtocol can be used instead of an ad-hoc Union[] of several known font types.

oh maybe I'm mistaken about that ... it is some other _typing. and not actually a bundle file, but in a virtualenv I have left over for some reason. good news? ```libraries/drivers/ili9341/_env/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/_compat.py
8:from ._typing import TYPE_CHECKING
yeah yay it's okay 😹
Installing stubs for a module named _typing seems like it may create problems in the future, but this name should be much safer.
For interest, ReadableBuffer and the like were inspired by the discussion in https://github.com/python/typing/issues/593. They are also defined in https://github.com/python/typeshed/tree/master/stdlib/_typeshed.
I had not been erasing my SD cards when trying new images and it occurred to me that the problem I'm having is on the part of the card not occupied by the image, so I did a full erase (overwrite) of the SD card and reloaded Scott's debug image. This time the Flash file system was created and seemed to work on the first load, but after power cycling it failed once again. I guess this is exactly what the original issue reported.
I had not been erasing my SD cards when trying new images and it occurred to me that the problem I'm having is on the part of the card not occupied by the image, so I did a full erase (overwrite) of the SD card and reloaded Scott's debug image. This time the Flash file system was created and seemed to work on the first load, but after power cycling it failed once again. I guess this is exactly what the original issue reported.
Yup -- same here.
@lone axle @idle owl Is this issue still open for the taking? https://github.com/adafruit/Adafruit_CircuitPython_framebuf/issues/43
I've been working on the framebuf library to add a new format for my display so I'm already somewhat familiar with the code. I'm done with that so I can take on this annotation task if it's still available.
Yes, still open for the taking. That would be great if you'd like to work on it and submit a PR.
I think this should revert the windows changes as well. I missed that with my revert.
@RetiredWizard Interesting that it recovered from an early command timeout. What brand and size of card are you using?
Are there any builds that work better for folks? I feel like this might be a regression.
Thanks for the PR! I've added a commit to fix the formatting so make sure and pull it locally before modifying anything else locally.
I'm still using zero2w-en_GB-20211208-8eee16c.kernel8.img because the SD Card works. I use the serial console rather than USB.
I haven't seen this before. ticks_ms does locking by disabling interrupts that may have something to do with this. It shouldn't block a watchdog timeout though.
Thank you @rsbohn! That seems to imply it's a SD card and USB interaction problem.
@slender iron Thank you so much for catching that Servokit issue.... I would have headed immediately into updating code.
Makes sense.
it looks like arduino code to me 🙂
Bonus! Not my problem 😄
@tannewt I've been using two SanDisk cards, a 1G and a 16G. I haven't noticed any difference based on which card I use.
7.1.0-beta.3 from circuitpython.org actually has been working pretty reliably on my zero2w. Unfortunately, I need to change some compile parameters so I can't use that image.
With the image I built from github I get the following results over UART on the initial boot. On subsequent power cycles the flash file system isn't accessible.
Adafruit CircuitPython 7.1.0-beta.3-166-gb60a80696 on 2021-12-20; Raspberry Pi Zero 2W with bcm2837
Board ID:raspberrypi_zero2w
write sectors result 3
write sectors result 3
Auto-reload` is on. Simply save files over USB to run them or enter REPL ...
I think this should revert the windows changes as well. I missed that with my revert.
The windows change was never merged into main. I closed the PR: #5756 before it was merged, so I think it's OK. I don't see any change in main: did I miss something?
- Fixes #5343.
alarm.wake_alarm was not being set properly after a real or fake deep sleep. I moved the responsibility for keeping track of whether the board had just hard-restarted to main.c, instead of having it in common-hal. The most recent wake alarm is now recorded in alarm.wake_alarm either after a hard-reset, or after a simulated (fake) deep sleep.
Light sleep was not setting alarm.wake_alarm. I did this in a port-independent way.
Also did a minor doc fix in alarm...
This is still not resolved as of 7.1.0-beta.3
We fixed an exception problem in 7.1.0-beta.3. Did you upgrade? Maye that fixed it.
If I run 7.1.0-beta.3-174-gbea052695 on 2021-12-22 on the pi zero 2W with USB I get read sectors result 3 and it tends to hang.
If I run the same but use the serial console the I still get the SD card errors but I can use the repl.
With the older 12-08 build USB doesn't work, but I can access the repl via serial (uart) and I can read and write the SD card.
No SD card means I have to type in anything I want to run, which is very retro indeed.
These should probably be named LED_* because they are channels of a single LED and to be consistent with the rp2040 xiao: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/boards/seeeduino_xiao_rp2040/pins.c#L39
Good news everyone. I just tested changes on the bootloader side to make a build that includes the 7.2 Softdevice and there is no need to do anything special to load Circuitpython. Drag/drop of the CP UF2 as per other boards works perfectly fine.
I'll close this issue once all the bootloader changes are merged in and tested with merged binaries.
So this obviously isn't the solution, I'm sure it breaks all sorts of things, but hopefully it will help ferret out the issue.
I commented out the reset_all_pins(); statement on line 109 of ports/broadcom/supervisor/port.c and my build is now working with the flash.
if ticks_ms were to stall with interrupts disabled, would ctrl-c still work?
anyway, I have replaced ticks_ms with a monotonic_ns-based equivalent. No stalls so far, but it's still early to say...
that's odd, ticks_ms and monotonic_ns both use port_get_raw_ticks though ticks_ms passes NULL for subticks that doesn't change anything about locking on atmel-samd (the subticks-is-NULL case just skips over a little bit of arithmetic)
https://madewith.mu/mu/users/2021/12/22/beta7.html <== for lovers of beta software!
CircuitPython version
NA
Code/REPL
NA
Behavior
NA
Description
I get a 404 if I click the Edit On Github links in the Documentation. This may be a readthedocs issue, or a configuration issue in the doc generation.
Reproducing this:
- Open a document in CircuitPython readthedocs - ie https://circuitpython.readthedocs.io/en/latest/shared-bindings/rp2pio/#rp2pio.StateMachine.readinto.
- Click the "Edit on GitHub" button.
Result:
-...
And also a typo/grammar thing.
Note that currently, the doc shows the "Read into..." line incorrectly formatted - and looks likes the line tails off at the phrase "The buffer...". This should make the RST format correctly (matching the format of other doc sections that don't have the same render glitch).
https://github.com/python/cpython/pull/27342 looks like the docs don't build with 3.10! why didn't we notice it in the PR that changed the python versions to 3.x?
we're still building the core with Collecting Sphinx<4 for some reason
I agree, this needs to revert f527ef0.
This also bumps sphinx to current versions so that it should work with 3.10
@RetiredWizard that's a huge clue and I should have thought about that. We have way to mark pins never_reset and we must be resetting something we shouldn't.
I agree, this needs to revert f527ef0.
That commit is only in 7.1.x? Could you submit a 7.1.x revert PR? Thanks.
Reverts adafruit/circuitpython#5755
@tulip sleet did you know you can make revert PRs from github?
I made #5765 through the github UI.
if ticks_ms were to stall with interrupts disabled, would ctrl-c still work?
No, it wouldn't because the incoming serial is checked for ctrl-c in an interrupt.
If you can catch it stalled, then you can use GDB to see where it is (and hopefully figure out why.)
@jepler Does this need the sphinx bump too?
anybody got an RP2040 and an MPU6050 breakout that could test that combo works? see #help-with-circuitpython for context
Yeah, I did, I think that's how I made it. Also the 7.1.x -> main merge PR's I am doing that way.
i have an MPU6050 and will try it
thanks @tulip sleet
I will be afk for <1 hour, will try when I return
it's a pink feather rp2040 btw
This allows for UART TX via PIO
seems okay, I was initially confused at sideset_enable being in the middle of a parameter list sometimes and at the end other times but that is because there are two related functions...
yeah, seeing this is what prompted me to tack it onto #5760
I think it would be good to consider that this current behavior (though surprising!) is probably shared with e.g., i2c readinto.
@slender iron I'm trying to set up the tftp server for my cm4io - followed the link you gave me a few -- I copied everything from the /boot of my SDCard image made by Raspberry pi imager to my tftp server folder -- and configured the cm4io for netwrok boot, It seems to be trying, but it it is not getting anything from the server... Did copy anything else to the tftp server? Anything else I need to do?
the folder should mirror the sdcard afaik
I've got a bit weird setup because I hacked my tftp version to look in two folders
hmmm -- ok - thanks -- so far, I cannot get it to boot from USB or network -- only SDCard -- I'll keep trying...
yes -- sounds promising...
I'm going to look into that after lunch
ah -- it helps to enable the network on the server!!! It boots!
so -- now that it boots, where is the file system on the CM4io? How do you get to CIRCUITPY?
@slender iron just spotted the request to test sideset opt - do I want the 7.1.0-beta 3, or the latest S3 build?
What does it mean if I get back a whack of i2c addresses from i2c.scan()?
I think you are getting too many?
I'm assuming you don't have a whack of i2c devices hooked up?
I have two. When I pass the sda and scl for the first to scan, I get one valid address. When I pass the sda and scl of the other, I get back every address.
you have two different buses, right? The scanning is sending an address and waiting for an acknowledgment, which is a specific kind of response. I think the device on that bus may be acting up in some way.
is that the device with no pullups on board?
Yes, using internal pullups
did you get some resistors and a breadboard to test it with external pullups?
I'm only using one bus, and only one device at a time (I'm passing in one set of pins only to the code).
Not yet.
i would vet it with that.
The issue is in common_hal_busio_i2c_probe
@slender iron When you have a minute can you please confirm the configurations of your cm4io for me. On the cm4io. I am booting from the network. If I have no SDCard inserted, then I get no file system (os.listdir()) is empty and I see nothing mount on my host computer. I guess taht maes sense since the cm4-lite (no eMMC) has no place to put the FS. If I insert an SDCard made by Raspberry pi Imager (with the same image as on the network boot) it boots (and I think it is booting from the network) and I see my CIRCUITPY Drive and os.listdir() shows my files. But if I put in a blank SDCard, then I still get no file system. I'm just cuirious how you have it set up. Do you have an SD Card inserted and if so , wha it is on it and do you get a CIRCUITPY Drive?
When nrf_twim_task_trigger(reg, NRF_TWIM_TASK_STOP); is run, the code then sits in a while loop waiting for a NRF_TWIM_EVENT_STOPPED event. This never fires, and the device eventually hangs.
However
When I check for an error inside that loop using (nrf_twim_event_check(reg, NRF_TWIM_EVENT_ERROR)), an INTERNAL_ERROR event is found.
I can then recover the bus using nrfx_twi_bus_recover
This succeeds, and I get a single valid address: 0x08
the sensor is acting up, I think. It would be good to test this in two other ways: 1. with external pullups. 2. on a non-NRF board, such as SAMD51
I should mention the aforementioned while loop properly exits after recovery, and the probe proceeds normally.
Gotcha. I should have a feathersense arriving tomorrow.
I'll wire something up over the holidays and see what happens 🙂
We have not seen this behavior before. A few devices do not respond well to that kind of probing, but it's rare.
Interesting.
The Feather Sense is still nRF. I would suggest ordering a Feather M4 or Metro M4 too. And did you get breaboard and jumpers, etc.?
Those have been ordered, and am expecting delivery before the new year.
excellent. Is the acting-up device proprietary, or can you say?
The one returning 0x08 is proprietary - I'm wondering if it's all working correctly, now.
The one returning all addresses is 3rd party.
i would websearch the all address one to see if there are any other reports of issues with it
Great idea 🙂 Thanks!
@dusky halo you can snag a build from the PR if it's done or I can give you one
@solar whale CP expects the sd card to have a partition table already
Ah… ok .. that makes sense. I’ll try that.
This bit of code picks the partition: https://github.com/adafruit/circuitpython/blob/main/ports/broadcom/supervisor/internal_flash.c#L42
and then CP fakes the partition table to USB like it normally does
Step by step….
🙂
I've tested that. It works in terms of I get the bytecode I expect. Now just trying it out with an oscilloscope - but I expect remaining issues to be my own.
👍
Thank you so much for fixing this!
CircuitPython version
Adafruit CircuitPython 7.1.0-beta.3 on 2021-12-13; Raspberry Pi Zero 2W with rp3a0
Adafruit CircuitPython 7.1.0-beta.3-174-gbea052695-dirty on 2021-12-22; Raspberry Pi Zero 2W with bcm2837
Code/REPL
import io
Behavior
Traceback (most recent call last):
File "", line 1, in
ImportError: no module named 'io'
Description
No response
Additional information
No response
seems okay, I was initially confused at sideset_enable being in the middle of a parameter list sometimes and at the end other times but that is because there are two related functions...
Should adafruit_circuitpython_ble have blinka in the requirements.txt? Looking at things from the contributing page bu didn't know how Bleutooth is handled regarding libraries plus Blinka.
adafruit-blinka-bleio is used on host computers, and we include blinka also so that pylint will find definitions for various things and not complain
I am working with nrf52840 board now. And I can make the circuitpython work fine with the adafruit bootloader which included softdevice.
However, when I change to the bootloader which don't included the softdevice.The circuitpython is not working.
I tried to modify the ports/nrf/bluetooth/bluetooth_common.mk to remove the "CFLAGS += -DSOFTDEVICE_PRESENT". I also tried to
change the ld file to delete the flash region of softdevice.
But I still can't make it work.
Is there any sug...
Got it, so it sounds like it makes sense to add Blinka to it then? As well as the bleio library (if it isn't already)?
Has anyone been able to successfully build circuitpython or any ESP32-S3 board?
Yay, That works. I partitioned an SDCard with a 256 Mbyte BOOT and 16Gbyte (rest of drive) CIRCUITPY partition. The cm4io boots from the network and CIRCUITPY is mounted. WooHoo! I don't understand why I can't get it to boot from the USB ports, but the netboot is working fine and it is easier to use. I'll stick with that for now. Thanks for the help.
that's odd,
ticks_msandmonotonic_nsboth use ...
The link to ticks_ms() isn't corroborated. I only had 5 or 6 stalls in total and for the first two, I didn't even try a keyboard interrupt. I know for the last two that the line contained ticks_ms and I seem to remember this was true for the ones before, too, but I'm not sure. No stalls since I replaced ticks_ms with monotonic_ns, but that might well be luck. And ticks_ms is used in waiting loops, so these lines get called fairly oft...
I think this should revert the windows changes as well. I missed that with my revert.
We have never tested without the SoftDevice, so there may be errors in the logic, and also the linking map may be wrong, since it assumes the firmware is placed after the SoftDevice in flash.
The attraction of using CircuitPython on the nRF boards is that it has BLE support, so we have always assumed the SoftDevice would be present. There are other chip families without BLE that we would recommend otherwise.
Sorry for crossposting with main help, this is probably more of a Development question as it's related to the releases and not function: for the Seeeduino XIAO, there is a "keyboard optimized" version that states it does NOT include pulseIO module, but the regular version also does not include the pulseIO module. Is there any version of the XIAO firmware that includes the pulseIO module? This seems to be an erroneous omission on the main firmware due to the language of it's specific exclusion on the keyboard optimized firmware. Please explain what's up with this :D!
many modules are excluded on SAMD21 devices because it cannot fit all of them. I would agree the way it's listed on the page makes it seem like pulsio might be present in the normal build. But I think it may not actually be included in the normal build either. You could make a custom build that enables it if you want perhaps though. If there are other modules you don't need you could turn them off to make room.
In the standard build I think maybe this line: https://github.com/adafruit/circuitpython/blob/900ec91fa6c991f2a2d95e3911a7e02c6a91dad3/ports/atmel-samd/boards/seeeduino_xiao/mpconfigboard.mk#L11 is disabling it (and likely other modules as well, but I'm not certain which ones)
@lone axle is there a way to use the build system to generate a version with pulseio enabled and maybe disable something else to make room for it? Or am I going to have to make a build environment on my own PC to do a custom build?
(Is there a 4 dummies guide that I can follow?)
So this obviously isn't the solution, I'm sure it breaks all sorts of things, but hopefully it will help ferret out the issue.
I commented out the reset_all_pins(); statement on line 109 of ports/broadcom/supervisor/port.c and my build is now working with the flash.
Cool! I tried this as well on my Pi 4B -- -- It now boots from the USB Drive and I can access CIRCUITPY on the SDCard.
Thanks!
You would have to set up the environment on your PC to make the custom build I think. There is a guide that covers the process here: https://learn.adafruit.com/building-circuitpython which does have a page that talks about enabling and disabling modules: https://learn.adafruit.com/building-circuitpython/customizing-included-modules
the ble library already has adafruit-blinka and adafruit-blinka-bleio as requirements: https://github.com/adafruit/Adafruit_CircuitPython_BLE/blob/main/requirements.txt
@lone axle you wrote this guide, right? https://learn.adafruit.com/multi-tasking-with-circuitpython/multiple-leds. I was thinking that the dictionaries used in the blink examples could be rewritten as classes and attributes.
class Blink:
def __init__(self, on, off, pin):
self.prev_time = -1
self.on = on
self.off = off
self.pin = pin
and then refer to to the fields as led.pin instead of led["PIN"] etc.
Yep, I did, and agree they could be. Probably better that way to try to make the definition of them more strict so it's harder to accidentally use the wrong name for something and have it not work.
Would it make sense to call it BlinkTask? If "Task" is used as an actually concept somewhere It's probably best to not use it here since they aren't "real" Tasks. But as a general term I think it fits what they do.
tasks are a concept (and a class) in asyncio
BlinkState? Blinker?
you could add methods to the class as well to do the blinking or checking, not sure if that makes sense for this example
a task is a wrapped coroutine
nRF52 bootloader project has updated the family for the nRF52833 to 0x621E937A for the nRF52833.
This will ensure that 840 firmware won't be able to be flashed to a 833 and vice-versa.
We need to update the Makefile here with some if statement to check for the nRf52833.
I don't know if there is anything else that needs updating.
yes I've done extremely basic things (usb connects, can open repl) on the espressif "devkitc" boards, both with and without psram.
I see. Probably best to avoid using that term then. I do like either BlinkState or Blinker. I've got it noted down on my todo list to rewrite the examples. The ones on the Servo pages could be updated similarly as well.
ok! thanks for thinking about this
This issue seems to have been resolved -- I have not had any occurrences recently. Should we close and re-open if it comes back?
Me neither. I have no idea what they fixed, though. I'll close it for now. Thanks for following up.
I'm not sure if this is the correct approach, but I stole the following code from the raspberrypi port and placed it at the top of ports/broadcom/mpconfigport.mk which seems to have enabled long integer support.
# Define an equivalent for MICROPY_LONGINT_IMPL, to pass to $(MPY-TOOL) in py/mkrules.mk
# $(MPY-TOOL) needs to know what kind of longint to use (if any) to freeze long integers.
# This should correspond to the MICROPY_LONGINT_IMPL definition in mpconfi...
is there a way to figure out which modules mpconfigboard.mk is enabling/disabling?
Yes thank you so much for this fix. It cleared the path to completing some Christmas gift projects that were confounding me!
The CIRCUITPY_SOMETHING settings are generally named after modules. The defaults for a particular port are in port/nameofport/mpconfigport.mk.
@tulip sleet is the pulseio module unsupported for the seeeduino xiao?
it appears to be missing from the matrix, but no explanation for why or why not
the xiao rp2040 module is supported, but this is some other kind of cpu
on the straight regular mainline xiao chip
THANK Y'ALL I GOT IT WORKING 😄
totally defeating the purpose of moving from arduino to python by compiling my own firmware but also loving how easy that was. Thank you all and thank you to whoever wrote that beautiful guide on how to DIY compile circuitpython. that was easy as pie. hopefully it actually works for what I'm trying to build 😄 (Or I can figure out that coding! lol)
Happy holidays
Awesome! Have you seen it start up without finding the partition sometimes? I'm seeing it sometimes not correctly start up and thus it doesn't load the partition.
Does i2c readinto support array input? I suppose it does but doesn't do the offset by element either. Maybe we should consider changing it as well for CP 8. I think going by element size makes more sense.
Want to try enabling this as well? We should probably set FULL_BUILD=1 and then disable the things we don't support. That'd catch a lot of stuff like this.
Here is a similar change done for ESP: https://github.com/adafruit/circuitpython/pull/5771
That looks right to me. Want to make a PR? The BCM chips don't have an RTC officially. We could probably fake it with the system timer though. I think it has microsecond resolution.
This is probably a dumb question, but are the ssd1306 drivers expected to work well an M0-based board like the Metro M0 Express? I’m asking because I seem to be running into memory allocation issues using either the framebuff or displayio based drivers.
So far I have not had any problems, but I'll let you know if I do.
Its hard to get the ssd1306 to work on an M0...in my experience -especially if you have anything else being loaded
@solar whale I tried whittling down which pin was causing issues on reset but didn't nail it down
Thanks. I went back to trying to just the basic simpletest demos to run and nope
I was afraid of that...
are you using the .mpy version of the library from the 7.x bundle
Yes, I am
are you getting the memory issue on import?
@solar whale the issue I'm seeing on 4b isn't pin dependent from what I can tell
There is not enough room in the build for pulseio. This is typical on the small SAMD21 builds.
so something else that is impacted by that reset all pins ?? not a specific pin?
Hmm, ok. I think I may have figured it out. It looks lie problem is the REPL. I presume terminalio is eating memory needed for the buffer. Boo.
@solar whale I'm seeing an error that data is corrupt after increasing the SD card clock. It's sporadic and caused by in incorrect load before the clock rate change
@stoic rain terminalio has a tilegrid for it's use
Is this on the 2w?
no, the 4b. on the 2w I actually get init failure when doing to high speed mode
(I wasn't checking that the card init actually finished ok)
Changes look relatively simple. Is there a variable that indicates the target? (For the nrf port)
@tulip sleet it built and flashed just fine, imported and showed that it's there in REPL throwing no complaints after "import pulseio"...now I'm confused how do I even test that it's there?
I followed the guide on how to configure modules and removed midi
tested with QT PY S2, enumerates fine!
if it imports, it's there. Sometimes a module is omitted also because it doesn't fit on a larger translation, though it might fit on some smaller ones. We aim to be consistent between translations
tested an s2 board, but not an s3
Code stolen from raspberrypi port
@slender iron I know you are heading off for the holidays. Feel free to let me know if there is something in particular you want me to try to look at. I think I finally have my setups all useable. I had a bit of a soldering mess on one of the pi adapters and I had to put the SWD header on it instead of the JTAG. Now I need to figure out the proper configuration for using it.... But I have two other with JTAG so I can use them until I do. Now that I have some working systems, I'll be happy to try to help. Still a steep learning curve to catch up, but any pointes would be welcome -- enjoy your break -- it'll all be here when you get back 😉
thanks @solar whale . I'm spending these last few hours looking. something has got to be off with how I'm doing data transactions
Okay, PR for the long integers submitted :). I don't know if you want to link this issue and open a new one for the RTC or just keep this one going.
Good luck, I have so much to learn -- and relearn about debugging.... it's been too long...
the broadcom chips are definitely the deep end
sdcards would be easier if we could sniff the data lines easily
getting this right will hopefully speed up sd card access
Have you ever noticed that it takes a long time to get contol-c to interrupt a running gloop?
no, I haven't looked at that specifically
Well, I've tried for 2 days straight now..... even did a hard reset on main... this is what I keep getting:
https://gist.github.com/UnexpectedMaker/7700489349043b8f5e1d5eba9e14796b
no big deal, but I find I have to hold control -c for a few seconds to get it to trigger. minor issue at this point.
over usb or uart?
kk, I didn't think uart worked at all 😄
Ah -- it's immediate over USB -- never-mind
Ah, long press ctrl-C. I'll give it a try.
Could I do a Broadcom build with no USB support? Sure it breaks the workflow, but that isn't really working just now.
I can test and put a PR in with FULL_BUILD enabled easily enough, but I don't think I could figure out everything that might need to be disabled.
I think I can track down the flag needed to enable just IO though if you want me to dig into that instead.
Unless of course you were talking to your team and not me :D
i'm puzzled -- what is "io" I don't see a model names "io" in the support matrix.
It is MICROPY_PY_IO, so it doesn't get found properly with the other native modules.
sorry -- now I see it in the rp2040 build
It is
MICROPY_PY_IO, so it doesn't get found properly with the other native modules.
ah so it is not in the matrix -- thanks -- it does show up with help('modules')
I can try to enable FULL_BUILD and work on the disables -- but probably not until next week
Whew :D, I just tried to compile with FULL_BUILD and realized I'm way out of my depth.... Identifying the MICRO_PY_IO flag solves my short term needs anyway. Thanks!!!
@slender iron FYI -- the SWD connector seems to work with the JTAG configuration -- I guess I thought some changes were needed, but I guess not -- at least at first glance. Nice! Now I have 3 working adapters.
time to work on dinner here -- have a great holiday!
you too! thanks!
I have way too many toys to play with !!
I just added the pictures and updated the store links. Some of them might not be "live" as they are still drafts on Tindie. These are left as downloads_display: false for now.
Automated website update for release 7.1.0-rc.0 by Blinka.
I just blew away my fork, and I'm starting from scratch again 😦
I've been out of the CPY loop for ages, sorry, but well done to everyone on hitting 7.1 rc ! the new stuff looks awesome, and it's great to see prelim asyncio support!
thanks, we have bugs left, but we want to get some 7.2.0 betas out, especially now with better rpi broadcom support
i tested it with the new qtpy esp32 (which, true to its name, is quite cute), talks to my wifi just fine,
folks can always turn it off to save power later
Ok, I got it compiling finally - after a clean fork and clone and submodule update... but either my tinyuf2 isn't right, or my CPY uf2 isn't right. because I can boot into uf2, but if I copy my CPY firmware.uf2 over, it just copies. No flashing orange on the LED... just stays green, and the file just appears on the drive 😦
Possibly something to do with the UF2 family ID changing for S3? Not really sure what that is.
Hmm, seems since yesterday the tinyuf2 S3 stuff has been merged and the add-s3 branch is gone. I'm going to go back to master and grab latest and remake my uf2 bootloader
I'm not able to build tinyuf2 - this is such a pain.
{
^
/Users/seon/tinyuf2/lib/esp-idf/components/hal/adc_hal.c:64:17: warning: 's_previous_init_code' defined but not used [-Wunused-variable]
static uint32_t s_previous_init_code[SOC_ADC_PERIPH_NUM] = {-1, -1};
^~~~~~~~~~~~~~~~~~~~
[290/1065] Building C object esp-idf/hal/CMakeFiles/__idf_hal.dir/spi_slave_hd_hal.c.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
make: *** [all] Error 2```
I wish CPY and TinyUF2 could at least be on the same IDF version.
I was on adafruit-circuitpython-adafruit_magtag_2.9_grayscale-en_US-20211223-605753c.uf2 and for whatever reason it wasn't working with I2C, but, rc0 seems to have fixed it!
just killed off my tinyuf2 fork as well and starting again from scratch. I just don't understand how this all keeps getting messed up. yesterday I could build from the add-s3 branch. today going back to master and making sure I pulled and my submodules were all good... I can no longer build.
submodules are a pain aren't they
Yup, especially when the IDF submodule has its own submodules. It would be way better if we could provide our own IDF and instead of hard coded file paths it used the IDF env paths. Just like MP used to do before cmake.
ok, finally got it..
Board ID:unexpectedmaker_tinys3
though it seems to be flashing the RGB LED green for a split second every 5 seconds... hmm, is that new?
my tinys2 does that too, not sure why
it's signifying "Code done running"
hmm, ok, is that "newish"?
@dhalbert this enables i2c by default
We have never tested without the SoftDevice, so there may be errors in the logic, and also the linking map may be wrong, since it assumes the firmware is placed after the SoftDevice in flash.
The attraction of using CircuitPython on the nRF boards is that it has BLE support, so we have always assumed the SoftDevice would be present. There are other chip families without BLE that we would recommend otherwise.
Thank you for your reply.
It seems that we need to do more work to make ...
This will enabled I2C power after a hard reset, but will not change the pin state after a soft reload. For that we would add it to reset_board().
So if you disabled power in boot.py by setting the pin high, it will stay high. Maybe this is what we want. If we moved pin setting to code.py, it would get changed every time code.py started.
I think that makes sense. It is similar to the CPB, which also turns off stuff on hard reset, but doesn't adjust it on each soft reload.
This fix...