#circuitpython-dev
1 messages · Page 361 of 1
whats up?
Can you pull down the BNO08x library, and fuss with this threshold: https://github.com/adafruit/Adafruit_CircuitPython_BNO08x/blob/ea0f05f7d3068246acafb65d65aece5cd8cfd992/.pylintrc#L256 and tell me how high it needs to be for Pylint to pass? https://github.com/adafruit/Adafruit_CircuitPython_BNO08x/runs/2127295355?check_suite_focus=true
The sky slaps knee
@lone axle If I remember correctly, you have to change https://github.com/adafruit/Adafruit_CircuitPython_BNO08x/blob/ea0f05f7d3068246acafb65d65aece5cd8cfd992/.pylintrc#L26 jobs=1 for it to acknowledge the threshold change. Which I think is a bug, but I think they're aware of it.
Try it with jobs=2 first though to make sure I'm not misremembering.
Yep, I can do that.
@slender iron I remembered a point worth considering - you can't have the jobs increased in Pylint, and have it acknowledge the duplicate code threshold change. We ran into this with the two libs that we opted to increase the threshold on. It ignores changes to that threshold if jobs>1. It's a bug. So if we increase that threshold, we will not have Pylint running as quickly.
Though it seems like this is out of my hands, so I suppose it's more of an FYI than it is something to discuss.
Thanks much. Let me know what you come up with.
how did you change the threshold? In pylintrc?
Yes.
I don't know of another way to do it.
It's not a normal check.
That you can disable.
Ok.
I will have Tim come up with an increased threshold that works on that specific library, and we'll call that the new threshold. And have Dylan run an Adabot patch. CI doesn't trip the needs-release check anymore, so we won't have to do a sweep afterwards.
👍
@lone axle Slightly bigger favor. Can you check the other two libraries here as well and see what they would require? https://github.com/issues?q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Aadafruit+"duplicate+code+in+library+files"+
Threshold-wise.
I can, it will take me a little while to be able to make it to all of them though.
No worries.
You are correct about the jobs=2 issue. It seems to ignore the min threshold when jobs is 2.
@idle owl the magic number for bno08x is min-similarity-lines=12 with that set to 12 it starts passing pre-commit when I run it locally.
Cheers.
@onyx hinge are you looking at cascadetoml for the imx?
Let me know what you find with the other two when you get to them.
@slender iron it's because of imx that I was poking at it
I'm not sure if it's going to be relevant though
@onyx hinge we can work to get it going on 3.7
here is my WIP for rp2040 flash: https://github.com/tannewt/circuitpython/commit/431b52c5c73469c714bf29d531205bdc6387b004
@slender iron I suspect the immediate term problem (supporting the GD chip) can be solved just by hand-writing the required config by hand, or by substituting in a "generic enough" one
"generic enough" is what we did on rp2040 feather right?
yup yup
ya, for now
I see two options to fix the config for gd: 1) uncomment the single fast read version or 2) switch sequence 4 to using 0x51 (iirc)
which is writing the second status byte
Way back when did you get very far in to understanding the imx flash config stuff?
ya, I grokked it
That sounds like what I understood
k, breakfast time for me and 🐱
Hi. Is a non-beta release planned soon for Pi Pico?
the next non-beta release will be for everything. The number of 6.2.0 issues is decreasing but is not zero yet
there's also the "port status" .. will raspberrypi port remain designated "beta" when 6.2.0 goes out?
(I don't know that we've decided to mark it as "stable")
After some amount of testing I've got a part-complete solution, but I'm running into roadblocks with bitbangio.
It, and internal I2C pull-ups seem to be mutually exclusive. If it's initialised as part of the i2c setup then I will inevitably get an error along these lines:
>>> import busio, board
>>> i2c = busio.I2C(board.SCL, board.SDA)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TimeoutError: Clock stretch too long
Afaict this is because `c...
That aside, I've added
CIRCUITPY_BUSIO_I2C_INTERNAL_PULLUPS_AVAILABLEbut a cursory search over the codebase doesn't suggest a place to:
- Define a default value for
CIRCUITPY_BUSIO_I2C_INTERNAL_PULLUPS_AVAILABLE- Check the value along with
CIRCUITPY_REQUIRE_I2C_PULLUPS
In py/circuitpy_mpconfig.mk add some code like this, alphabetically is possible:
CIRCUITPY_BUSIO_I2C_INTERNAL_PULLUPS_AVAILABLE ?= 0
CFLAGS += -DCIRCUITPY_BUSIO_I2C_INTERNAL_PULLUPS_AVAILABLE=$...
Afaict this is because
common_hal_digitalio_digitalinout_constructsets the pin pull state toPULL_NONEso no matter where or when I enable internal pull-ups, bitbangio will inevitably trample them.
Do you feel that that common_hal_digitalio_digitalinout_construct() should perhaps take an extra argument specifying the pullup and/or the initial value? I'm not sure if that would help or not based on your program flow.
@tulip sleet Thanks, I'm just writing at article on soil sensors on Instructables using Pi Pico and was wondering what version to recommend installing. I only need analogue inputs, digital outputs and i2c to work (and displayio).
all those work, except busio.I2C is flaky on some sensors (not a CPy problem), and bitbangio.I2C would work
but really, it's in quite good shape, especially now the accidental overclocking of the flash chip has been fixed
This is the 0 byte write thing? I get some occasional quirks on a nobrand SSD1306 screen but that also completely fails on me at times and then recovers so I've assumed so far it's the screen. (It has onboard 10k pullups, running it at 400kHz over 8 in. wires).
that was fixed by beta.3. There are still some sensors (notably TCS34725, a color sensor), that don't seem to like something about the hardware I2C timing. The waveforms look fine on the Saleae
it's also possible to wedge some sensors into a bad state by doing probing, but nearly all seem to be fine. Also the PA1010D I2C GPS module likes bitbangio.I2C a lot better
beta.3 had a serious problem for feather rp2040 but I don't think that one affected the pico
i forgot the clocking issue was only on feather?
(didn't we have the flash settings wrong? It's been long enough I don't quite remember)
beta.4 will be out relatively soon, but we have no target day yet
Unrelated to my plants, has there been any thoughts on the broken dma/wav playback? https://github.com/adafruit/circuitpython/issues/4208
i haven't heard any further conjecture on that issue
@idle owl here's what I found on the other two libraries to get them passing the dupe check from pylint locally:
LSM6DS:
min-similarity-lines=6
PyBadger:
min-similarity-lines=12
I retested this with a simple program on the MagTag, and I don't see this problem now.
import alarm
import time
print("HelloWorld!") # I edited this during simulated deep sleep.
a = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + 10)
alarm.exit_and_deep_sleep_until_alarms(a)
Convenient. Thank you!
We'll go with 12 apparently.
@onyx hinge I released cascadetoml 0.3.0 on pip. hopefully it'll work on 3.7
@onyx hinge Can you get me the still image of your heart circuit sculpture? Doesn't need to be high res, it's going into the newsletter. I can't really pull guide images from Learn, only images in pages, and I don't see that still anywhere else.
@idle owl hold on...
No rush
Ah yes! Thank you. That works.
@slender iron yay it's working here with py37. ```../cascadetoml/cascadetoml.py cascade filter sku="GD25Q64C"
{'sku': ['GD25Q64C']}
[[nvm]]
Data for path: flash/gigadevice/GD25Q64C.toml...```
one thing I don't understand is, why do devices ship without quad enable .. enabled? what potentially breaks?
the top two data pins are HOLD and write protect by default
oh so you lose a function of those pins
yup
hadn't occurred to me
OK looks like some of the PWM setup is being done, but maybe the pinmux is not being set right...? (imx)
@tulip sleet There was some library you and Limor were talking about and I'm supposed to add it to the contributor bundle. I never knew what library it was though.
Ah thanks
sure, its components map closely to their chosen blocks
@jepler Jeff, would you interface it to ulab like so (pseudocode)?
b = displayio.Bitmap(8, 8, 256)
a = array.array('H', range(64))
bitmaptools.arrayblit(b, a)
arr = ulab.frombuffer(a)
What would be really great is, if this worked in the other direction, too. I.e., if you could pipe the data into a bitmap object, like so
arr = ulab.linspace(0, 100, num=64, dtype=ulab.uint8)
b = displayio.Bitmap(8, 8, 256, buffer=arr.tobytes())
i.e., without hav...
Added the lib to the bundle.
@v923z the goal was to have it work with a ulab array too, though I didn't test it before.
Here's what you can write now that this PR has been merged, freshly tested:
>>> arr = ulab.linspace(0, 100, num=64, dtype=ulab.uint8)
>>> b = displayio.Bitmap(8, 8, 256)
>>> bitmaptools.arrayblit(b, arr)
>>> print([b[i] for i in range(64)])
[0, 1, 3, 4, 6, 7, 9, 11, 12, 14, 15, 17, 19, 20, 22, 23, 25, 26, 28, 30, 31, 33, 34, 36, 38, 39, 41, 42, 44, 46, 47, 49, 50, 52, 53, 55, 57, 58, ...
@v923z the goal was to have it work with a ulab array too, though I didn't test it before.
Here's what you can write now that this PR has been merged, freshly tested:
Thanks!
Because of "dirty rectangles" (the bitmap needs to track which portions of the itself have changed, to make display refreshes more efficient) we can't enable using the same storage for a writable ulab array and a bitmap, so a copy will be necessary. Unless someone sees a clever way around this little det...
Alright, looks like the build checks all passed now. I think this is ready for review.
pulsein for the RP2040 was addressed by PR #4262. pulseout is still not implemented.
Thank you! Github tells me this is your first pull request to any repo, congratulations on that as well.
A few minor things. Sorry I didn't see them in the first round of reviewing.
This makes a displayio.Bitmap usable as a read-only buffer.
It enables this to work:
>>> b[0] = 32
>>> b[1] = 64
>>> b[8] = 64
>>> ulab.frombuffer(b, dtype=ulab.uint16).reshape((8,8))
array([[32, 64, 0, 0, 0, 0, 0, 0],
[64, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0,...
I tried 80k which is bigger than the wav file and CircuitPython becomes non responsive at the same point.
@tulip sleet my flash init changes are here: https://github.com/tannewt/circuitpython/tree/rp2040_flash
stage2.c.jinja gets templated and then compiled
@slender iron I didn't dig into the compilation flags, but wondered whether making the functions in stage2.c static, or using -fwhole-program, or using -flto would get space back.
ah, good point
I assume you determined -fPIC was necessary, but .. why? don't you know the RAM address where you'll be loaded?
yay!
it gets loaded twice
at different addresses? Ok.. I'll allow it
🙎
so close!
yeah I'm getting about 270 here
lto didn't help any more than static
so it does fit if I don't change the pad settings
ssi_hw->dr0 = status_command;
ssi_hw->dr0 = status_command;
``` this is really supposed to be repeated?
ya, the second could be zero
you need to send a second byte to trigger a read
may be able to use an eeprom mode to skip the extra writes and reads
+ if ({{ clock_divider }} <= 2) {
ssi_hw->rx_sample_dly = 1;
+ }
``` based on the comment, can this assignment be made conditional?
wait_and_read(1);
ssi_hw->dr0 = (uint8_t) CMD_WRITE_STATUS2;
ssi_hw->dr0 = {{ quad_enable_bit_mask }};
wait_and_read(2);
``` I don't suppose these can be merged, 3 `dr0` assigns + `wait_and_read(3)`?
the wait causes chip select to de-assert
so you can't skip it
I think we might be able to always set the delay
@tidal kiln do you have the fan controller IC? There are a number of PRs for it: https://github.com/adafruit/Adafruit_CircuitPython_EMC2101/pulls
nope. but on the way. ordered today.
kk, cool
with intent to take a look at those PRs
thanks!
np
//| """Returns the USB enumeration status (read-only)."""
Let's not say mount because it doesn't have to do with the filesystem (even though TinyUSB uses this term.)
One, thing. Good otherwise. Thanks!
@slender iron I was trying to get a build going from your repo but failing. If you can send me an elf that includes stage2, I can look at the assembler. There doesn't look like a lot to shrink. Maybe the wait_and_read() routine could be squeezed in some way, since it only gets called with 1 or 2
rm -rf build-raspberry_pi_pico
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
{'sku': ['stage2.c.jinja']}
Traceback (most recent call last):
File "gen_stage2.py", line 11, in <module>
quad_enable_status_byte = flashes["nvm"][0]["quad_enable_status_byte"]
IndexError: list index out of range
@slender iron it's good to know why, thanks -- I don't see any obvious space savings, I tried tinkering with some stuff but it didn't make a difference
is this in the regular elf?
@tulip sleet did you init submodules?
@tulip sleet there is a "4" watchdog_hw->scratch[1] = wait_and_read(4);
yes, I did
oh! do the feather, not the pico
that shouldn't affect the assembly code
the compiler can optimize it better then
I used the copy in my thermal camera experiment, but noticed the image was not refreshing when updating the bitmap.
Right now I am doing the following, but I don't know if this is the optimal way:
image_group.remove(image_tile)
image_group.append(image_tile)
Thanks for the feature, I am not sure I fully understand everything that is happening under the hood, but it works.
you could maybe just put the wait() part in a routine, and then exapnd 1, 2, or 4 reads into straightline code. that may or may not be an improvement
it's probably more worth my time to just figure out how to use it from CP code
could even just link in a second copy
it all fits without the capacity read
In https://github.com/adafruit/circuitpython/pull/4403#issuecomment-801546317, @dglaude reported that the screen wasn't updating. This is due to forgetting to mark the target of the arrayblit operation as "dirty".
the benefit from doing in CP would be that we could do more complicated init if a board has very different flash chips
but you were sad about losing some pico-sdk functionality?
you would have to rewrite?
no, it'd be ok because the stage2 does full init
I just have to redo their internal functionality to stop things and then restart them
it sounded like you could propose a PR to their current API to read more stuff
read more of the status register or whatever
I'd really like a general command in their sdk
May need to do display.refresh()
On Mar 17, 2021, at 8:23 PM, David Glaude @.***> wrote:
I used the copy in my thermal camera experiment, but noticed the image was not refreshing when updating the bitmap.
Right now I am doing the following, but I don't know if this is the optimal way:image_group.remove(image_tile) image_group.append(image_tile)Thanks for the feature, I am not sure I fully understand everything that is happening under the hood, but ...
not sure why they didn't just add that
i think you could propose it and put it in our fork and it would eventually show up?
and then we could stop using our fork
i don't remember; they are updating so fast that we should keep merging from upstream
if we are using our fork
ya, they are releasing pretty slowly though
and develop hasn't moved that much either
anyway, I'll sort something out tomorrow
i looked at the assembler (i fudged the size to 512 bytes in the .ld). this is all striaght line code, I don't see much to squeeze. I thought there were more conditionals and calls
maybe wait_and_read could be shrunk by a few instructions, but not much, not enough to make a difference. it was 280 when I built it
@v923z ah, the mental model of displayio is different than what you're thinking of .. There are what I think folks call "immediate mode" graphics engines where to redraw you run through sections of code which say "draw THIS, over THERE" and when it's done the new content of the screen is ready. If the content of a bitmap changes, you have to also run the code which says to draw the bitmap.
By contrast, I'd say that a big element of displayio is that you declare that some graphical e...
did you add the statics?
no
it dropped it by 10 I think when I did
yaah 280 to 270
only 18 off 😛
i like your overall plan better, though
ya, I'll just change the sdk
so I can use it to get capacity
time to get off the comp now though
good night!
👋
Sorry I missed this. I guess this is now the risk we face with the write_pixel function broken out separately.
One note of caution, if a dirty region’s x1 == x2, this signifies that there is no dirty area. Right now there is no checking inside set_dirty_area to enforce x1 != x2. Is there a possibility that x1 could equal x2 here? If so, it will cause unexpected refresh/dirty rectangle behavior for single column changes.
I'm looking at building a macro keyboard (like so many others) and I was thinking of qwiik connectors. Adafruit has buttons with qwiik connectors, but they are not i2c. sparkfun has i2c qwiik buttons, but only mentions a Arduino library.
Anyone know if there is a Circuitpython library to use these in a project?
there are drivers for some Sparkfun qwiic products in the community bundle
Thanks, I'll go look.
Running this on 6.2.0-beta.3-11-g7970c882a on 2021-03-04 on a Pi Pico
import time
import math
import random
import struct
import board
import pwmio
import digitalio
from audiopwmio import PWMAudioOut as AudioOut
from audiocore import WaveFile
import rp2pio
import adafruit_pioasm
AUDIO_PIN_L = board.GP18
AUDIO_PIN_R = board.GP19
audio_out = AudioOut(AUDIO_PIN_L, right_channel=AUDIO_PIN_R)
stereo_file1 = open("scanner-left-16k.wav", "rb")
stereo_file2 = open("scanne...
@kmatch98 if you don't mind, I'd like to leave this possible "inefficiency" for now. From what I can tell, the scenario you outline
- would only affect programs where an
arrayblit()call doesn't actually touch any pixels - would not create an incorrect display
- would only cause some pixels to be needlessly redrawn (an inefficiency)
If that's correct, a user who is concerned about the loss of efficiency can simply ensure they don't call arrayblit() to do nothing.
I would like ...
These buffers are > 65535 bytes. I wonder if there's a 16-bit limit somewhere.
In #4430, @kmatch98 raised an issue where calling displayio_bitmap_set_dirty_area with an "empty area" could in fact dirty some pixels.
This made me start looking in the code for ways to make the C APIs more resistant to misuse. To that end, I
- Added more area helpers (
canon,copy_coordsandarea_empty)canonswaps the coordinates of an area if necessary to make it "canonical"copy_coordscopies the x1/y1/x2/y2 coordinates of one area (but not its 'next' poi...
While chasing another problem I discovered a strange Magtag behavior.
Using an i2c device (in this case the tlv493d) and mqtt I was having to power off and on each time I was making a change, or I would get
ValueError: No I2C device at address: 5e
When I changed
i2c = busio.I2C(board.SCL, board.SDA)
to
i2c = busio.I2C(board.SCL, board.SDA, frequency = 400000)
the problem goes away.
@jepler Maybe I am unclear or am misunderstanding, here goes a scenario where I think it would cause an incorrect dirty rectangle:
-
Bitmap is created 100 x 100 pixels
-
The bitmap is manipulated a lot and the
dirty_arearectangle covers a big chunk of the area, say (0,0) to (100,100) -
Somebody calls
arrayblitwithx1==x2.
- No pixels are updated in the bitmap (in this case, the for loops do nothing).
- The bitmap's
dirty_area.x1anddirty_area.x2is set to the same v...
@unkempt crow that is interesting. The datasheet talks about 400 kHz as typical but doesn't say it's minimum. I will bring this to the attention of the right folks. If you have a non-ESP32S2 board to test the sensor on, that would be great. I will order one of these to test more thoroughly.
I am not sure this is ESP32-S2-specific.
@unkempt crow is this you? https://github.com/adafruit/Adafruit_CircuitPython_TLV493D/issues/9
Solves the redraw problem observed.
@unkempt crow could you try taking readings without using wifi to see if the lockup occurs then?
I didn't test it but it makes sense to me. This is new to me to define the typecode of data stored in a buffer. Need to lock this away so I'll remember it.
Good example for defining a buffer, see:
int common_hal_displayio_bitmap_get_buffer(displayio_bitmap_t *self, mp_buffer_info_t *bufinfo, mp_uint_t flags)
Didn't test, but seems to make sense. I'm not familiar with the usage of buffers or the notation used in the type definition .buffer_p, so I can't comment on the implementation.
Based on the test code demonstrated, it looks like it performs the function requested, to get ulab access into a bitmap.
As for the color depth, main thing is to keep the color index >= 256 colors if you want to use this in ulab. If folks are clamoring to save memory on bitmaps when using this, perhaps the...
I'm closing this because #4405 does fix it. I ran the test program above without error.
@jepler Merge if this is ready from your point of view.
`Using:
import board
import busio
import adafruit_tlv493d
print("starting up")
Hardware I2C setup:
i2c = busio.I2C(board.SCL, board.SDA, frequency = 400000)
#i2c = busio.I2C(board.SCL, board.SDA)
tlv = adafruit_tlv493d.TLV493D(i2c)`
I can turn the error on and off on the Magtag but not on a Clue
Has there been given anymore thought to fixing the dir() issue that appears in the CPX library. It seems like there is a fundamental problem with the core and dir() calling properties, but could a temporary fix be implemented in the CPX library. https://github.com/adafruit/circuitpython/issues/4171
I worry about a hack fix that makes it appear that dir() works in general.
@unkempt crow could you open an issue on the library with the info? Thanks a lot, and we will investigate further
The busio library?
Will do. And yes, I'm probably lubarb on GitHub
@tannewt do you want to do this by 6.2.0 final?
I understand. I am teaching a workshop using the CPX and have a lesson coming up on CircuitPython. The refactor of the CPX library has completely broken the ability to use dir(), so it will be a lot harder to walk them through using the REPL to see whats available.
if you just do cp.<tab>, does that break also?
Perfect, thank you! That is an excellent workaround.
For interactive use, cp.<tab> is a workaround that can list the available functions and properties
@unkempt crow responded on github. let's move to #help-with-circuitpython and can you post a photo of your setup there?
I've been prodding this library as an alternative to some other code I have, and it's super-impressive. One question: what's the most appropriate way to change the auto-generated device name?
In my MIDI Monitor tool, I get this:

and I've had good success with other boards on changing the detected devicename - which I appreciate might be a USB setting rather than a MIDI-specific...
@still zephyr I invited you to CircuitPython librarians so you can do PR reviews on libraries
Thanks @slender iron
np, it just lets you help me 🙂
🙂 ok no problem always like to help
thanks! it's appreciated
It's ok with me if it misses 6.2.0 but I don't plan on switching to anything else until it's out for review. (So it'll be out for review if 6.2.0 is blocked on me working on other things.)
@tulip sleet are you hoping to do an rc next instead of a beta?
@slender iron - maaaybee an RC next, but we would want to do a feature freeze and do a 6.2.x branch at that point, since we have so many new things coming in. Looking at the 6.2.0 issues https://github.com/adafruit/circuitpython/milestones/6.2.0 I think 4431 is worth trying to fix. As for 4042, other boards, we don't have PR's for a few not-yet-on-sale ones, so we could skip those. 4041 is up to you, and I am looking at 4010 right now to decide if it's worth trying to fix
@tannewt I assume you're not interested in bending this rule of bitmaps even if a hypothetical speed improvement can be had due to avoiding memory copies.
I'm not sure exactly what you are proposing.
Remember that displayio was designed to 1) reduce the in-memory footprint by not having one big bitmap and 2) reduce the SPI traffic by tracking dirty rectangles. It (barely) works on the SAMD21 for the original Hallowing. I think the TileGrid model does a good job for 2d widget style l...
we could start with 7.0.0. betas right away, as soon as we do the incompatible changes: new ulab API, remove the transitional compatibility stuff
I think I'd do one more beta since beta.3 is a bit rough
i feel that's good too
I will want to do further 6.2 stable releases for rp2040 boards too
i thought maybe you were pushing for an rc 🙂
no, seems like you are 🙂
no 🙂 I just want to get usb_cdc turned off, etc., and the Feather RP2040 fixes in
I could make a beta any time: the release notes are up to date. I could do it this afternoon
ya, that'd be my vote
i think it's a good time -- there are plenty of fixes piled up
ok, I will start on that, I just need to do the download counts and contributors
jeff and your minds didn't explode with my flash setup for rp2040 so I can probably get that in next week
righto -- i think contributing to pico-sdk is the right tack
👍 that's my task today
it'll be nice to read capacity from the flash
I just ordered ~30 different flash chips from digikey....
ok, I will start on the beta right now. Mostly need to wait for zillions of download logs files (I have all of Feb but no March)
I'm pretty happy with the nvm.toml stuff
thanks! we should publish daily jsons of counts on public s3
that way we know where to pick up with the next release
i know how to do it with some AWS features or other, I just haven't gotten started on that, but it sounds like something I might have time for. I was hoping I could have the server logs be confined to HTTP GET's but that doesn't seem to be a setting choice
👍
so I can troll through them with a server-side script; I think I wwas going to use Lambda or something like that
ok, regular beta, and then maybe some infrastructure work for the next release
👍 thanks!
@kmatch98 I believe that was in my code already but did not have the expected effect.
May need to do display.refresh()
And @jepler explanation is likely right, no need to compare previous content and new content, if something was copied over into the bitmap, it likely has changed.
This is sort of the bug that @dglaude experienced above, because I forgot the call to displayio_bitmap_set_dirty_area in arrayblit.
[we'll correct the bug in the core of course]
I did try to trigg...
Then, when I type a key in REPL serial, it goes into REPL prompt almost immediately, with REPL and CUIRCUITPY connection maintained. In your test case, at which step does it lose connection ?
The button check is to get out of the sleep loop in case things go wrong and I can't get to CIRCUITPY.
If I use the test below on a Feather nRF52480 or a CLUE (using board.BUTTON_A instead of board.SWITCH), then I lose the serial connection to /dev/ttyACM0 while it pretends to deep sleep. T...
Thanks! @jun2sak for taking this on... I just have one concern about the debug prints.
I think port specific code (even if it is guarded) should not be in the shared parts of the codebase.
@infovore How do two boards show up in that tool?
@onyx hinge I am about to make a release. Is #4429 good to merge?
Since the usb_cdc module is on hold indefinitely, will this issue be reopened? I'm stuck on a nightly until, fingers crossed, this is available as an option in version 7.
Thanks
its not on hold indefinitely - we turned it off a few PR's ago because it was confusing some IDEs - you can build yourself and enable, or i think use nighties from over a week ago :)
This Guide page describes how to configure a build to turn it on: https://learn.adafruit.com/building-circuitpython/customizing-usb-devices
Thanks @ladyada and @dhalbert for the fast response! I'll have a look at that. I was so happy when I saw it was added just a few days ago and very confused when I tried the latest nightly and it wasn't available.
@tulip sleet if it's not too late, I think it is but I didn't fully look into the dirty area issue that kmatch raised. there may be something about what he's saying that I don't understand
yeah, that's why I didn't merge it, so i could wait until beta.5
i know you did try it, but i didn't follow the discussion
CI pylint is busting me for things it didn't bust me for a few days ago in library examples, like importing non-existent secrets, and import order of said non-existent file
and missing docstring
@onyx hinge I think I will wait on the merge of #4429 since there is some mild question
ok, weird, the pylint errors are referring to last week's file, not the present one, but last week's file succeeded last week
@tulip sleet that is fine, either way the effect is mild
Right now it just restarts CircuitPython:
>>> microcontroller.on_next_reset(microcontroller.RunMode.BOOTLOADER)
>>> microcontroller.reset()
[tio 15:51:33] Disconnected
[tio 15:51:35] Connected
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 6.2.0-beta.3-258-gc0d4b3732-dirty on 2021-03-17; IMXRT1010-EVK with IMXRT1011DAE5A
@gilded cradle hey. do you think this is something blinka should be taking care of? relates to this:
https://github.com/adafruit/Adafruit_CircuitPython_DHT/issues/63
but here's how blinka ties in:
https://forums.adafruit.com/viewtopic.php?f=60&t=175209#p859042
i guess the other option is to make sure the user code exits nicely?
@tidal kiln possibly, but I'm not sure how simple getting it to work in Blinka would be since maybe libgpiod_pulsein is holding onto it.
yep. that's exactly what's happening. just not sure who/where/how has the responsibility of killing the thread.
It may be an issue in the libgpiod_pulsein script, which is written in c. Some deeper exploration would be needed as I'm mostly guessing at this point. 🙂
Ah, ok. So it may be totally doable with a try/except KeyError block.
yah. something like that try/except....just some mechanism that would make sure that blinka's deinit stuff gets called....
right
there may be some pythony solution to this i'm not aware of
like registering a callback with SIGINT?
🤷♀️ not sure. I've only minimally played around with subprocess.
yah. same here. just some basic launching etc.
you OK if i open an issue just so we have something for reference?
Sure
Pushing from my repo due to duplicate branch from accidental previous beta.4
@onyx hinge or @slender iron could you approve https://github.com/adafruit/circuitpython-org/pull/652? For reasons having to do with previous accidental beta.4, I submitted this from my own repo instead of adafruit blinka. But everything else is OK.
I cannot merge it myself because I am the PR author
@tulip sleet hmmmm I think there's a problem...:
the languages list seems to be everything, but we withdrew several translation since the last release
build_release_files has language_allow_list = [ "ID", ...
it looked like it was a different order
but maybe it didn't get used in all the right places .. en_GB is on the list in your new files.json but it shouldn't be
i will clean out the bad languages by hand; i think we didn't have a release since that change?
the allow list needs to be moved so that generate_download_info() uses it too. I'll enter an issue.
@onyx hinge where is the allow list?
never mind I was looking in the wrong repo
Removing "hi",
"en_GB",
"cs",
"ko",
"el"
I think that's right?
i checked it systematically, so yes
Note: Not building languages {'en_GB', 'ko', 'hi', 'cs', 'el'}
I wonder if we can/could json.dumps(..., sort_keys=True)
thank you!
well it was a happy accident I had to do the PR by hand and you had a keen eye
thank you
- enable USB midi
- Upgrade the flash chip
- quiet down some sdk compiler messages
https://github.com/adafruit/circuitpython/pull/4384 😦 what are the alternatives, besides the repl?
you just need to re-enable CIRCUITPY_USB_CDC and you'll have the separate CDC channel again
do i have to do that in c/c++? or in python?
you have to do a custom build of CircuitPython
i would probably screw it somehow
it's a very useful thing to know how to build. Have you done Linux command line before? Do you have a Linux box? I would recommend that over Mac or Windows.
would it be possible to, somehow, have something to be able to control enabling that 2nd usb_cdc? or it's part of the bootloader?
i can spin a vm, and have some devices with linux
it will be controllable in boot.py. I have to do the work. It's my next major thing to do.
because we want to make it easy to use again
you could stick with beta.3 for now if you don't need to move forward
oh, if it will be able to be enabled in boot.py, then yeah, i will wait for it
i dont see anything i need in there on my rp2040, so, i will hold on to beta3
thank you!
if you are desperate I can spin you one, but it's not that hard. https://learn.adafruit.com/building-circuitpython/build-circuitpython just follow the directions
nah, im not desperate at all
like, for instance, you may want to turn off CIRCUITPY, etc., in the future once you get a device you want to leave plugged in permanently
i actually want to make a device to be permanently plugged in, but i kinda want to have flash access too, so c# can open/read/save a file into there
but i do have some doubts about boot.py, so, i will ask in #help-with-circuitpython
@tidal kiln @gilded cradle maybe look into using atexit, to force the deinit when its not used in a context (with ...)? https://docs.python.org/3/library/atexit.html#module-atexit
Oh yeah, I think you're right. I think we used that for neopixels.
@raven canopy neat. thanks! will check it out.
MIDI input crashes but output works, so i think merge and then we can investigate more
i tested sending midi data out from metro m7, works OK
https://github.com/adafruit/circuitpython/pull/4435#pullrequestreview-615930442
receiving does not, but im not convinced that it is imx specific
was a windows thing perhaps
this fixes it:
`
SPDX-FileCopyrightText: 2021 ladyada for Adafruit Industries
SPDX-License-Identifier: MIT
simple_test
import time
import random
import usb_midi
import adafruit_midi
from adafruit_midi.control_change import ControlChange
from adafruit_midi.note_off import NoteOff
from adafruit_midi.note_on import NoteOn
from adafruit_midi.pitch_bend import PitchBend
print(usb_midi.ports)
midi = adafruit_midi.MIDI(midi_in=usb_midi.ports[0],...
this is a dup of
https://github.com/adafruit/circuitpython/issues/4020
so closing this one since there's more people there
hihi closing since this is not circuitpython-core related - we have a todo for SDIO already if its wired to SDIO!
Ok, so here's the thing. It doesn't appear we currently store the raw .py or .mpy files on amazon or elsewhere, only zipped vesions. I'm trying to figure out the best solution here, but would like input from others. Here's the options I see:
We can use the .zip files from the release assets from GitHub to build a bundle, but a zip file with more zip files will probably be annoying to the user because it's more work than just grabbing the bundle itself.
We can start storing .mpy and .py...
We can start storing .mpy and .py files on Amazon s3 somewhere like we do with all the circuitpython releases, but I'm not sure what are limits are and this may take up a bunch of room unless we just keep the latest versions of everything.
The CircuitPython releases are more than 3000 files for each merged pull requests or release. The bundles are tiny in comparison. I periodically clean out these files and I could do the same on the bundles. But maybe you just need to keep the latest un...
Alright, cool. Storing the .py and .mpy files on S3 sounds like the best solution at this point then, but I'll allow others to chime in too.
@ionic elk do you have an esp32-s2 CircuitPython UDP socket server test .py? I haven't been able to get it to work with clients yet (https://gist.github.com/anecdata/3d5be8bd12db74f9301af6b348272278)
solved: it needs to bind the actual IP address, not just 127.0.0.1 or localhost
And I think it would be fine to store them in the same bucket as the builds, so we don't need another set of credentials. We can just make a new top-level folder.
Ok, I was just diving into JSZip a bit and it looks like it can do local extraction of zip content, so Amazon may not be necessary. I'm going to get something working without it first and if it looks like it's needed, we can do that. But it is nice to know that it is an option.
@tulip sleet thanks for doing the release!
yw - it was a lot less work this time except for the language thing
the ongoing release notes is maybe more time altogether, but a lot less painful
Why not just create the bundles the same way that the Bundle repo's .github/workflows/release.yml does, utilizing circuitpython-build-tools? Could probably work it into the current workflow file, and have them built on each release. Would only need to establish how to store/use the data for the specific bundles.
I would love to have a just-in-time service, but that would require some serious caching mechanisms to overcome the bandwidth issues with always requesting assets from GH.
@kmatch98 @FoamyGuy with my other work items I don't think I'll find the time to test this particularly soon. If one of you has the chance to put it through its paces it would be appreciated. Otherwise, I'll try to get back to it next week!
There's bound to be at least one problem introduced by this, I'm just curious what it is :grimacing:
I would love to have a just-in-time service, but that would require some serious caching mechanisms to overcome the bandwidth issues with always requesting assets from GH.
We would store the assets on S3, so I don't think it's too much of an issue. There could be caching behind that, but I think we could see if it's necessary. It could all be client-side JavaScript, just fetch multiple files from S3.
This release, 6.2.0-beta.5, is the sixth beta release of CircuitPython 6.2.0. Notable changes since 6.2.0-beta.4 include [[HIGHLIGHTS]]. See Port status below for details on port stability for each port, and Known issues for known problems. If you find any issues with this release, please file an issue.
Download from circuitpython.org
Firmware downloads are available from the [downloads page](https://circui...
@jepler I'll spend some time on this the next couple of days. Looks like your paying back a lot of debt (mostly withdrawn by me recently!). I'll do a code look and then some real trials to look for any weirdness.
Why not just create the bundles the same way that the Bundle repo's
.github/workflows/release.ymldoes, utilizingcircuitpython-build-tools? Could probably work it into the current workflow file, and have them built on each release. Would only need to establish how to store/use the data for the specific bundles.
I think the main issue with doing pre-built bundles is there are just too many permutations to make it practical.
I would love to have a just-in-time service, but that w...
Thanks for the improvements @jepler. I will test this out tomorrow
This is an addition to add color palette getters/setters for the OnDiskBitmap. This will allow for palete animations/color cycling for bitmaps without having to load them into RAM.
Also, this adds a flag that provides an option to force refresh of an OnDiskBitmap whenever the palette is modified.
This work was spurred out of an exploration of animated icons. @FoamyGuy demonstrated that using OnDiskBitmap allowed loading of significantly more images for the "TouchDeck" p...
I think these are both covered now by supervisor.runtime.serial_connected and supervisor.runtime.usb_connected.
yay for closing our oldest issue!
- Add FunHouse board
- Make
PWMOutconstructor return status values instead of throwing exceptions.PWMOutmay be created before exceptions can be thrown for backlight, etc. Changes inesp32s2andstmdue to this (hence tagging @hierophect for a look).
draft for now; backlight issues
@hathach I have noticed that the REPL is slow to appear in CircuitPython on nRF52, after connecting via a terminal program. I have seen this in Linux and after power-up or hard rest. This has been true for a while now. I will try to characterize this better but am opening this issue at least as a placeholder.
is it always slow or just start to be slow recently. I will try to narrow down the scope to analyze the issue.
Ping @tannewt who added the loop in question in 9d91111b1
@ladyada this is one of the possible causes of being unable to write more than 1MB to the Metro M7 with GD25Q32 flash fitted
@crimson ferry UDP servers? I actually don't know what's involved with that. I just wrote sendto and recvfrom_into. Shouldn't any server structure regarding datagrams happen on top of those?
There's no connectivity state with datagrams so the concept of a UDP server isn't built into the API in any obvious way I know of
I got the server part working (I think), it needed to bind to the explicit IP address rather than "127.0.0.1" or "localhost", though I have yet to be able to read the replies from the server (can read replies from CPython servers)
It's the "bind" part I don't get
I guess bind was pre-exisiting for TCP
Yes, I guess you have to bind but I'm not sure I proofed that for UDP
I can try poking at some test sketches for that
With "bind" you need to actually grab the real IP address from the ESP32-S2 via the debug console or wifi module, have you done that?
can i ask something weird about what you're talking about?
ESP32-S2 UDP Client works fine, as you know. Server, when bound to explicit IP, will receive and show data sent back. I haven't yet gotten CPython, ESP32-S2, or ESP32SPI UDP clients to be able to read that returned data. May have to get serious and watch the packets on the network.
(i know it's kinda rude to stick myself in the middle of a chat, but, i may be able to help)
(I wasn't expecting the explicit IP required, since CPython is pretty casual about it)
@signal pasture totally fine, go ahead
@crimson ferry so an ESP32-S2 socket will receive UDP data fine with recvfrom_into, when bound to an address? But when it sends a reply back with sendto, it fails?
@ionic elk from the server perspective, it shows data sent back to the client. But none of my clients can rad that (yet?)
I mean, presumably both ends require an address bound to them, if you're using ESP32-S2s on both ends
@crimson ferry can you be more specific about what you mean by "shows data sent back to the client"
What actual calls are you using
@signal pasture we're talking about the ESP32-S2 implementation of socketpool.Socket. We don't have TCPServer on Circuitpython
or at least not on the module level
maybe up in the libs or something I dunno, I'm the C monkey
UDP server: bind, recvfrom_into, and sendto. Client: sendto, recvfrom_into. (sendto includes the IP/Port tuple)
"shows data sent back to the client": size = s.sendto(buf[:size], addr) print("Sent", buf[:size], size, "bytes to", addr)
So on your UDP server, you have valid data that seems to be going out with sendto, and it isn't working
so either the server sendto, or the client recvfrom, is failing on the reply. Gotcha.
but is anything listening on the other side?
I can check it out, thanks for clarifying
yes, the client is waiting with a recvfrom_into
@signal pasture presumably the client listens with recvfrom_into (a blocking call) after it sends the original request.
yes, but is the server listening?
TCP Client and Server are functional at a low level on ESP32-S2; UDP Client is all good; UDP Server seems to work though I haven't yet gotten replies back at the clienthttps://gist.github.com/anecdata/3d5be8bd12db74f9301af6b348272278
The definition of DBL_TAP_REG must match tinyuf2.
After this, the sequence below brings up the bootloader, as does the "1200 baud" trick which is useful for scripting
>>> microcontroller.on_next_reset(microcontroller.RunMode.BOOTLOADER)
>>> microcontroller.reset()
@signal pasture In my scenario, both client and server are repeatedly sending and listening
@signal pasture we are talking about datagrams, so listen() is not used, if that's what you're thinking of
None of this uses TCP calls
@crimson ferry can you post an issue for possible problems with either sendo/recvfrom in a reply context from a UDP server, with whatever code you can post?
I'll track it from there.
by "listen" i meant "some device on the other side that is ready to receive anything"
yeah, I want to play around more to make sure I'm not missing something dumb
@signal pasture yes, that would be the client, using the call recvfrom_into, which will block until it receives something.
my goal is to get TCP and UDP sockets fully interoperable across CPython, ESP32-S2, and ESP2SPI (though there are no servers in the latter)
@crimson ferry sure. And so just to recap, I've never tried UDP from the server context you're describing, so it's possible I missed something about the interaction between bind and sendto, or something
or timeout
makes sense then
@crimson ferry it actually also might be a timeout problem, when I think about it. I might need to go in and make sure that sendto has appropriate timeout handling
sendto is fine from the client side
UDP didn't get the huge timeout/blocking pass I did on TCP
sendto appears to succeed from the server side
well, give it a bit more work and then tag me in an issue whenever you'd like me to look
I tested STM changes on a Feather STM32405, creating PWMOut's in the REPL to check the new error handling.
tested on metro m7 both with and without!
dotstars/LED/backlight/TFT works. i have more to test but this is good for now
There are DNP resistors on the MIMXRT1010-EVK board (see SCH-45852) that lead to these pins on the arduino-style header not being connected through. In theory someone could populate them, but as it the presence of these names in the pins module caused problems when they didn't work as expected.
Closes #3012.
Be careful, following these instructions can leave you with a board in a difficult to recover state!
- Put this in code.py:
print("hello world")
while True:
pass
- reset the board
- connect via usb-cdc to repl
- hit "A" then "ctrl-c"
Normally, you'd expect the ctrl-c to interrupt. However, it doesn't. If "ctrl-c" is the FIRST thing typed through usb-cdc, then it probably works. But typing anything else first leaves it non-working. My Linux terminal p...
Is there a better way to do "profiling" and find where time is spend?
start2 = time.monotonic() <put the code here>
stop2 = time.monotonic()
print("Time copy: %0.3f s" % (stop2-start2))
Hi. I was just looking at some of the PIO code in CircuitPython and this line looks wrong. The tests for tx and rx on this line look superfluous and would do something wierd if transfer was called with two NULL data pointers (probably not possible with current code). https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/rp2pio/StateMachine.c#L620
Ok I'm trying to figure out best infrastructure for S3. Right now CircuitPython uses GitHub actions, which works pretty well. It has the Amazon token as part of repo-specific secrets. Long term it would probably be best to have each repo upload its zip files to Amazon S3, but that would likely require another Actions sweep first and that would only upload the latest files.
Adabot has access as well and already has the secrets set up, so that looks pretty promising, but I didn't want to bog...
?serverinfo
Retroactive LGTM. The only thing we lose here is telling users that they might want to reshuffle certain initializations on STM32 so the dynamic timer allocation doesn't reserve timers on pins that require PWMOut. That was an STM32 specific issue, so I didn't want to abstract it to the shared bindings level. That only comes up if you're using PWMOut and PulseIO/Protomatter simultaniously though, so it's probably fine to leave debugging to the user.
Remind me the incentive for standardizing...
Remind me the incentive for standardizing these exceptions again, does it have a benefit for displays? It's been a while since I touched it.
The reason to remove the exceptions and pass back status codes was that the on-board display initialization in boards/<someboard>/board.c is done before exceptions will work or can be reported. common_hal_displayio_display_construct() was calling common_hal_pwmio_pwmout_construct(), and when the latter failed, an exception was getting raised. ...
I added it three years ago... Have you reproduced an issue with this or just suspect a problem?
I think the assumption is that it'd be incorrect for this code to occur when the spi bus is locked. Having this be a loop allows you to detect the error with a debugger when developing.
I think the bundle builder could just upload the files in the unpacked bundle. Otherwise every library repo has to know the S3 secret. Or it could be a webhook, like readthedocs, which does not require secrets. Nominally, that would require a server to answer the webhook, but you could use AWS Lambda to do this really easily, e.g. https://medium.com/mindorks/building-webhook-is-easy-using-aws-lambda-and-api-gateway-56f5e5c3a596 (many other examples can be found).
One advantage of doing it ...
@dhalbert that's right, I remember that now. I thought I had a custom handler for that but I guess not. I guess we could make common_hal_pwmio_pwmout_construct() aware of whether it's being called from board.c or the python code, but that's maybe too much work for some minor flash savings and failure conditions.
I'm ok with having it only update once a day since we generally direct people to use the bundle anyways.
@onyx hinge hey Jeff, is AudioPWMIO normally supposed to be interruptible by the REPL or no?
If you're interactive, .play() will return to the REPL while the sound continues playing
if you exit the repl sound will stop
so a ctrl-c should exit
.play() returns immediately in other words
so normally it's followed by a while True: or while speaker.playing: loop which will be interruptible with ctrl-c
is that answering your question?
Just a heads-up that I posted an issue under the Adafruit_CircuitPython_DisplayIO_SH1107 library on GitHub regarding the SH1107 128x64 OLED FeatherWing Display and the Feather RP2040 over I2C. Since the problem seems to occur only with the RP2040 and this display (also tested with M0 and STM32 boards and a different display with no issue), I wasn't sure where best to post but wanted to bring this to the attention of those of you working on the RP2040 in case it is relevant.
https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_SH1107/issues/4
I added it three years ago... Have you reproduced an issue with this or just suspect a problem?
My particular use case was attempting a file access in an interrupt handler, and observing that it locks up the board if the interrupt happens during screen update.
I think the assumption is that it'd be incorrect for this code to occur when the spi bus is locked. Having this be a loop allows you to detect the error with a debugger when developing.
There is nothing to prevent this code...
fine to merge when CI is green
@slender iron (or really anyone else) looking for something else to work on in the core if you have something that's not high priority but needs to be done. I have a couple weeks vacation and well can't go anywhere so may as well do something!
@blissful pollen there is a quick PIO ASM bug you could knock out
will think about stuff for the core
cool is there an issue for it? I can go look for it
yup, only issue on the PIO_ASM repo I think
Thanks for this PR! I'm unable to get this working on my Meowbit with the WAV sample code in the Circuitpython documentation. The speaker makes a little strangled sound, and then the program hangs irrecoverably, requiring a manual erase of the entire flash. If you have a test sketch of your own, I'm happy to try that.
The style and timer allocation stuff looks generally ok, I can't point out where the h...
Please revert this as per the previous comment. This module needs some reworks, and Pin.c isn't a good place to abstract this kind of thing in the meantime.
We use "for Adafruit Industries" to designate work that was sponsored by Adafruit, so you don't have to include it in your byline.
This should be a static function within PWMAudioOut.c, it doesn't need to be in Pin.c. The function in DigitalIO is very old and shouldn't be adjusting the pull and speed as it does, so it needs to be tweaked anyway.
Added board info and images for my new TinyS2 ESP32-S2 board
@hierophect thank you for the review!
I'm unable to get this working on my Meowbit with the WAV sample code in the Circuitpython documentation. The speaker makes a little strangled sound, and then the program hangs irrecoverably, requiring a manual erase of the entire flash. If you have a test sketch of your own, I'm happy to try that.
My guess is that it's #4397 :-)
You should be able to get `Wav...
@tyomitch ah, thanks for the full context, that probably is it. I'll make a note of my problem for Scott in the issue.
@tannewt It seems the most likely place for this to be encountered in practice is with the Meowbit, which shares the SPI bus between the flash and the screen (I assume this is where you first encountered the problem, @tyomitch). Specifically, when a module tries to access the flash while the screen is updating, it causes an irrecoverable hang. Then you need to figure out how to manually wipe the NOR flash somehow, like introducing an intentional exception into your build. I just ran into it w...
Firmware
Adafruit CircuitPython 6.2.0-beta.4 on 2021-03-18; FeatherS2 with ESP32S2 # also tested on beta.2
Code/REPL
CircuitPython native UDP Server code & CPython UDP Client code are in the comments below.
Behavior
I've been testing cross-compatibility of CPython, CircuitPython ESP32SPI, and CircuitPython ESP32-S2 sockets, both TCP and UDP. All supported combinations work except CircuitPython ESP32-S2 UDP Server... none of the thr...
If there are unwanted wider consequences for this change, and since the Meowbit is just one board (and a historically annoying one, for this same reason), this could be folded into an optional mpconfigboard macro so it doesn't apply to other boards.
CircuitPython ESP32-S2 UDP Socket Server example code:
import wifi
import socketpool
import ipaddress
import time
from secrets import secrets
TIMEOUT = None
HOST = "" # see below; 127.0.0.1 and localhost don't work
PORT = 5000
MAXBUF = 256
# connect to wifi
print("Connecting to Wifi")
wifi.radio.connect(secrets["ssid"], secrets["password"])
pool = socketpool.SocketPool(wifi.radio)
print("Self IP", wifi.radio.ipv4_address)
HOST = str(wifi.radio.ipv4_address)
ser...
CPython UDP Socket Client example code:
#!/usr/bin/env python3
import time
import socket
TIMEOUT = 5
HOST = "192.168.6.198" # edit as needed
PORT = 5000
MAXBUF = 256
buf = bytearray(MAXBUF)
while True:
print("Create UDP Client Socket")
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.settimeout(TIMEOUT)
size = s.sendto(b"Hello, world", (HOST, PORT))
print("Sent", size, "bytes")
size, addr = s.recvfrom_into(buf)
print("Receive...
@hierophect seems something is odd about the client port number, TCP vs. UDP.
It generates a best case stage2 for all the possible flashes and will work with others of the same capability as well. Flash size is dynamically configured based on the flash.
This also moves TCM designated code and data into RAM so that it's space is freed in the XIP cache.
Hi. Has anyone managed to get an implementation of PWM on PIO on RP2040 to work like the ones floating around for MicroPython?
want me to test feather rp2040 artifact? i could verify it uses QSPI?
for QBasic-compatible music strings
(https://en.wikibooks.org/wiki/QBasic/Appendix#PLAY)
The music parser is WIP and comments are welcome
before the input validation and missing features
are added; in particular, would microbit syntax
(https://microbit-micropython.readthedocs.io/en/v1.0.1/tutorials/music.html#wolfgang-amadeus-microbit)
be preferable?
A minor cleanup .. no testing performed.
BOOT2_S_UPPER ?= sdk/src/rp2_common/boot_stage2/boot2_generic_03h.S and related lines should be removed unless it's possible/intended for boards to go back to an asm boot2 in which case removing this line is probably wrong
(other lines being the BOOT2_S_UPPER settings in individual board files)
There seems to be an issue with the way that the progress_bar library is working. Running the progress_bar simpletest I am getting this mostly filled bar with lines in it:

The function responsible for updating the progress bars bitmap is here: https://github.com/adafru...
Looks like the byte-order of the port number is the issue. i.e. 63312 is 0xF750 and 20727 is 0x50F7. Not sure which side isn't using network byte-order, though...
That's very "interesting" :grin: , clearly it needs more testing and less simply feeling confident it must be right :) I'll try to find time to dig in to it next week.
Firmware
Adafruit CircuitPython 6.2.0-beta.2 on 2021-03-01; Raspberry Pi Pico with rp2040
Code/REPL
import busio, bitbangio
i2c = bitbangio.I2C(board.GP1, board.GP0)
Behavior
Traceback (most recent call last):
File "", line 1, in
TimeoutError: Clock stretch too long
Description
- Error while using i2c...
- Only happens when...
- might be related to #4291...
Additional Info
...
you gotta love accidentally sending a form before filling it in 🙄
I replicated @foamyguy observations with some bitmap pixel writes. It looks "timing" related because if I write pixels relatively slow it looks ok, but if I write them fast, then it is hit or miss. I suspect this is related to the refresh cycles and if they hit during the middle of the drawing. Will dig in more and report back.
I don't know some of technical details, but you are testing!
Are there cases where data[3] is out of range (too small, probably)? It looks like you just assume 2MB (2**21)? Could you add a comment explaing this
I'm confused; I thought this file didn't fit in the 256 bytes, or did you remove some stuff or put it elsewhere?
There are one or two board files (not in raspberrypi) that don't use , , but just ,. How about testing for , and then split and trim, or use re.split().
It was a < vs > issue in displayio_area_canon in shared-module/displayio/__init__.c.
Here's my branch with this one minor tweak: https://github.com/kmatch98/circuitpython/tree/bitmap-dirty-improvements
Thanks @kmatch98 I pulled in that change!
It's possible for me to fix this problem in the pico-sdk by adding the following line of code
i2c->hw->sda_hold = 2;
directly after this line of code
i2c->hw->fs_spklen = lcnt < 16 ? 1 : lcnt / 16;
This modification sets the SDA hold time during transmit (IC_SDA_TX_HOLD) to two ic_clk clock cycles rather than leaving it at the default of one ic_clk clock cycle.
I ...
@fivdi A very interesting find! Would you be able to submit a Pull Request to make that change? I glanced at the datasheet and I'm not sure what negative consequence there could be to this change, except possibly at higher I2C data rates.
@hathach I did a bisect and narrowed this down to:
commit 5351a93c70fcacc50a154edac0a6d6d1028296e0
Author: hathach thach@tinyusb.org
Date: Mon Nov 23 13:39:14 2020 +0700
update tinyusb to fix cdc connection race
issue is fixed in https://github.com/hathach/tinyusb/pull/557
Before this commit, connecting to the REPL on a Feather nRF52840 responds immediately. Afterwards, it takes about five seconds after connecting to print the initial prompt. I looked in `/var/lo...
Thanks for the excellent sleuthing!
Found an off-by-one error in bitmaptools.rotozoom. Here's the minor updates: https://github.com/kmatch98/circuitpython/tree/bitmap-dirty-improvements
I checked bitmap.fill, bitmap.blit and bitmaptools.fill_region and bitmaptools.rotozoom. Tommorrow I will look a spend a little more time looking at bitmap loading (imageload and OnDiskBitmap) and doing changes to palettes.
Here's my test code so far:
# Trials for bitmap dirty rectangle tracking
# Move text aroun...
I think this may be the issue, in Socket.c sendto():
dest_addr.sin_port = htons(port);
A cursory glance at the lwip layer indicates that the port byte order is mostly managed there. However, bind() and connect() also switch the port byte order in common-hal/socketpool/Socket.c and they work fine (bind is a local port though, and I don't think...
thanks @dhalbert I will look at this next week, there is also a relevant fix for dcd of nrf52 OUT transfer that could cause drop of packet recently, will see if that also fix this. https://github.com/hathach/tinyusb/pull/733
@jepler
If you can modify the bitmap via its buffer,
memoryview(bitmap)[X+Y*bitmap.width] = 0there is not a facility in micropython to notify the bitmap that its content has been modified.
If I understand correctly, your only concern here is that this refresh/update function has to be called manually, otherwise, while the data will be "updated", this fact will not be reflected on the display itself.
But is this really a problem? If someone is using this very low-level buffer u...
@tannewt I assume you're not interested in bending this rule of bitmaps even if a hypothetical speed improvement can be had due to avoiding memory copies.
I'm not sure exactly what you are proposing.
Remember that
displayiowas designed to 1) reduce the in-memory footprint by not having one big bitmap and 2) reduce the SPI traffic by tracking dirty rectangles. It (barely) works on the SAMD21 for the original Hallowing. I think the TileGrid model does a good job for 2d widg...
Hey all how does circuitpython work under the hood. What i am trying to do is add functionality to my code to provide the deque module from the collections library in python. The library is in c and so i was thinking it should'nt be hard to add it to the circuitpython base. Am i missing something here. Is there a guide or instructions on how to do this sort of thing
@fivdi A very interesting find! Would you be able to submit a Pull Request to make that change? I glanced at the datasheet and I'm not sure what negative consequence there could be to this change, except possibly at higher I2C data rates.
@jepler the PR is at https://github.com/raspberrypi/pico-sdk/pull/273
Thanks for the excellent sleuthing!
@dhalbert you're welcome
@vague latch are you familiar with building CircuitPython https://learn.adafruit.com/building-circuitpython once you can build it, you can modify it....
so is there anything stopping me adding a standard python library
It is written in C, not python -- if you want to ad a python library, you can do that without rebuilding CP.
yeah, so actual cpython library
would it be worthwhile adding in the whole collections library then.
is it a balancing act between functionality and size for the main build
Right -- If you think it is something that needs to be added, you can open an issue for discussion or add it and then create a PR to see if it is something that should be added for all.
ok. thanks for that. ill do some testing.
I usually start by writing a Python library to try things out. That’s usually much quicker to get something working and try out all the logic. (Unless it needs access to something that not available to Python then that’s a different story.) Then if it needs to be faster that’s really the reason to put it into the core C code. But if you want to learn more about how CircuitPython is built then by all means go for it! And ask around here, the guides are a starting point but there are many ways to get stuck. Ive learned a lot by asking here when I’m stuck.
so i really want to get up and running an async type code base.
i watched david beazleys discussion on asyncronous and concurrent programming and his code utilises heapq and deque
i was looking to add these functionalities to my code and noticed neither of them are implemented.
or if they are i couldnt see them
Have you tried the tasko options? I’ve not used them. It I know some support of async is available.
it wasnt running at the speed i was expecting so i thought i will try and write one myself.
Got it, I see a similar issue noted here: https://github.com/WarriorOfWire/tasko/issues/1. Maybe that’s your issue 🙂
maybe. I will look into that. I cnat seem to build circuit python forthe feathers2 at the moment anyway
does the circuitpython build require a certain version of python
what issues are you getting ?
I dont remember what the issue was i t basically never looped through
or the issue with the build
that one was fnmatch.py Nonetype is not iterable
Feather S2 is an ESP32-S2 which does require some extra set up to build.
Scroll down to the "readme" section of this page: https://github.com/adafruit/circuitpython/tree/main/ports/esp32s2
if you have not done the install and export steps for the esp-idf you'll need to do those.
esp tools want python3 but call python
That version should be okay. I am able to build and I use python 3.8 as well
on an ubuntu VM I installed python-is-python3 for that
ok
mine is set up that way (python3 is actually called python in my environment)
ok my error is in ```circuitpython/ports/esp32s2/esp-idf/tools/ldgen/generation.py", line 84, in do_section_expansion
expansions = fnmatch.filter(sections_in_obj, section)
File "/home/tim/miniconda3/lib/python3.8/fnmatch.py", line 55, in filter
for name in names:
TypeError: 'NoneType' object is not iterable
ninja: build stopped: subcommand failed.
Makefile:310: recipe for target 'esp-idf-stamp' failed
make: *** [esp-idf-stamp] Error 1
did you run these commands in the repo also?
git submodule sync --quiet --recursive
git submodule update --init
yep
Those and the install / export of the esp-idf are the main gotchas that I am aware of. If you've taken care of those I'm not sure what else could be giving you trouble.
I don't recognize that error specifically. But as other folks come online someone may know what it's about.
hmm thanks for your help anyway
ill have a fiddle with it and look at the update of tasko
I honestly don't know much about anaconda, but I noticed your path has miniconda in it. I have seen other folks have issues with anaconda environment before. I'm not certain if it's your issue. But if you have a way to try a "vanilla" python environment it might be worth a shot.
@tannewt Hypothetically, if a ulab array can be a writable view onto a bitmap, you would have to call a new dirty() method on the bitmap after modifying it outside the knowledge of the Bitmap itself:
b = displayio.Bitmap(8, 8, 256)
a = ulab.frombuffer(b) # create a ulab.array that views onto b, but see below
a[y,x] = p
b.dirty(x, y, x+1, y+1) # This call doesn't exist yet, because we've worked to prevent the need for it
If you omitted the call to the new dirty() function, or ...
@kmatch98 this is great! you should add your test in tests/circuitpython-manual
Ok, I did some more tests and didn't find anything more. All I found else was that one issue in rotozoom (listed above). Once you merge that, I think it's good to me. I'll add a review.
Here's my latest test code that I used, now including tests with adafruit_imageload and displayio.OnDiskBitmap.
# Trials for bitmap dirty rectangle tracking
# Move text around, label and bitmap_label
# Make bitmap boxes
# - Move them
# - Change palette
# - Change individual pixel...
Looks like you added the rotozoom fix, so all looks good to me.
hmmm I think there's a (probably preexisting) problem with dirty areas for TileGrids that transpose_xy when updating grid elements
I sorta suspect the coordinates "dirtied" are not accounting for transposition alone
Just wanted to confirm that this happens as David says. It's odd. It's the kind of thing you think "should work" but somehow it doesn't quite. Impressive stuff, though, what goes on under the hood.
I haven't distilled this down into a test program, but I had a tilegrid with 8x5-pixel tiles, sized 4x23, and transposed. (so it ends up being a wide and short tilegrid)
I found that after the initial draw, only a narrow strip at the left of the tilegrid would be updated when I changed the tiles.
Here are the relevant snippets. Running with recent main branch on a feather rp2040.
font = displayio.Bitmap(8, 5*256, 2)
with open("/font5x8.bin", "rb") as f:
f.read(2)
bitm...
.. I'm working around it by modifying the palette, which causes the whole tilegrid to redraw ..
I’ve never looked into how the refresh areas works with rotations. I suspect you’ve probably found a weakness where dirty_area isn’t transposed.
Looks like it is trying to handle it here https://github.com/adafruit/circuitpython/blob/e084a92671b01220c795d114bee9d5058dbfa680/shared-module/displayio/TileGrid.c#L586
http://wifitest.adafruit.com 403 Forbidden 😦 Is it look for certain headers or blocking some kinds of IPs? --> n/m, just needs the full URL http://wifitest.adafruit.com/testwifi/index.html
I'm not able to follow what that code is doing right now, maybe some other time
@crimson ferry hmm it looks like you're supposed to use a particular URL within that host according to the examples. Do you think it's "new" that the front page doesn't say something? ```$ curl http://wifitest.adafruit.com/testwifi/index.html
This is a test of Adafruit WiFi!
If you can read this, its working :)
No, just me remembering wrong
https://web.archive.org/web/20190507081127/http://wifitest.adafruit.com/ In 2019 it already said 403 to the front page
haha: https://wifitest.adafruit.com/wifitest/ (note reversed words) says This is a test of the CC3000 module! If you can read this, its working 🙂
interesting
@crimson ferry ah I see you'd already updated yourself when I said that. glad you figured it out
interesting, wasn't aware of the alternate
Seems like it's not unreasonable for the "/" page to say something besides 403, so I sent an internal message to our web folks. Dunno whether they'll do anything, but the issue has been raised.
they often have bigger fish to fry
I can understand not having anything at the root, keeps out the riff-raff. I do that with some of my domains.
b = displayio.Bitmap(8, 8, 256) a = ulab.frombuffer(b) # create a ulab.array that views onto b, but see below a[y,x] = p b.dirty(x, y, x+1, y+1) # This call doesn't exist yet, because we've worked to prevent the need for itIf you omitted the call to the new dirty() function, or specified the wrong rectangle, the display might not be correct. If you're OK with adding a "displayio.Bitmap.dirty" method that users would have to call if they used this advanced feat...
It looks like numpy tracks whether the original storage was mutable or not, so e.g., if the origin is a bytes object it is immutable but if it's a bytearray then it's mutable:
>>> import numpy as np
>>> a = np.frombuffer(b'abcd', dtype=np.uint16)
>>> a
array([25185, 25699], dtype=uint16)
>>> a[0] = 1
ValueError: assignment destination is read-only
versus
>>> a = np.frombuffer(bytearray(b'abcd'), dtype=np.uint16)
>>> a[0] = 1
>>> a
array([ 1, 25699], dt...
I can help show you what is needed to accomplish the initial check for whether the storage is mutable,
I think you brought this up in the thread that I linked to above, and I don't know what the right solution is. On the one hand, numpy-compatibility is great, and I would advocate that. On the other hand, a microcontroller is simply not a computer, and we have to be careful about how we squander bytes both in flash, and RAM. If you judge compatibility to be important, then I am OK wit...
$ ./micropython/ports/unix/micropython
MicroPython v1.14-120-g42cf77f48 on 2021-03-20; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> from ulab import numpy as np
>>> a = np.frombuffer('ulab', dtype=np.uint16)
>>> a[0] = 0x5555
Segmentation fault
ow, I didn't realize it would do that (ulab master branch + micropython unix port)
Is anyone else still seeing Adafruit CircuitPython 6.2.0-beta.4 on 2021-03-18; Adafruit Feather RP2040 with rp2040 disappearing after reset?
...and is there a better procedure to get it back than the Raspberry Pi org PICO flash nuke UF2?
@tannewt did not find any significant issue, there are for sure different methods to verify the arguments. As discussed I verify three module in shared bindings. For me, we can keep as a reference and move-on.
BUSIO
I2C
| Enum/Allowed Args | FUN_OBJ_X | VAR_BETWEEN | FUN_OBJ_KW | |
|---|---|---|---|---|
| Make New | X | |||
| d... |
...I have a very strange Requests bug that only manifests on the Feather RP2040 (some primitive behaves different? timing? other?) But I want to make sure the flash is stable to rule that out as an issue.
hey @tulip sleet can the bin generated for circuitpython be loaded into memory through DAP and be fine or is it better to just drop the uf2 via usb?
i'm developing my workflow for burning bootloaders and loading circuit python onto a lot of boards in a pretty fast go, and want to know if I can just DAP it into memory or if I need to individually drop circuitpython on them via USB
You could load the .bin with DAP; we do that kind of thing at the factory, though we often don't load CircuitPython on the boards, but instead some Arduino test program. There's nothing special about using the .UF2 bootloader.
oh gotcha, i'm wondering if it's worth while to do or just let the end user do it.
I don't really have plans to add arduino support for my boards because it's just cumbersome
one day maybe
the tester loads a test program; the human checks the test output, and then that is it
i'm going to eventually need to make a more robust test jig
On the Qt Py, board.NEOPIXEL_POWER cannot be controlled, by, say, doing digitalio.DigitalInOut(board.NEOPIXEL_POWER). The pin is always in use, because it is set to high in board.c and also set to never reset. But if the never_reset is removed, then the pin does get reset, and the status NeoPixel goes out. So it needs to be special-cased in some way.
Closing... code formatting using Uncrustify for c and Black for python implemented in #4362.
@jepler It seems to me that we have somewhat diverged from the original issue, so I opened a dedicated one here: https://github.com/v923z/micropython-ulab/issues/350
@caternuson Can you measure the frequency and duty cycles of both clocks? They both look like they are more like 95kHz than 100kHz and the Pico seems to spend more time high than low. Is the pull up story the same for both including any s/w enabled pull-ups in the respective processors?
Perhaps it's worth a look in the analogue world to see what's going on.
@lone axle let me know if you are around, want to discuss about the readinto issue
Yep, I am and sure! we can do that.
So I am trying to test your solution, what imageload version did you use?
I think we have two different issues there 1) the unexpected argument with the current released version of CircuitPython. and 2) Certain images get loaded improperly and then look different than their raw image file.
1.4?
Yes at the beginning I was not sue, and I was not having the same error as you, so I guess is the imageload version, as I am using an old one
Yeah, version 0.14.0 is where the issue was introduced I think. That was the one I was using when I noticed the unexpected argument error.
ah ok, gotya, I am testing this right now, I will put my review in the comments. I was not sure about the version of the imageload, I guess with old version works ok
Yeah, that is true. The old versions did not try to use the new readinto() function so they do not have these issues.
@lone axle review is done, do I need to do anything else?
That is perfect. Thank you! I'll give it a little longer today to see if anyone else has any thoughts or ideas. But if we don't get anything else I'll go ahead and merge this tonight so that we hopefully avoid too many folks ending up with the combination of versions that leads to the crash.
drat, there's no UART pin left on the rp2040 feather once you use an rgbmatrix featherwing
(rx only)
I guess I can try implementing the PIO UART
😬
I've been running thestandard "color_wheel" demo on an STM32F11CE Blackpill with a 16 RGB neopixel ring.
I noticed that when it is running, the pattern occasionally "stalls" for varying amounts of time - sometimes over a full second.
I added a print out the time between cycles of the the color wheel and you can see in the sample below how it sometime takes a lot longer between cycles. I have no idea why...
I tried just running a counter that does not use neopixels and I did not see this be...
The frequency of the "stalls" is highly variable. They appear to occur more reliably after a RESET or power cycle and are less frequent after a soft reboot.
Sometimes it will run for minutes with out a stall and the length of the stall is also highly variable.
My apologies for the vagueness of this issue.... it is odd.
Thanks for the help guys.
So since the STM32F07 is a strict super set of the STM32F05, should load the circuitpython .bin file of the STM32F05 Feather directly into the F07 Discovery board, or just copy the canio module into the lib after loading the STM32F07 .bin file?
rx-only uart with pio: https://gist.github.com/c172ba263b6596ded7ead4e8cd4da805
@Shubhankargo I'm not sure I understand what you mean. You should not use the Feather binary since it will have totally different pin definitions and oscillator settings. CanIO is a native module and does not have a .mpy file in the libraries folder of the filesystem, so I'm not sure what you mean there either.
If you want to use CAN on the F407 Discovery now that support has been merged, you should visit the s3 lin...
I was just playing some audio on a Feather nRF52840 and changed the code from stereo to mono and I could still see the audio was active on the right_channel. I could see on the serial console that it was doing Auto-reload but I verified code.py had actually changed. I did a microcontroller.reset() and then it was actually using the pins I defined. I'm just watching audio on LEDs so not sure if samples will then play on both channels but there was certainly activity on right_channel when...
BTW the PWM does not continue after a sample is playing resulting in clicks. I think this differs to the RP2040 implementation which carries on PWMing at quiescent_value. Is that a bug? I noticed it today on 6.1.0 and wayback when writing and playing Adafruit Learn: Quick Draw Duo. You can hear the clicks in the video as thuds at the end of the exaggerated richochet.
Related to https://github.com/adafruit/Adafruit_CircuitPython_ImageLoad/issues/47
An incorrect mask was being used when extracting 4-bit data from a file.
This updates the bitmask for 4-bit colors, to allow proper color loading of 4-bit bitmaps.
Looks great. You beat me to it!
@jepler beat me to it. Thanks Jeff!
Would be more obvious if written as 0x0f.
@mental nexus Are you planning to make a Cartesian plane widget, if not I would like to work on it
By Cartesian plane, that means like an x,y graph? I don’t have plans but it would be a great addition. Go for it! I saw some plotting code recently in these chats, maybe Arduino. If I run across it I’ll try to point you to the link if it might be helpful. But go for it!
I tested this successfully with a Feather RP2040 and the imageload simpletest script. Confirmed this does resolve the issue.
Yes, I was looking at Microplot, even do a PR, just checking with you, do not want that we work in the same thing 🙂 Thanks
I replicated your issue when writing into a transposed bitmap. I get strange behavior that depends upon the bitmap size. I’ll dig into this over the next couple of days.
Mainly I need to build my debugging skills on the CP core side and this is a good trial with watching the dirty rectangle updates.
Excited to see you stepping up to look into this @kmatch98 -- thanks in advance!
.. implemented only on raspberrypi, where it's easiest. If this is considered useful enough, we can potentially implement it on at least SOME other ports. However, each port is a bit different so for now I just made them ignore the frequency= constructor parameter and return 1_000_000 for the frequency property.
This is useful to me because using a frequency of 1000 lets me track the length of WWWB symbols, which are from 200ms to 800ms long.
Crud. TIL that the PyGame library doesn't support Apple's M1 processor yet.
😮
YES! Just made the Feather M4 feather light up when I push a button. I'm proud of myself ^_^ This it my first CircuitPython experience!
nice job! 🙂
blinky type projects are greatly undervalued for the impact they have 🙂
Time to hook up a speaker for a tone!
Great stuff @nocturne monolith! Today the LED, tomorrow - the world! 🙂
MUAHAHAHAHA
Now I'm concerned just what tone you're planning on emitting! lol
+1 on changing PulseIn frequency.
Actually, I hooked up the button to a keyboard. Small steps!
and also fix typo on qtpy2040
One action has been stuck in "upload artifacts" for 4 hours. Gonna merge without green.
This looks neat!
I wonder whether we'll want to place it in its own separate module, like we did with audiomp3.
Good find on space savings :)
Why don't we make this 0 by default? I don't think the re1_5_dumpcode() serves any purpose for the normal user.
I wonder whether we'll want to place it in its own separate module, like we did with audiomp3.
Isn't it too simple for a module of its own? MP3Decoder (including mp3dec) has 2470 bytes of code, Music only 546
When the MX25R1635F flash IC is connected to nRF52840 over quad-SPI bus - the CircuitPython does not boot.
Primary reason for that is incorrect 'quad_enable_bit_mask' definition used in current 'devices.h'
This is an excerpt from the datasheet:

For compatibility reasons with all the family of the MX25R1635F IC's and with all the modes of operation it is wort...
Thank you! I don't have the hardware to verify, but I also noticed these changes bring things in line with the above MX25R6435F part.
The two devices still have a different start_up_time_us, not sure if important. If CircuitPython is loaded from a uf2 bootloader, as is customary on Adafruit boards, it does not matter.
@tannewt looks like you may need to pick up this change for nvm.toml.
@jepler Thank you for the review and merge actions!
800 us of 'start_up_time_us' is good enough. It is specified as a minimum value in the datasheet:

I spent much of the weekend developing a project on the Feather RP2040 that uses RGBMatrix.
Occasionally (1 in 20?) times when I would write out code.py, the board would freeze (USB stopped, matrix scanning stopped). A hard reset cured it, and I never lost my CIRCUITPY contents.
@ladyada also saw this at least once while she was testing the code, but we decided at the time to brush it off. Unfortunately, it's real and it's still there.
@lone axle You up for pulling down a PR and seeing what the min-similarity-lines threshold would need to be to get it passing?
Yep I can do that.
@lone axle Then if you could PR the change to that PR, I'd really appreciate it.
If it will let you anyway.
Or push directly to the PR, whatever works.
If neither works, you can make a separate PR. Rerunning the Actions job on PRs seems to pick up changes to .pylintrc.
Excellent, thank you for that info
squeee .. I PR'd into pico-sdk and they accepted it
I added the line
CIRCUITPY_USB_MSC = 0
to the bottom of:
https://github.com/adafruit/circuitpython/blob/1be5ca7881a8aa8d32a783bc6a94994886463c30/ports/raspberrypi/boards/pimoroni_tiny2040/mpconfigboard.mkThis is what my mpconfigboard.mk board looks like
I get the same error when adding CIRCUITPY_USB_MSC = 0 in mpconfigboard.mk for Raspberry Pi Pi...
Closes #4417
I only compile-tested this for feather rp2040 with
diff --git a/ports/raspberrypi/boards/adafruit_feather_rp2040/mpconfigboard.mk b/ports/raspberrypi/boards/adafruit_feather_rp2040/mpconfigboard.mk
index f4106b94a..f891c3668 100644
--- a/ports/raspberrypi/boards/adafruit_feather_rp2040/mpconfigboard.mk
+++ b/ports/raspberrypi/boards/adafruit_feather_rp2040/mpconfigboard.mk
@@ -7,3 +7,5 @@ CHIP_VARIANT = RP2040
CHIP_FAMILY = rp2
INTERNAL_FLASH_FILESYSTEM =...
This looks good to me. alarm_enter_deep_sleep in particular looks like a good idea that should help with conflicts with the 5s USB delay period (see comment), I'll be bringing that over to the STM32 port implementation too. Had a couple notes/questions related to style and compatibility.
This will also need to be implemented for ESP32-S2, correct?
How does this handle interaction with the mandatory 5s delay (CIRCUITPY_USB_CONNECTED_SLEEP_DELAY) after first startup? That relies on the use of port_interrupt_after_ticks() to exit when it is ready to enter true deep sleep. It caused problems on my STM32 implementation if the sleep duration was less than five seconds - you implementation may catch it automatically but I figured I'd check in about it.
Would you like to attribute yourself as author here?
Does anyone have experience using SWO as a logging output in Jlink?
The current audiomixer has a level property but it applies to both channels equally. It would be useful for some cases to be able to play mono and stereo samples and give them a fine grain position between left and right.
Good afternoon all you wonderful folks!
<@&356864093652516868> CircuitPython Weekly meeting in a few minutes here. If you're participating with Hug Reports and Status Updates, please add yourself to the notes doc. https://docs.google.com/document/d/11uksHbpF2KT8sBC9Bov9XLtSgM62HXAHUKVxKhjr5cE/edit
CircuitPython Weekly for March 22nd, 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to participate...
We're finishing up an internal meeting - we'll be there soon!
@slender iron Reminder that you're on notes for the meeting today. I am still unsure of my power status. Seem stable? But 🤷♀️
yup, on it
Thanks!
@dhalbert this was my interpretation of what Limor was seeing, but it could be something else..
BRB
lurking
chonk++;
👍
I think that we should also guard the usb_msc... declarationsinsupervisor/usb.hwith#if CIRCUITPY_USB_MSC`.
And then there's the badge, a @CircuitPython-powered watch form factor design using a nRF52840 and a bunch of sensors, and sponsored by @digikey, @oshpark, @kicad_pcb & @sparkfun. https://t.co/pkqwfSTi8p
The 2021 virtual Open Hardware Summit is coming up in just 20 days! Owing to (gestures broadly), the 2020 OHS bags have just arrived – including the long-awaited badge, a double-PCB wearable! As well as one other, very special wearable... Let's take a look!
// https://2021.oshwa.org/tickets
// https://www.eventbrite.com/e/open-hardware-summit...
Inspired by the NYTimes Moveable Type installation, Contentful developer evangelist Shy Ruparel shares the low-powered E-Ink display that showcases the past Contentful blog posts using the AdaFruit MagTag built on a stream.
Soil Moisture Sensing With the Maker Pi Pico: This project demonstrates using two common hobbyist soil moisture sensors with the Cytron Maker Pi Pico and an optional small OLED screen. One sensor measures the resistance of the soil with a probe using a DC voltage, the other sensor measures the …
Found an interesting product the other day for a USB Mouse Jiggler to prevent your computer from going to sleep so I decided to make a DIY version of the mouse jiggler using the raspberry pi pico. thanks for the view!
○○○ LINKS ○○○
Mouse Jiggler ► https://amzn.to/2O2tCQo
raspberry pi pico ► https://amzn.to/3ebnWOH
github mouse jiggler ► http...
Fork of https://launchpad.net/pycoreutils. Contribute to jaraco/cmdix development by creating an account on GitHub.
🥚
I'm also trying to connect multiple displays (ST7735) to a pico and fail because the dc-pin is checked if it is in use. I don't understand the rational behind that: as long as the CS pin does not select the device, it should ignore everything anyhow. So is it really necessary to check for dc-pin usage at all?
This example hangs the board after a few seconds if AUDIO_DAUGHTERBOARD = True is changed to AUDIO_DAUGHTERBOARD = False to do local wave audio:
https://github.com/kevinjwalters/circuitpython-examples/blob/master/pico/larson-scanner.py
https://github.com/kevinjwalters/circuitpython-examples/tree/master/audio
Serial console dies, CIRCUITPY no longer works, PWM pins are left PWMing.
committee? maybe
Committee I think. A few of the weblate contributors were talking with each other in the chat during my stream over the past weekend.
A big hug to the weblate GANG.
😊
Sorry for my "unreadable" comments ....
(on desk of ladyada last night)
it's a flat flex cable pinout for easily connecting displays
@still zephyr have you tried reading the I2C registers directly?
I wouldn't wait for the pico-sdk
1 cord = 3.6 cubic meters
And the Blue LED will be what?
Not yet, I was not aware I will look/dig into that this week,
oohhh wow 😮 🙂 Thanks
🙂 it's usually my preference
since you can use the datasheet as documentation for it
text only for now! sorry forgot to add it to the status area too
got ya
In order to facilitate better video making, I had an idea to modify my folding table by adding a custom video accessory clamp bar. In this video, I show the planning and construction and how I overcame some of the trickier build issues.
Support Me and my channel on Patreon
https://www.patreon.com/makermelissa
*******...
@blissful pollen audomixer for rp2040 would be good
it uses assembly that the cortex m0 doesn't have so it'd need a generic C implementation as an option
Sure i'll take a look at that
We tried to turn it on but it uses ARM instructions not available on the Cortex M0. So, we'll need a generic C implementation that we can use when the instructions aren't available.
Sorry -- I have to leave early -- have a great week 👋
@blissful pollen picking up and finishing pending PRs would be awesome too
Thanks @lone axle 🙂
You mean ones that are now pretty old/potentially abandoned? (though I have to poke a couple library ones I have)
yup, the old core ones
I think the one to switch to different python files to run is pretty close
@thorny jay are you text only still?
I'll try my mic.
kk
@idle owl Yes it helps, thank you very much.
@timber mango Thank you for contributing and be in your first CP meeting 🙂
If you have any further questions, feel free to ping me. But I think you're on the right track, and any issues can be handled in review.
One of the ways we've attempted to alleviate this issue with pin names in some of the libraries to allow keyword arguments for uses to add to the initialize if they want to customize the pins that are used (which is needed in the case if pin names are different). A more general "board-level" solution would be really cool though.
Thanks again I will
You're entirely welcome!
@still zephyr it was a pleasure to join the meeting.
@idle owl thanks for the clarification.
If you guys want to discuss further the PR just ping me.
You're welcome! Thank you for the contribution!
https://learn.adafruit.com/adafruit-feather/feather-specification doesn't seem to mention pin naming. Perhaps it should. But FeatherS2 has used otherwise-standard Feather "D"-names on different pins.
FeatherS2, e.g., microcontroller.pin.GPIO9 board.D11 board.IO9 board.SCL
(not the same physical pin location as D11 on other Feathers)
@slender iron quick question, since the M4 is pretty port specific worth splitting audio mixer into common-hal?
Thanks all!
@blissful pollen I don't think so because it'll work on any cortex with those instructions
@onyx hinge has some #if statements in the mp3 lib that you can use
okay that answers my next question if you knew where they'd be 🙂
Thank you!
np
please test with this change and let us know if it resolves the problem for you
This change resolves the problem for me.
Thanks.
Ok, maybe I start to understand the FeatherS2 issue: https://gist.github.com/dglaude/495f6faacc674222d9797fb87e08fcfe
So I believe those 5 Dx are wrong, they should match M4 things.
yup
D5 = org_board.IO33
D6 = org_board.IO38
D9 = org_board.IO1
D10 = org_board.IO3
D11 = org_board.IO7
So this should be changed (or at least checked in the code) and @atomic summit should fix that graphic too.
I think that we should also guard the
usb_msc...declarationsinsupervisor/usb.hwith#if CIRCUITPY_USB_MSC`.
Good idea, done. Please re-review @dhalbert
They are not wrong as there is no rule that states they need to match. Discussing this where you stared talking about it in my FeatherS2 thread now 🙂
Fixing the graphic is not an option as I ship printed cards with my boards and have shipped thousands.
where are we at with the RTC on rp2040? https://forums.adafruit.com/viewtopic.php?f=60&t=177035
Thanks! Tested that building Trinket M0 and Feather RP2040 don't fail when CIRCUITPY_USB_MSC = 0 is added to mpconfigboardk.mk.
Hypothesis #2: recvfrom_into() needs the port byte order switched. The TCP case works with recv_into() but not with recvfrom_into(). Swapping the port byte order in CircuitPython UDP server code between recv and send does work:
size, addr = s.recvfrom_into(buf)
print("Received", buf[:size], size, "bytes from", addr)
addr = (addr[0], htons(addr[1])) #test
size = s.sendto(buf[:size], addr)
print("Sent", buf[:size], size, "bytes to", addr)
On the wav playback problems on RP2040 / Pi Pico, I can reliably hang CircuitPython with some code I cited in: https://github.com/adafruit/circuitpython/issues/4208#issuecomment-804296887
This resolves an error in redrawing when using transform_xy with displayio.TileGrid.
The logic for displayio_tilegrid_get_refresh_areas did not consider the TileGrid's transform_xy value and the transform of dirty rectangles was not being performed.
Here is the result with version Adafruit CircuitPython 6.2.0-beta.4 on 2021-03-18; Adafruit PyPortal with samd51j20:

this might be a record for me:
@kevinjwalters I don't have this setup anymore. I could if it would help, but it looks like maybe a fix has been found.
@bablokb You almost always want pin in use checking because it catches misuses. This is a very special case where you want to share display busses. The easiest solution by far is to use a separate pins for the second DC and reset. Otherwise, we could check if another display bus objects are using the same reset and DC and ignore the duplication. It's not a priority for us though.
@dhalbert I tried your code (deep sleep for 10 secs). I found no problems with serial connection while in pretended deep sleep, that means serial line was kept connected and I could go into REPL by typing a key. I tested it on Windows 10 host.
Hi, thanks for adding this. Could you please remove TinyPICO-Compatible from the features? Here's a guide that has the values you can use: https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/adding-to-downloads.
We need to limit these because when we didn't the available options in the filters on circuitpython.org got out of control and wasn't very useful anymore. Thanks.
But is this really a problem? If someone is using this very low-level buffer utility, then it is expected that they would explicitly call refresh. I reckon, this is probably not for the faint of heart, and then the only question is, whether all functions in
circuitpythonshould be high-level, or is it OK to allow the more experienced users to directly tamper with the hardware. Perhaps, this would set some precedence, so I understand your reluctance to open a potential Pandora's box.
I'...
Ok, thanks for looking into this @jposada202020. I'll close this since it hasn't been an issue for many years.
This looks good to me. Code that calls transfer should already be able to handle failures. Thanks! Looks like it just needs a final merge.
Hi, thanks for adding this. Could you please remove TinyPICO-Compatible from the features? Here's a guide that has the values you can use: https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/adding-to-downloads.
We need to limit these because when we didn't the available options in the filters on circuitpython.org got out of control and wasn't very useful anymore. Thanks.
Oh yeah, sure! I actually didn't mean to leave that in the features list after ...
@hierophect I did not change anything around the 5s delay check, but I think true deep sleep may cause the delay because RTC is prescaled and port_get_raw_ticks() would return a wrong value. This may occur when your .py code try to enter true deep sleep too soon (<5secs) after wake up from the last sleep.
Maintaining tick value even when the prescaler is enabled is quite complicated...
Yes it is a superset but the original version is also used in main.c, so I leave both. I admit the name ".._2" is not so good.
Yes I think so. You have to set up timer here because the timer would otherwise be reset in the cleanup after py vm execution.
Has anybody else seen Feather RP2040 stop running CP after ~36 hours on time? Neopixel is off and heartbeat LED is off. Running Friday’s S3 uf2
@mental nexus thanks for that PR!
However, true deep sleep seems to not work with a lot of the alarm systems I use in fake deep sleep, is hard to log, and frequently disconnects my Jlink. The RTC also seems to retain problems across resets, so the chip also needs to be power cycled to get back up and running again, which further complicates things. I'd appreciate any other pairs of eyes on the problem.
I'm confused; is this problem now gone?
I'malso curious whether we should consider renaming the functionality of
common_hal_alarm_light_sleep_until_alarmsto simplycommon_hal_alarm_wait_until_alarms, since it doesn't really sleep any more than the circuitpython default, and try to fold more power saving intocommon_hal_alarm_light_sleep_until_alarms. STM32's STOP mode might be a good fit for this, as would the ESP32S2 light sleep feature.
The nRF52 sleep PR does have a true light sleep, so I think we could keep it. But ...
I can also hang the Pi Pico with code mentioned in https://github.com/adafruit/circuitpython/issues/4208#issuecomment-804296887
I tested it on Windows 10 host.
I saw this problem on Linux. I'll test on Windows 10. There are some possible outstanding issues with CDC USB on nRF.
I was glad to finally catch this bug. The end behavior was totally weird since it depended on how fast it was drawn, since the refresh timing seemed to matter on the final display result. It lets me know I eventually need to learn how refreshes get triggered, but that’s yet another rabbit hole.
I don't think so. I'd expect merging 1.15 in to be easier after 1.14 has already been. I suspect 1.14 merge will be much more difficult. We shouldn't merge 1.14 until we branch off for 6.2.0 though because it may lead to instability.
Though if 1.15 comes out before 6.2.0 is branched, I'm not sure it makes much difference if we start with 1.15.
Addresses UDP server issue https://github.com/adafruit/circuitpython/issues/4445 by changing the recvfrom_into() port number into network byte-order, so that sendto() sends to the correct client port.
Successful sequence:
CircuitPython socketpool UDP Server:
code.py output:
Connecting to Wifi
Self IP 192.168.6.198
Server ping 192.168.6.198 0.0 ms
Create UDP Server socket ('192.168.6.198', 5000)
CPython UDP Client:
Create UDP Client Socket
Sent 12 bytes
...
Sorry I missed the meeting this week. <feelsbad.gif>
It's been... a day. Add to it the first day of kids physically back in school in 1+ year. Will catch up on the YT replay
My application needs to monitor these time pulses relatively precisely (ms-level) while doing other things (redrawing a displayio screen). I need something running more predictably than a "forever loop" of python bytecode that also redraws a display.
Using exactly the approach you suggest (count time periods with polling plus monotonic_ns) I actually spent quite a bit of time believing I was dealing with interference from the power switching of the RGBMatrix display interfering with a wea...
I’m hoping to be settled enough with my work routine to really start at least lurking during the meetings.
Why do this in C at all? Can't Python do it? The RTTTL library is very similar but in Python: https://github.com/adafruit/Adafruit_CircuitPython_RTTTL/
The main difference is that adafruit_rtttl cannot play things in background while other Python code runs.
Perhaps there is a lower level API we need to add. I highly doubt we need to do any parsing in C though.
It would be nice to be able to implement AudioSample classes in Python, but I thought there was a conscious decision ...
This looks good to me. Code that calls transfer should already be able to handle failures. Thanks! Looks like it just needs a final merge.
I want to attach 12 (!) displays to a pico, using two SPI-busses. Although the pico is a pin-monster, this does not work out if I have a dedicated dc-pin for every display. (I'm building an advent Calendar with two picos and 24 displays in total).
"Catching misuse" is fine as long as the check is for real misuse and not for non-standard but valid usage. Since this is no priority on your side, I will see if I fork the library or switch to C.
I too have this issue since using circuit python on an RPI pico, and also a nucleo development board using the newer STLINK-V3 which also provides composite USB devices and an MSD for easy flashing.
I have been using Ubuntu 18.04, but I just upgraded to 20.04 hoping they may have fixed it. It has only been a day and no crashes (yet) but I have turned off auto mount, and I try to safely eject the drive before turning it off. (This seems to help).
Last night I discoved this in my dmesg, t...
Wouldn't it be better to accept a DigitalInOut object instead of a pin object, so you can use the same instance in both places to avoid the error?
We have a consultant helping us with Smoothie, and he has suggested this...
"the correct way to handle it is to report as a removable device, and generate an eject event rather than a disconnect
and we want to do that anyway because there's some really annoying W10 bugs related to disappearing MSC devices"
This won't help when the CP device is just turned off or tugged out of the port though, but maybe a control key in the REPL could tell it to do this which we can do before t...
I've not had any particular i2c issues but looking at #4082 the clock speed looked wrong. Here's a view from Ikalogic SQ25 of a (Maker) Pi Pico talking to a generic SSD1306-driven screen and using the change contrast command to get something to capture (at 25MHz).

This has the 10k pullups on SSD1306 and whatever the RP2040 might be doing.
I too...
@caternuson I captured a few traces talking to an SSD1306 and they look different to yours. I put in #4466 for it as the clock speed looks signficantly wrong...
I tried some 4 byte writes as I'm pretty sure I've read a discussion (perhaps with @Gadgetoid) about the special case bitbang code kicking in at <= X where X may equal 2.
The trace looks very different for 4 byte write. Here's first part. It's sped up a bit to 265kHz but it's still not the requested 400kHz.

Can displayio drive multiple physical screens as one displayio.Display?
@kevinjwalters yes currently any write <= 2 bytes will go through a bitbangio instance:
I've got an outstanding PR to change this to == 0 since rp2040 can handle 1 and 2 byte writes fine but will not do a 0-byte address-only write (used to check for the address ACK when probing the bus). I think this was the result of some misunderstanding or very ...
Did you finish this up? We can get it in when the defaulting, etc. is all squared away.
@kevinjwalters The 2 bytes-or-fewer writes are done using bitbangio and I would expect their timing to be approximate. The other off-timing may be due to clock divisor granularity.
FYI, my PyPortal (SAMD51 / M4) talking to its ADT7410 running 6.1.0 matches the two traces @caternuson put in the other ticket at 94.697 kHz.
Hi, we would like to add a new board (this one: https://github.com/watterott/senseBox-MCU) to circuitpython (our status: https://github.com/felixerdy/circuitpython/tree/main/ports/atmel-samd/boards/sensebox_mcu). The board is samd21 based and we are already able to run easy programms. The Board has 2 XBee Slots which can equipped with wifi, sd or lora-bees. One problem we are facing at the moment is, that all pins are not powered by default. The Board has the option to power each port individually (see: https://github.com/watterott/senseBox-MCU/blob/master/arduino/samd/variants/sensebox_mcu/variant.cpp#L199 and https://github.com/watterott/senseBox-MCU/blob/master/arduino/samd/libraries/senseBoxIO/src/senseBoxIO.h how it's done with arduino) When we try to power the xbee 2 ports with ```
xb2_pwr = DigitalInOut(board.XB2_PWR)
xb2_pwr.direction = Direction.OUTPUT
xb2_pwr.value = True
Regression tested with all supported combinations of CPython, CircuitPython ESP32SPI, and CircuitPython native (esp32s2) TCP and UDP clients and servers, see: https://github.com/anecdata/Socket
@jolly roost wait, you are trying to power a radio module from a gpio pin?
@jolly roost you are aware that those pins can supply like 4mA of current only?
the modules are powered with 3.3V directly from the regulator not from the gpio pins. But its possible to deactivate the whole power circuit for each interface (UART, I2C, XBee with SPI etc.) individually. In arduino it works easy and its also possible to power up the i2c power circuit on the board an read for example data from an bme680. But when I try the same with the XBee 2 PWR the board crashes
what does it give as the reason for entering the safe mode?
You are in safe mode: something unanticipated happened. The microcontroller's power dipped. Make sure your power supply provides enough power for the whole circuit and press reset (after ejecting CIRCUITPY).
Works fine if all screens display the same content. I tried to create multiple displayio.Display, but failed because I could not create the necessary bus (displayio.FourWire).
@jolly roost learn.adafruit.com/how-to-add-a-new-board-to-circuitpython that safe mode is due to the brown out detector firing
you may have in-rush current when enabling a portion of the board that dips the main supply
ok btw you can use them as 'raw' RGB tft displays, you dont get displayio but you can always draw to em.
https://github.com/adafruit/Adafruit_CircuitPython_RGB_Display
bigger caps \o/
the microcontroller may have different brownout settings, but those aren't exposed in CircuitPython. A custom build apepars able to change them. ```#ifndef SAMD21_BOD33_LEVEL
// Set brownout detection to ~2.7V. Default from factory is 1.7V,
// which is too low for proper operation of external SPI flash chips
// (they are 2.7-3.6V).
#define SAMD21_BOD33_LEVEL (39)
and incidentally there you have our motivation for the value we use
@jolly roost
if your board has no flash chip then it may be safe to change the brown-out level see 37.10.3 Brown-Out Detectors Characteristics of the datasheet https://community.atmel.com/sites/default/files/forum_attachments/SAM-D21-Family-Datasheet-DS40001882B.pdf
thank you for your help. I'll try to change the brown out detection level and try again
We do report as a removable device already because on Linux we get the eject command from the host and then report media isn't available. I don't know how that helps when a device is unplugged though.
Why do this in C at all? Can't Python do it? The RTTTL library is very similar but in Python: https://github.com/adafruit/Adafruit_CircuitPython_RTTTL/
The main difference is that
adafruit_rtttlcannot play things in background while other Python code runs.
Yup! True.
Perhaps there is a lower level API we need to add. I highly doubt we need to do any parsing in C though.
It would be nice to be able to implement AudioSample classes in Python, but I thought there...
Right now we can only playback RawSamples, WAV and MP3. It'd be nice to add a synthio module that can generate audio based on settings set from Python. For buffering changes, it could also take in MIDI commands and apply them over time.
The Teensy Audio library is a really neat Arduino library we can reference: https://github.com/PaulStoffregen/Audio
It has these synth modules:
- wavetable
- drum
- string
- sine
- sine_hires
- sine_fm
- waveform
- waveformMod
- pwm
- toneswe...
@dhalbert sorry Dan, I hadn't updated the original PR message since I fixed my issues. My original thinking was that the term "light sleep" might be better suited to more power saving tasks, since the ESP32S2 light sleep saves no power compared to time.sleep, and I thought the same would be true for STM32. But since Scott argued that we can still put in manual clock gating into other ports, I think our current situation is fine.
I wouldn't be opposed to nailing down some official guideli...
Ok, well I'm ok with this. Your need makes sense. I think that it'd be good to:
- Error in other ports if they get any other different value since they don't try to change.
- Switch
trigger_durationto cycles instead of microseconds as well. - Document the class as a whole in dealing with cycles, not microseconds.
Reading the docs here may help you understand what I mean: https://circuitpython.readthedocs.io/en/6.1.x/shared-bindings/pulseio/index.html#pulseio.PulseIn Updating from ...
Great! Thanks for fixing this!
I want to attach 12 (!) displays to a pico, using two SPI-busses. Although the pico is a pin-monster, this does not work out if I have a dedicated dc-pin for every display. (I'm building an advent Calendar with two picos and 24 displays in total).
We don't support 12 displays out of the box anyway. So, you'll need to compile it yourself regardless. Since you are doing that, you can comment out the pin check too: https://github.com/adafruit/circuitpython/blob/main/shared-bindings/displayi...
Do you need help with the ESP32-S2 implementation? My STM32 implementation will be compatible, but we'll need to make ESP32-S2 compatible before merging.
Is there a reason the original cannot use this expanded implementation? If they need to be separate, maybe it could be idle_woken_from_sleep, or something.
Ok, @jepler and @dhalbert, this is passing. Please take another look.
There could be an nrf-only include file that is conditionally included in the appropriate nrf-only files.
@hierophect If you could add this to ESP32-S2, that would be great. I started to do this to fix #4010, but got waylaid. I would not expect @jun2sak to need to do this. @jun2sak is using a weak definition to make this not nrf-only for now.
Thanks for resolving the issue I raised.
Also, I don't see the difference between a screen, and a DAC: both are peripheral devices, they just, well, display data in different ways. So, if you can pipe data into a DAC, or serial port, then why should you not be able to do the same with a display? I understand that the display requires extra functions, but that is not really a conceptual difference.
You can with
busio.SPI.displayiois meant to be higher level and also allow display sharing with the CircuitPython core f...
@slender iron as far as I could tell you also got all issues @tulip sleet raised resolved, but I was too cowardly to merge it with my approval.
🙂 I'm working on imx now
squee, much appreciate
kinda daunted about testing all of the boards though....
i was waylaid by a veterinary event; all done now
everything ok?
I have 1010/1020/1050/1060 evks, I can go through and test 'em all. @slender iron are you doing it in tinyuf2 or cp or both?
Gryphon had a abcess on her lip that opened up; we didn't know there was an abcess, and she was bleeding noticeably. She may or may not need dental work later. We though it was more serious.
she has been in rough shape for a couple of weeks
that's good news overall I think
yah
I remember you mentioning that
she is quite old
just cp. tinyuf2 isn't on my radar
I'd love to hand it off to you 🙂
I kinda feel like I should do the other external flash settings too. That way we'd be on nvm.toml completely
okay -- well, I am pretty sure that when you boot tinyuf2->cp, that it's tinyuf2's flash_config that is used even after it hands off
but I could be wrong, etc
@onyx hinge ya, that sounds right actually
but to keep in mind when testing!
because it's the bootrom that sets everything up
should we remove the flash settings from CP completely?
I guess that'd mess up teensy
I wonder if we want a separate repo for imx flash
then we pull it into cp and tinyuf2
could be?
it doesn't belong "in" nvm.toml, does it?
"nvm.jinja"
heck maybe somebody wants your rp2040 generator for their pico-sdk project
ya, that's a good question
nvm.toml could have the python script or a couple for different techniques
least common denomiter settings vs detect and change settings
I think I need to look at https://github.com/adafruit/circuitpython/issues/4431
before I switch away from rp2040
I need to think on the imx some more
i just rebuilt circuitpython and had to manually install cascadetoml with pip btw dont know if i should make it an issue or what but never had to do that before
the build process now needs that. We should probably put a check in a makefile for it.
yah maybe update this page saying you need to install cascadetoml with pip https://learn.adafruit.com/building-circuitpython/build-circuitpython idk tho
oh btw the digitzer works great on windows but acts super weird on mac, dont have linux to test but im guessing will be weird there too. it works but sometimes
it's been very difficult or impossible to make an HID definition for certain devices that works across the three major platforms. Same has been true for Gamepad
that must be super annoying 😦
yah, frustrating ... OK, I have updated the Learn Guide to tell you to do pip3 install -r requirements-dev.txt.
you added it to before the builder has git cloned the repo isn't requirements-dev.txt in the repo?
oops, yes :/
haha no problem glad i could help and not just ask questions 🙂
Ok, I have the first piece of this finished. I decided to put the JSON file building code into the circuitpython-build-tools when the bundle is built and it will be attached as an asset with the bundle.
One of the complication I was realizing that we would run into by having the files on Amazon S3 and the web files on GitHub would be CORS or Cross Origin Resource Sharing policies. This is a mechanism by the browser to help reduce Cross Site Scripting vulnerabilities and if we had the files...
It seems like the imx boards are going to be the next exciting area for CP. Is there a suggested demo board to use to get started on the RT1011 while we wait for the Metro M7 that’s coming soon? Or if coming soon is really soon, soon, then is it best to wait a bit for that?
@tulip sleet can I chat with you real quick about a sleep thing?
sure, in a minute
np, whenever you have a bit
@ionic elk ok, in Amelia
This is great, and should work well for learn.adafruit.com as well.
Are you expecting the first bundle with the new JSON file to be built tonight?
Ya, we're working to polish it up for release. the 1010 EVK is good because it has swd: https://www.digikey.com/short/pz34z0v5
huh, that's weird. I guess the system doesn't really have any way of noticing duplicate entries. ``` { MP_OBJ_NEW_QSTR(MP_QSTR_D0), MP_ROM_PTR(&pin_GPIO_09) },
{ MP_OBJ_NEW_QSTR(MP_QSTR_RX), MP_ROM_PTR(&pin_GPIO_09) },
...
// UART
{ MP_OBJ_NEW_QSTR(MP_QSTR_RX), MP_ROM_PTR(&pin_GPIO_09) },
@gilded cradle re Justin's question ^^: circuitpython-build-tools will need a new release for your changes to be pushed to PyPI, and subsequently used when the bundle release happens tonight.

